On 15.11.2014 00:47, Chris Mason wrote: > > Ok, I think this is related to the new fair read/writer lock > implementation in the generic kernel code. btrfs_clear_path_blocking() > will end up taking locks outside of the strict locking order the rest > of Btrfs uses. This used to be fine because we hold the blocking lock > while we do it, but with the new queued locks we're running into > trouble. We hit a similar bug earlier and I convinced myself the > problem was only with btrfs_next_leaf and our trylock. But it's a > bigger problem than I realized. > > So for now I've changed btrfs_clear_path_blocking to honor the rules > and fixed up our trylock to make it faster. > > I'm letting a test run on this patch over the weekend, since I don't > want any surprises with your backup farm. > > -chris
Hi Chris Here comes a short feedback.... I applied your patch (Fix lockups from btrfs_clear_path_blocking) yesterday and my system survived this night! ;-) Thank you for the quick fix. Regards Patrick -- Patrick Schmid <sch...@phys.ethz.ch> support: +41 44 633 2668 IT Services Group, HPT H 8 voice: +41 44 633 3997 Departement Physik, ETH Zurich CH-8093 Zurich, Switzerland -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
