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] [day] [month] [year] [list]
Date:	Thu, 24 Mar 2011 19:30:42 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Lai Jiangshan <laijs@...fujitsu.com>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, dipankar@...ibm.com,
	akpm@...ux-foundation.org, mathieu.desnoyers@...ymtl.ca,
	josh@...htriplett.org, niv@...ibm.com, tglx@...utronix.de,
	peterz@...radead.org, rostedt@...dmis.org, Valdis.Kletnieks@...edu,
	dhowells@...hat.com, eric.dumazet@...il.com, darren@...art.com
Subject: Re: [PATCH RFC tip/core/rcu 01/11] rcu: call __rcu_read_unlock()
 in exit_rcu for tiny RCU

On Thu, Mar 24, 2011 at 06:07:12AM -0700, Paul E. McKenney wrote:
> On Thu, Mar 24, 2011 at 11:45:48AM +0800, Lai Jiangshan wrote:
> > On 02/26/2011 03:40 AM, Paul E. McKenney wrote:
> > > On Fri, Feb 25, 2011 at 04:29:46PM +0800, Lai Jiangshan wrote:
> > >> On 02/23/2011 09:39 AM, Paul E. McKenney wrote:
> > >>>
> > >>> diff --git a/kernel/rcutiny_plugin.h b/kernel/rcutiny_plugin.h
> > >>> index 015abae..3cb8e36 100644
> > >>> --- a/kernel/rcutiny_plugin.h
> > >>> +++ b/kernel/rcutiny_plugin.h
> > >>
> > >> My original patch was just for tree RCU. It is not merged.
> > >> I forgot the tiny RCU case then, this change is needed for tree & tiny RCU.
> > > 
> > > Good catch, I have applied the TREE_RCU patch.  I intend to submit
> > > both for the next merge window.
> > > 
> > 
> > Hi, Paul
> > 
> > It is still not merged, and it is not in your git tree.
> 
> Indeed it is not yet in my external git tree.  Here is my normal work
> flow:
> 
> 1.	Develop and test continuously.
> 
> 2.	Based on testing, review, etc., determin which commits are
> 	ready for the next merge window.
> 
> 3.	Midway through the -rc releases, push the commits targeted
> 	to the next merge window to rcu/next.  Push any additional
> 	commits to rcu/testing.
> 
> 4.	Towards the last -rc, rebase, retest, wait for the -next
> 	tree to take the changes, and, if all is well, send Ingo
> 	a pull request.
> 
> Exposing your changes to -next during the merge window would cause
> pointless irritation due to random conflicts with rapidly changing
> code.
> 
> > I'm writing some patches, to avoid conflict with your code,
> > which branch I should based on?
> 
> But, yes, it would be much easier for us to handle your changes if
> I post them via -rcu.  So I have created a new branch rcu/kfree_rcu
> that is -not- consumed by -next.  The rcu/next and rcu/testing
> branches include your base kfree_rcu() patch, but not the uses of
> it.  These branches are based on 2.6.38, and I will move them ahead
> at -rc3 or -rc4.
> 
> These currently contain your original patches, but I will be pulling
> your latest set.

Which are now available at rcu/kfree_rcu.

							Thanx, Paul

> > Is origin/rcu/next OK?
> 
> origin/rcu/kfree_rcu for the moment to avoid messing up -next.  But
> it will be origin/rcu/next after rebasing onto -rc3 or -rc4.
> 
> 							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/

Powered by blists - more mailing lists