linux-kernel - Re: [PATCHSET][RFC][CFT] parallel lookups

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: <20160416032750.GW25498@ZenIV.linux.org.uk>
Date:	Sat, 16 Apr 2016 04:27:51 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Andreas Dilger <adilger@...ger.ca>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCHSET][RFC][CFT] parallel lookups

On Fri, Apr 15, 2016 at 09:02:02PM -0600, Andreas Dilger wrote:

> Looks very interesting, and long awaited.  How do you see the parallel
> operations moving forward?  Staying as lookup only, or moving on to parallel
> modifications as well?

lookup + readdir.  Not even atomic_open at this point, and that's the
route I'd suggest for modifiers - i.e. a combined lookup + mkdir, etc.
operations.  But we'd really need to sort atomic_open pathway out first...

Let's discuss that at LSFMM, corridor track if needed.  With lookups I'd been
able to keep the surgery site pretty much entirely in VFS proper - fs/dcache.c
and (after earlier massage) a single function in fs/namei.c.  With readdir
it'll be somewhat more invasive - pre-seeding dcache is done in a bunch of
filesystems right now (mostly the network ones, where readdir request is
equivalent to bulk lookup, as well as synthetic-inodes ones a-la procfs)
and it'll need to be regularized; ncpfs is particularly nasty, what with its
case-changing crap), but at least it will be reasonably compact.  For
atomic_open, and worse yet - mkdir/mknod/symlink/link/unlink/rmdir/rename
it will really dip into filesystem code.  A lot.

FWIW, I agree that relying on i_mutex^Wi_rwsem for dcache protection is
something worth getting rid of in the longer term.  But that protection is
there right now, and getting rid of that will take quite a bit of careful
massage.  I don't have such a transition plotted yet; not enough information
at the moment, and I seriously suspect that atomic_open would be the best
place to start.  If nothing else, there are reasonably few instances of that
puppy.  Moreover, we badly need to regularize the paths around do_last() -
right now they are messy as hell.  Once that is sorted out, we'll be in better
position to deal with the rest of directory-modifying operations.