sh: use generic uaccess

From: Arnd Bergmann <[email protected]>

As reported by many people, the nommu SH code runs into a compiler error with a newly added syscall:

  + {standard input}: Error: displacement to undefined symbol .L105 overflows 8-bit field :  => 590, 593
  + {standard input}: Error: displacement to undefined symbol .L135 overflows 8-bit field :  => 603
  + {standard input}: Error: displacement to undefined symbol .L140 overflows 8-bit field :  => 606

+ {standard input}: Error: displacement to undefined symbol .L76 overflows 12-bit field: => 591, 594
+ {standard input}: Error: displacement to undefined symbol .L77 overflows 8-bit field : 607 => 607, 582, 585
+ {standard input}: Error: displacement to undefined symbol .L97 overflows 12-bit field: => 607
+ {standard input}: Error: pcrel too far: 604, 590, 577, 593, 572, 569, 598, 599, 596, 610 => 610, 574, 599, 569, 598, 596, 601, 590, 604, 595, 572, 577, 593

Avoid the code that triggers this entirely by using the same generic uaccess code that m68k and riscv have on nommu.

Link https://lore.kernel.org/all/[email protected]/ open here

Signed-off-by Arnd Bergmann <[email protected]>

---
 arch/sh/include/asm/uaccess.h    |  5 +++++
 arch/sh/include/asm/uaccess_32.h | 23 -----------------------
 2 files changed, 5 insertions(+), 23 deletions(-)

arch/sh/include/asm/uaccess.h +5 -0

index a79609eb14be..b42764d55901 100644
@@ -2,6 +2,7 @@
 #ifndef __ASM_SH_UACCESS_H
 #define __ASM_SH_UACCESS_H
 
+#ifdef CONFIG_MMU
 #include <asm/extable.h>
 #include <asm-generic/access_ok.h>
 

@@ -130,4 +131,8 @@ struct mem_access {
 int handle_unaligned_access(insn_size_t instruction, struct pt_regs *regs,
 			    struct mem_access *ma, int, unsigned long address);
 
+#else
+#include <asm-generic/uaccess.h>
+#endif
+
 #endif /* __ASM_SH_UACCESS_H */

arch/sh/include/asm/uaccess_32.h +0 -16

index 5d7ddc092afd..e053f2fd245c 100644
@@ -35,7 +35,6 @@ do {								\
 	}							\
 } while (0)
 
-#ifdef CONFIG_MMU
 #define __get_user_asm(x, addr, err, insn) \
 ({ \
 __asm__ __volatile__( \

@@ -56,16 +55,6 @@ __asm__ __volatile__( \
 	".previous" \
 	:"=&r" (err), "=&r" (x) \
 	:"m" (__m(addr)), "i" (-EFAULT), "0" (err)); })
-#else
-#define __get_user_asm(x, addr, err, insn)		\
-do {							\
-	__asm__ __volatile__ (				\
-		"mov." insn "	%1, %0\n\t"		\
-		: "=&r" (x)				\
-		: "m" (__m(addr))			\
-	);						\
-} while (0)
-#endif /* CONFIG_MMU */
 
 extern void __get_user_unknown(void);
 

@@ -140,7 +129,6 @@ do {							\
 	}						\
 } while (0)
 
-#ifdef CONFIG_MMU
 #define __put_user_asm(x, addr, err, insn)			\
 do {								\
 	__asm__ __volatile__ (					\

@@ -164,17 +152,6 @@ do {								\
 		: "memory"					\
 	);							\
 } while (0)
-#else
-#define __put_user_asm(x, addr, err, insn)		\
-do {							\
-	__asm__ __volatile__ (				\

Wouldn't that make these operations slower or do you think that GCC is able to optimize this well enough?

Also, this is something that should definitely be boot-tested to make sure this doesn't introduce any regressions.

Quoted 3 lines · John Paul Adrian Glaubitz

Wouldn't that make these operations slower or do you think that GCC is able to optimize this well enough?

It's only single load/store instructions, so it should make no difference. If anything, the generic code should allow the compiler to have better register allocation and produce better output than the assembler version (which is how this avoids the ICE), but it's unlikely to be noticeably either.

Quoted 2 lines

Also, this is something that should definitely be boot-tested to make sure this doesn't introduce any regressions.

Agree.

Quoted 5 lines · Arnd Bergmann

Quoted 3 lines · John Paul Adrian Glaubitz

Wouldn't that make these operations slower or do you think that GCC is able to optimize this well enough?

Quoted 5 lines

It's only single load/store instructions, so it should make no difference. If anything, the generic code should allow the compiler to have better register allocation and produce better output than the assembler version (which is how this avoids the ICE), but it's unlikely to be noticeably either.

I have not seen an ICE on v6.8-rc1 so far. What config was it that triggered it?