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. -- 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
