linux-kernel - [PATCHSET v2] ->follow_link() without dropping from RCU mode

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:	Wed, 9 Dec 2015 05:32:09 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	linux-kernel@...r.kernel.org
Cc:	linux-fsdevel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Neil Brown <neilb@...e.com>
Subject: [PATCHSET v2] ->follow_link() without dropping from RCU mode

On Tue, Nov 17, 2015 at 10:57:52PM +0000, Al Viro wrote:

> 	Right now we stay in RCU mode for fast symlink traversal.
> However, anything trickier drops out of RCU mode - back in 4.2
> the symlink-related pile had grown too large to add this on top
> of everything else.  Below is an attempt to do that now.
> 
> Those who prefer to use git for review can find that series in
> git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.symlinks

Compared to the previous iteration:
	* rebased to 4.4-rc4.
	* NFS (in case of pagecache hit, of course) also stays in RCU mode.
	* renamed inode_nohigh() as suggested by dchinner, moved to
fs/inode.c - less header PITA that way.

What's there:
01/11: switch befs long symlinks to page_symlink_operations
02/11: logfs: don't duplicate page_symlink_inode_operations
03/11: udf: don't duplicate page_symlink_inode_operations
04/11: ufs: get rid of ->setattr() for symlinks
        Simplifying things a bit by switching them to page_symlink_operations
where possible.

05/11: namei: page_getlink() and page_follow_link_light() are the same thing
        Get rid of some code duplication

06/11: don't put symlink bodies in pagecache into highmem
        Bugfix for a long-standing mess.  For pagecache-based symlinks we end
up with kmap() of the body for the duration of traversal.  Which could take
a long time if we walk into e.g. slow automount along the way.  It's DoSable,
actually.  Not hard to fix - there's no reason to use GFP_HIGHUSER_MOVABLE
for those guys; GFP_USER serves just as well.

07/11: replace ->follow_link() with new method that could stay
        Meat of the series - we switch to a new method (->get_link()) that
differs from ->follow_link() in getting dentry and inode separately; it
can be called in RCU mode (with NULL dentry) and it should bail out with
ERR_PTR(-ECHILD) if it needs non-RCU.  All instances converted, most of them
by making them bail out immediately in RCU mode.  Some are trivialy
RCU-safe, though; those do not bail out at all.

08/11: teach page_get_link() to work in RCU mode
09/11: teach shmem_get_link() to work in RCU mode
10/11: teach proc_self_get_link()/proc_thread_self_get_link()
11/11: teach nfs_get_link() to work in RCU mode
        Teaching more instances to stay in RCU mode if they can.  (8) and
(11) are similar to what Neil had done back in March, except for the lack of
kmap mess to deal with - that's one of the benefits of having (6) done...

	Missing, probably worth adding: XFS, overlayfs.  Maybe gfs2 - if it's
at all possible (not sure if it is).  Maybe autofs4 as well.

	Procfs magical symlinks definitely are *not* worth trying to handle
in RCU mode - ->d_revalidate() on them is such that it'll kick us out of
RCU mode before we even see that it's a symlink, let alone try to follow it.

Any help with review and testing would be welcome.  FWIW, it seems to survive
the beating here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/