On Wed, Mar 29, 2023 at 06:54:11AM +0200, Greg Kroah-Hartman wrote: > On Tue, Mar 28, 2023 at 03:37:40PM -0700, Dennis Zhou wrote: > > I've been hitting a failed data device lookup when using dm-verity and a > > root device on an emmc partition. This is because there is a race where > > dm-verity is looking for a data device, but the partitions on the emmc > > device haven't been probed yet. > > > > Initially I looked at solving this by changing devt_from_devname() to > > look for partitions, but it seems there is legacy reasons and issues due > > to dm. > > > > MMC uses 2 levels of probing. The first to handle initializing the > > host and the second to iterate attached devices. The second is done by > > a workqueue item. However, this paradigm makes wait_for_device_probe() > > useless as a barrier for when we can assume attached devices have been > > probed. > > > > This patch fixes this by exposing 2 methods inc/dec_probe_count() to > > allow device drivers that do asynchronous probing to delay waiters on > > wait_for_device_probe() so that when they are released, they can assume > > attached devices have been probed. > Thanks for the quick reply. > Please no. For 2 reasons: > - the api names you picked here do not make much sense from a global > namespace standpoint. Always try to do "noun/verb" as well, so if > we really wanted to do this it would be "driver_probe_incrememt()" > or something like that. Yeah that is a bit of a blunder on my part... > - drivers and subsystems should not be messing around with the probe > count as it's a hack in the first place to get around other issues. > Please let's not make it worse and make a formal api for it and allow > anyone to mess with it. > That's fair. > Why can't you just use normal deferred probing for this? > I'm not familiar with why mmc is written the way it is, but probing creates a notion of the host whereas the devices attached are probed later via a work item. Examining it a bit closer, inlining the first discovery call avoids all of this mess. I sent that out just now in [1]. Hopefully that'll be fine. [1] https://lore.kernel.org/lkml/20230329202148.71107-1-dennis@xxxxxxxxxx/T/#u > thanks, > > greg k-h Thanks, Dennis
