linux-stable.git/arch/arc, branch v5.7.9 Linux kernel stable tree ARC: elf: use right ELF_ARCH 2020-07-16T06:13:33+00:00 Vineet Gupta vgupta@synopsys.com 2020-05-27T21:18:45+00:00 2dcd4768a2b85eca699f049906f22d5cbb83e070 commit b7faf971081a4e56147f082234bfff55135305cb upstream. Cc: <stable@vger.kernel.org> Signed-off-by: Vineet Gupta <vgupta@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit b7faf971081a4e56147f082234bfff55135305cb upstream.

Cc: <stable@vger.kernel.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARC: entry: fix potential EFA clobber when TIF_SYSCALL_TRACE 2020-07-16T06:13:33+00:00 Vineet Gupta vgupta@synopsys.com 2020-05-20T05:28:32+00:00 1c2952b4f8a5ac9e24d5a065e384b1d8a6de5a1d commit 00fdec98d9881bf5173af09aebd353ab3b9ac729 upstream. Trap handler for syscall tracing reads EFA (Exception Fault Address), in case strace wants PC of trap instruction (EFA is not part of pt_regs as of current code). However this EFA read is racy as it happens after dropping to pure kernel mode (re-enabling interrupts). A taken interrupt could context-switch, trigger a different task's trap, clobbering EFA for this execution context. Fix this by reading EFA early, before re-enabling interrupts. A slight side benefit is de-duplication of FAKE_RET_FROM_EXCPN in trap handler. The trap handler is common to both ARCompact and ARCv2 builds too. This just came out of code rework/review and no real problem was reported but is clearly a potential problem specially for strace. Cc: <stable@vger.kernel.org> Signed-off-by: Vineet Gupta <vgupta@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 00fdec98d9881bf5173af09aebd353ab3b9ac729 upstream.

Trap handler for syscall tracing reads EFA (Exception Fault Address),
in case strace wants PC of trap instruction (EFA is not part of pt_regs
as of current code).

However this EFA read is racy as it happens after dropping to pure
kernel mode (re-enabling interrupts). A taken interrupt could
context-switch, trigger a different task's trap, clobbering EFA for this
execution context.

Fix this by reading EFA early, before re-enabling interrupts. A slight
side benefit is de-duplication of FAKE_RET_FROM_EXCPN in trap handler.
The trap handler is common to both ARCompact and ARCv2 builds too.

This just came out of code rework/review and no real problem was reported
but is clearly a potential problem specially for strace.

Cc: <stable@vger.kernel.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge tag 'arc-5.7-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc 2020-05-19T22:40:51+00:00 Linus Torvalds torvalds@linux-foundation.org 2020-05-19T22:40:51+00:00 3c9e66568ad40dc17518fa00e2b28c3b450040d4 Pull ARC fixes from Vineet Gupta: - fix recent DSP code regression on ARC700 platforms - fix thinkos in ICCM/DCCM size checks - USB regression fix - other small fixes here and there * tag 'arc-5.7-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc: ARC: show_regs: avoid extra line of output ARC: guard dsp early init against non ARCv2 ARC: [plat-eznps]: Restrict to CONFIG_ISA_ARCOMPACT ARC: entry: comment arc: remove #ifndef CONFIG_AS_CFI_SIGNAL_FRAME arc: ptrace: hard-code "arc" instead of UTS_MACHINE ARC: [plat-hsdk]: fix USB regression ARC: Fix ICCM & DCCM runtime size checks 
Pull ARC fixes from Vineet Gupta:

 - fix recent DSP code regression on ARC700 platforms

 - fix thinkos in ICCM/DCCM size checks

 - USB regression fix

 - other small fixes here and there

* tag 'arc-5.7-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
  ARC: show_regs: avoid extra line of output
  ARC: guard dsp early init against non ARCv2
  ARC: [plat-eznps]: Restrict to CONFIG_ISA_ARCOMPACT
  ARC: entry: comment
  arc: remove #ifndef CONFIG_AS_CFI_SIGNAL_FRAME
  arc: ptrace: hard-code "arc" instead of UTS_MACHINE
  ARC: [plat-hsdk]: fix USB regression
  ARC: Fix ICCM & DCCM runtime size checks
ARC: show_regs: avoid extra line of output 2020-05-14T22:05:00+00:00 Vineet Gupta vgupta@synopsys.com 2020-05-05T19:19:22+00:00 7915502377c54c9f58f6ac537bde0c2c342a6742 Signed-off-by: Vineet Gupta <vgupta@synopsys.com> 
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
ARC: guard dsp early init against non ARCv2 2020-04-29T18:53:51+00:00 Eugeniy Paltsev Eugeniy.Paltsev@synopsys.com 2020-04-28T18:50:24+00:00 40db9367ec1e653ea45400b69c3c7b80745b12eb As of today we guard early DSP init code with ARC_AUX_DSP_BUILD (0x7A) BCR check to verify that we have CPU with DSP configured. However that's not enough as in ARCv1 CPU the same BCR (0x7A) is used for checking MUL/MAC instructions presence. So, let's guard DSP early init against non ARCv2. Fixes: 4827d0cf744e ("ARC: handle DSP presence in HW") Reported-by: Angelo Ribeiro <angelor@synopsys.com> Suggested-by: Jose Abreu <oabreu@synopsys.com> Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Signed-off-by: Vineet Gupta <vgupta@synopsys.com> 
As of today we guard early DSP init code with
ARC_AUX_DSP_BUILD (0x7A) BCR check to verify that we have
CPU with DSP configured. However that's not enough as in
ARCv1 CPU the same BCR (0x7A) is used for checking MUL/MAC
instructions presence.

So, let's guard DSP early init against non ARCv2.

Fixes: 4827d0cf744e ("ARC: handle DSP presence in HW")
Reported-by: Angelo Ribeiro <angelor@synopsys.com>
Suggested-by: Jose Abreu <oabreu@synopsys.com>
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
ARC: [plat-eznps]: Restrict to CONFIG_ISA_ARCOMPACT 2020-04-27T20:00:28+00:00 Vineet Gupta vgupta@synopsys.com 2020-04-14T18:41:51+00:00 799587d5731db9dcdafaac4002463aa7d9cd6cf7 Elide invalid configuration EZNPS + ARCv2, triggered by a make allyesconfig build. Granted the root cause is in source code (asm/barrier.h) where we check for ARCv2 before PLAT_EZNPS, but it is better to avoid such combinations at onset rather then baking subtle nuances into code. Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Vineet Gupta <vgupta@synopsys.com> 
Elide invalid configuration EZNPS + ARCv2, triggered by a
make allyesconfig build.

Granted the root cause is in source code (asm/barrier.h) where we check
for ARCv2 before PLAT_EZNPS, but it is better to avoid such combinations
at onset rather then baking subtle nuances into code.

Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
arch: split MODULE_ARCH_VERMAGIC definitions out to <asm/vermagic.h> 2020-04-23T01:50:26+00:00 Masahiro Yamada masahiroy@kernel.org 2020-04-21T16:13:55+00:00 62d0fd591db1f9dcf68fb963b3a94af085a6b166 As the bug report [1] pointed out, <linux/vermagic.h> must be included after <linux/module.h>. I believe we should not impose any include order restriction. We often sort include directives alphabetically, but it is just coding style convention. Technically, we can include header files in any order by making every header self-contained. Currently, arch-specific MODULE_ARCH_VERMAGIC is defined in <asm/module.h>, which is not included from <linux/vermagic.h>. Hence, the straight-forward fix-up would be as follows: |--- a/include/linux/vermagic.h |+++ b/include/linux/vermagic.h |@@ -1,5 +1,6 @@ | /* SPDX-License-Identifier: GPL-2.0 */ | #include <generated/utsrelease.h> |+#include <linux/module.h> | | /* Simply sanity version stamp for modules. */ | #ifdef CONFIG_SMP This works enough, but for further cleanups, I split MODULE_ARCH_VERMAGIC definitions into <asm/vermagic.h>. With this, <linux/module.h> and <linux/vermagic.h> will be orthogonal, and the location of MODULE_ARCH_VERMAGIC definitions will be consistent. For arc and ia64, MODULE_PROC_FAMILY is only used for defining MODULE_ARCH_VERMAGIC. I squashed it. For hexagon, nds32, and xtensa, I removed <asm/modules.h> entirely because they contained nothing but MODULE_ARCH_VERMAGIC definition. Kbuild will automatically generate <asm/modules.h> at build-time, wrapping <asm-generic/module.h>. [1] https://lore.kernel.org/lkml/20200411155623.GA22175@zn.tnic Reported-by: Borislav Petkov <bp@suse.de> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Jessica Yu <jeyu@kernel.org> 
As the bug report [1] pointed out, <linux/vermagic.h> must be included
after <linux/module.h>.

I believe we should not impose any include order restriction. We often
sort include directives alphabetically, but it is just coding style
convention. Technically, we can include header files in any order by
making every header self-contained.

Currently, arch-specific MODULE_ARCH_VERMAGIC is defined in
<asm/module.h>, which is not included from <linux/vermagic.h>.

Hence, the straight-forward fix-up would be as follows:

|--- a/include/linux/vermagic.h
|+++ b/include/linux/vermagic.h
|@@ -1,5 +1,6 @@
| /* SPDX-License-Identifier: GPL-2.0 */
| #include <generated/utsrelease.h>
|+#include <linux/module.h>
|
| /* Simply sanity version stamp for modules. */
| #ifdef CONFIG_SMP

This works enough, but for further cleanups, I split MODULE_ARCH_VERMAGIC
definitions into <asm/vermagic.h>.

With this, <linux/module.h> and <linux/vermagic.h> will be orthogonal,
and the location of MODULE_ARCH_VERMAGIC definitions will be consistent.

For arc and ia64, MODULE_PROC_FAMILY is only used for defining
MODULE_ARCH_VERMAGIC. I squashed it.

For hexagon, nds32, and xtensa, I removed <asm/modules.h> entirely
because they contained nothing but MODULE_ARCH_VERMAGIC definition.
Kbuild will automatically generate <asm/modules.h> at build-time,
wrapping <asm-generic/module.h>.

[1] https://lore.kernel.org/lkml/20200411155623.GA22175@zn.tnic

Reported-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Jessica Yu <jeyu@kernel.org>
ARC: entry: comment 2020-04-13T05:45:35+00:00 Vineet Gupta vgupta@synopsys.com 2020-04-10T21:22:05+00:00 49b41356f74b95d1b913aed2f964999a55f5235e Signed-off-by: Vineet Gupta <vgupta@synopsys.com> 
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
arc: remove #ifndef CONFIG_AS_CFI_SIGNAL_FRAME 2020-04-13T05:27:10+00:00 Masahiro Yamada masahiroy@kernel.org 2020-04-13T02:05:38+00:00 a75ff01390339643ebb86382bfcfe8b1b734e870 CONFIG_AS_CFI_SIGNAL_FRAME is never defined for ARC. Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Vineet Gupta <vgupta@synopsys.com> 
CONFIG_AS_CFI_SIGNAL_FRAME is never defined for ARC.

Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
arc: ptrace: hard-code "arc" instead of UTS_MACHINE 2020-04-13T05:27:09+00:00 Masahiro Yamada masahiroy@kernel.org 2020-04-13T01:32:40+00:00 9eca345c67ad69652d54fd929830758c324f25ca ARC uses the UTS_MACHINE defined in the top Makefile as follows: UTS_MACHINE := $(ARCH) We know it is "arc" when we are building the kernel for ARC. Hard-code user_regset_view::name, like many other architectures do. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Vineet Gupta <vgupta@synopsys.com> 
ARC uses the UTS_MACHINE defined in the top Makefile as follows:

  UTS_MACHINE     := $(ARCH)

We know it is "arc" when we are building the kernel for ARC.
Hard-code user_regset_view::name, like many other architectures do.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>