lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6caa4c33-583c-65ff-6303-296f1c87a762@linux.intel.com>
Date:   Wed, 4 May 2022 21:49:12 +0530
From:   "Kumar, M Chetan" <m.chetan.kumar@...ux.intel.com>
To:     Loic Poulain <loic.poulain@...aro.org>
Cc:     netdev@...r.kernel.org, kuba@...nel.org, davem@...emloft.net,
        johannes@...solutions.net, ryazanov.s.a@...il.com,
        krishna.c.sudi@...el.com, m.chetan.kumar@...el.com,
        linuxwwan@...el.com
Subject: Re: [PATCH] net: wwan: fix port open

Hi Loic,

On 5/4/2022 8:14 PM, Loic Poulain wrote:
> Hi Chetan,
> 
> On Wed, 4 May 2022 at 16:09, M Chetan Kumar
> <m.chetan.kumar@...ux.intel.com> wrote:
>>
>> Wwan device registered port can be opened as many number of times.
>> The first port open() call binds dev file to driver wwan port device
>> and subsequent open() call references to same wwan port instance.
>>
>> When dev file is opened multiple times, all contexts still refers to
>> same instance of wwan port. So in tx path, the received data will be
>> fwd to wwan device but in rx path the wwan port has a single rx queue.
>> Depending on which context goes for early read() the rx data gets
>> dispatched to it.
>>
>> Since the wwan port is not handling dispatching of rx data to right
>> context restrict wwan port open to single context.
> 
> The reason for this behavior comes from:
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2313348.html
> 
> Especially:
> ---
> "I told you before, do not try to keep a device node from being opened
> multiple times, as it will always fail (think about passing file
> handles around between programs...) If userspace wants to do this, it
> will do it.  If your driver can't handle that, that's fine, userspace
> will learn not to do that. But the kernel can not prevent this from
> happening."
> ---
> 
> So maybe a user-side solution would be more appropriate, /var/lock/ ?

OK. So this means user space application like modem manager should lock the wwan 
port so that wwan port will not be available for other programs ?

Regards,
Chetan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ