[LU-9868] dcache/namei fixes for lustre

• Type: Bug
• Resolution: Unresolved
• Priority: Major
• Fix Version/s: Upstream
• Affects Version/s: Upstream, Lustre 2.11.0, Lustre 2.12.0, Lustre 2.10.5
• Labels: patch upstream
• Environment: upstream and well as any lustre 2.11 client.
• Severity: 3
• Assignee: James A Simmons
• Reporter: James A Simmons

Description

From Neil Brown that works at SuSE

I was drawn to look at this code due to the tests on
DCACHE_DISCONNECTED which are often wrong, and it turns out
they are used wrongly in lustre too. Fixing one led to some
clean-up. Fixing the other is straight forward.

A particular change here from the previous posting is
the first patch which tests for DCACHE_PAR_LOOKUP in ll_dcompare().
Without this patch, two threads can be looking up the same
name in a given directory in parallel. This parallelism lead
to my concerns about needing improved locking in ll_splice_alias().
Instead of improving the locking, I now avoid the need for it
by fixing ll_dcompare.

This code passes basic "smoke tests".

Note that the cast to "struct dentry *" in the first patch is because
we have a "const struct dentry *" but d_in_lookup() requires a
pointer to a non-const structure. I'll send a separate patch to
change d_in_lookup().

Issue Links

• is duplicated by: LU-16179 race in ll_splice_alias() may lead to two valid dentries for the same file
• is related to: LU-11501 use the dcache properly with .lustre/fid
• is related to: LU-9735 Sles12Sp2 and 2.9 getcwd() sometimes fails
• is related to: LU-12997 getcwd() returns ENOENT on RHEL7
• is related to: LU-13486 tests sanity/32* fail
• is related to: LU-12511 Prepare lustre for adoption into the linux kernel