From: NeilBrown <neilb@suse.com>
To: Oleg Drokin <oleg.drokin@intel.com>,
Greg Kroah-Hartman <greg@kroah.com>,
Andreas Dilger <andreas.dilger@intel.com>
Cc: Lustre Development List <lustre-devel@lists.lustre.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: [PATCH 0/6] dcache/namei fixes for lustre
Date: Wed, 02 Aug 2017 13:06:18 +1000 [thread overview]
Message-ID: <150164273003.13199.7841976922211510658.stgit@noble> (raw)
This series is a revised version of two patches I sent
previously (one of which was sadly broken).
That patch has been broken into multiple parts for easy
review. The other is included unchanged as the last of
this series.
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().
---
NeilBrown (6):
staging: lustre: llite: handle DCACHE_PAR_LOOKUP in ll_dcompare
staging: lustre: llite: use d_splice_alias for directories.
staging: lustre: llite: remove directory-specific code from ll_find_alias()
staging: lluste: llite: simplify ll_find_alias()
staging: lustre: llite: refine ll_find_alias based on d_exact_alias
staging: lustre: llite: fix incorrect DCACHE_DISCONNECTED test
drivers/staging/lustre/lustre/llite/dcache.c | 10 +++
.../staging/lustre/lustre/llite/llite_internal.h | 2 -
drivers/staging/lustre/lustre/llite/namei.c | 60 ++++++++++----------
3 files changed, 40 insertions(+), 32 deletions(-)
--
Signature
next reply other threads:[~2017-08-02 3:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-02 3:06 NeilBrown [this message]
2017-08-02 3:06 ` [PATCH 6/6] staging: lustre: llite: fix incorrect DCACHE_DISCONNECTED test NeilBrown
2017-08-02 3:06 ` [PATCH 2/6] staging: lustre: llite: use d_splice_alias for directories NeilBrown
2017-08-02 3:06 ` [PATCH 5/6] staging: lustre: llite: refine ll_find_alias based on d_exact_alias NeilBrown
2017-08-02 3:06 ` [PATCH 3/6] staging: lustre: llite: remove directory-specific code from ll_find_alias() NeilBrown
2017-08-02 3:06 ` [PATCH 1/6] staging: lustre: llite: handle DCACHE_PAR_LOOKUP in ll_dcompare NeilBrown
2017-08-02 3:06 ` [PATCH 4/6] staging: lluste: llite: simplify ll_find_alias() NeilBrown
2017-08-20 2:58 ` [lustre-devel] [PATCH 0/6] dcache/namei fixes for lustre James Simmons
2017-10-20 0:39 ` NeilBrown
2017-10-24 21:50 ` James Simmons
2017-10-24 22:35 ` NeilBrown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=150164273003.13199.7841976922211510658.stgit@noble \
--to=neilb@suse.com \
--cc=andreas.dilger@intel.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lustre-devel@lists.lustre.org \
--cc=oleg.drokin@intel.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox