On Thu, Sep 26, 2013 at 10:47:02AM -0700, Christoph Hellwig wrote: > On Thu, Sep 26, 2013 at 08:43:51AM +1000, Dave Chinner wrote: > > You're just papering over the larger problem, in that the writeback > > work is running concurrently with the bdi_unregister() function that > > is tearing the bdi down. You should try to fix the underlying race > > condition, as documented in bdi_destroy. > > The problem is even worse than that, and it's the lack of a proper > refcounting on the bdi as seen by gems like bdi_prune_sb and the moving > of writeback requests in bdi_destroy. The right fix is to dynamically > allocate the bdi (or at least the bdi_writeback), and make sure that we > keep it around as long as a filesystem and thus the writeback code > refers to. Then a block device going away can just set a flag to stop > writeback from trying instead of having the bdi ripped out underneath > it which is guaranteed to fail and historically has failed in a large > number of misterious ways. Yup, be nice to see this rat-hole cleaned up properly, especially those silly "pull disk, unplug-runs-sync_fs, fs hangs trying to do IO to the disk that just got unplugged" bugs we get reported every so often. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
