xfs
[Top] [All Lists]

Re: crash in xfs in current

To: Eric Sandeen <sandeen@xxxxxxxxxxx>, reinoudkoornstra@xxxxxxxxx
Subject: Re: crash in xfs in current
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Mon, 6 Jun 2016 23:27:17 -0700
Cc: xfs@xxxxxxxxxxx, wagi@xxxxxxxxx, viro@xxxxxxxxxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <79c8e051-24a9-2e2b-553a-bcab17d03e83@xxxxxxxxxxx>
References: <CAAA5faG3Ls0Dh_bx=950db9BV01zoLfmubKbM0UYkWpS0y60BA@xxxxxxxxxxxxxx> <79c8e051-24a9-2e2b-553a-bcab17d03e83@xxxxxxxxxxx>
User-agent: Mutt/1.5.24 (2015-08-30)
On Mon, Jun 06, 2016 at 11:39:59PM -0500, Eric Sandeen wrote:
> xfs_dir2_leaf_lookup_int() only hits that ASSERT if it was given
> a name to rename, and failed to find the original.  i.e. that should
> not happen.
> 
>         /*
>          * Loop over all the entries with the right hash value
>          * looking to match the name.
>          */
> 
> <do that loop>
> <fail to find the hash value for the name>
> <then:>
> 
>         ASSERT(args->op_flags & XFS_DA_OP_OKNOENT);
>         /*
>          * Here, we can only be doing a lookup (not a rename or remove).
>          * If a case-insensitive match was found earlier, re-read the
>          * appropriate data block if required and return it.
>          */
> 
> A rename should never fail to find the original name.

FYI, this looks very much the same like the Bug Daniel reported, which
I tried to help debugging in person over the weekend.  His backtrace
points to cancelling a dirty transaction after xfs_dir_replace failed,
which most likely comes from the failing lookup, except that he probably
doen't have XFS_DEBUG enabled.

Given that 4.7-rc1 comes with the new shared locks for lookups, and
there are very little other changes I wonder if there is any relation
It would be good if Reinoud and/or Daniel can confirm that Linux 4.6
is ok.

<Prev in Thread] Current Thread [Next in Thread>