linux-kernel - Re: [RFC] speeding up the stat() family of system calls...

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFyoUwL2Rkt1qof41HciGCNk9LHdP3ezUFeVYM=gam44rg@mail.gmail.com>
Date:	Mon, 23 Dec 2013 16:12:20 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Al Viro <viro@...iv.linux.org.uk>,
	"the arch/x86 maintainers" <x86@...nel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] speeding up the stat() family of system calls...

On Mon, Dec 23, 2013 at 4:00 PM, H. Peter Anvin <hpa@...or.com> wrote:
>
> I guess I'm a bit puzzled... the current code should be just fine if
> everything is present, and do we really care about the performance if we
> actually have an error condition?

I think we should. You could make it to do something like eighteen
expensive page faults in a row for EFAULT, and that's just disgusting,
when there is no reason to do it.

But to be honest, the resulting assembly is also easier to read,
because it doesn't have those annoying bogus branch targets all over
in the middle of the code. That was actually my main issue - looking
at the generated fs/stat.s file and not puking ;)

(it's still hard to read with all the fixup section stuff, but it's
better. And it really does generate better code, so..)

> I'm a bit concerned about the put_user_fail: label having uniqueness
> problem, which I know some versions of gcc at least get very noisy over.

Oh, you're right, I forgot to actually declare the label so that gcc
sees that it's a local one.

So it needs a

   __label__ put_user_fail;

in the put_user_try() (and yes, maybe the label name should have
underscores prepended or something, just to make sure it's internal).

But gcc is perfectly fine with multiple labels in different scopes if
you do that. We already use that in a few places, so this isn't even a
new pattern for us.

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