linux-kernel - Re: [-mm PATCH 1/4] RCU: split classic rcu

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:	Wed, 27 Sep 2006 09:32:40 -0700
From:	"Paul E. McKenney" <paulmck@...ibm.com>
To:	Christoph Hellwig <hch@...radead.org>,
	Dipankar Sarma <dipankar@...ibm.com>,
	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [-mm PATCH 1/4] RCU: split classic rcu

On Mon, Sep 25, 2006 at 05:54:33PM +0100, Christoph Hellwig wrote:
> On Sat, Sep 23, 2006 at 09:01:41PM +0530, Dipankar Sarma wrote:
> > 
> > This patch re-organizes the RCU code to enable multiple implementations
> > of RCU. Users of RCU continues to include rcupdate.h and the
> > RCU interfaces remain the same. This is in preparation for
> > subsequently merging the preepmtpible RCU implementation.
> 
> I still disagree very strongly.  In a given tree there should be oneRCU
> implementation for the traditional interface.  We probably want srcu
> in addition, but not things hiding behind the interface.

Hello, Christoph!

I agree very much with your "oneRCU to defer them all" goal for the
traditional interface.

However, the current implementation is extremely well-tested and seems
to be quite reliable.  Yes, there might still be a rough edge or two
in cases where people do call_rcu() in tight loops, but even that is
being covered in most cases where "don't do that" doesn't apply (e.g.,
close(open()) from user space).  The Linux implementation of RCU is
almost six years old, and first appeared in mainline almost four years
ago -- that is some -serious- testing!

We will be switching to a new implementation.  I am working to make it
as reliable as I know how, but it seems reasonable to have a changeover
period that might be measured in years.  I -really- don't want to be
inflicting even the possibility of RCU implementation bugs on anyone who
has not "signed up" for code that has not yet be hammered into total
and complete submission!  CONFIG_PREEMPT_RT is quite reliable even now,
but there is "quite reliable" and then there is "hammered into total
and complete submission".  ;-)

Also, we need any new implementation of RCU to be in a separate file.
I don't want to even think about the number of times that I accidentally
changed the wrong version of RCU when working on the -rt implementation
before we split it -- the functions have the same name, right?  :-/

So maybe we rip the multi-RCU infrastructure out once we have fully
(and I mean -fully-) tested the new RCU implementation, taken care of
any performance anomalies, and so on.  I would be totally OK with that,
but believe the split will be needed in the meantime.

Fair enough?  Or am I missing something?

							Thanx, Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/