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:   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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ