linux-kernel - Re: [PATCH 0/4] RCU: various merge candidates

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20060828191642.GA32697@in.ibm.com>
Date:	Tue, 29 Aug 2006 00:46:42 +0530
From:	Dipankar Sarma <dipankar@...ibm.com>
To:	Andrew Morton <akpm@...l.org>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Paul E McKenney <paulmck@...ibm.com>
Subject: Re: [PATCH 0/4] RCU: various merge candidates

On Mon, Aug 28, 2006 at 12:06:11PM -0700, Andrew Morton wrote:
> On Mon, 28 Aug 2006 21:38:45 +0530
> Dipankar Sarma <dipankar@...ibm.com> wrote:
> 
> > This patchset consists of various merge candidates that would
> > do well to have some testing in -mm. This patchset breaks
> > out RCU implementation from its APIs to allow multiple
> > implementations, gives RCU its own softirq and finally
> > lines up preemptible RCU from -rt tree as a configurable
> > RCU implementation for mainline.
> > 
> > All comments and testing is welcome. RFC at the moment, but
> > I can later submit patches against -mm, Andrew, if you want.
> > They have been tested lightly using dbench, kernbench and ltp
> > (both CONFIG_CLASSIC_RCU=y and n) on x86 and ppc64.
> 
> ouch.
> 
> akpm:/usr/src/25> grep rcu series
> radix-tree-rcu-lockless-readside.patch
> adix-tree-rcu-lockless-readside-update.patch
> radix-tree-rcu-lockless-readside-semicolon.patch
> adix-tree-rcu-lockless-readside-update-tidy.patch
> adix-tree-rcu-lockless-readside-fix-2.patch
> adix-tree-rcu-lockless-readside-fix-3.patch

Not related to RCU implementation.

> rcu-add-lock-annotations-to-rcu_bh_torture_read_lockunlock.patch

rcutorture (test module) patch independent of the implementation changes.

> srcu-3-rcu-variant-permitting-read-side-blocking.patch
> srcu-3-rcu-variant-permitting-read-side-blocking-fix.patch
> srcu-3-rcu-variant-permitting-read-side-blocking-srcu-add-lock-annotations.patch
> srcu-3-add-srcu-operations-to-rcutorture.patch
> srcu-3-add-srcu-operations-to-rcutorture-fix.patch
> add-srcu-based-notifier-chains.patch
> add-srcu-based-notifier-chains-cleanup.patch
> srcu-report-out-of-memory-errors.patch
> srcu-report-out-of-memory-errors-fixlet.patch
> cpufreq-make-the-transition_notifier-chain-use-srcu.patch

srcu (sleepable rcu) patches independent of the core RCU implementation
changes in the patchset. You can queue these up either before
or after srcu.


> rcu-add-module_author-to-rcutorture-module.patch
> rcu-fix-incorrect-description-of-default-for-rcutorture.patch
> rcu-mention-rcu_bh-in-description-of-rcutortures.patch
> rcu-avoid-kthread_stop-on-invalid-pointer-if-rcutorture.patch
> rcu-fix-sign-bug-making-rcu_random-always-return-the-same.patch
> rcu-add-fake-writers-to-rcutorture.patch
> rcu-add-fake-writers-to-rcutorture-tidy.patch

rcutorture fix patches independent of rcu implementation changes
in this patchset.

> 
> Now what?

Heh. I can always re-submit against -mm after I wait for a day or two
for comments :) Or I can wait. I think rcutorture patches are
fairly safe to merge and should go in soon. srcu and the patchset
I mailed today should probably get more testing in -mm before
going in.

Thanks
Dipankar

Thanks
Dipankar
-
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/