linux-kernel - Re: linux-next-20110923: warning kernel/rcutree.c:1833

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: <20110929171901.GA6900@linux.vnet.ibm.com>
Date:	Thu, 29 Sep 2011 10:19:01 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	"Kirill A. Shutemov" <kirill@...temov.name>,
	linux-kernel@...r.kernel.org, Dipankar Sarma <dipankar@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Lai Jiangshan <laijs@...fujitsu.com>
Subject: Re: linux-next-20110923: warning kernel/rcutree.c:1833

On Thu, Sep 29, 2011 at 10:12:05AM -0700, Paul E. McKenney wrote:
> On Thu, Sep 29, 2011 at 02:30:44PM +0200, Frederic Weisbecker wrote:

[ . . . ]

> > Sure I can take your patches (I'm going to merge the delta into the first).
> > But if you want a rebase against -rc8, it's going to be easier if you
> > do that rebase on the branch you want me to work on. Then I work on top
> > of it.
> > 
> > For example we can take your rcu/dynticks, rewind to
> > "rcu: Make synchronize_sched_expedited() better at work sharing"
> > 771c326f20029a9f30b9a58237c9a5d5ddc1763d, rebase on top of -rc8
> > and I rebase my patches (yours included) on top of it and I repost.
> > 
> > Right?
> 
> Yep!  Your earlier three patches look to need some extended-quiescent-state
> rework as well:
> 
> b5566f3d: Detect illegal rcu dereference in extended quiescent state
> ee05e5a4: Inform the user about dynticks-idle mode on PROVE_RCU warning
> fa5d22cf: Warn when rcu_read_lock() is used in extended quiescent state
> 
> So I will leave these out and let you rebase them.

And for whatever it is worth, my following patches depend on yours as
well, so will not include them in the rebase:

61cf7640: Remove one layer of abstraction from PROVE_RCU checking
9a4d1ce3: Warn when srcu_read_lock() is used in an extended quiescent state

							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/