On Fri, 16 Mar 2012, Theodore Tso wrote: > I thought another fix at the USB layer also went in that attempted to > fix this problem for 3.2, and so with two separate band-aid patches, I > think we had thought the problem had been addressed. I can't recall any USB fix like that. The only thing I remember is your change to ext4 (leaving the problem still present in ext3). > The real problem is that all of the patches which I've seen to date > are band-aids, in that we aren't properly sending a "device as > disappeared" notification to the file system layer, but instead we are > trying to keep enough of the pointers valid (while also freeing other > data structures), such that the file system can blindly write into a > partially dismantled block device, and hopefully not oops. That's not a band-aid approach; it's the way reference counting is _intended_ to work. The whole idea of refcounting is that instead of synchronizing every single operation, you keep data structures around so long as anyone might be using them. > Some have argued that my suggested approach of having an explicit > super_ops revoke() function, which tells the file system that the > block device is gone, etc., isn't necessary because this can be solved > in userspace somehow. Personally I think that's nuts, since we'll > continue to play whack-a-mole, but I haven't had time to work up > patches addressing this --- since this is really only a problem for > naive users who pull USB sticks without unmounting them first (and so > it never happens to me :-), and I've got a lot of other fish to > try..... I suspect Paul's patch is the right thing to do. It might even make the ext4 fix unnecessary, although I don't understand the details well enough to verify it. Maybe Paul can check -- the commit I'm referring to is 7c2e70879fc0949b4220ee61b7c4553f6976a94d (ext4: add ext4-specific kludge to avoid an oops after the disk disappears). Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
