linux-kernel - Please revert 5b479c91da90eef605f851508744bfe8269591a0 (md partition rescan)

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-next>] [day] [month] [year] [list]

Message-ID: <17986.26930.952993.510918@notabene.brown>
Date:	Thu, 10 May 2007 10:37:06 +1000
From:	Neil Brown <neilb@...e.de>
To:	torvalds@...ux-foundation.org
Cc:	David Greaves <david@...eaves.com>,
	Doug Ledford <dledford@...hat.com>
Subject: Please revert 5b479c91da90eef605f851508744bfe8269591a0 (md partition rescan)

Hi Linus,
 Could you please revert

    5b479c91da90eef605f851508744bfe8269591a0

It causes an oops when auto-detecting raid arrays, and it doesn't seem
easy to fix.
The array may not be 'open' when do_md_run is called, so bdev->bd_disk
might be NULL, so bd_set_size can oops.
I cannot really open the array (blkdev_get) at this point as I
deadlock on mddev->reconfig_mutex.
I could simply guard against bdev->bd_disk being NULL, but that is too
ugly as sometimes the partitions would be found, and sometimes not.

This whole approach of opening an md device before it has been
assembled just seems to get more and more painful.  I think I'm going
to have to come up with something clever to provide both backward
comparability with usage expectation, and sane integration into the
rest of the kernel.
Maybe if you open before the array is assembled you get a completely
different bdev somehow, and on array assembly, a new bdev, or gendisk
or something, gets swapped in so the next open finds it....

Anyway, if that patch can go I'd appreciate it.

Thanks,
NeilBrown
-
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/