linux-next: manual merge of the rcu tree with the powerpc tree

[Thomas Gleixner]

"Paul E. McKenney" <paulmck at kernel.org> writes:
> On Thu, May 21, 2020 at 02:51:24PM +1000, Stephen Rothwell wrote:
>> Hi all,
>> 
>> On Tue, 19 May 2020 17:23:16 +1000 Stephen Rothwell <sfr at canb.auug.org.au> wrote:
>> >
>> > Today's linux-next merge of the rcu tree got a conflict in:
>> > 
>> >   arch/powerpc/kernel/traps.c
>> > 
>> > between commit:
>> > 
>> >   116ac378bb3f ("powerpc/64s: machine check interrupt update NMI accounting")
>> > 
>> > from the powerpc tree and commit:
>> > 
>> >   187416eeb388 ("hardirq/nmi: Allow nested nmi_enter()")
>> > 
>> > from the rcu tree.
>> > 
>> > I fixed it up (I used the powerpc tree version for now) and can carry the
>> > fix as necessary. This is now fixed as far as linux-next is concerned,
>> > but any non trivial conflicts should be mentioned to your upstream
>> > maintainer when your tree is submitted for merging.  You may also want
>> > to consider cooperating with the maintainer of the conflicting tree to
>> > minimise any particularly complex conflicts.
>> 
>> This is now a conflict between the powerpc commit and commit
>> 
>>   69ea03b56ed2 ("hardirq/nmi: Allow nested nmi_enter()")
>> 
>> from the tip tree.  I assume that the rcu and tip trees are sharing
>> some patches (but not commits) :-(
>
> We are sharing commits, and in fact 187416eeb388 in the rcu tree came
> from the tip tree.  My guess is version skew, and that I probably have
> another rebase coming up.
>
> Why is this happening?  There are sets of conflicting commits in different
> efforts, and we are trying to resolve them.  But we are getting feedback
> on some of those commits, which is probably what is causing the skew.

Correct. We had to rebase that. I don't think we do it again. The
changes I just sent out are carefully crafted to avoid that.

Thanks,

        tglx