linux-kernel - Re: Word-at-a-time dcache name accesses (was Re: .. anybody know of any filesystems that depend on the exact VFS 'namehash' implementation?)

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: <CABS55+D97mKFdQhGdAXjMGfyRiWd4Os8wfRq9YNa-FQAEQSR7Q@mail.gmail.com>
Date:	Sun, 4 Mar 2012 19:58:33 -0800
From:	Jason Garrett-Glaser <jason@...4.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andi Kleen <andi@...stfloor.org>, "H. Peter Anvin" <hpa@...or.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Al Viro <viro@...iv.linux.org.uk>
Subject: Re: Word-at-a-time dcache name accesses (was Re: .. anybody know of
 any filesystems that depend on the exact VFS 'namehash' implementation?)

On Fri, Mar 2, 2012 at 3:46 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Here's a new version of that patch.
>
> It's based n the cleanups I committed and pushed out today, so the base
> may not look familiar, but the upside is that this does the configuration
> automatically (currently the patch enables the word accesses on x86 by
> default as long as DEBUG_PAGEALLOC isn't set).
>
> I worked around my problems with stupid branch prediction on the '/' test
> at the end by just reorganizing the code a bit, and it actually all just
> looks cleaner.
>
> This *does* assume that "bsf" is a reasonably fast instruction, which is
> not necessarily the case especially on 32-bit x86. So the config option
> choice for this might want some tuning even on x86, but it would be lovely
> to get comments and have people test it out on older hardware.

There is an improvement you can make to this.  "bsf" is microcoded in
many future CPUs (e.g. Piledriver) in favor of tzcnt, which has
slightly different flag behavior and no undefined behavior and is part
of BMI1.  This costs a few clocks in such chips -- not as bad as the
Really Slow bsf in chips like the Pentium 4 and Atom, but more than is
necessary (and stalls the instruction decoder, at least on AMD, while
the microcode unit runs).

However, "tzcnt" is opcode-equivalent to "rep bsf", for some odd sort
of backwards compatibility.  Therefore, if your code does the same
thing with both tzcnt and bsf, you can simply use rep bsf instead, and
it'll work without any CPU checks.  The manuals claim that this works
on legacy CPUs, i.e. won't SIGILL.

The only downside I've noticed to this is that valgrind incorrectly
SIGILLs on rep bsf.

Jason
--
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/