On Thu, Jul 22, 2021 at 04:01:39PM +0200, Arnd Bergmann wrote:
> On Thu, Jul 22, 2021 at 3:57 PM Johannes Berg
> wrote:
> >
> > >
> > > The remaining architectures at the moment are: ia64, mips, parisc,
> > > s390, um and xtensa. We should probably convert these as well, but
> >
> > I'm not sure
On 7/22/21 5:48 AM, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Remove the arc implemenation of strncpy/strnlen and instead use the
> generic versions. The arc version is fairly slow because it always does
> byte accesses even for aligned data, and its checks for user_addr_max()
> differ from
On Jul 22 2021, Andreas Schwab wrote:
>
> On Jul 22 2021, Vladimir Isaev via Libc-alpha wrote:
>
> > diff --git a/elf/dl-runtime.c b/elf/dl-runtime.c
> > index 9d0d941000..6099a44ffb 100644
> > --- a/elf/dl-runtime.c
> > +++ b/elf/dl-runtime.c
> > @@ -56,7 +56,7 @@ _dl_fixup (
> > # ifdef ELF_MA
This came up during arc64 glibc bringup on qemu usermode.
On ARC, lazy rezolver calls _dl_fixup() with 2nd argument as PC of the
PLT entry beiing fixed up. Thus this needs to be full 64-bit value for
arc64, however _dl_fixup() defines @reloc_arg as ElfW(Word) which maps
to Elf64_Word -> uint32_t c
On Thu, Jul 22, 2021 at 3:57 PM Johannes Berg wrote:
>
> >
> > The remaining architectures at the moment are: ia64, mips, parisc,
> > s390, um and xtensa. We should probably convert these as well, but
>
> I'm not sure it makes sense to convert um, the implementation uses
> strncpy(), and that shou
>
> The remaining architectures at the moment are: ia64, mips, parisc,
> s390, um and xtensa. We should probably convert these as well, but
I'm not sure it makes sense to convert um, the implementation uses
strncpy(), and that should use the libc implementation, which is tuned
for the actual hard
On Jul 22 2021, Vladimir Isaev via Libc-alpha wrote:
> diff --git a/elf/dl-runtime.c b/elf/dl-runtime.c
> index 9d0d941000..6099a44ffb 100644
> --- a/elf/dl-runtime.c
> +++ b/elf/dl-runtime.c
> @@ -56,7 +56,7 @@ _dl_fixup (
> # ifdef ELF_MACHINE_RUNTIME_FIXUP_ARGS
> ELF_MACHINE_RUNTIME_F
On Thu, Jul 22, 2021 at 02:48:13PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> As these are now in asm-generic, it's no longer necessary to
> declare them in the architecture.
Looks good,
Reviewed-by: Christoph Hellwig
___
linux-snps-arc m
On Thu, Jul 22, 2021 at 02:48:14PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Most architectures do not need a custom implementation, and in most
> cases the generic implementation is preferred, so change the polariy
> on these Kconfig symbols to require architectures to select them wh
On Thu, Jul 22, 2021 at 02:48:12PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The inline version is used on three NOMMU architectures and is
> particularly inefficient when it scans the string one byte at a time
> twice. It also lacks a check for user_addr_max(), but this is
> probably
On Thu, Jul 22, 2021 at 02:48:11PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Remove the microblaze implemenation of strncpy/strnlen and instead use
> the generic versions. The microblaze version is fairly slow because it
> always does byte accesses even for aligned data, and it lacks
On Thu, Jul 22, 2021 at 02:48:10PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Remove the csky implemenation of strncpy/strnlen and instead use the
> generic versions. The csky version is fairly slow because it always does
> byte accesses even for aligned data, and it lacks a checks fo
On Thu, Jul 22, 2021 at 02:48:09PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Remove the arc implemenation of strncpy/strnlen and instead use the
> generic versions. The arc version is fairly slow because it always does
> byte accesses even for aligned data, and its checks for user_ad
On Thu, Jul 22, 2021 at 02:48:08PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Remove the hexagon implementation of strncpy/strnlen and instead use
> the generic version. The hexagon version reads the data twice for
> strncpy() by doing an extra strnlen(), and it apparently lacks a che
On Thu, Jul 22, 2021 at 02:48:07PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> This function is never called because h8300 uses the asm-generic
> inline function version.
>
> Signed-off-by: Arnd Bergmann
Looks good,
Reviewed-by: Christoph Hellwig
__
Looks good,
Reviewed-by: Christoph Hellwig
Note that the uml version has a minor conflict with my pending set_fs()
removal for uml, but that should be easy to resolve.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.inf
From: Arnd Bergmann
Most architectures do not need a custom implementation, and in most
cases the generic implementation is preferred, so change the polariy
on these Kconfig symbols to require architectures to select them when
they provide their own version.
The new name is CONFIG_ARCH_HAS_{STRN
From: Arnd Bergmann
As these are now in asm-generic, it's no longer necessary to
declare them in the architecture.
Signed-off-by: Arnd Bergmann
---
arch/arc/include/asm/uaccess.h | 5 -
arch/hexagon/include/asm/uaccess.h | 6 --
arch/um/include/asm/uaccess.h | 5 +
3 files
From: Arnd Bergmann
The inline version is used on three NOMMU architectures and is
particularly inefficient when it scans the string one byte at a time
twice. It also lacks a check for user_addr_max(), but this is
probably ok on NOMMU targets.
Consolidate the asm-generic implementation with the
From: Arnd Bergmann
Remove the microblaze implemenation of strncpy/strnlen and instead use
the generic versions. The microblaze version is fairly slow because it
always does byte accesses even for aligned data, and it lacks a checks
for user_addr_max().
Signed-off-by: Arnd Bergmann
---
arch/m
From: Arnd Bergmann
Remove the csky implemenation of strncpy/strnlen and instead use the
generic versions. The csky version is fairly slow because it always does
byte accesses even for aligned data, and it lacks a checks for
user_addr_max().
Signed-off-by: Arnd Bergmann
---
arch/csky/Kconfig
From: Arnd Bergmann
Remove the hexagon implementation of strncpy/strnlen and instead use
the generic version. The hexagon version reads the data twice for
strncpy() by doing an extra strnlen(), and it apparently lacks a check
for user_addr_max().
Signed-off-by: Arnd Bergmann
---
arch/hexagon/
From: Arnd Bergmann
Remove the arc implemenation of strncpy/strnlen and instead use the
generic versions. The arc version is fairly slow because it always does
byte accesses even for aligned data, and its checks for user_addr_max()
differ from the generic code.
Signed-off-by: Arnd Bergmann
---
From: Arnd Bergmann
I had run into some regressions for the previous version of this
series, the new version is based on v5.14-rc2 instead.
These two functions appear to be unnecessarily different between
architectures, and the asm-generic version is a bit questionable,
even for NOMMU architectu
From: Arnd Bergmann
This function is never called because h8300 uses the asm-generic
inline function version.
Signed-off-by: Arnd Bergmann
---
arch/h8300/kernel/h8300_ksyms.c | 2 --
arch/h8300/lib/Makefile | 2 +-
arch/h8300/lib/strncpy.S| 35
From: Arnd Bergmann
This is a preparation for changing over architectures to the
generic implementation one at a time. As there are no callers
of either __strncpy_from_user() or __strnlen_user(), fold these
into the strncpy_from_user() and strnlen_user() functions to make
each implementation inde
26 matches
Mail list logo
