On Tue, Jun 7, 2016 at 12:27 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> 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.
In my case, it looks like that the lookup failed.
First you try to find the xfs_buf, lbp if the pointer to that buffer.
Then you try to find the leaf entry with the same hash value.
Then you look over the entries with the hash value and look if the names match.
Hopefully XFS_CMP_EXACT is returned.
What I do NOT get is why this flag needs to be set: XFS_DA_OP_OKNOENT
I see it being set in xfs_attr_{get, set, remove}, but I am not able
to see that anywhere in the path of this function.
In each of these xfs_attrs I see locks acquired and locked released,
no problem, other than that it's assumed the you obtain the lock.
If the beginning checks during the lock process don't work out you ASSERT.
>
> 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.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
