linux-kernel - Re: [lustre-devel] [PATCH 0/6] dcache/namei fixes for lustre

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.20.1708200354030.5810@casper.infradead.org>
Date:   Sun, 20 Aug 2017 03:58:03 +0100 (BST)
From:   James Simmons <jsimmons@...radead.org>
To:     NeilBrown <neilb@...e.com>
cc:     Oleg Drokin <oleg.drokin@...el.com>,
        Greg Kroah-Hartman <greg@...ah.com>,
        Andreas Dilger <andreas.dilger@...el.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Lustre Development List <lustre-devel@...ts.lustre.org>
Subject: Re: [lustre-devel] [PATCH 0/6] dcache/namei fixes for lustre


> 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.
 
> 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
> 
> _______________________________________________
> lustre-devel mailing list
> lustre-devel@...ts.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
>