linux-kernel - Re: [3.8-rc3 -> 3.8-rc4 regression] Re: [PATCH] module, async: async_synchronize

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]

Date:	Tue, 26 Nov 2013 13:53:08 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Josh Hunt <joshhunt00@...il.com>
Cc:	Tejun Heo <tj@...nel.org>, Jonathan Nieder <jrnieder@...il.com>,
	Ming Lei <ming.lei@...onical.com>,
	Alex Riesen <raa.lkml@...il.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Jens Axboe <axboe@...nel.dk>,
	USB list <linux-usb@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [3.8-rc3 -> 3.8-rc4 regression] Re: [PATCH] module, async:
 async_synchronize_full() on module init iff async is used

On Tue, Nov 26, 2013 at 1:29 PM, Josh Hunt <joshhunt00@...il.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/