linux-kernel - Re: [git pull] vfs.git - including i

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]

Date:	Sun, 24 Jan 2016 18:17:37 +1100
From:	Dave Chinner <david@...morbit.com>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [git pull] vfs.git - including i_mutex wrappers

On Sun, Jan 24, 2016 at 01:20:02AM +0000, Al Viro wrote:
> On Sun, Jan 24, 2016 at 11:26:58AM +1100, Dave Chinner wrote:
> 
> > That's fair enough. However, compare this to how core locking
> > changes occur in the mm subsystem - they go through multiple patch
> > postings and review so there's no surprise when the pull request
> > comes.
> 
> ... and the thread in question has grown from precisely that (and not the first
> iteration, either) for earlier such change (RCU symlinks).  Subsequent one
> (follow_link -> get_link, with RCU symlink traversal for non-embedded
> symlinks) also went through fsdevel mailbombs (a couple of iterations, IIRC).

I haven't been following them closely, either, because it's
something I haven't needed to care much about. There's way more that
goes on than I can follow, but I would have expected something like
a pending i_mutex change to at least have a standalone "heads-up"
to inform various developers that they is a significant change
coming...

> Speaking of the earlier changes - IIRC, there had been plans to start
> hashing (at least some of) XFS symlinks.  I think it was from hch, along
> the lines of "stash a buffer with symlink body into ->i_link the first time
> around, free it from inode eviction".

No idea - there hasn't been any followup, and nobody is telling me
they have a symlink traversal performance problem, so it's way off
my radar. I don't even know what workload RCU symlinks is supposed
to optimise....

> As long as that freeing is RCU-delayed,
> doing so would work just fine and give you symlink traversal without dropping
> from RCU mode...  OTOH, if that gets resurrected, it probably ought to go
> through XFS tree - all VFS infrastructure is there (since 4.2), so it's
> purely XFS business at this point...  One thing to watch out for is that
> RCU delay - see shmem.c fix in the same pull request for related example.

I can't see me getting to this in the next few months, to tell you
the truth. There's way more important things we need to do in XFS
land right now (like merge and stabilise reflink, reverse mapping,
DAX, etc), so this is likely to sit until someone who really needs
it comes along.

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com