Re: [PATCH 1/3] y2038: linux: Provide __futimes64 implementation
On Mon, 6 Jul 2020 22:58:27 +
Vineet Gupta wrote:
> Hi Lukasz,
>
> On 2/17/20 5:17 AM, Lukasz Majewski wrote:
> > This patch provides new __futimes64 explicit 64 bit function for
> > setting file's 64 bit attributes for access and modification time
> > (by specifying file descriptor number).
> >
> > Internally, the __utimensat64_helper function is used. This patch
> > is necessary for having architectures with __WORDSIZE == 32 Y2038
> > safe.
> >
> > Moreover, a 32 bit version - __futimes has been refactored to
> > internally use __futimes64.
> >
> > The __futimes is now supposed to be used on systems still
> > supporting 32 bit time (__TIMESIZE != 64) - hence the necessary
> > conversion of struct timeval to 64 bit struct __timeval64.
> >
> > The check if struct timevals' usec fields are in the range between
> > 0 and 100 has been removed as Linux kernel performs it
> > internally in the implementation of utimensat (the conversion
> > between struct __timeval64 and __timespec64 is not relevant for
> > this particular check).
> >
> > Last but not least, checks for tvp{64} not being NULL have been
> > preserved from the original code as some legacy user space programs
> > may rely on it.
> >
> > Build tests:
> > ./src/scripts/build-many-glibcs.py glibcs
> >
> > Run-time tests:
> > - Run specific tests on ARM/x86 32bit systems (qemu):
> > https://github.com/lmajewski/meta-y2038 and run tests:
> > https://github.com/lmajewski/y2038-tests/commits/master
> >
> > Above tests were performed with Y2038 redirection applied as well
> > as without to test the proper usage of both __futimes64 and
> > __futimes. ---
> > include/time.h| 3 +++
> > sysdeps/unix/sysv/linux/futimes.c | 42
> > +--
>
> ARC is 32-bit + TIMESIZE==64 but the new code is not getting built
> (instead generic variant is). How do I override the generic fiel to
> be built instead ?
The futimes.c from sysdeps/unix/sysv/linux/ shall be built.
The futimes.c is defined in following locations:
y2038-glibc/misc
y2038-glibc/sysdeps/unix/sysv/linux
y2038-glibc/sysdeps/mach/hurd
The first one is a stub. The last one is for hurd.
ARC shall use the middle one as well.
When I'm in doubt (or when for example code is auto generated to wrap a
syscall) I do use
https://github.com/lmajewski/meta-y2038/blob/master/README
with gdb to check which function is called. Maybe it would help you too?
>
> > 2 files changed, 26 insertions(+), 19 deletions(-)
> >
> > diff --git a/include/time.h b/include/time.h
> > index b81ecd5e6e..c24066bf3a 100644
> > --- a/include/time.h
> > +++ b/include/time.h
> > @@ -210,8 +210,11 @@ extern int __utimensat64_helper (int fd, const
> > char *file, libc_hidden_proto (__utimensat64_helper);
> >
> > #if __TIMESIZE == 64
> > +# define __futimes64 __futimes
> > # define __futimens64 __futimens
> > #else
> > +extern int __futimes64 (int fd, const struct __timeval64 tvp64[2]);
> > +libc_hidden_proto (__futimes64);
> > extern int __futimens64 (int fd, const struct __timespec64 tsp[2]);
> > libc_hidden_proto (__futimens64);
> > #endif
> > diff --git a/sysdeps/unix/sysv/linux/futimes.c
> > b/sysdeps/unix/sysv/linux/futimes.c index 4bea864470..21b41e4138
> > 100644 --- a/sysdeps/unix/sysv/linux/futimes.c
> > +++ b/sysdeps/unix/sysv/linux/futimes.c
> > @@ -17,35 +17,39 @@
> >
RE: Linux kernel commit "add phy-mode support for the KSZ9031 PHY" broke ETH for Synopsys HSDK board.
Hi Oleksij,
Thanks a lot for a detailed explanation and advices!
Changing phy-mode to "rgmii-id" solved the issue.
Thank you for help!
Best regards,
Evgeniy Didin
-Original Message-
From: Oleksij Rempel
Sent: Friday, July 3, 2020 8:18 AM
To: Evgeniy Didin
Cc: Alexey Brodkin ; Eugeniy Paltsev
; linux-snps-arc@lists.infradead.org; Jose Abreu
Subject: Re: Linux kernel commit "add phy-mode support for the KSZ9031 PHY"
broke ETH for Synopsys HSDK board.
Hi Evgeniy,
Am 03.07.20 um 01:28 schrieb Evgeniy Didin:
> Hi Oleksij,
>
> Synopsys ARC HSDK board has “Micrel KSZ9031 Gigabit PHY” chip on it, boot log:
>> Starting network: stmmaceth f0008000.ethernet eth0: PHY [stmmac-0:00]
>> driver [Micrel KSZ9031
> Gigabit PHY] (irq=POLL)
> With recent commit bcf3440c6dd ("net: phy: micrel: add phy-mode
> support for the KSZ9031 PHY") Ethernet stopped
>
> working on HSDK board.
>
>
> It seems that there is a lack of *phy* configuration in hsdk.dts file, see:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/
> arch/arc/boot/dts/hsdk.dts#n229
>
> What fields do you think we should add to the *ethernet-phy@0* configuration?
> Or maybe something else is causing the eth issue? Do you have any thoughts on
> this?
Short answer:
mac: ethernet@8000 {
...
phy-mode = "rgmii-id"; (or "rgmii-rxid")
...
}
Long answer:
According to the RGMII v1.2 specification: "PC board design will require clocks
to be routed such that an additional trace delay of greater than 1.5ns and less
than 2.0ns"
Usually, to get this kind of delay on the clock line, you should make the clock
line 10-15cm longer then the data lines.
Since it is kind of complicated, to add this long traces to a tiny embedded
board, was introduced specification RGMII v2.0. It allows for MAC and/or PHY to
have internal delay. A device with internal delay will be called "rgmii-id". In
the kernel it is preffered to add this delay by the PHY, not MAC. Otherwise it
will be a bug and should be fixed.
Since most of embedded boards do not have room for 15cm clock traces, then in
most cases 'phy-mode = "rgmii"' is not correct. It will work as long as PHY
driver will be fixed. Like in this case.
Per default KSZ9031 was configured as "rgmii-rxid":
- no delay on TX path (MAC to PHY)
- 1.2ns delay on RX path (PHY to MAC)
If it was working on your board in "rgmii-rxid" mode, then:
- the MAC added some delay. in this case, most probably it is a bug and should
be fixed in the MAC driver.
- there was no TX delay and the PHY was working by accident on the edge of
specification. Did you had some kind of random packet drops?
- The clock line is actually 10-15cm longer then data lines.
Beside, phy0 on this board is bootstrapped to the address 0, which is broadcast
address on the MDIO bus. Please don't use this address if possible. And, it is
probably a good idea to add in the comment the part name of the PHY. Бecause
patching PHY drivers is usually done like: "туши свет, бросай гранату" ;)
--
Regards,
Oleksij
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARC: [plat-hsdk]: Switch ethernet phy-mode to rgmii-id
HSDK board has Micrel KSZ9031, recent commit
bcf3440c6dd ("net: phy: micrel: add phy-mode support for the KSZ9031 PHY")
caused a breakdown of Ethernet.
Using 'phy-mode = "rgmii"' is not correct because accodring RGMII
specification it is necessary to have delay on RX (PHY to MAX)
which is not generated in case of "rgmii".
Using "rgmii-id" adds necessary delay and solves the issue.
Also adding name of PHY placed on HSDK board.
Signed-off-by: Evgeniy Didin
Cc: Eugeniy Paltsev
Cc: Alexey Brodkin
---
arch/arc/boot/dts/hsdk.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arc/boot/dts/hsdk.dts b/arch/arc/boot/dts/hsdk.dts
index 9acbeba832c0..d6427d47e5a1 100644
--- a/arch/arc/boot/dts/hsdk.dts
+++ b/arch/arc/boot/dts/hsdk.dts
@@ -208,7 +208,7 @@
reg = <0x8000 0x2000>;
interrupts = <10>;
interrupt-names = "macirq";
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
snps,pbl = <32>;
snps,multicast-filter-bins = <256>;
clocks = <&gmacclk>;
@@ -226,7 +226,7 @@
#address-cells = <1>;
#size-cells = <0>;
compatible = "snps,dwmac-mdio";
- phy0: ethernet-phy@0 {
+ phy0: ethernet-phy@0 { /* Micrel KSZ9031 */
reg = <0>;
};
};
--
2.16.2
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 1/3] y2038: linux: Provide __futimes64 implementation
On 7/7/20 12:21 AM, Lukasz Majewski wrote: >> ARC is 32-bit + TIMESIZE==64 but the new code is not getting built >> (instead generic variant is). How do I override the generic fiel to >> be built instead ? > The futimes.c from sysdeps/unix/sysv/linux/ shall be built. > > The futimes.c is defined in following locations: > y2038-glibc/misc > y2038-glibc/sysdeps/unix/sysv/linux > y2038-glibc/sysdeps/mach/hurd > > The first one is a stub. The last one is for hurd. > ARC shall use the middle one as well. It seems I mixed up the various *utime* files. Following are currently building for ARC sysdeps/unix/sysv/linux/generic/futimesat.c sysdeps/unix/sysv/linux/generic/utimes.c#2 sysdeps/unix/sysv/linux/futimes.c sysdeps/unix/sysv/linux/futimens.c sysdeps/unix/sysv/linux/utimensat.c The issue is generic/utimes.c Is that the right file to build. If yes then it needs fixing as it expects __NR_utimensat (and thus require the aliasing hack in ARC sysdep.h) #define __NR_utimensat __NR_utimensat_time6 P.S. I know glibc wiki has a bunch of pages (from Arnd?) for the y2038 support. Are there other (newer) docs which explain the whole song and dance or is it the usual RTFC. > When I'm in doubt (or when for example code is auto generated to wrap a > syscall) I do use > https://github.com/lmajewski/meta-y2038/blob/master/README > > with gdb to check which function is called. Maybe it would help you too? Yeah. I typically use build logs to see which exact file is built and then objdump to corroborate. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v7.1 07/13] ARC: Linux Syscall Interface
On 06/07/2020 22:25, Vineet Gupta wrote: > On 7/6/20 6:20 AM, Adhemerval Zanella via Libc-alpha wrote: > diff --git a/sysdeps/unix/sysv/linux/arc/clone.S > b/sysdeps/unix/sysv/linux/arc/clone.S >>> > diff --git a/sysdeps/unix/sysv/linux/arc/fixup-asm-unistd.h > b/sysdeps/unix/sysv/linux/arc/fixup-asm-unistd.h >>> > + > +/* Adjustments to ARC asm-generic syscall ABI (3.9 kernel) for 64-bit > time_t > + support. */ > + > +/* fstat64 and fstatat64 need to be replaced with statx. */ > + > +#undef __NR_fstat64 > +#undef __NR_fstatat64 >>> >>> This is certainly needed as they are present in ARC arch-syscall.h but we >>> need to >>> use statx. >>> > +/* Replace all other 32-bit time syscalls with 64-bit variants. */ > + > +# undef __NR_clock_adjtime > +# undef __NR_clock_getres > +# undef __NR_futex > +# undef __NR_mq_timedreceive > +# undef __NR_mq_timedsend > +# undef __NR_ppoll > +# undef __NR_pselect6 > +# undef __NR_recvmmsg > +# undef __NR_rt_sigtimedwait > +# undef __NR_sched_rr_get_interval > +# undef __NR_semtimedop > +# undef __NR_timerfd_settime > +# undef __NR_timerfd_gettime > +# undef __NR_utimensat I am trying to understand why these are required since arc does not define them in arch-syscall.h. >>> >>> arch-syscall.h doesn't define them precisely due to these being here. When >>> update-syscalls is run, the 32-bit syscalls are generated for ARC (since >>> kernel >>> ABI provides these because that was v3.9 circa 2013). Adding them >>> fixup-asm-unistd.h removes them (perhaps I need to add this in changelog to >>> clarify - atleast for myself). >>> And the generic implementation should handle the time64 variant. If they are not this is something we need to handle it. >>> >>> At the time we we doing this, arch-syscall.h generation was not yet in >>> place, >>> however I tried to undef in generic/sysdep.h for TIMESIZE==64. However I >>> was asked >>> me to add this to ARC specific fixup-asm-unistd.h >>> https://sourceware.org/pipermail/libc-alpha/2020-March/112395.html >>> https://sourceware.org/pipermail/libc-alpha/2020-April/112909.html >> >> My confusion here, I forgot that this header is only used glibcsyscalls.py >> to actually generate arch-syscall.h. >> >> You changes does look correct. > > Actually we can add a few more entries here which have 64-bit variants. > > +# undef __NR_clock_gettime > +# undef __NR_clock_nanosleep > +# undef __NR_clock_settime > +# undef __NR_timer_gettime > +# undef __NR_timer_settime It should not intefere since ARC also defines __ASSUME_TIME64_SYSCALLS and the 32-bit fallback syscalls won't be used in this case. As a side note, now that arch-syscall.h is based on latest kernel version and all the 32-bit ABIs with old 32-bit time_t have upstream support for 64-bit time_t we can simplify a bit some implementation by assuming the 64-bit time_t is always defined and adding a fallback only for !define __ASSUME_TIME64_SYSCALLS. > > > diff --git a/sysdeps/unix/sysv/linux/arc/kernel_stat.h > b/sysdeps/unix/sysv/linux/arc/kernel_stat.h > >>> This specific one is actually dead code. I did post a patch to this effect >>> and >>> followed up with supporting data that enabling it on 64-bit arches doesn't >>> lead to >>> any changes in generated code. >>> >>> https://sourceware.org/pipermail/libc-alpha/2020-February/111259.html >>> https://sourceware.org/pipermail/libc-alpha/2020-June/115217.html >>> >> >> Ack. > > Thx. I'll repost this after things settle at bit. > > diff --git a/sysdeps/unix/sysv/linux/arc/sysdep.h > b/sysdeps/unix/sysv/linux/arc/sysdep.h >>> >>> ... >>> > +/* 32-bit time syscalls are not available, but the redefines allow > generic > + wrappers to work. */ > +#define __NR_clock_adjtime __NR_clock_adjtime64 > +#define __NR_clock_getres__NR_clock_getres_time64 > +#define __NR_futex __NR_futex_time64 > +#define __NR_mq_timedreceive __NR_mq_timedreceive_time64 > +#define __NR_mq_timedsend__NR_mq_timedsend_time64 > +#define __NR_ppoll __NR_ppoll_time64 > +#define __NR_pselect6__NR_pselect6_time64 > +#define __NR_recvmmsg__NR_recvmmsg_time64 > +#define __NR_rt_sigtimedwait __NR_rt_sigtimedwait_time64 > +#define __NR_sched_rr_get_interval > __NR_sched_rr_get_interval_time64 > +#define __NR_semtimedop __NR_semtimedop_time64 > +#define __NR_timerfd_gettime __NR_timerfd_gettime64 > +#define __NR_timerfd_settime __NR_timerfd_settime64 > +#define __NR_utimensat __NR_utimensat_time64 As for the fixup-asm-unistd.h, the generic implementation should handle it without the requirement of the ABI to add such tricks. >>> >>> fixup-asm-unistd.h is different, but this could be avoided. I
Re: [PATCH 1/3] y2038: linux: Provide __futimes64 implementation
On Tue, 7 Jul 2020, Vineet Gupta via Libc-alpha wrote: > The issue is generic/utimes.c > > Is that the right file to build. If yes then it needs fixing as it expects > __NR_utimensat (and thus require the aliasing hack in ARC sysdep.h) It was the right file to build, back when sysdeps/unix/sysv/linux/utimes.c required a utimes syscall to be present and architectures with the generic syscall interface didn't gave one. Now, there is nothing in sysdeps/unix/sysv/linux/utimes.c that wouldn't work on asm-generic architectures. So generic/utimes.c should be removed. Likewise, hppa/utimes.c should also be removed (now that sysdeps/unix/sysv/linux/utimes.c doesn't use the utimes syscalls, it doesn't matter than hppa got it late), and the __ASSUME_UTIMES definition in sysdeps/unix/sysv/linux/hppa/kernel-features.h should also be removed (because nothing will use it once the hppa utimes.c goes away). Similarly, there is no longer a need for generic/futimesat.c so that can go away as well. -- Joseph S. Myers jos...@codesourcery.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v7.2 07/13] ARC: Linux Syscall Interface
---
Changes since v7.1:
- Added a few more 32-bit time_t syscalls to fixup-asm-unistd.h
and regen arch-syscall.h to remove them: __NR_timer{g,s}ettime,
__NR_clock_{gettime,nanosleep,settime}
- minimal/annotated list of 32-bit syscall aliases in ARC sysdeps.h
for 64-bit time_t support
- Open-coded SYS_ify() but retained the macro as used by common
code
- No functional changes in generated dsos.
Changes since v7:
- used long int (iso int) in sysdep.h/syscall_error for handling registers
---
sysdeps/unix/sysv/linux/arc/arch-syscall.h| 298 ++
sysdeps/unix/sysv/linux/arc/bits/timesize.h | 21 ++
sysdeps/unix/sysv/linux/arc/clone.S | 93 ++
.../unix/sysv/linux/arc/fixup-asm-unistd.h| 46 +++
sysdeps/unix/sysv/linux/arc/jmp_buf-macros.h | 6 +
sysdeps/unix/sysv/linux/arc/kernel-features.h | 27 ++
sysdeps/unix/sysv/linux/arc/kernel_stat.h | 26 ++
sysdeps/unix/sysv/linux/arc/mmap_internal.h | 27 ++
sysdeps/unix/sysv/linux/arc/sigaction.c | 31 ++
sysdeps/unix/sysv/linux/arc/sigrestorer.S | 29 ++
sysdeps/unix/sysv/linux/arc/syscall.S | 33 ++
sysdeps/unix/sysv/linux/arc/syscalls.list | 3 +
sysdeps/unix/sysv/linux/arc/sysdep.c | 33 ++
sysdeps/unix/sysv/linux/arc/sysdep.h | 226 +
sysdeps/unix/sysv/linux/arc/vfork.S | 42 +++
15 files changed, 941 insertions(+)
create mode 100644 sysdeps/unix/sysv/linux/arc/arch-syscall.h
create mode 100644 sysdeps/unix/sysv/linux/arc/bits/timesize.h
create mode 100644 sysdeps/unix/sysv/linux/arc/clone.S
create mode 100644 sysdeps/unix/sysv/linux/arc/fixup-asm-unistd.h
create mode 100644 sysdeps/unix/sysv/linux/arc/jmp_buf-macros.h
create mode 100644 sysdeps/unix/sysv/linux/arc/kernel-features.h
create mode 100644 sysdeps/unix/sysv/linux/arc/kernel_stat.h
create mode 100644 sysdeps/unix/sysv/linux/arc/mmap_internal.h
create mode 100644 sysdeps/unix/sysv/linux/arc/sigaction.c
create mode 100644 sysdeps/unix/sysv/linux/arc/sigrestorer.S
create mode 100644 sysdeps/unix/sysv/linux/arc/syscall.S
create mode 100644 sysdeps/unix/sysv/linux/arc/syscalls.list
create mode 100644 sysdeps/unix/sysv/linux/arc/sysdep.c
create mode 100644 sysdeps/unix/sysv/linux/arc/sysdep.h
create mode 100644 sysdeps/unix/sysv/linux/arc/vfork.S
diff --git a/sysdeps/unix/sysv/linux/arc/arch-syscall.h
b/sysdeps/unix/sysv/linux/arc/arch-syscall.h
new file mode 100644
index ..58cd927da81b
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/arc/arch-syscall.h
@@ -0,0 +1,298 @@
+/* AUTOGENERATED by update-syscall-lists.py. */
+#define __NR_accept 202
+#define __NR_accept4 242
+#define __NR_acct 89
+#define __NR_add_key 217
+#define __NR_adjtimex 171
+#define __NR_arc_gettls 246
+#define __NR_arc_settls 245
+#define __NR_arc_usr_cmpxchg 248
+#define __NR_bind 200
+#define __NR_bpf 280
+#define __NR_brk 214
+#define __NR_cacheflush 244
+#define __NR_capget 90
+#define __NR_capset 91
+#define __NR_chdir 49
+#define __NR_chroot 51
+#define __NR_clock_adjtime64 405
+#define __NR_clock_getres_time64 406
+#define __NR_clock_gettime64 403
+#define __NR_clock_nanosleep_time64 407
+#define __NR_clock_settime64 404
+#define __NR_clone 220
+#define __NR_clone3 435
+#define __NR_close 57
+#define __NR_connect 203
+#define __NR_copy_file_range 285
+#define __NR_delete_module 106
+#define __NR_dup 23
+#define __NR_dup3 24
+#define __NR_epoll_create1 20
+#define __NR_epoll_ctl 21
+#define __NR_epoll_pwait 22
+#define __NR_eventfd2 19
+#define __NR_execve 221
+#define __NR_execveat 281
+#define __NR_exit 93
+#define __NR_exit_group 94
+#define __NR_faccessat 48
+#define __NR_fadvise64_64 223
+#define __NR_fallocate 47
+#define __NR_fanotify_init 262
+#define __NR_fanotify_mark 263
+#define __NR_fchdir 50
+#define __NR_fchmod 52
+#define __NR_fchmodat 53
+#define __NR_fchown 55
+#define __NR_fchownat 54
+#define __NR_fcntl64 25
+#define __NR_fdatasync 83
+#define __NR_fgetxattr 10
+#define __NR_finit_module 273
+#define __NR_flistxattr 13
+#define __NR_flock 32
+#define __NR_fremovexattr 16
+#define __NR_fsconfig 431
+#define __NR_fsetxattr 7
+#define __NR_fsmount 432
+#define __NR_fsopen 430
+#define __NR_fspick 433
+#define __NR_fstatfs64 44
+#define __NR_fsync 82
+#define __NR_ftruncate64 46
+#define __NR_futex_time64 422
+#define __NR_get_mempolicy 236
+#define __NR_get_robust_list 100
+#define __NR_getcpu 168
+#define __NR_getcwd 17
+#define __NR_getdents64 61
+#define __NR_getegid 177
+#define __NR_geteuid 175
+#define __NR_getgid 176
+#define __NR_getgroups 158
+#define __NR_getitimer 102
+#define __NR_getpeername 205
+#define __NR_getpgid 155
+#define __NR_getpid 172
+#define __NR_getppid 173
+#define __NR_getpriority 141
+#define __NR_getrandom 278
+#define __NR_getresgid 150
+#define __NR_getresuid 148
+#define __NR_getrlimit 163
+#define __NR_getrusage 165
+#define __NR_getsid 156
+#define __NR_getsockname 204
+#define
Re: [PATCH v7.1 07/13] ARC: Linux Syscall Interface
On 7/7/20 12:24 PM, Adhemerval Zanella via Libc-alpha wrote: > > > On 06/07/2020 22:25, Vineet Gupta wrote: >> On 7/6/20 6:20 AM, Adhemerval Zanella via Libc-alpha wrote: >> diff --git a/sysdeps/unix/sysv/linux/arc/clone.S >> b/sysdeps/unix/sysv/linux/arc/clone.S >> diff --git a/sysdeps/unix/sysv/linux/arc/fixup-asm-unistd.h >> b/sysdeps/unix/sysv/linux/arc/fixup-asm-unistd.h >> + >> +/* Adjustments to ARC asm-generic syscall ABI (3.9 kernel) for 64-bit >> time_t >> + support. */ >> + >> +/* fstat64 and fstatat64 need to be replaced with statx. */ >> + >> +#undef __NR_fstat64 >> +#undef __NR_fstatat64 This is certainly needed as they are present in ARC arch-syscall.h but we need to use statx. >> +/* Replace all other 32-bit time syscalls with 64-bit variants. */ >> + >> +# undef __NR_clock_adjtime >> +# undef __NR_clock_getres >> +# undef __NR_futex >> +# undef __NR_mq_timedreceive >> +# undef __NR_mq_timedsend >> +# undef __NR_ppoll >> +# undef __NR_pselect6 >> +# undef __NR_recvmmsg >> +# undef __NR_rt_sigtimedwait >> +# undef __NR_sched_rr_get_interval >> +# undef __NR_semtimedop >> +# undef __NR_timerfd_settime >> +# undef __NR_timerfd_gettime >> +# undef __NR_utimensat > > I am trying to understand why these are required since arc does not > define > them in arch-syscall.h. arch-syscall.h doesn't define them precisely due to these being here. When update-syscalls is run, the 32-bit syscalls are generated for ARC (since kernel ABI provides these because that was v3.9 circa 2013). Adding them fixup-asm-unistd.h removes them (perhaps I need to add this in changelog to clarify - atleast for myself). > And the generic implementation should handle the time64 variant. If they > are not this is something we need to handle it. At the time we we doing this, arch-syscall.h generation was not yet in place, however I tried to undef in generic/sysdep.h for TIMESIZE==64. However I was asked me to add this to ARC specific fixup-asm-unistd.h https://sourceware.org/pipermail/libc-alpha/2020-March/112395.html https://sourceware.org/pipermail/libc-alpha/2020-April/112909.html >>> >>> My confusion here, I forgot that this header is only used glibcsyscalls.py >>> to actually generate arch-syscall.h. >>> >>> You changes does look correct. >> >> Actually we can add a few more entries here which have 64-bit variants. >> >> +# undef __NR_clock_gettime >> +# undef __NR_clock_nanosleep >> +# undef __NR_clock_settime >> +# undef __NR_timer_gettime >> +# undef __NR_timer_settime > > It should not intefere since ARC also defines __ASSUME_TIME64_SYSCALLS > and the 32-bit fallback syscalls won't be used in this case. In an ideal world yes, but as we see from hacks in sysdep.h, there's code which build/works inadvertently. If nothing else, this documents that those syscalls are not to be used. > As a side note, now that arch-syscall.h is based on latest kernel version > and all the 32-bit ABIs with old 32-bit time_t have upstream support for > 64-bit time_t we can simplify a bit some implementation by assuming > the 64-bit time_t is always defined and adding a fallback only for > !define __ASSUME_TIME64_SYSCALLS. OK. >> diff --git a/sysdeps/unix/sysv/linux/arc/sysdep.h >> b/sysdeps/unix/sysv/linux/arc/sysdep.h ... >> +/* 32-bit time syscalls are not available, but the redefines allow >> generic >> + wrappers to work. */ >> +#define __NR_clock_adjtime __NR_clock_adjtime64 >> +#define __NR_clock_getres __NR_clock_getres_time64 >> +#define __NR_futex __NR_futex_time64 >> +#define __NR_mq_timedreceive__NR_mq_timedreceive_time64 >> +#define __NR_mq_timedsend __NR_mq_timedsend_time64 >> +#define __NR_ppoll __NR_ppoll_time64 >> +#define __NR_pselect6 __NR_pselect6_time64 >> +#define __NR_recvmmsg __NR_recvmmsg_time64 >> +#define __NR_rt_sigtimedwait__NR_rt_sigtimedwait_time64 >> +#define __NR_sched_rr_get_interval >> __NR_sched_rr_get_interval_time64 >> +#define __NR_semtimedop __NR_semtimedop_time64 >> +#define __NR_timerfd_gettime__NR_timerfd_gettime64 >> +#define __NR_timerfd_settime__NR_timerfd_settime64 >> +#define __NR_utimensat __NR_utimensat_time64 > > As for the fixup-asm-unistd.h, the generic implementation should handle it > without the requirement of the ABI to add such tricks. fixup-asm-unistd.h is different, but this could be avoided. I know for sure that ll code literally expects __NR_futex (atleast used to). But I can remove this and see what comes out. > > However it seems that we are still miss
Re: [GIT PULL] ARC updates for 5.8-rc5
The pull request you sent on Tue, 7 Jul 2020 06:18:57 +: > git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/ tags/arc-5.8-rc5 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/9e4d7696213f0231f7a54512da4b8514eb316edb Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v7.1 07/13] ARC: Linux Syscall Interface
On Tue, 7 Jul 2020, Vineet Gupta via Libc-alpha wrote:
> > Each implementation has it ows requirements so I can't really say if
> > a helper function does make sense for all of them. For pause
> > specifically we can even simplify to since all architectures have
> > either ppoll or ppoll_time64:
> >
> > int
> > __libc_pause (void)
> > {
> > #ifdef __NR_ppoll_time64
> > return SYSCALL_CANCEL (ppoll_time64, NULL, 0, NULL, NULL);
> > #else
> > return SYSCALL_CANCEL (ppoll, NULL, 0, NULL, NULL);
> > #endif
> > }
>
> But how is this compatible with older kernels (and perhaps this is a general
> question). I mean one/more ABIs minimum kernel would not have the ppoll or
> ppoll64
> so how will new glibc work with such a kernel ? Is it not required to ?
See commit 089b772f98afd9eb6264c6489bc96a30bf6af4ac, where I removed
__ASSUME_PPOLL because all supported kernel versions now had that syscall
for all glibc architectures.
In general this sort of thing needs a review of whether a given syscall is
available for all glibc architectures in their minimum kernel versions.
For the old kernels in question, that means checking the
architecture-specific syscall table as used to dispatch syscalls at
runtime, which used to have an architecture-specific format before
unification work was done; it used to mean checking asm/unistd.h as well,
but now we have syscall tables in glibc that's probably no longer
required. It also involves checking compat syscall tables for 32-bit
binaries on 64-bit kernels, as sometimes a syscall didn't get added to the
native and compat syscall tables at the same time (see the comments in
sparc/kernel-features.h about various socket-related syscalls, for
example).
--
Joseph S. Myers
jos...@codesourcery.com
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v5 03/25] mm/arc: Use general page fault accounting
Use the general page fault accounting by passing regs into handle_mm_fault().
It naturally solve the issue of multiple page fault accounting when page fault
retry happened.
Fix PERF_COUNT_SW_PAGE_FAULTS perf event manually for page fault retries, by
moving it before taking mmap_sem.
CC: Vineet Gupta
CC: linux-snps-arc@lists.infradead.org
Signed-off-by: Peter Xu
---
arch/arc/mm/fault.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c
index 587dea524e6b..f5657cb68e4f 100644
--- a/arch/arc/mm/fault.c
+++ b/arch/arc/mm/fault.c
@@ -105,6 +105,7 @@ void do_page_fault(unsigned long address, struct pt_regs
*regs)
if (write)
flags |= FAULT_FLAG_WRITE;
+ perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
retry:
mmap_read_lock(mm);
@@ -130,7 +131,7 @@ void do_page_fault(unsigned long address, struct pt_regs
*regs)
goto bad_area;
}
- fault = handle_mm_fault(vma, address, flags, NULL);
+ fault = handle_mm_fault(vma, address, flags, regs);
/* Quick path to respond to signals */
if (fault_signal_pending(fault, regs)) {
@@ -155,22 +156,9 @@ void do_page_fault(unsigned long address, struct pt_regs
*regs)
* Major/minor page fault accounting
* (in case of retry we only land here once)
*/
- perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
-
- if (likely(!(fault & VM_FAULT_ERROR))) {
- if (fault & VM_FAULT_MAJOR) {
- tsk->maj_flt++;
- perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MAJ, 1,
- regs, address);
- } else {
- tsk->min_flt++;
- perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MIN, 1,
- regs, address);
- }
-
+ if (likely(!(fault & VM_FAULT_ERROR)))
/* Normal return path: fault Handled Gracefully */
return;
- }
if (!user_mode(regs))
goto no_context;
--
2.26.2
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v7.1 07/13] ARC: Linux Syscall Interface
On 7/7/20 2:32 PM, Joseph Myers wrote:
> On Tue, 7 Jul 2020, Vineet Gupta via Libc-alpha wrote:
>
>>> Each implementation has it ows requirements so I can't really say if
>>> a helper function does make sense for all of them. For pause
>>> specifically we can even simplify to since all architectures have
>>> either ppoll or ppoll_time64:
>>>
>>> int
>>> __libc_pause (void)
>>> {
>>> #ifdef __NR_ppoll_time64
>>> return SYSCALL_CANCEL (ppoll_time64, NULL, 0, NULL, NULL);
>>> #else
>>> return SYSCALL_CANCEL (ppoll, NULL, 0, NULL, NULL);
>>> #endif
>>> }
>>
>> But how is this compatible with older kernels (and perhaps this is a general
>> question). I mean one/more ABIs minimum kernel would not have the ppoll or
>> ppoll64
>> so how will new glibc work with such a kernel ? Is it not required to ?
>
> See commit 089b772f98afd9eb6264c6489bc96a30bf6af4ac, where I removed
> __ASSUME_PPOLL because all supported kernel versions now had that syscall
> for all glibc architectures.
But that still doesn't explain how new glibc works with old kernels (for say
when
a port support was first merged, with say asm-generic ABI).
Ah it seems any glibc is only required to work with "arch_minimum_kernel"
(generic
or architecture override) which over time itself keeps moving forward due to
various reasons (e.g. 64-bit time support etc). So indeed a bleeding edge glibc
of
today won't necessarily work with an arch kernel for say when its glibc port was
first merged, but will for the corresponding arch_minimum_kernel.
> In general this sort of thing needs a review of whether a given syscall is
> available for all glibc architectures in their minimum kernel versions.
> For the old kernels in question, that means checking the
> architecture-specific syscall table as used to dispatch syscalls at
> runtime, which used to have an architecture-specific format before
> unification work was done; it used to mean checking asm/unistd.h as well,
> but now we have syscall tables in glibc that's probably no longer
> required. It also involves checking compat syscall tables for 32-bit
> binaries on 64-bit kernels, as sometimes a syscall didn't get added to the
> native and compat syscall tables at the same time (see the comments in
> sparc/kernel-features.h about various socket-related syscalls, for
> example).
>
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 1/3] y2038: linux: Provide __futimes64 implementation
Hi Vineet, > On 7/7/20 12:21 AM, Lukasz Majewski wrote: > >> ARC is 32-bit + TIMESIZE==64 but the new code is not getting built > >> (instead generic variant is). How do I override the generic fiel to > >> be built instead ? > > The futimes.c from sysdeps/unix/sysv/linux/ shall be built. > > > > The futimes.c is defined in following locations: > > y2038-glibc/misc > > y2038-glibc/sysdeps/unix/sysv/linux > > y2038-glibc/sysdeps/mach/hurd > > > > The first one is a stub. The last one is for hurd. > > ARC shall use the middle one as well. > > It seems I mixed up the various *utime* files. > Following are currently building for ARC > > sysdeps/unix/sysv/linux/generic/futimesat.c > sysdeps/unix/sysv/linux/generic/utimes.c#2 > > sysdeps/unix/sysv/linux/futimes.c > sysdeps/unix/sysv/linux/futimens.c > sysdeps/unix/sysv/linux/utimensat.c > > The issue is generic/utimes.c > > Is that the right file to build. If yes then it needs fixing as it > expects __NR_utimensat (and thus require the aliasing hack in ARC > sysdep.h) > > #define __NR_utimensat__NR_utimensat_time6 > > P.S. I know glibc wiki has a bunch of pages (from Arnd?) for the > y2038 support. This wiki page was developed by Albert Aribaud and shall give you a grasp about the work needed for Y2038 conversion. However, it is now outdated as we already made some progress. The most accurate list of supported/converted syscalls can be found here: https://github.com/lmajewski/y2038_glibc/commit/b94a7f1126dc5bd652ba3a856753e85e48a6e845 and the most up to date development branch for Y2038 conversion: https://github.com/lmajewski/y2038_glibc/commits/y2038_edge (I've sent yesterday a patch series to convert futex to futex_time64). > Are there other (newer) docs which explain the whole > song and dance or is it the usual RTFC. > > > When I'm in doubt (or when for example code is auto generated to > > wrap a syscall) I do use > > https://github.com/lmajewski/meta-y2038/blob/master/README > > > > with gdb to check which function is called. Maybe it would help you > > too? > > Yeah. I typically use build logs to see which exact file is built and > then objdump to corroborate. Ok. > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpitzzOBHX_P.pgp Description: OpenPGP digital signature ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
