linux-kernel - Re: [PATCH] mmc: allow mmc to block wait_for_device

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: <ZCSfwBiponFGFXlN@snowbird>
Date:   Wed, 29 Mar 2023 13:29:52 -0700
From:   Dennis Zhou <dennis@...nel.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     "Rafael J . Wysocki" <rafael@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mmc: allow mmc to block wait_for_device_probe()

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@kernel.org/T/#u

> thanks,
> 
> greg k-h

Thanks,
Dennis