linux-next: manual merge of the rseq tree with Linus' tree

linux-next: manual merge of the rseq tree with Linus' tree

[Stephen Rothwell]

Hi Mathieu,

[I may regret adding the rseq tree ...]

Today's linux-next merge of the rseq tree got a conflict in:

  arch/x86/entry/entry_64.S

between commits:

  9da78ba6b47b ("x86/entry/64: Remove the restore_c_regs_and_iret label")
  26c4ef9c49d8 ("x86/entry/64: Split the IRET-to-user and IRET-to-kernel paths")
  e53178328c9b ("x86/entry/64: Shrink paranoid_exit_restore and make labels local")

from Linus' tree and commit:

  60a77bfd24d5 ("membarrier: x86: Provide core serializing command (v2)")

from the rseq tree.

I fixed it up (see below) 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.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/entry/entry_64.S
index a2b30ec69497,4859f04e1695..000000000000
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@@ -617,21 -612,8 +617,25 @@@ GLOBAL(retint_user
  	mov	%rsp,%rdi
  	call	prepare_exit_to_usermode
  	TRACE_IRQS_IRETQ
 +
 +GLOBAL(swapgs_restore_regs_and_return_to_usermode)
 +#ifdef CONFIG_DEBUG_ENTRY
 +	/* Assert that pt_regs indicates user mode. */
 +	testb	$3, CS(%rsp)
 +	jnz	1f
 +	ud2
 +1:
 +#endif
  	SWAPGS
 -	jmp	restore_regs_and_iret
 +	POP_EXTRA_REGS
 +	POP_C_REGS
 +	addq	$8, %rsp	/* skip regs->orig_ax */
++	/*
++	 * ARCH_HAS_MEMBARRIER_SYNC_CORE rely on iret core serialization
++	 * when returning from IPI handler.
++	 */
 +	INTERRUPT_RETURN
 +
  
  /* Returning to kernel space */
  retint_kernel:
@@@ -651,17 -633,19 +655,21 @@@
  	 */
  	TRACE_IRQS_IRETQ
  
 -/*
 - * At this label, code paths which return to kernel and to user,
 - * which come from interrupts/exception and from syscalls, merge.
 - */
 -GLOBAL(restore_regs_and_iret)
 -	RESTORE_EXTRA_REGS
 -restore_c_regs_and_iret:
 -	RESTORE_C_REGS
 -	REMOVE_PT_GPREGS_FROM_STACK 8
 +GLOBAL(restore_regs_and_return_to_kernel)
 +#ifdef CONFIG_DEBUG_ENTRY
 +	/* Assert that pt_regs indicates kernel mode. */
 +	testb	$3, CS(%rsp)
 +	jz	1f
 +	ud2
 +1:
 +#endif
 +	POP_EXTRA_REGS
 +	POP_C_REGS
 +	addq	$8, %rsp	/* skip regs->orig_ax */
+ 	/*
+ 	 * ARCH_HAS_MEMBARRIER_SYNC_CORE rely on iret core serialization
+ 	 * when returning from IPI handler.
+ 	 */
  	INTERRUPT_RETURN
  
  ENTRY(native_iret)

Re: linux-next: manual merge of the rseq tree with Linus' tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Mathieu,
> 
> [I may regret adding the rseq tree ...]
> 
> Today's linux-next merge of the rseq tree got a conflict in:
> 
>   arch/x86/entry/entry_64.S
> 
> between commits:
> 
>   9da78ba6b47b ("x86/entry/64: Remove the restore_c_regs_and_iret label")
>   26c4ef9c49d8 ("x86/entry/64: Split the IRET-to-user and IRET-to-kernel paths")
>   e53178328c9b ("x86/entry/64: Shrink paranoid_exit_restore and make labels local")
> 
> from Linus' tree and commit:
> 
>   60a77bfd24d5 ("membarrier: x86: Provide core serializing command (v2)")
> 
> from the rseq tree.
> 
> I fixed it up (see below) 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.

NAK!

There's absolutely no way such invasive x86 changes should be done outside the x86 
tree and be merged into linux-next.

linux-next should be for the regular maintenance flow, for changes pushed by 
maintainers and part of the regular maintenance process - not for work-in-progress 
features that may or may not be merged upstream in that form ...

Thanks,

	Ingo

Re: linux-next: manual merge of the rseq tree with Linus' tree

[Stephen Rothwell]

Hi Ingo,

On Wed, 15 Nov 2017 09:07:12 +0100 Ingo Molnar <mingo@kernel.org> wrote:
>
> There's absolutely no way such invasive x86 changes should be done outside the x86 
> tree and be merged into linux-next.
> 
> linux-next should be for the regular maintenance flow, for changes pushed by 
> maintainers and part of the regular maintenance process - not for work-in-progress 
> features that may or may not be merged upstream in that form ...

Sure.  I was given the impression that Linus was going to be asked to
merge this tree during this merge window, so I assumed that it had been
seen by the appropriate people.  Most of these patches include you,
Linus and Andrew (among others) on their cc's and they seem to have
gone through several revisions.

I guess Mathieu has jumped the gun.

I'll drop it again tomorrow.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the rseq tree with Linus' tree

[Mathieu Desnoyers]

----- On Nov 15, 2017, at 3:07 AM, Ingo Molnar mingo@kernel.org wrote:

> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
>> Hi Mathieu,
>> 
>> [I may regret adding the rseq tree ...]
>> 
>> Today's linux-next merge of the rseq tree got a conflict in:
>> 
>>   arch/x86/entry/entry_64.S
>> 
>> between commits:
>> 
>>   9da78ba6b47b ("x86/entry/64: Remove the restore_c_regs_and_iret label")
>>   26c4ef9c49d8 ("x86/entry/64: Split the IRET-to-user and IRET-to-kernel paths")
>>   e53178328c9b ("x86/entry/64: Shrink paranoid_exit_restore and make labels
>>   local")
>> 
>> from Linus' tree and commit:
>> 
>>   60a77bfd24d5 ("membarrier: x86: Provide core serializing command (v2)")
>> 
>> from the rseq tree.
>> 
>> I fixed it up (see below) 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.
> 
> NAK!
> 
> There's absolutely no way such invasive x86 changes should be done outside the
> x86
> tree and be merged into linux-next.

Hi Ingo,

These "invasive" changes to entry*.S is simply adding comments such as:

++        /*
++         * ARCH_HAS_MEMBARRIER_SYNC_CORE rely on iret core serialization
++         * when returning from IPI handler.
++         */
 +        INTERRUPT_RETURN

The more extensive change is from Andy Lutomirski, which went through the
x86 tree.

> 
> linux-next should be for the regular maintenance flow, for changes pushed by
> maintainers and part of the regular maintenance process - not for
> work-in-progress features that may or may not be merged upstream in that form ...

If you prefer, I'd be happy to send the patch
"membarrier: x86: Provide core serializing command (v2)"
for integration through the x86 maintainer tree. However, you'd have to wait until
the rest of the "rseq" tree gets pulled by Linus, given that the generic code
is provided within that tree.

By the way, I was awaiting feedback on the core serializing membarrier command from
Android guys on arm 64, and things are looking good. They have done integration into
their platform, have successfully run their tests on a board, and are now moving to
another board which is known to reproduce the core serialization issue within minutes.

What course of action do you prefer ?

Thanks,

Mathieu


> 
> Thanks,
> 
> 	Ingo

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: linux-next: manual merge of the rseq tree with Linus' tree

[Mathieu Desnoyers]

----- On Nov 15, 2017, at 9:48 AM, Stephen Rothwell sfr@canb.auug.org.au wrote:

> Hi Ingo,
> 
> On Wed, 15 Nov 2017 09:07:12 +0100 Ingo Molnar <mingo@kernel.org> wrote:
>>
>> There's absolutely no way such invasive x86 changes should be done outside the
>> x86
>> tree and be merged into linux-next.
>> 
>> linux-next should be for the regular maintenance flow, for changes pushed by
>> maintainers and part of the regular maintenance process - not for
>> work-in-progress
>> features that may or may not be merged upstream in that form ...
> 
> Sure.  I was given the impression that Linus was going to be asked to
> merge this tree during this merge window, so I assumed that it had been
> seen by the appropriate people.  Most of these patches include you,
> Linus and Andrew (among others) on their cc's and they seem to have
> gone through several revisions.
> 
> I guess Mathieu has jumped the gun.

The membarrier core serializing command has been developed in the open
since Aug. 27, 2017 [1]. That's one full development cycle. On Sept 28,
2017, I started CCing Ingo when I noticed I would have to add documentation
to each architecture return-to-usermode paths [2]. I have never heard feedback
from him until now.

I am open to remove the x86-specific membarrier core serializing patch from
my tree and hand it to the x86 maintainers after the generic code makes it
into Linus' tree, if this is seen as the appropriate way forward.

Thanks,

Mathieu

[1] http://lkml.kernel.org/r/20170827195404.22171-2-mathieu.desnoyers@efficios.com
[2] http://lkml.kernel.org/r/911707916.20840.1506605496314.JavaMail.zimbra@efficios.com


> 
> I'll drop it again tomorrow.
> 
> --
> Cheers,
> Stephen Rothwell

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: linux-next: manual merge of the rseq tree with Linus' tree

[Thomas Gleixner]

On Wed, 15 Nov 2017, Mathieu Desnoyers wrote:
> ----- On Nov 15, 2017, at 9:48 AM, Stephen Rothwell sfr@canb.auug.org.au wrote:
> 
> > Hi Ingo,
> > 
> > On Wed, 15 Nov 2017 09:07:12 +0100 Ingo Molnar <mingo@kernel.org> wrote:
> >>
> >> There's absolutely no way such invasive x86 changes should be done outside the
> >> x86
> >> tree and be merged into linux-next.
> >> 
> >> linux-next should be for the regular maintenance flow, for changes pushed by
> >> maintainers and part of the regular maintenance process - not for
> >> work-in-progress
> >> features that may or may not be merged upstream in that form ...
> > 
> > Sure.  I was given the impression that Linus was going to be asked to
> > merge this tree during this merge window, so I assumed that it had been
> > seen by the appropriate people.  Most of these patches include you,
> > Linus and Andrew (among others) on their cc's and they seem to have
> > gone through several revisions.
> > 
> > I guess Mathieu has jumped the gun.
> 
> The membarrier core serializing command has been developed in the open
> since Aug. 27, 2017 [1]. That's one full development cycle. On Sept 28,
> 2017, I started CCing Ingo when I noticed I would have to add documentation
> to each architecture return-to-usermode paths [2]. I have never heard feedback
> from him until now.
> 
> I am open to remove the x86-specific membarrier core serializing patch from
> my tree and hand it to the x86 maintainers after the generic code makes it
> into Linus' tree, if this is seen as the appropriate way forward.

To be honest, I was looking at this stuff losely, but the continous flux of
it and the entanglement with the rseq series did not really help.

I have no idea why you are trying to force shove that rseq stuff into
4.15. It's not been complete before the merge window opened and it's still
not complete AFAICT.

That x86 membarrier thing is not yet clear if it is required at all, so why
is this so high priority?

Can we please handle this as any other feature which is not ready before
the merge window and postpone the rseq stuff for 4.16?

The core serialization thing might be a correctness issue and we can fix
that independently once we have gathered enough information from
Intel/AMD.

Thanks,

	tglx

Re: linux-next: manual merge of the rseq tree with Linus' tree

[Mathieu Desnoyers]

----- On Nov 15, 2017, at 10:22 AM, Thomas Gleixner tglx@linutronix.de wrote:

> On Wed, 15 Nov 2017, Mathieu Desnoyers wrote:
>> ----- On Nov 15, 2017, at 9:48 AM, Stephen Rothwell sfr@canb.auug.org.au wrote:
>> 
>> > Hi Ingo,
>> > 
>> > On Wed, 15 Nov 2017 09:07:12 +0100 Ingo Molnar <mingo@kernel.org> wrote:
>> >>
>> >> There's absolutely no way such invasive x86 changes should be done outside the
>> >> x86
>> >> tree and be merged into linux-next.
>> >> 
>> >> linux-next should be for the regular maintenance flow, for changes pushed by
>> >> maintainers and part of the regular maintenance process - not for
>> >> work-in-progress
>> >> features that may or may not be merged upstream in that form ...
>> > 
>> > Sure.  I was given the impression that Linus was going to be asked to
>> > merge this tree during this merge window, so I assumed that it had been
>> > seen by the appropriate people.  Most of these patches include you,
>> > Linus and Andrew (among others) on their cc's and they seem to have
>> > gone through several revisions.
>> > 
>> > I guess Mathieu has jumped the gun.
>> 
>> The membarrier core serializing command has been developed in the open
>> since Aug. 27, 2017 [1]. That's one full development cycle. On Sept 28,
>> 2017, I started CCing Ingo when I noticed I would have to add documentation
>> to each architecture return-to-usermode paths [2]. I have never heard feedback
>> from him until now.
>> 
>> I am open to remove the x86-specific membarrier core serializing patch from
>> my tree and hand it to the x86 maintainers after the generic code makes it
>> into Linus' tree, if this is seen as the appropriate way forward.
> 
> To be honest, I was looking at this stuff losely, but the continous flux of
> it and the entanglement with the rseq series did not really help.
> 
> I have no idea why you are trying to force shove that rseq stuff into
> 4.15. It's not been complete before the merge window opened and it's still
> not complete AFAICT.

The rseq and cpu_opv parts have not moved much in the past weeks, and the
core of their development was done publicly since Oct. 12, 2017 [1]. It has
been discussed at the Kernel Summit as well.

[1] lkml.kernel.org/r/20171012230326.19984-1-mathieu.desnoyers@efficios.com

> 
> That x86 membarrier thing is not yet clear if it is required at all, so why
> is this so high priority?

I think you refer to the migration "bug" wrt core serialization, which is
a different topic. The membarrier sync_core command allows JIT to ensure
a core serializing instruction is issued on every core before they return
to that mm, before the JIT reclaims code memory. Those are different topics.

> Can we please handle this as any other feature which is not ready before
> the merge window and postpone the rseq stuff for 4.16?

Linus showed interest in merging the rseq tree when we discussed at the
Kernel Summit. The tree has not changed much since then. I only integrated
membarrier patches that were implemented around the time of the 4.14 merge
window, which I queued for the 4.15 (current) window.

> The core serialization thing might be a correctness issue and we can fix
> that independently once we have gathered enough information from
> Intel/AMD.

Even though the membarrier sync_core command will be relevant independently
of Intel and AMD's feedback, I'm open to postpone this x86-specific patch.

Thanks,

Mathieu

> 
> Thanks,
> 
> 	tglx

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: linux-next: manual merge of the rseq tree with Linus' tree

[Thomas Gleixner]

On Wed, 15 Nov 2017, Mathieu Desnoyers wrote:
> ----- On Nov 15, 2017, at 10:22 AM, Thomas Gleixner tglx@linutronix.de wrote:
> > Can we please handle this as any other feature which is not ready before
> > the merge window and postpone the rseq stuff for 4.16?
> 
> Linus showed interest in merging the rseq tree when we discussed at the
> Kernel Summit. The tree has not changed much since then. I only integrated
> membarrier patches that were implemented around the time of the 4.14 merge
> window, which I queued for the 4.15 (current) window.

Linus showed interest for a lot of things in the past. That does not mean
it makes things magically complete and ready.

As Michael pointed out there is no man page, not even a draft for it
available. See: Documentation/process/adding-syscalls.rst

Aside of that, since KS I have about 400 mails, i.e. 20 per work day,
regarding this stuff in my inbox. Seriously from the sheer amount of
discussion I had the impression that this in not yet in a shape to be
merged.

Thanks,

	tglx

Re: linux-next: manual merge of the rseq tree with Linus' tree

[Mathieu Desnoyers]

----- On Nov 15, 2017, at 11:04 AM, Thomas Gleixner tglx@linutronix.de wrote:

> On Wed, 15 Nov 2017, Mathieu Desnoyers wrote:
>> ----- On Nov 15, 2017, at 10:22 AM, Thomas Gleixner tglx@linutronix.de wrote:
>> > Can we please handle this as any other feature which is not ready before
>> > the merge window and postpone the rseq stuff for 4.16?
>> 
>> Linus showed interest in merging the rseq tree when we discussed at the
>> Kernel Summit. The tree has not changed much since then. I only integrated
>> membarrier patches that were implemented around the time of the 4.14 merge
>> window, which I queued for the 4.15 (current) window.
> 
> Linus showed interest for a lot of things in the past. That does not mean
> it makes things magically complete and ready.
> 
> As Michael pointed out there is no man page, not even a draft for it
> available. See: Documentation/process/adding-syscalls.rst

The rseq commit has a manpage associated for seq. The cpu_opv does not have it
yet, nor the new membarrier commands. I plan to write those quickly after the
tree reaches master.


> Aside of that, since KS I have about 400 mails, i.e. 20 per work day,
> regarding this stuff in my inbox. Seriously from the sheer amount of
> discussion I had the impression that this in not yet in a shape to be
> merged.

The recent discussion thread was about core serialization vs migration, which is
a different topic that was raised by Andy Lutomirski. The other emails were RFC
sent out as last rounds of validation before doing the PR, and it seemed that
nobody had any objection left.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: linux-next: manual merge of the rseq tree with Linus' tree

[Thomas Gleixner]

On Wed, 15 Nov 2017, Mathieu Desnoyers wrote:

> ----- On Nov 15, 2017, at 11:04 AM, Thomas Gleixner tglx@linutronix.de wrote:
> 
> > On Wed, 15 Nov 2017, Mathieu Desnoyers wrote:
> >> ----- On Nov 15, 2017, at 10:22 AM, Thomas Gleixner tglx@linutronix.de wrote:
> >> > Can we please handle this as any other feature which is not ready before
> >> > the merge window and postpone the rseq stuff for 4.16?
> >> 
> >> Linus showed interest in merging the rseq tree when we discussed at the
> >> Kernel Summit. The tree has not changed much since then. I only integrated
> >> membarrier patches that were implemented around the time of the 4.14 merge
> >> window, which I queued for the 4.15 (current) window.
> > 
> > Linus showed interest for a lot of things in the past. That does not mean
> > it makes things magically complete and ready.
> > 
> > As Michael pointed out there is no man page, not even a draft for it
> > available. See: Documentation/process/adding-syscalls.rst
> 
> The rseq commit has a manpage associated for seq. The cpu_opv does not have it
> yet, nor the new membarrier commands. I plan to write those quickly after the
> tree reaches master.

And that's a special rule for you, right?

Documentation/process/adding-syscalls.rst is for everybody else who
implements a new syscall.

Thanks,

	tglx

Re: linux-next: manual merge of the rseq tree with Linus' tree

[Mathieu Desnoyers]

----- On Nov 15, 2017, at 11:30 AM, Thomas Gleixner tglx@linutronix.de wrote:

> On Wed, 15 Nov 2017, Mathieu Desnoyers wrote:
> 
>> ----- On Nov 15, 2017, at 11:04 AM, Thomas Gleixner tglx@linutronix.de wrote:
>> 
>> > On Wed, 15 Nov 2017, Mathieu Desnoyers wrote:
>> >> ----- On Nov 15, 2017, at 10:22 AM, Thomas Gleixner tglx@linutronix.de wrote:
>> >> > Can we please handle this as any other feature which is not ready before
>> >> > the merge window and postpone the rseq stuff for 4.16?
>> >> 
>> >> Linus showed interest in merging the rseq tree when we discussed at the
>> >> Kernel Summit. The tree has not changed much since then. I only integrated
>> >> membarrier patches that were implemented around the time of the 4.14 merge
>> >> window, which I queued for the 4.15 (current) window.
>> > 
>> > Linus showed interest for a lot of things in the past. That does not mean
>> > it makes things magically complete and ready.
>> > 
>> > As Michael pointed out there is no man page, not even a draft for it
>> > available. See: Documentation/process/adding-syscalls.rst
>> 
>> The rseq commit has a manpage associated for seq. The cpu_opv does not have it
>> yet, nor the new membarrier commands. I plan to write those quickly after the
>> tree reaches master.
> 
> And that's a special rule for you, right?
> 
> Documentation/process/adding-syscalls.rst is for everybody else who
> implements a new syscall.

I'll prepare the manpage before the PR.

Thanks,

Mathieu

> 
> Thanks,
> 
> 	tglx

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: linux-next: manual merge of the rseq tree with Linus' tree

[Mathieu Desnoyers]

----- On Nov 15, 2017, at 10:00 AM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote:

> ----- On Nov 15, 2017, at 9:48 AM, Stephen Rothwell sfr@canb.auug.org.au wrote:
> 
>> Hi Ingo,
>> 
>> On Wed, 15 Nov 2017 09:07:12 +0100 Ingo Molnar <mingo@kernel.org> wrote:
>>>
>>> There's absolutely no way such invasive x86 changes should be done outside the
>>> x86
>>> tree and be merged into linux-next.
>>> 
>>> linux-next should be for the regular maintenance flow, for changes pushed by
>>> maintainers and part of the regular maintenance process - not for
>>> work-in-progress
>>> features that may or may not be merged upstream in that form ...
>> 
>> Sure.  I was given the impression that Linus was going to be asked to
>> merge this tree during this merge window, so I assumed that it had been
>> seen by the appropriate people.  Most of these patches include you,
>> Linus and Andrew (among others) on their cc's and they seem to have
>> gone through several revisions.
>> 
>> I guess Mathieu has jumped the gun.
> 
> The membarrier core serializing command has been developed in the open
> since Aug. 27, 2017 [1]. That's one full development cycle. On Sept 28,
> 2017, I started CCing Ingo when I noticed I would have to add documentation
> to each architecture return-to-usermode paths [2]. I have never heard feedback
> from him until now.
> 
> I am open to remove the x86-specific membarrier core serializing patch from
> my tree and hand it to the x86 maintainers after the generic code makes it
> into Linus' tree, if this is seen as the appropriate way forward.

Hi Stephen,

fyi, I removed the core serializing membarrier commits from the
linux-rseq rseq/for-next branch. That work will indeed be postponed
to the 4.16 queue.

Thanks,

Mathieu

> 
> Thanks,
> 
> Mathieu
> 
> [1]
> http://lkml.kernel.org/r/20170827195404.22171-2-mathieu.desnoyers@efficios.com
> [2]
> http://lkml.kernel.org/r/911707916.20840.1506605496314.JavaMail.zimbra@efficios.com
> 
> 
>> 
>> I'll drop it again tomorrow.
>> 
>> --
>> Cheers,
>> Stephen Rothwell
> 
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

linux-next: manual merge of the rseq tree with Linus' tree

[Stephen Rothwell]

Hi Mathieu,

Today's linux-next merge of the rseq tree got a conflict in:

  kernel/sched/core.c

between commit:

  7863406143d8 ("sched/isolation: Move housekeeping related code to its own file")

from Linus' tree and commit:

  533bd7403b04 ("x86: Introduce sync_core_before_usermode (v2)")

from the rseq tree.

I fixed it up (see below) 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.

-- 
Cheers,
Stephen Rothwell

diff --cc kernel/sched/core.c
index c85dfb746f8c,43099a091742..000000000000
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@@ -27,7 -26,7 +27,8 @@@
  #include <linux/profile.h>
  #include <linux/security.h>
  #include <linux/syscalls.h>
 +#include <linux/sched/isolation.h>
+ #include <linux/processor.h>
  
  #include <asm/switch_to.h>
  #include <asm/tlb.h>