On 12/20/16 1:00 PM, David Sterba wrote:
> On Tue, Dec 13, 2016 at 02:33:33PM -0500, Jeff Mahoney wrote:
>> In __btrfs_run_delayed_refs, the error path when run_delayed_extent_op
>> fails sets locked_ref->processing = 0 but doesn't re-increment
>> delayed_refs->num_heads_ready. As a result, we can
On Tue, Dec 13, 2016 at 02:33:33PM -0500, Jeff Mahoney wrote:
> In __btrfs_run_delayed_refs, the error path when run_delayed_extent_op
> fails sets locked_ref->processing = 0 but doesn't re-increment
> delayed_refs->num_heads_ready. As a result, we can end up triggering
> the WARN_ON in btrfs_sele
In __btrfs_run_delayed_refs, the error path when run_delayed_extent_op
fails sets locked_ref->processing = 0 but doesn't re-increment
delayed_refs->num_heads_ready. As a result, we can end up triggering
the WARN_ON in btrfs_select_ref_head since the head remains in the tree
with ->processing = 0 a
