Re: [PATCH] btrfs: fix refcount_t usage when deleting btrfs_delayed_nodes

2017-12-22 Thread Liu Bo
On Fri, Dec 15, 2017 at 11:58:27AM -0800, Chris Mason wrote: > refcounts have a generic implementation and an asm optimized one. The > generic version has extra debugging to make sure that once a refcount > goes to zero, refcount_inc won't increase it. > > The btrfs delayed inode code wasn't

Re: [PATCH] btrfs: fix refcount_t usage when deleting btrfs_delayed_nodes

2017-12-21 Thread Liu Bo
On Sat, Dec 16, 2017 at 08:42:51AM +0200, Nikolay Borisov wrote: > > > On 15.12.2017 21:58, Chris Mason wrote: > > refcounts have a generic implementation and an asm optimized one. The > > generic version has extra debugging to make sure that once a refcount > > goes to zero, refcount_inc won't

Re: [PATCH] btrfs: fix refcount_t usage when deleting btrfs_delayed_nodes

2017-12-15 Thread Nikolay Borisov
On 15.12.2017 21:58, Chris Mason wrote: > refcounts have a generic implementation and an asm optimized one. The > generic version has extra debugging to make sure that once a refcount > goes to zero, refcount_inc won't increase it. I guess you meant to say

[PATCH] btrfs: fix refcount_t usage when deleting btrfs_delayed_nodes

2017-12-15 Thread Chris Mason
refcounts have a generic implementation and an asm optimized one. The generic version has extra debugging to make sure that once a refcount goes to zero, refcount_inc won't increase it. The btrfs delayed inode code wasn't expecting this, and we're tripping over the warnings when the generic