Re: [GIT PULL] workqueue changes for v4.2-rc1
From: Paul E. McKenney
Date: Sat Jun 27 2015 - 12:21:27 EST
On Sat, Jun 27, 2015 at 10:09:28AM +0200, Ingo Molnar wrote:
>
> * Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> > On Fri, Jun 26, 2015 at 9:01 AM, Tejun Heo <tj@xxxxxxxxxx> wrote:
> > >
> > > Ooh, it isn't in mainline yet but pulling rcu tree will cause a silent
> > > conflict with this pull request which leads to build failure.
> >
> > I tend to try to do a full "make allmodconfig" build between all pull
> > requests (although I can optimize that a bit for very targeted pull
> > requests), so hopefully I'll notice and remember your note.
> >
> > But just in case:
> >
> > > The two colliding commits are.
> > >
> > > 5b95e1af8d17 ("workqueue: wq_pool_mutex protects the attrs-installation")
> > > eeacf8982637 ("rcu: Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN()")
> > >
> > > The former adds rcu_lockdep_assert() usage and the latter renames and flips
> > > it. It can be resolved by renaming and negating the conditions in the new
> > > usage.
> >
> > it would be great if when I get the RCU pull request that introduces that
> > renaming, whoever sends it to me could remind me about it.
> >
> > I'm assuming the pull request will come through Ingo. Ingo?
>
> Yeah.
>
> There was some discussion about how to warn about RCU failures precisely, so I
> think Paul yanked the new style RCU warnings for the time being. When/if they
> come back I'll be careful and will remind you of semantic conflicts.
Yes, it ended up in the batch destined for v4.3.
If it would make things easier, I could easily introduce the new API in
v4.3, along with the changes visible at that time, and pull the old API
in v4.4. That way, the conflicts appearing in v4.4 could be resolved
in the originating tree, given that the new API would then be in place
everywhere.
Either way works for me, just let me know!
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/