linux-kernel - Re: [RFC PATCH 00/35] remove in-kernel syscall invocations

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+55aFx9eSF2X7Cu84hPym+ca+uO4HStZ4r5XFmneH44ZJPoyw@mail.gmail.com>
Date:   Sun, 11 Mar 2018 13:15:59 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Dominik Brodowski <linux@...inikbrodowski.net>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andrew Lutomirski <luto@...nel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC PATCH 00/35] remove in-kernel syscall invocations

On Sun, Mar 11, 2018 at 3:55 AM, Dominik Brodowski
<linux@...inikbrodowski.net> wrote:
> Here is a first set of patches which reduce the number of syscall invocations
> from within the kernel.

This all looks ok to me. I think there may be some room for cleanup
and bikeshedding later (the "ksys_mmap_pgoff()" name made me go "that
sounds more like a real helper than a kernel syscall", for example),
but on the whole I think it's best to start with this kind of fairly
direct translation.

In fact, because it all looks *so* mechanical, I'd even be willing to
just pull this into 4.16, if that makes the real work that this
depends on easier?

Anyway, ack from me, qith the only question being how you want to
handle the patches. Direct pull request to me, go through the -mm
tree, or just keep them in your own git tree and then build upon it
and send it all later?

                       Linus