On Fri, Apr 07, 2023 at 01:24:15AM -0700, Dennis Zhou wrote: > On Mon, Apr 03, 2023 at 11:50:41AM +0200, Ulf Hansson wrote: > > On Fri, 31 Mar 2023 at 20:23, Dennis Zhou <dennis@xxxxxxxxxx> wrote: > > > > > > 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@xxxxxxxxxx> 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? > > > > Yes, I can help to test. Allow me a few days to see what I can do. > > > > Note that, just having one eMMC and one SD card should work too. It > > doesn't have to be multiple eMMCs. > > > > > > > > > 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. > > > > You certainly have a point! > > > > This should work when the mmc blk module is built-in. Even if that > > doesn't solve the entire problem, it should be a step in the right > > direction. > > > > I will give it some more thinking and run some tests at my side, then > > I will get back to you again. > > > > Hi Ulf, is there an update on testing with this patch? > Ping. Thanks, Dennis
