From: Dennis Zhou <dennis@kernel.org>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mmc: inline the first mmc_scan() on mmc_start_host()
Date: Fri, 31 Mar 2023 11:23:12 -0700 [thread overview]
Message-ID: <ZCclEE6Qw3on7/eO@snowbird> (raw)
In-Reply-To: <CAPDyKFrcdJuyA9B-JDReacT2z1ircDoY4oTXZQ8AVFk6UEFYsw@mail.gmail.com>
Hi Ulf,
On Fri, Mar 31, 2023 at 02:43:10PM +0200, Ulf Hansson wrote:
> On Thu, 30 Mar 2023 at 01:48, Dennis Zhou <dennis@kernel.org> wrote:
> >
> > When using dm-verity with a data partition on an emmc device, dm-verity
> > races with the discovery of attached emmc devices. This is because mmc's
> > probing code sets up the host data structure then a work item is
> > scheduled to do discovery afterwards. To prevent this race on init,
> > let's inline the first call to detection, __mm_scan(), and let
> > subsequent detect calls be handled via the workqueue.
>
> In principle, I don't mind the changes in $subject patch, as long as
> it doesn't hurt the overall initialization/boot time. Especially, we
> may have more than one mmc-slot being used, so this needs to be well
> tested.
>
I unfortunately don't have a device with multiple mmcs available. Is
this something you could help me with?
> Although, more importantly, I fail to understand how this is going to
> solve the race condition. Any I/O request to an eMMC or SD requires
> the mmc block device driver to be up and running too, which is getting
> probed from a separate module/driver that's not part of mmc_rescan().
I believe the call chain is something like this:
__mmc_rescan()
mmc_rescan_try_freq()
mmc_attach_mmc()
mmc_add_card()
device_add()
bus_probe_device()
mmc_blk_probe()
The initial calling of this is the host probe. So effectively if there
is a card attached, we're inlining the device_add() call for the card
attached rather than waiting for the workqueue item to kick off.
dm is a part of late_initcall() while mmc is a module_init(), when built
in becoming a device_initcall(). So this solves a race via the initcall
chain. In the current state, device_initcall() finishes and we move onto
the late_initcall() phase. But now, dm is racing with the workqueue to
init the attached emmc device.
Thanks,
Dennis
>
> Kind regards
> Uffe
>
> >
> > Signed-off-by: Dennis Zhou <dennis@kernel.org>
> > ---
> > Sigh.. fix missing static declaration.
> >
> > drivers/mmc/core/core.c | 15 +++++++++++----
> > 1 file changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> > index 368f10405e13..fda7ee57dee3 100644
> > --- a/drivers/mmc/core/core.c
> > +++ b/drivers/mmc/core/core.c
> > @@ -2185,10 +2185,8 @@ int mmc_card_alternative_gpt_sector(struct mmc_card *card, sector_t *gpt_sector)
> > }
> > EXPORT_SYMBOL(mmc_card_alternative_gpt_sector);
> >
> > -void mmc_rescan(struct work_struct *work)
> > +static void __mmc_rescan(struct mmc_host *host)
> > {
> > - struct mmc_host *host =
> > - container_of(work, struct mmc_host, detect.work);
> > int i;
> >
> > if (host->rescan_disable)
> > @@ -2249,6 +2247,14 @@ void mmc_rescan(struct work_struct *work)
> > mmc_schedule_delayed_work(&host->detect, HZ);
> > }
> >
> > +void mmc_rescan(struct work_struct *work)
> > +{
> > + struct mmc_host *host =
> > + container_of(work, struct mmc_host, detect.work);
> > +
> > + __mmc_rescan(host);
> > +}
> > +
> > void mmc_start_host(struct mmc_host *host)
> > {
> > host->f_init = max(min(freqs[0], host->f_max), host->f_min);
> > @@ -2261,7 +2267,8 @@ void mmc_start_host(struct mmc_host *host)
> > }
> >
> > mmc_gpiod_request_cd_irq(host);
> > - _mmc_detect_change(host, 0, false);
> > + host->detect_change = 1;
> > + __mmc_rescan(host);
> > }
> >
> > void __mmc_stop_host(struct mmc_host *host)
> > --
> > 2.40.0
> >
next prev parent reply other threads:[~2023-03-31 18:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-29 20:21 [PATCH] mmc: inline the first mmc_scan() on mmc_start_host() Dennis Zhou
2023-03-29 22:56 ` kernel test robot
2023-03-29 23:36 ` kernel test robot
2023-03-29 23:48 ` [PATCH v2] " Dennis Zhou
2023-03-31 12:43 ` Ulf Hansson
2023-03-31 18:23 ` Dennis Zhou [this message]
2023-04-03 9:50 ` Ulf Hansson
2023-04-07 8:24 ` Dennis Zhou
2023-04-11 20:29 ` Dennis Zhou
2023-04-12 11:05 ` Ulf Hansson
2023-05-12 11:42 ` Ulf Hansson
2023-06-08 20:49 ` Dennis Zhou
2023-06-09 6:19 ` Greg KH
2023-06-09 7:16 ` Dennis Zhou
2023-06-09 8:53 ` Greg KH
2023-06-09 8:58 ` Linus Walleij
2023-06-12 14:55 ` Ulf Hansson
2023-06-27 17:20 ` Geert Uytterhoeven
2023-06-27 18:09 ` Biju Das
2023-06-30 11:26 ` Ulf Hansson
2023-06-30 13:34 ` Wolfram Sang
2023-06-30 22:09 ` Dennis Zhou
2023-06-13 14:25 ` [PATCH] " Ulf Hansson
2023-06-15 16:06 ` Dennis Zhou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZCclEE6Qw3on7/eO@snowbird \
--to=dennis@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.