linux-kernel - Re: [PATCH 0/9] Support follow

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: <21752.24468.376138.308459@quad.stoffel.home>
Date:	Thu, 5 Mar 2015 08:52:20 -0500
From:	"John Stoffel" <john@...ffel.org>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	NeilBrown <neilb@...e.de>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/9] Support follow_link in RCU-walk.

>>>>> "Al" == Al Viro <viro@...IV.linux.org.uk> writes:

Al> On Thu, Mar 05, 2015 at 04:21:21PM +1100, NeilBrown wrote:
>> Hi Al (and others),
>> 
>> I wonder if you could look over this patchset.
>> It allows RCU-walk to follow symlinks in many common cases,
>> thus removing a surprising performance hit caused by using symlinks.
>> 
>> The last could of patches make changes to XFS and NFS to support
>> this but I haven't forwarded to the relevant lists yet.
>> If/when the early code meets with approval I'll do that.
>> 
>> The first patch almost certainly needs to be changed.  I originally
>> wrote this code when filesystems could see inside nameidata.
>> It is now opaque so the simplest solution was to provide an
>> accessor function.
>> Maybe I should as a 'flags' arg to ->follow_link?? Or have
-> follow_link and ->follow_link_rcu ??
>> What do you suggest?

Al> Umm...  Some observations:
Al> 	* now ->follow_link() can be called in RCU mode, which means
Al> that it can race with fs shutdown; not a problem, except that now it
Al> joins ->lookup() et.al. in "if some data structure is needed in RCU
Al> case of that, make sure it's not destroyed without an RCU delay somewhere
Al> between the entry into ->kill_sb() and destruction.
Al> 	* highmem pages in symlinks: that BS shouldn't be allowed at
Al> all.  Just make sure that at least for those filesystems symlink inodes
Al> get mapping_set_gfp_mask(&inode->i_data, GFP_KERNEL) and be done with that.

So what happens if your filesystem is 10Tb in size, and you have 50
million files and lots of them are symlinks?  I've got developers who
do shit like this and wonder why performance sucks....  and I just
worry that GPF_KERNEL is a limited resource.  But maybe 64bit systems
won't really have any problems?

Rest of this is way outside my pay grade to commment on.
--
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/