linux-kernel - Re: [RFC] driver core: don't hold dev's parent lock when using async probe

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180524140021.GA214888@google.com>
Date:   Thu, 24 May 2018 22:00:21 +0800
From:   Martin Liu <liumartin@...gle.com>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     gregkh@...uxfoundation.org, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org, jenhaochen@...gle.com,
        liumartin@...gle.com
Subject: Re: [RFC] driver core: don't hold dev's parent lock when using async
 probe

On Tue, May 22, 2018 at 01:09:44PM -0400, Alan Stern wrote:
> On Tue, 22 May 2018, martin_liu wrote:
> 
> > not sure if we still need 'bf74ad5bc417 ("[PATCH] Hold the
> > device's parent's lock during probe and remove")' since it has
> > been there over 10 years. If we still need it and hard to fix it
> > , the simple way is to find a place not to allow USB subsystem
> > drivers to have async probe capability. Any suggestion is welcome.
> 
> I don't think the "allows_async_probing" attribute is the best way to 
> attack this.  Some other approach, like a special-purpose flag, might 
> be better.
> 
> Yes, USB still needs to have parent's locks held during probing.  
> Here's the reason.  A USB device can have multiple interfaces, each
> bound to its own driver.  A driver may sometimes need to issue a reset,
> but in USB there's no way to reset a single interface.  Only the entire
> device can be reset, and of course this affects all the interfaces.  
> Therefore a driver needs to acquire the device lock before it can issue
> a reset.
> 
> The problem is that the driver's thread may already hold the device
> lock.  During a normal probe sequence, for example, the interfaces get
> probed by the hub driver while it owns the device lock.  But for probes
> under other circumstances (for example, if the user writes to the
> driver's "bind" attribute in sysfs), the device lock might not be held.
> 
> A driver cannot tell these two cases apart.  The only way to make it
> work all the time is to have the caller _always_ hold the device lock
> while the driver is probed (or the removed, for that matter).
> 
> Alan Stern

Thanks for the reply and more detail about the backgroud. I'd like to
have a conclusion about it. Please kindly correct me if my understanding
is wrong. Regarding to the "special-purpose flag", do you mean we could
find a place in USB subsystem to have the flag set (not sure if it's
easy to find it). Driver core would be base on the flag to decide if we
need to hold the device's parent's lock.

Martin