Re: [GIT PULL rcu/next] RCU commits for 3.20

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Mon, Feb 09, 2015 at 08:56:10AM +0100, Ingo Molnar wrote:
> 
> * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> 
> > On Fri, Feb 06, 2015 at 07:28:23PM +0100, Ingo Molnar wrote:
> > > 
> > > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> > > 
> > > > On Tue, Feb 03, 2015 at 03:34:45PM +0100, David Hildenbrand wrote:
> > > > > > 
> > > > > > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> > > > > > 
> > > > > > > Hello, Ingo,
> > > > > > > 
> > > > > > > The changes in this series include:
> > > > > > > 
> > > > > > > 1.	Documentation updates.  These were posted to LKML at
> > > > > > > 	https://lkml.org/lkml/2015/1/7/496.
> > > > > > > 
> > > > > > > 2.	Miscellaneous fixes.  These were posted to LKML at
> > > > > > > 	https://lkml.org/lkml/2015/1/7/507.
> > > > > > > 
> > > > > > > 3.	Preemptible-RCU fixes, including fixing an old bug in the
> > > > > > > 	interaction of RCU priority boosting and CPU hotplug.  These were
> > > > > > > 	posted to LKML at https://lkml.org/lkml/2015/1/7/535.
> > > > > > > 
> > > > > > > 4.	SRCU updates.  These were posted to LKML at
> > > > > > > 	https://lkml.org/lkml/2015/1/7/555.
> > > > > > > 
> > > > > > > 5.	RCU CPU stall-warning updates.  These were posted to LKML at
> > > > > > > 	https://lkml.org/lkml/2015/1/7/565.
> > > > > > > 
> > > > > > > 6.	RCU torture-test updates.  These were posted to LKML at
> > > > > > > 	https://lkml.org/lkml/2015/1/7/591.
> > > > > > > 
> > > > > > > These changes are available in the git repository at:
> > > > > > > 
> > > > > > >   git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git for-mingo
> > > > > > > 
> > > > > > > for you to fetch changes up to 78e691f4ae2d5edea0199ca802bb505b9cdced88:
> > > > > > > 
> > > > > > >   Merge branches 'doc.2015.01.07a', 'fixes.2015.01.15a', 'preempt.2015.01.06a', 'srcu.2015.01.06a', 'stall.2015.01.16a' and 'torture.2015.01.11a' into HEAD (2015-01-15 23:34:34 -0800)
> > > > > > > 
> > > > > > > ----------------------------------------------------------------
> > > > > > > 
> > > > > > > Alexander Gordeev (1):
> > > > > > >       rcu: Remove redundant rcu_is_cpu_rrupt_from_idle() from tiny RCU
> > > > > > > 
> > > > > > > Calvin Owens (1):
> > > > > > >       ksoftirqd: Enable IRQs and call cond_resched() before poking RCU
> > > > > > > 
> > > > > > > David Hildenbrand (1):
> > > > > > >       hotplugcpu: Avoid deadlocks by waking active_writer
> > > > > > > 
> > > > > 
> > > > > Hi Ingo, Paul,
> > > > > 
> > > > > Heiko/Christian seem to have hit the bug (hotplugcpu: Avoid deadlocks by waking
> > > > > active_writer addresses) in 3.18-rc3.
> > > > > 
> > > > > And as commit b2c4623dcd07 was in linux starting with 3.18-rc3, we should
> > > > > probably (have done a) cc-stable.
> > > > 
> > > > Good point, though appropriate RCU changes seem to make their 
> > > > way to -stable without explicit CCs.  Maybe I should be doing 
> > > > them, but doing so in the past has normally gotten me 
> > > > complaints from the -stable maintainers.
> > > > 
> > > > Ingo, how would you like me to be handling this in the future?
> > > 
> > > So if you put a Cc: stable tag into the commit then usually they 
> > > get picked up automatically.
> > > 
> > > Just make sure you don't Cc: the stable team on patch 
> > > submissions (which might or might not make it into 
> > > Linus's tree), that's what will get complaints.
> > > 
> > > Does that work for you?
> > 
> > I will give it a spin.  I thought that adding the "Cc: 
> > stable" tag to the commit log got me complaints when I 
> > later did git-format-patch and git-send-email, but 
> > perhaps I was confused or this has since changed.
> 
> Yeah, I believe that will get you complaints, so you have 
> to avoid sending those emails to -stable - but there's no 
> restriction on what can be in the Cc: entries of the commit 
> log itself.

OK, so if I understand correctly, I need to add the Cc: stable
tags after the last git-format-patch/git-send-email, but (of
course) before the git-request-pull.  Is that the trick?

						Thanx, Paul