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:   Thu, 23 Nov 2023 09:42:12 -0800
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Qais Yousef <qyousef@...alina.io>
Cc:     Joel Fernandes <joel@...lfernandes.org>,
        Frederic Weisbecker <frederic@...nel.org>,
        Neeraj Upadhyay <quic_neeraju@...cinc.com>,
        Josh Triplett <josh@...htriplett.org>,
        Boqun Feng <boqun.feng@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        Zqiang <qiang.zhang1211@...il.com>,
        Andrea Righi <andrea.righi@...onical.com>,
        John Stultz <jstultz@...gle.com>, linux-kernel@...r.kernel.org,
        rcu@...r.kernel.org
Subject: Re: [PATCH] rcu: Provide a boot time parameter to enable lazy RCU

On Tue, Nov 21, 2023 at 10:15:56PM +0000, Qais Yousef wrote:
> On 11/22/23 15:26, Paul E. McKenney wrote:
> 
> > > Either way; I'll follow what the crowd wants too :-)
> > 
> > Usually a wise choice.  ;-)
> > 
> > But I must defer to the people using it.
> 
> >From Android PoV I'd like to be able to boot with default disabled and allow
> people to opt-in. At least for the time being until we have confidence no one
> is caught with surprise if this caused unexpected problems.
> 
> In the future it might default to on once it gets wider usage and testing.
> 
> So having a new Kconfig to DEFAULT_OFF sounds good to me to enable a compile
> time switch to pick the default with a boot time to further control.
> 
> Which would be my plan for v2 unless I hear another suggestion in the coming
> week (where I hope people would have had a chance to look and think about it).

Sounds good to me!  Silence will be interpreted as assent.  ;-)

							Thanx, Paul

> > > No need for the rcu_barrier() then? Only reason why we use the _cb flavour
> > 
> > The module_param() parameters are processed during early boot, before
> > the boot CPU has enabled interrupts.  In fact, before rcu_init()
> > is invoked, which is in turn long before the scheduler has started.
> > Calling rcu_barrier() that early is not so good for your kernel's
> > actuarial statistics.
> 
> Ah, I missed that it is done that early.
> 
> > 
> > I am guessing that the module_param_cb() processing happens somewhat
> > later in the kernel's lifetime.
> 
> 
> Thanks!
> 
> --
> Qais Yousef

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ