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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> * Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel]     [Linux USB Development]     [Yosemite News]     [Linux SCSI]

  Powered by Linux