sh: use generic uaccess

  From: Arnd Bergmann <arnd@arndb.de>

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/07d8877b-d933-46f4-8ca4-c10ed602f37e@app.fastmail.com/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/sh/include/asm/uaccess.h    |  5 +++++
 arch/sh/include/asm/uaccess_32.h | 23 -----------------------
 2 files changed, 5 insertions(+), 23 deletions(-)
  

Hi Arnd,

On Tue, 2024-01-23 at 14:23 +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> 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/07d8877b-d933-46f4-8ca4-c10ed602f37e@app.fastmail.com/
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  arch/sh/include/asm/uaccess.h    |  5 +++++
>  arch/sh/include/asm/uaccess_32.h | 23 -----------------------
>  2 files changed, 5 insertions(+), 23 deletions(-)
> 
> diff --git a/arch/sh/include/asm/uaccess.h b/arch/sh/include/asm/uaccess.h
> index a79609eb14be..b42764d55901 100644
> --- a/arch/sh/include/asm/uaccess.h
> +++ b/arch/sh/include/asm/uaccess.h
> @@ -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 */
> diff --git a/arch/sh/include/asm/uaccess_32.h b/arch/sh/include/asm/uaccess_32.h
> index 5d7ddc092afd..e053f2fd245c 100644
> --- a/arch/sh/include/asm/uaccess_32.h
> +++ b/arch/sh/include/asm/uaccess_32.h
> @@ -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__ (				\
> -		"mov." insn "	%0, %1\n\t"		\
> -		: /* no outputs */			\
> -		: "r" (x), "m" (__m(addr))		\
> -		: "memory"				\
> -	);						\
> -} while (0)
> -#endif /* CONFIG_MMU */
>  
>  #if defined(CONFIG_CPU_LITTLE_ENDIAN)
>  #define __put_user_u64(val,addr,retval) \

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.

Adrian
  

On Tue, Jan 23, 2024, at 14:55, John Paul Adrian Glaubitz wrote:
>
> 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.

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

Agree.

      Arnd
  

Hi Arnd,

On Tue, 2024-01-23 at 15:14 +0100, Arnd Bergmann wrote:
> On Tue, Jan 23, 2024, at 14:55, John Paul Adrian Glaubitz wrote:
> > 
> > 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.

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

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

Adrian
  

Hi Adrian,

On Tue, Jan 23, 2024 at 3:20 PM John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Tue, 2024-01-23 at 15:14 +0100, Arnd Bergmann wrote:
> > On Tue, Jan 23, 2024, at 14:55, John Paul Adrian Glaubitz wrote:
> > >
> > > 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.
>
> I have not seen an ICE on v6.8-rc1 so far. What config was it that triggered it?

v6.8-rc1/sh4-gcc12/sh-allmodconfig
v6.8-rc1/sh4-gcc11/sh-allyesconfig
v6.8-rc1/sh4-gcc13/sh-allmodconfig
v6.8-rc1/sh4-gcc13/sh-allyesconfig

e.g. http://kisskb.ellerman.id.au/kisskb/buildresult/15111229/

Gr{oetje,eeting}s,

                        Geert