On Fri, May 12, 2006 at 10:55:20PM +0100, Russell King wrote: > On Fri, May 12, 2006 at 10:43:54PM +0100, Al Viro wrote: > > On Fri, May 12, 2006 at 09:34:16PM +0100, Russell King wrote: > > > On Fri, May 12, 2006 at 10:36:57AM -0700, Linus Torvalds wrote: > > > > Yes. We could just revert that commit, but it seems correct, and I'd > > > > really like for somebody to understand _why_ that commit matters at all. I > > > > certainly don't see the overlap here.. > > > > > > Reverting the commit breaks MMC/SD in a very real way, and the fix > > > is plainly correct and is actually the only possible fix that can be > > > applied. > > > > Bullshit. Could you explain what generic code dereferences ->driverfs_dev > > after del_gendisk()? If you see such beast, please tell; _that_ is the > > real bug. > > Al, I think you're going to eat your own bull on this one. > > You'll find that in the reply I've just sent to Linus - two oopen > reported by two different people since the mount/umount hotplug > events got re-merged. > > The problem case is: > > - insert card > - mount filesystem > - remove card > - umount filesystem <bang, oops> > > The generic code is block_uevent(), which is called at umount time > _after_ the gendisk has been deleted (which happens when the card has > been removed.) > > Basically, you can't umount a destroyed block device without oopsing. So block_uevent() is bogus; great, we've located the real bug. The real question: what uses these events and what can userland _do_ when it gets something about a device that had been gone for a month? Secondary question: who had resurrected that crap? I distinctly remember killing it off... - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
