linux-kernel - Re: [GIT PULL] RCU changes for v4.12

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: <CA+55aFyhPo7xtCRkhECo7KZc6Xj=Ogb8CNDzamYcureu9NFGTQ@mail.gmail.com>
Date:   Mon, 1 May 2017 18:19:44 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     "Paul E. McKenney" <paulmck@...ibm.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [GIT PULL] RCU changes for v4.12

On Mon, May 1, 2017 at 2:59 AM, Ingo Molnar <mingo@...nel.org> wrote:
> Linus,
>
> Please pull the latest core-rcu-for-linus git tree from:
>
>    git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-rcu-for-linus

I pulled this, and then after looking at it, ended up un-pulling it again.

I refuse to take that nasty <linux/rcu_segcblist.h> header file from hell.

I see absolutely no point in taking a header file of several hundred
lines of code.

We have traditionally done too much inline code anyway, but we've
learnt our lesson - and even back when we did too much of it, we
didn't put random code that nobody uses and by definition cannot be
performance-critical in big inline functions in header files.

If it was some one-liner helper function, that would be one thing. But
there are functions that don't even fit on the screen, and that have
multiple loops and memory barriers in them.

The one function I decided to grep for was used EXACTLY NOWHERE. Yet
it was apparently SO INCREDIBLY important that it needed to be inlined
in a huge header file despite being huge and complicated.

So no. This is too ugly to live, and certainly too ugly to be pulled.

The RCU code needs to start showing some good taste.

There are valid reasons to inline even large functions, if they have
constant arguments that make us expect them to generate a single
instruction of code in the end. But that was very much not the case
here.

Not pulling. Try again next merge window when the code has been
cleaned up and isn't too ugly to live.

               Linus