linux-kernel - Re: [RFC][PATCHSET] sanitized pathwalk machinery (v3)

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: <20200304205428.GA1280418@ZenIV.linux.org.uk>
Date:   Wed, 4 Mar 2020 20:54:28 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCHSET] sanitized pathwalk machinery (v3)

On Wed, Mar 04, 2020 at 04:20:51PM +0000, Al Viro wrote:
> On Wed, Mar 04, 2020 at 05:28:12AM -0800, Matthew Wilcox wrote:
> > On Wed, Mar 04, 2020 at 06:55:47AM +0000, Al Viro wrote:
> > > On Tue, Mar 03, 2020 at 11:23:39PM -0600, Eric W. Biederman wrote:
> > > > Do the xfs-tests cover that sort of thing?
> > > > The emphasis is stress testing the filesystem not the VFS but there is a
> > > > lot of overlap between the two.
> > > 
> > > I do run xfstests.  But "runs in KVM without visible slowdowns" != "won't
> > > cause them on 48-core bare metal".  And this area (especially when it
> > > comes to RCU mode) can be, er, interesting in that respect.
> > > 
> > > FWIW, I'm putting together some litmus tests for pathwalk semantics -
> > > one of the things I'd like to discuss at LSF; quite a few codepaths
> > > are simply not touched by anything in xfstests.
> > 
> > Might be more appropriate for LTP than xfstests?  will-it-scale might be
> > the right place for performance benchmarks.
> 
> Might be...  I do run LTP as well, but it's still a 4-way KVM on a 6-way
> amd64 host (phenom II X6 1100T) - not well-suited for catching scalability
> issues.
> 
> Litmus tests mentioned above are more about verifying the semantics;
> I hadn't moved past the "bunch of home-grown scripts creating setups
> that would exercise the codepaths in question + trivial pieces
> in C, pretty much limited to syscall()" stage with that; moving those
> to LTP framework is something I'll need to look into.  Might very well
> make sense; for now I just want a way to get test coverage of that code
> with minimal headache.

FWIW, I've just took mainline and added to follow_dotdot{,_rcu}() (.. handling,
RCU and non-RCU cases) gathering the number of full iterations through the
first loop, the way that loop had been left and the number of full iterations
through the second loop.  Anything other than 3 common cases (think /..,
/proc/.., /proc/scsi/..) get reported.  Built, booted and started xfstests
on it.  So far all it has caught was .. into overmounted root early in the
boot (0 full passes through the first loop, left it via the first break
when it ran into current->fs->root, 1 full pass through the second loop).
Nothing from xfstests run (yet); LTP will be the next one to go...

Note, BTW, that this unusual call in early boot has hit RCU case and would
almost certainly do so on all boxen.  So in all of that there had not been
a single sodding call that would've hit the traversal into overmount of
parent in non-RCU case.