linux-kernel - Re: [PATCH v2] vfs: avoid recopying file names in getname

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: <20150411235655.GK889@ZenIV.linux.org.uk>
Date:	Sun, 12 Apr 2015 00:56:55 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Boqun Feng <boqun.feng@...il.com>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Paul Moore <pmoore@...hat.com>
Subject: Re: [PATCH v2] vfs: avoid recopying file names in getname_flags

On Tue, Apr 07, 2015 at 04:38:26PM +0800, Boqun Feng wrote:
> Ping again...

What exactly does it buy us?  You need a pathname just a bit under 4Kb, which,
with all due respect, is an extremely rare case.  Resulting code is more
complicated, we _still_ copy twice (sure, the second time is for 16 bytes or
so, but...), instead of "compare with the address of embedded array" we get
the loveliness like
> > > +	if (name->name != ((char *)name - EMBEDDED_NAME_MAX)) {
this...   _And_, on top of everything else, we get name and name->name
guaranteed to hit different cachelines, in all cases, including the common
ones.

What for?  It's not as if userland memory had been communicated with by
IP over carrier pigeons, after all, and the cost of 4Kb worth of
(essentially) memcpy() is going to be
	a) incurred in extremely rare case
and
	b) be dwarfed by the work we need to _do_ with what we'd copied.
After all, that pathname is going to be parsed and traversed - all 4Kb
worth of it.

So what's the point?
--
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/