Re: [PATCH v3] asm-generic ABI: Allow statx syscall despite fstatat64, fstat64

2020-02-24 Thread Vineet Gupta
On 2/24/20 4:29 PM, Vineet Gupta wrote: > An old version of asm-generic syscall ABI (e.g. ARC 2013) provided > fstat[at]64 syscalls for implementing the stat family. > > These sycalls are passthru (no interworking/itemized-copy needed > between kernel and user structs since they are binary comapti

Re: [PATCH] Force 64-bit time based syscalls for TIMESIZE==64 on 32-bit arches

2020-02-24 Thread Vineet Gupta
On 2/24/20 4:59 PM, Alistair Francis wrote: >> +/* Override syscalls for asm-generic ABIs with 64-bit time. */ >> +#if __WORDSIZE == 32 && __TIMESIZE == 64 >> + >> +# undef __NR_futex >> +# define __NR_futex __NR_futex_time64 > I think you should do what RV32 does and wrap these in ifndef's ARC a

Re: [PATCH] Force 64-bit time based syscalls for TIMESIZE==64 on 32-bit arches

2020-02-24 Thread Alistair Francis
On Mon, Feb 24, 2020 at 10:34 AM Vineet Gupta wrote: > > This provides better out-of-box support for 32-bit arches with 64-bit > time_t > > Signed-off-by: Vineet Gupta > --- > sysdeps/unix/sysv/linux/generic/sysdep.h | 48 > 1 file changed, 48 insertions(+) > > diff --gi

[PATCH v3] asm-generic ABI: Allow statx syscall despite fstatat64, fstat64

2020-02-24 Thread Vineet Gupta
An old version of asm-generic syscall ABI (e.g. ARC 2013) provided fstat[at]64 syscalls for implementing the stat family. These sycalls are passthru (no interworking/itemized-copy needed between kernel and user structs since they are binary comaptible). However with switch to 64-bit time_t the com

Re: [PATCH v2] asm-generic ABI: Allow statx syscall despite fstatat64,fstat64

2020-02-24 Thread Joseph Myers
On Mon, 24 Feb 2020, Vineet Gupta wrote: > diff --git a/sysdeps/unix/sysv/linux/fxstat64.c > b/sysdeps/unix/sysv/linux/fxstat64.c > index 9133a0a29b8e..93394c450f1c 100644 > --- a/sysdeps/unix/sysv/linux/fxstat64.c > +++ b/sysdeps/unix/sysv/linux/fxstat64.c > @@ -33,15 +33,15 @@ int > ___fxstat6

Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)

2020-02-24 Thread Joseph Myers
On Mon, 24 Feb 2020, Lukasz Majewski wrote: > I'm probably not aware of something - but as done in the following > patch: > > https://github.com/lmajewski/y2038_glibc/commit/c96eeb73175961c4ac80fdd3b6adc132805387c9 > > I do need to remove librt_hidden_proto / librt_hidden_def to have > proper sy

[PATCH v2] asm-generic ABI: Allow statx syscall despite fstatat64, fstat64

2020-02-24 Thread Vineet Gupta
An old version of asm-generic syscall ABI (e.g. ARC 2013) provided fstat[at]64 syscalls for implementing the stat family. These sycalls are passthru (no interworking/itemized-copy needed between kernel and user structs since they are binary comaptible). However with switch to 64-bit time_t the com

kisskb: OK linus/axs101_defconfig/arcompact Tue Feb 25, 08:15

2020-02-24 Thread noreply
OK linus/axs101_defconfig/arcompact Tue Feb 25, 08:15 http://kisskb.ellerman.id.au/kisskb/buildresult/14151568/ Commit: Merge tag 'linux-watchdog-5.6-rc3' of git://www.linux-watchdog.org/linux-watchdog 0c0ddd6ae47c9238c18f475bcca675ca74c9dc31 Compiler: arc-buildroot-linux-uclibc-gcc

kisskb: OK linus/axs103_smp_defconfig/arcv2 Tue Feb 25, 08:15

2020-02-24 Thread noreply
OK linus/axs103_smp_defconfig/arcv2 Tue Feb 25, 08:15 http://kisskb.ellerman.id.au/kisskb/buildresult/14151567/ Commit: Merge tag 'linux-watchdog-5.6-rc3' of git://www.linux-watchdog.org/linux-watchdog 0c0ddd6ae47c9238c18f475bcca675ca74c9dc31 Compiler: arc-linux-gcc.br_real (Buildroo

Re: [PATCH] asm-generic ABI: Allow statx syscall despite fstatat64, fstat64

2020-02-24 Thread Florian Weimer
* Vineet Gupta: > On 2/24/20 11:13 AM, Florian Weimer wrote: >> * Vineet Gupta: >> >>> On 2/24/20 10:39 AM, Florian Weimer wrote: > +# undef STAT64_IS_NOT_KERNEL_STAT64 Sorry, I think that going forward, we prefer that such macros are always defined, with values 0 or 1 as appropriat

Re: [PATCH] asm-generic ABI: Allow statx syscall despite fstatat64,fstat64

2020-02-24 Thread Vineet Gupta
On 2/24/20 11:13 AM, Florian Weimer wrote: > * Vineet Gupta: > >> On 2/24/20 10:39 AM, Florian Weimer wrote: +# undef STAT64_IS_NOT_KERNEL_STAT64 >>> Sorry, I think that going forward, we prefer that such macros are always >>> defined, with values 0 or 1 as appropriate. >> >> And that means w

Re: [PATCH] asm-generic ABI: Allow statx syscall despite fstatat64, fstat64

2020-02-24 Thread Florian Weimer
* Vineet Gupta: > On 2/24/20 10:39 AM, Florian Weimer wrote: >>> +# undef STAT64_IS_NOT_KERNEL_STAT64 >> >> Sorry, I think that going forward, we prefer that such macros are always >> defined, with values 0 or 1 as appropriate. > > And that means we also need to additionally define this to 0 in al

Re: [PATCH] asm-generic ABI: Allow statx syscall despite fstatat64,fstat64

2020-02-24 Thread Vineet Gupta
On 2/24/20 10:39 AM, Florian Weimer wrote: >> +# undef STAT64_IS_NOT_KERNEL_STAT64 > > Sorry, I think that going forward, we prefer that such macros are always > defined, with values 0 or 1 as appropriate. And that means we also need to additionally define this to 0 in all ports which don't end up

Re: [PATCH] asm-generic ABI: Allow statx syscall despite fstatat64, fstat64

2020-02-24 Thread Florian Weimer
* Vineet Gupta: > +/* Ports define to 1 when glibc struct stat64 is not compatible with > + kernel stat64. This forces use of statx syscall (and explicit > interworking) > + even when fstat64 syscall is available. For asm-generic ABI this happened > + with switch to 64-bit time_t. */ > + >

kisskb: OK linus/axs103_smp_defconfig/arcv2 Tue Feb 25, 05:35

2020-02-24 Thread noreply
OK linus/axs103_smp_defconfig/arcv2 Tue Feb 25, 05:35 http://kisskb.ellerman.id.au/kisskb/buildresult/14151236/ Commit: Merge branch 'akpm' (patches from Andrew) b0dd1eb220c06892e0a4098378c4296650f3f8db Compiler: arc-linux-gcc.br_real (Buildroot 2016.11-git-00613-ge98b4dd) 6.2.1 2016

kisskb: OK linus/axs101_defconfig/arcompact Tue Feb 25, 05:35

2020-02-24 Thread noreply
OK linus/axs101_defconfig/arcompact Tue Feb 25, 05:35 http://kisskb.ellerman.id.au/kisskb/buildresult/14151237/ Commit: Merge branch 'akpm' (patches from Andrew) b0dd1eb220c06892e0a4098378c4296650f3f8db Compiler: arc-buildroot-linux-uclibc-gcc (Buildroot 2015.08.1) 4.8.4 / GNU ld (GN

[PATCH] Force 64-bit time based syscalls for TIMESIZE==64 on 32-bit arches

2020-02-24 Thread Vineet Gupta
This provides better out-of-box support for 32-bit arches with 64-bit time_t Signed-off-by: Vineet Gupta --- sysdeps/unix/sysv/linux/generic/sysdep.h | 48 1 file changed, 48 insertions(+) diff --git a/sysdeps/unix/sysv/linux/generic/sysdep.h b/sysdeps/unix/sysv/linux/

[PATCH] asm-generic ABI: Allow statx syscall despite fstatat64, fstat64

2020-02-24 Thread Vineet Gupta
An old version of asm-generic syscall ABI (e.g. ARC 2013) provided fstat[at]64 syscalls for implementing the stat family. These sycalls are passthru (no interworking/itemized-copy needed between kernel and user structs since they are binary comaptible). However with switch to 64-bit time_t the com

Re: [RESEND PATCH v2 9/9] ath5k: Constify ioreadX() iomem argument (as in generic implementation)

2020-02-24 Thread Krzysztof Kozlowski
On Mon, Feb 24, 2020 at 01:54:00PM +0100, Geert Uytterhoeven wrote: > Hi Krzysztof, > > On Mon, Feb 24, 2020 at 1:47 PM Krzysztof Kozlowski wrote: > > On Thu, Feb 20, 2020 at 10:48:33AM +0100, Jiri Slaby wrote: > > > On 19. 02. 20, 18:50, Krzysztof Kozlowski wrote: > > > > The ioreadX() helpers h

RE: [RESEND PATCH v2 9/9] ath5k: Constify ioreadX() iomem argument (as in generic implementation)

2020-02-24 Thread David Laight
From: Geert Uytterhoeven > Sent: 24 February 2020 12:54 > To: Krzysztof Kozlowski ... > > > > diff --git a/drivers/net/wireless/ath/ath5k/ahb.c > > > > b/drivers/net/wireless/ath/ath5k/ahb.c > > > > index 2c9cec8b53d9..8bd01df369fb 100644 > > > > --- a/drivers/net/wireless/ath/ath5k/ahb.c > > > >

Re: [RESEND PATCH v2 9/9] ath5k: Constify ioreadX() iomem argument (as in generic implementation)

2020-02-24 Thread Geert Uytterhoeven
Hi Krzysztof, On Mon, Feb 24, 2020 at 1:47 PM Krzysztof Kozlowski wrote: > On Thu, Feb 20, 2020 at 10:48:33AM +0100, Jiri Slaby wrote: > > On 19. 02. 20, 18:50, Krzysztof Kozlowski wrote: > > > The ioreadX() helpers have inconsistent interface. On some architectures > > > void *__iomem address a

Re: [RESEND PATCH v2 9/9] ath5k: Constify ioreadX() iomem argument (as in generic implementation)

2020-02-24 Thread Krzysztof Kozlowski
On Thu, Feb 20, 2020 at 10:48:33AM +0100, Jiri Slaby wrote: > On 19. 02. 20, 18:50, Krzysztof Kozlowski wrote: > > The ioreadX() helpers have inconsistent interface. On some architectures > > void *__iomem address argument is a pointer to const, on some not. > > > > Implementations of ioreadX() d

Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)

2020-02-24 Thread Lukasz Majewski
Dear All, > On Mon, 24 Feb 2020 11:42:23 +0100 > Andreas Schwab wrote: > > > On Feb 24 2020, Lukasz Majewski wrote: > > > > > On Mon, 24 Feb 2020 11:23:51 +0100 > > > Andreas Schwab wrote: > > > > > >> On Feb 24 2020, Lukasz Majewski wrote: > > >> > > >> > If I add those functions a

Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)

2020-02-24 Thread Lukasz Majewski
On Mon, 24 Feb 2020 11:42:23 +0100 Andreas Schwab wrote: > On Feb 24 2020, Lukasz Majewski wrote: > > > On Mon, 24 Feb 2020 11:23:51 +0100 > > Andreas Schwab wrote: > > > >> On Feb 24 2020, Lukasz Majewski wrote: > >> > >> > If I add those functions as hidden_alias then those would be > >>

Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)

2020-02-24 Thread Andreas Schwab
On Feb 24 2020, Lukasz Majewski wrote: > On Mon, 24 Feb 2020 11:23:51 +0100 > Andreas Schwab wrote: > >> On Feb 24 2020, Lukasz Majewski wrote: >> >> > If I add those functions as hidden_alias then those would be >> > accessible inside glibc without PLT, but will not be exported (and >> > redire

Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)

2020-02-24 Thread Lukasz Majewski
On Mon, 24 Feb 2020 11:23:51 +0100 Andreas Schwab wrote: > On Feb 24 2020, Lukasz Majewski wrote: > > > If I add those functions as hidden_alias then those would be > > accessible inside glibc without PLT, but will not be exported (and > > redirection for Y2038 will not work). > > They aren't

Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)

2020-02-24 Thread Andreas Schwab
On Feb 24 2020, Lukasz Majewski wrote: > If I add those functions as hidden_alias then those would be accessible > inside glibc without PLT, but will not be exported (and redirection for > Y2038 will not work). They aren't? PLT avoidance is about internal references, and uses a different name th

Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)

2020-02-24 Thread Lukasz Majewski
Hi Andreas, > On Feb 24 2020, Lukasz Majewski wrote: > > >> elf/check-localplt complains about the newly added symbols > >> > >> Extra PLT reference: libc.so: __lutimes64 > >> Extra PLT reference: libc.so: __wait4_time64 > >> Extra PLT reference: libc.so: __setitimer64 > >> Extra PLT reference:

Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)

2020-02-24 Thread Andreas Schwab
On Feb 24 2020, Lukasz Majewski wrote: >> elf/check-localplt complains about the newly added symbols >> >> Extra PLT reference: libc.so: __lutimes64 >> Extra PLT reference: libc.so: __wait4_time64 >> Extra PLT reference: libc.so: __setitimer64 >> Extra PLT reference: libc.so: __utime64 >> Extra P

Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)

2020-02-24 Thread Lukasz Majewski
Hi Arnd, > On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski > wrote: > > > [2] - https://github.com/lmajewski/y2038_glibc/commits/y2038_edge > > I tried packaging this into a .deb package for use with rebootstrap, > but ran into a couple of test failures from glibc itself, when > testing the