Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 31 Mar 2023 09:30:12 +0200
From:   Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To:     Dennis Zhou <dennis@kernel.org>
Cc:     "Rafael J . Wysocki" <rafael@kernel.org>,
        Ulf Hansson <ulf.hansson@linaro.org>,
        linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mmc: allow mmc to block wait_for_device_probe()
Message-ID: <ZCaMBEDaISmajPRj@kroah.com>
References: <20230328223740.69446-1-dennis@kernel.org>
 <ZCPEcxueuGUaRNOP@kroah.com>
 <ZCSfwBiponFGFXlN@snowbird>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZCSfwBiponFGFXlN@snowbird>
Precedence: bulk

On Wed, Mar 29, 2023 at 01:29:52PM -0700, Dennis Zhou wrote:
> 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

Looks much better, except for the kernel test bot issues...

thanks,

greg k-h