Re: [PATCH] btrfs: check the right variable in btrfs_del_dir_entries_in_log

[David Sterba <dsterba@suse.cz>]

On Thu, Aug 20, 2020 at 11:29:11AM +0100, Filipe Manana wrote:
> On Wed, Aug 19, 2020 at 5:25 PM David Sterba <dsterba@suse.cz> wrote:
> >
> > On Mon, Aug 10, 2020 at 05:31:16PM -0400, Josef Bacik wrote:
> > > With my new locking code dbench is so much faster that I tripped over a
> > > transaction abort from ENOSPC.  This turned out to be because
> > > btrfs_del_dir_entries_in_log was checking for ret == -ENOSPC, but this
> > > function sets err on error, and returns err.  So instead of properly
> > > marking the inode as needing a full commit, we were returning -ENOSPC
> > > and aborting in __btrfs_unlink_inode.  Fix this by checking the proper
> > > variable so that we return the correct thing in the case of ENOSPC.
> > >
> > > Fixes: 4a500fd178c8 ("Btrfs: Metadata ENOSPC handling for tree log")
> > > Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> >
> > Added to misc-next, with updated changelog and comment explaining the
> > ENOENT.
> 
> Looking at the part added to the changelog:
> 
> "The ENOENT needs to be checked, because btrfs_lookup_dir_item() can
> return -ENOENT if the dir item isn't in the tree log (which would happen
> if we hadn't fsync'ed this guy).  We actually handle that case in
> __btrfs_unlink_inode, so it's an expected error to get back."
> 
> btrfs_lookup_dir_item() returns NULL when the dir item does not exist
> in the log.
> What can return -ENOENT is btrfs_lookup_dir_index_item(), which we
> call right after calling btrfs_lookup_dir_item().
> The fact that one returns NULL and the other returns -ENOENT is what
> made me question why the special handling for -ENOENT.
> 
> Other than the wrong function name, it looks good to me.

Function name updated in the patch, thanks.