linux-kernel - Re: [PATCH v2 00/36] x86: Rewrite all syscall entries except native 64-bit

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:	Tue, 6 Oct 2015 09:39:28 +0100
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andy Lutomirski <luto@...nel.org>
Cc:	"the arch/x86 maintainers" <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Brian Gerst <brgerst@...il.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH v2 00/36] x86: Rewrite all syscall entries except native 64-bit

On Tue, Oct 6, 2015 at 1:47 AM, Andy Lutomirski <luto@...nel.org> wrote:
>
> The patchset is structured as a removal of the old fast syscall
> code, then the change that makes syscalls into real functions, then
> a clean re-implementation of fast syscalls.
>
> If we want some of the 25 cycles back, we could consider open-coding
> a new C fast path.

Ok, the 25 cycles are apparently just 12 cycles. Did you forget to
update that after doing some of the optimizations - or is it 25 cycles
on 64-bit and 12 cycles on 32-bit?

But regardless, I've read through the series twice, and I don't see
anything wrong. The one thing I thought I noticed ended up being
mooted by a patch later in the series.

Of course, this is the kind of code where reading the patch doesn't
necessarily catch any of the really subtle problems at all, but you
seem to have tested it fairly heavily too.

So ACK on the whole series. I don't mind a few cycles for the fast
case if it means it's more maintainable, and sadly I suspect that with
so many distributions using audit functionality, the fast case is
almost unheard of anyway, and the fact that you sped up the slow case
is what matters more. Snif.

I'd like to see this as a git tree, with your longish explanation as
the pull request for the x86 merge, so that that gets saved for
posterity too in the kernel commit logs. But that's between you and
Ingo or whoever ends up being the person who picks this up.

                   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/