Greg KH (greg@xxxxxxxxx) wrote: > On Thu, Jan 12, 2012 at 01:15:35PM -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. > > > > Change-Id: Icdd06cf3ced555dcd9994cfcc9478a9071a802f1 > > What is this field for? It makes no sense for a kernel patch > submission. > > > Signed-off-by: Paul Taysom <taysom@xxxxxxxxxxxx> > > Downstream-bug-report: http://crosbug.com/24165 > > Is that a regular field that we now use? > Hi Greg, What is the conventional way of doing this? There is a lot of good data in the bug report which might be useful to reviewers. We couldn't find a de-facto way of referencing the downstream bug database so we just made up a new field. Sorry. We'll use the correct field name next time. So what is the correct field name? Regards, Mandeep > And shouldn't this go to the stable kernel releases as well? > > Third time's a charm? > > 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
