Re: [3.8-rc3 -> 3.8-rc4 regression] Re: [PATCH] module, async:async_synchronize_full() on module init iff async is used

From: Linus Torvalds
Date: Tue Nov 26 2013 - 16:53:20 EST


On Tue, Nov 26, 2013 at 1:29 PM, Josh Hunt <joshhunt00@xxxxxxxxx> wrote:
>
> Both ahci and sata_svw call ata_host_activate(), which call
> ata_host_register() and async_schedule(async_port_probe, ap).

Well, with the modern logic ("only wait for async probing if the
module itself did async probing") the ahci and svw modules didn't
really change any behavior.

But other modules did. I wonder, for example, if people insmod the dm
module, and expect all devices to exist afterwards. Which the old
logic of "we always wait for all async code regardless of whether we
started it ourselves" would do, but the new logic does not.

Something similar might hit the (non-modular) md auto-detect ioctl.

So maybe we should just special-case those two issues, and say "let's
just wait for async requests here"

Something like the appended (whitespace-damaged) diff. Does that make
a difference to you guys? And if it does, can you check *which* of the
two async_synchronize_full() calls it is that matters for your cases?

Linus

--- duh, apply by hand --

diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 0704c523a76b..7e7a2f743b11 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -351,6 +351,7 @@ static int __init dm_init(void)
goto bad;
}

+ async_synchronize_full();
return 0;

bad:
diff --git a/drivers/md/md.c b/drivers/md/md.c
index b6b7a2866c9e..1d173dc662fc 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -8602,6 +8602,7 @@ static void autostart_arrays(int part)
i_scanned = 0;
i_passed = 0;

+ async_synchronize_full();
printk(KERN_INFO "md: Autodetecting RAID arrays.\n");

while (!list_empty(&all_detected_devices) && i_scanned < INT_MAX) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/