[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <750091485.16756.1517921554396.JavaMail.zimbra@efficios.com>
Date: Tue, 6 Feb 2018 12:52:34 +0000 (UTC)
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: Stephen Rothwell <sfr@...b.auug.org.au>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
"H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Linux-Next Mailing List <linux-next@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Will Deacon <will.deacon@....com>
Subject: Re: linux-next: manual merge of the tip tree with Linus' tree
----- On Feb 5, 2018, at 7:40 PM, Stephen Rothwell sfr@...b.auug.org.au wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/arm64/kernel/entry.S
>
> between commit:
>
> 4bf3286d29f3 ("arm64: entry: Hook up entry trampoline to exception vectors")
>
> from Linus' tree and commit:
>
> f1e3a12b6543 ("membarrier/arm64: Provide core serializing command")
>
> from the tip tree.
>
> I fixed it up (probably not completely - 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.
The change introduced by 4bf3286d29 "arm64: entry: Hook up entry trampoline
to exception vectors" adds a trampoline as mechanism for return:
- eret // return to kernel
+
+#ifndef CONFIG_UNMAP_KERNEL_AT_EL0
+ eret
+#else
+ .if \el == 0
+ bne 4f
+ msr far_el1, x30
+ tramp_alias x30, tramp_exit_native
+ br x30
+4:
+ tramp_alias x30, tramp_exit_compat
+ br x30
+ .else
+ eret
+ .endif
+#endif
Which means that with CONFIG_UNMAP_KERNEL_AT_EL0, for return to EL0,
the eret is in the trampoline:
.macro tramp_exit, regsize = 64
adr x30, tramp_vectors
msr vbar_el1, x30
tramp_unmap_kernel x30
.if \regsize == 64
mrs x30, far_el1
.endif
eret
.endm
ENTRY(tramp_exit_native)
tramp_exit
END(tramp_exit_native)
ENTRY(tramp_exit_compat)
tramp_exit 32
END(tramp_exit_compat)
One approach I would consider for this is to duplicate this
comment and add it just above the "eret" instruction within the
macro:
/*
* ARCH_HAS_MEMBARRIER_SYNC_CORE rely on eret context synchronization
* when returning from IPI handler, and when returning to user-space.
*/
Or perhaps Will has something else in mind ?
Thanks,
Mathieu
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/arm64/kernel/entry.S
> index b34e717d7597,5edde1c2e93e..000000000000
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@@ -324,21 -302,11 +324,25 @@@ alternative_else_nop_endi
> ldp x28, x29, [sp, #16 * 14]
> ldr lr, [sp, #S_LR]
> add sp, sp, #S_FRAME_SIZE // restore sp
> +
> + .if \el == 0
> +alternative_insn eret, nop, ARM64_UNMAP_KERNEL_AT_EL0
> +#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
> + bne 4f
> + msr far_el1, x30
> + tramp_alias x30, tramp_exit_native
> + br x30
> +4:
> + tramp_alias x30, tramp_exit_compat
> + br x30
> +#endif
> + .else
> + /*
> + * ARCH_HAS_MEMBARRIER_SYNC_CORE rely on eret context synchronization
> + * when returning from IPI handler, and when returning to user-space.
> + */
> - eret // return to kernel
> + eret
> + .endif
> .endm
>
> .macro irq_stack_entry
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
Powered by blists - more mailing lists