From: Neil Brown <neilb@suse.de>
To: torvalds@linux-foundation.org
Date: Thu, 10 May 2007 10:37:06 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17986.26930.952993.510918@notabene.brown>
Cc: akpm@suse.de, linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: David Greaves <david@dgreaves.com>, Doug Ledford <dledford@redhat.com>
Subject: Please revert 5b479c91da90eef605f851508744bfe8269591a0 (md partition rescan)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1314
Lines: 33


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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/