linux-kernel - Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

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: <alpine.LFD.2.20.1705121444260.3061@knanqh.ubzr>
Date:   Fri, 12 May 2017 14:59:48 -0400 (EDT)
From:   Nicolas Pitre <nicolas.pitre@...aro.org>
To:     "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

On Fri, 12 May 2017, Paul E. McKenney wrote:

> On Fri, Apr 28, 2017 at 05:10:40PM -0700, Paul E. McKenney wrote:
> > On Fri, Apr 28, 2017 at 05:51:15PM -0400, Nicolas Pitre wrote:
> > > On Fri, 28 Apr 2017, Paul E. McKenney wrote:
> > > 
> > > > Hello, Nicolas!
> > > > 
> > > > Saw the TTY write up LWN and figured I should send this your way.
> > > > It should be worth about 2K compared to current -next, which gave
> > > > up the 2K compared to v4.10.  So really getting things back to where
> > > > they were.
> > > > 
> > > > My current plan is to push this into v4.13.
> > > 
> > > Excellent!
> > > 
> > > If every maintainer finds a way to (optionally) reduce the size of the 
> > > code they maintain by 2K then we'll get a much smaller kernel pretty 
> > > soon.
> > 
> > I would feel better if it wasn't me who had added the 2K, but then
> > again, I do look forward to seeing a negative-sized kernel!  ;-)
> 
> And I am getting a lot of offlist pressure to remove both Tiny RCU and
> Tiny SRCU.  I am pushing back, but I might or might not prevail.  In case
> my pushback gets pushed back, do you have a -tiny tree or some such where
> the code could go?

No.  "Available in mainline" is the name of the game for all I do. If it 
can't be made acceptable for mainline then it basically has no chance of 
gaining traction and becoming generally useful. My approach is therefore 
to always find solutions that can be maintained upstream and contributed 
to with minimal fuss by anyone.

Nicolas