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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
