public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
To: James Simmons <jsimmons@infradead.org>
Cc: Oleg Drokin <oleg.drokin@intel.com>,
	Greg Kroah-Hartman <greg@kroah.com>,
	Andreas Dilger <andreas.dilger@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Lustre Development List <lustre-devel@lists.lustre.org>
Subject: Re: [lustre-devel] [PATCH 0/6] dcache/namei fixes for lustre
Date: Fri, 20 Oct 2017 11:39:50 +1100	[thread overview]
Message-ID: <87k1zqfy95.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <alpine.LFD.2.20.1708200354030.5810@casper.infradead.org>

[-- Attachment #1: Type: text/plain, Size: 1944 bytes --]

On Sun, Aug 20 2017, James Simmons wrote:

>> 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().
>
> To let you know this patch has been under going testing and we have a
> ticket open to track the progess:
>
> https://jira.hpdd.intel.com/browse/LU-9868
>
> Your patch did reveal that a piece of a fix landed earlier is missing :-(
> So currently the client can oops. I will send the fix shortly but this
> work will have to rebased after. As soon as we can get some cycles we will
> figure out what is going on. Thanks for helping out.

Hi,
 what happened about this?  I had a look around the ticket and couldn't
 find anything about an oops.  If there is still a problem I'd be very
 happy to help work out what it is - but I don't know where to look.

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2017-10-20  0:40 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-02  3:06 [PATCH 0/6] dcache/namei fixes for lustre NeilBrown
2017-08-02  3:06 ` [PATCH 6/6] staging: lustre: llite: fix incorrect DCACHE_DISCONNECTED test 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-02  3:06 ` [PATCH 2/6] staging: lustre: llite: use d_splice_alias for directories NeilBrown
2017-08-20  2:58 ` [lustre-devel] [PATCH 0/6] dcache/namei fixes for lustre James Simmons
2017-10-20  0:39   ` NeilBrown [this message]
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=87k1zqfy95.fsf@notabene.neil.brown.name \
    --to=neilb@suse.com \
    --cc=andreas.dilger@intel.com \
    --cc=greg@kroah.com \
    --cc=jsimmons@infradead.org \
    --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