[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1ab7594855718e24ddc629ebbab1edc8bdcd799a.camel@physik.fu-berlin.de>
Date: Tue, 23 Jan 2024 14:55:35 +0100
From: John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
To: Arnd Bergmann <arnd@...nel.org>, Yoshinori Sato
<ysato@...rs.sourceforge.jp>, Rich Felker <dalias@...c.org>
Cc: Arnd Bergmann <arnd@...db.de>, linux-sh@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org
Subject: Re: [PATCH] sh: use generic uaccess
Hi Arnd,
On Tue, 2024-01-23 at 14:23 +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@...db.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@...db.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
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Powered by blists - more mailing lists