On Thu, Jan 12, 2012 at 11:57:42AM -0800, Paul Taysom wrote: > From: Paul Taysom <taysom@xxxxxxxxxx> > > A USB stick with a ext file system on it, would occasionally crash > when the stick was pulled. > > The problem was a timer was being set on the Backing Device Interface, > bdi, after the USB device had been removed and the bdi had been > unregistered. The bdi would then be later reinitialized by zeroing > the timer without removing from the timer from the timer queue. > This would eventually result in a kernel crash (NULL ptr dereference). > > When the bdi is unregistered, the dev field is set to NULL. This > indication is used by bdi_unregister to only unregister the device > once. > > Fix: When the backing device is invalidated, the mapping backing_dev_info > should be redirected to the default_backing_dev_info. > > Created 3 USB sticks with ext2, ext4 and one with both apple and DOS > file systems on it. Inserted and removed USB sticks many times in random > order. With out the bug fix, the kernel would soon crash. With the fix, > it did not. Ran on both stumpy and amd64-generic. > > Signed-off-by: Paul Taysom <taysom@xxxxxxxxxxxx> > Downstream-bug-report: http://crosbug.com/24165 > Cc: Mandeep Baines <msb@xxxxxxxxxxxx> > Cc: Greg KH <greg@xxxxxxxxx> > Cc: Jens Axboe <axboe@xxxxxxxxx> > Cc: Theodore Tso <tytso@xxxxxxxxxx> > Cc: Andrew Morton <akpm@xxxxxxxxxx> > Cc: <linux-usb@xxxxxxxxxxxxxxx> > Cc: <linux-kernel@xxxxxxxxxxxxxxx> > Cc: Alexander Viro <viro@xxxxxxxxxxxxxxxxxx> > Cc: <linux-fsdevel@xxxxxxxxxxxxxxx> > --- > fs/block_dev.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/fs/block_dev.c b/fs/block_dev.c > index afe74dd..9f9b617 100644 > --- a/fs/block_dev.c > +++ b/fs/block_dev.c > @@ -1,4 +1,4 @@ > -/* > +nvalid/* > * linux/fs/block_dev.c > * > * Copyright (C) 1991, 1992 Linus Torvalds Minor nit, I don't think you ment the first line of the file to be changed this way.... greg k-h -- 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
