[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87h7w9t450.fsf@nanos.tec.linutronix.de>
Date: Thu, 21 May 2020 22:38:35 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: paulmck@...nel.org, Stephen Rothwell <sfr@...b.auug.org.au>
Cc: Michael Ellerman <mpe@...erman.id.au>,
PowerPC <linuxppc-dev@...ts.ozlabs.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
Linux Next Mailing List <linux-next@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Nicholas Piggin <npiggin@...il.com>
Subject: Re: linux-next: manual merge of the rcu tree with the powerpc tree
"Paul E. McKenney" <paulmck@...nel.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@...b.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
Powered by blists - more mailing lists