| Message ID | cover.1589789487.git.viresh.kumar@linaro.org |
|---|---|
| Headers | show |
| Series | Syscalls: Add support for time64 variants | expand |
On Mon, May 18, 2020 at 10:15 AM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > Hi, > > This updates the pending syscall tests that lacked the time64 updates. > > V3: > - Fix issues related to passing incorrect timespec type to syscalls. > - Take care of futex and semtimedop tests where the architecture > provides the syscall number, but doesn't implement it. > - Other improvements and cleanups. Hi Viresh, These all look good to me. I cross-referenced it with my list of syscall changes, and found that this set of patches does not contain clock_{gettime,settime,adjtime,getres,nanosleep}, waitid, statx and msgctl/semctl/shmctl. Did you cover all of those in a previous patches, or are they planned for a follow-up? There is also a list of syscalls that may need to get updates to their tests because passing a timeval/timespec into them is now broken and they need to receive the __kernel_old_* variants: time, stime, gettimeofday, settimeofday, adjtimex, nanosleep, alarm, select, old_select, io_getevents, utime, utimes, futimesat, oldstat/oldlstat/oldfstat, newstat/newlstat/newfstat/newfstatat, stat64/lstat64/fstat64/fstatat64, and wait4/waitid/getrusage. Arnd
On 18-05-20, 11:02, Arnd Bergmann wrote: > These all look good to me. > > I cross-referenced it with my list of syscall changes, and found that this > set of patches does not contain > clock_{gettime,settime,adjtime,getres,nanosleep}, These are already already merged. > waitid, statx and msgctl/semctl/shmctl Hmm, I didn't see them in the list of time64 calls somehow. Nor is there a _time64 syscall number available for them. What did I miss ? Or the original syscalls only support the 64bit timespec and there is no separate time64 variant ? > There is also a list of syscalls that may need to get updates to their tests > because passing a timeval/timespec into them is now broken and they need > to receive the __kernel_old_* variants: Ahh, if I understand correct you are only talking about the cases where the syscall is called directly without the libc wrapper, right ? We can't use timeval/timespec there anymore. > time, stime, gettimeofday, settimeofday, adjtimex, nanosleep, > alarm, select, old_select, io_getevents, utime, utimes, futimesat, > oldstat/oldlstat/oldfstat, newstat/newlstat/newfstat/newfstatat, > stat64/lstat64/fstat64/fstatat64, and wait4/waitid/getrusage. Okay, will have a look at them as well. Thanks for the information.
On Mon, May 18, 2020 at 11:12 AM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > On 18-05-20, 11:02, Arnd Bergmann wrote: > > These all look good to me. > > > > I cross-referenced it with my list of syscall changes, and found that this > > set of patches does not contain > > clock_{gettime,settime,adjtime,getres,nanosleep}, > > These are already already merged. > > > waitid, statx and msgctl/semctl/shmctl > > Hmm, I didn't see them in the list of time64 calls somehow. Nor is > there a _time64 syscall number available for them. What did I miss ? > Or the original syscalls only support the 64bit timespec and there is > no separate time64 variant ? I was mistaken about waitid, we never added a time64 syscall for that since the arguments do not overflow and it takes a timeval rather than a timespec. In this case you just have to make sure to pass the correct rusage structure based on __kernel_old_timeval instead of the glibc timeval. For msgctl/semctl/shmctl, the existing syscalls were extended in a compatible way, using an extended 'high' field for each 32-bit seconds value. I later learned that on some architectures, the 'compat' version of that failed to zero-initialize those fields, so I guess all we need is a test that ensures this was fixed correctly, by initializing the '*_high' to something nonzero before calling the syscall, and checking that it gets zero-filled by the syscall. Ideally one would also check that they contain the correct values after y2038 (same as we'd like for sys_clock_gettime and the syscall wrappers based on that), but I don't know if that can easily be done in ltp now because setting the system time may have undesired side-effects. > > There is also a list of syscalls that may need to get updates to their tests > > because passing a timeval/timespec into them is now broken and they need > > to receive the __kernel_old_* variants: > > Ahh, if I understand correct you are only talking about the cases > where the syscall is called directly without the libc wrapper, right ? > We can't use timeval/timespec there anymore. Exactly. There are probably also ioctls with the same problem, but I don't know which ioctl commands are actually tested by ltp. I would guess that the socket timestamps (both ioctl and setsockopt based ones) do have some tests that need to be updated. Arnd
On 18-05-20, 11:21, Arnd Bergmann wrote: > On Mon, May 18, 2020 at 11:12 AM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > Ahh, if I understand correct you are only talking about the cases > > where the syscall is called directly without the libc wrapper, right ? > > We can't use timeval/timespec there anymore. > > Exactly. There weren't a lot of offenders I believe. I have fixed them and sent a patchset for that. > There are probably also ioctls with the same problem, but > I don't know which ioctl commands are actually tested by ltp. > > I would guess that the socket timestamps (both ioctl and > setsockopt based ones) do have some tests that need to be > updated. I tried to do some search based on: git grep "ioctl" `git grep -l tst_syscall` git grep "setsockopt" `git grep -l tst_syscall` but found nothing :( Do I need to look for something else ?
On Tue, May 19, 2020 at 10:54 AM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > On 18-05-20, 11:21, Arnd Bergmann wrote: > > On Mon, May 18, 2020 at 11:12 AM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > > Ahh, if I understand correct you are only talking about the cases > > > where the syscall is called directly without the libc wrapper, right ? > > > We can't use timeval/timespec there anymore. > > > > Exactly. > > There weren't a lot of offenders I believe. I have fixed them and sent a > patchset for that. > > > There are probably also ioctls with the same problem, but > > I don't know which ioctl commands are actually tested by ltp. > > > > I would guess that the socket timestamps (both ioctl and > > setsockopt based ones) do have some tests that need to be > > updated. > > I tried to do some search based on: > > git grep "ioctl" `git grep -l tst_syscall` > git grep "setsockopt" `git grep -l tst_syscall` > > but found nothing :( > > Do I need to look for something else ? I just tried looking for socket timestamps using git grep 'SO_TIMESTAMP\|SIOCGSTAMP\|SO_.*TIMEO' but that also did not find any tests. I guess those interfaces are currently not tested as part of LTP at all. Testing for setsockopt only covers a very small subset of the system call. Same for the SNDDRV_, PPP, PP?ETTIME, ioctls, which are somewhat device specific. It might be good to test the snddrv interfaces, but they probably have a separate testsuite somewhere outside of LTP already. I did find something for v4l2 (VIDIOC_QUERYBUF, VIDIOC_QBUF, VIDIOC_DQBUF, VIDIOC_DQEVENT), but haven't looked at what the tests do. I also see tests for input_event in testcases/kernel/input/. These seem fine as they include the kernel header for 'struct input_event', which is the correct approach. One other interface affected by the time64 changes is elf_prstatus for core dumps. This is not a system call though, and it does not have a test case either. Arnd
On 18-05-20, 11:21, Arnd Bergmann wrote: > For msgctl/semctl/shmctl, the existing syscalls were extended in a > compatible way, using an extended 'high' field for each 32-bit > seconds value. I later learned that on some architectures, the > 'compat' version of that failed to zero-initialize those fields, so I > guess all we need is a test that ensures this was fixed correctly, > by initializing the '*_high' to something nonzero before calling > the syscall, and checking that it gets zero-filled by the syscall. Okay, I see the new structure (struct semid64_ds) getting added to the kernel. But I am not sure how to call the 'compat' version, can you please help ? Do I just need to call like this ? struct semid64_ds buf_ds = { .sem_otime_high = 1, .sem_ctime_high = 1 }; union semun arg; arg.buf = &buf_ds; semctl(semid, 0, IPC_STAT, arg); ?
On Tue, May 19, 2020 at 11:42 AM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > On 18-05-20, 11:21, Arnd Bergmann wrote: > > For msgctl/semctl/shmctl, the existing syscalls were extended in a > > compatible way, using an extended 'high' field for each 32-bit > > seconds value. I later learned that on some architectures, the > > 'compat' version of that failed to zero-initialize those fields, so I > > guess all we need is a test that ensures this was fixed correctly, > > by initializing the '*_high' to something nonzero before calling > > the syscall, and checking that it gets zero-filled by the syscall. > > Okay, I see the new structure (struct semid64_ds) getting added to the > kernel. But I am not sure how to call the 'compat' version, can you > please help ? > > Do I just need to call like this ? > > struct semid64_ds buf_ds = { > .sem_otime_high = 1, > .sem_ctime_high = 1 > }; > union semun arg; > > arg.buf = &buf_ds; > semctl(semid, 0, IPC_STAT, arg); > > ? Yes, and then check that the two fields now contain zeroes. This needs to be compile-time guarded in some form to avoid running it on 64-bit machines (which don't have the fields), or to run into compile-time failures with old kernel headers that don't expose the fields. Note that the struct definitions are architecture-specific, so unfortunately you can't just provide a copy of that definition in ltp unless you add all eight versions that the kernel defines. Perhaps ltp already has a way to probe whether the headers have the latest struct definition. Arnd
Hi, This updates the pending syscall tests that lacked the time64 updates. V3: - Fix issues related to passing incorrect timespec type to syscalls. - Take care of futex and semtimedop tests where the architecture provides the syscall number, but doesn't implement it. - Other improvements and cleanups. Viresh Kumar (17): syscalls/timer_gettime: Add support for time64 tests syscalls/timer_settime: Add support for time64 tests syscalls/timerfd: Add support for time64 tests syscalls/sched_rr_get_interval: Add support for time64 tests syscalls/futex: Merge futex_wait_bitset tests syscalls/futex: Add support for time64 tests syscalls/io_pgetevents: Add support for time64 tests syscalls/sigwaitinfo: Migrate to new test framework syscalls/rt_sigtimedwait: Add support for time64 tests syscalls/mq_timed{send|receive}: Add support for time64 tests syscalls/recvmmsg: Add support for time64 tests syscalls/ppoll: Add support for time64 tests syscalls/select6: Add support for time64 tests syscalls/semop: Migrate to new test framework syscalls/semtimedop: Add support for semtimedop and its time64 version syscalls/utimensat: Migrate to new test framework syscalls/utimensat: Add support for time64 tests include/lapi/io_pgetevents.h | 15 +- include/tst_timer.h | 196 +++++++ runtest/syscalls | 3 +- testcases/kernel/syscalls/futex/.gitignore | 1 - testcases/kernel/syscalls/futex/Makefile | 1 - .../syscalls/futex/futex_cmp_requeue01.c | 34 +- .../syscalls/futex/futex_cmp_requeue02.c | 24 +- testcases/kernel/syscalls/futex/futex_utils.h | 52 +- .../kernel/syscalls/futex/futex_wait01.c | 79 +-- .../kernel/syscalls/futex/futex_wait02.c | 102 ++-- .../kernel/syscalls/futex/futex_wait03.c | 87 ++- .../kernel/syscalls/futex/futex_wait04.c | 81 +-- .../kernel/syscalls/futex/futex_wait05.c | 2 +- .../kernel/syscalls/futex/futex_wait_bitset.h | 75 --- .../syscalls/futex/futex_wait_bitset01.c | 101 +++- .../syscalls/futex/futex_wait_bitset02.c | 18 - .../kernel/syscalls/futex/futex_wake01.c | 67 ++- .../kernel/syscalls/futex/futex_wake02.c | 95 ++-- .../kernel/syscalls/futex/futex_wake03.c | 109 ++-- .../kernel/syscalls/futex/futex_wake04.c | 146 +++-- testcases/kernel/syscalls/futex/futextest.h | 122 +++-- .../syscalls/io_pgetevents/io_pgetevents01.c | 33 +- .../syscalls/io_pgetevents/io_pgetevents02.c | 51 +- testcases/kernel/syscalls/ipc/semop/Makefile | 2 +- testcases/kernel/syscalls/ipc/semop/semop.h | 55 ++ testcases/kernel/syscalls/ipc/semop/semop01.c | 148 +++-- testcases/kernel/syscalls/ipc/semop/semop02.c | 156 +++--- testcases/kernel/syscalls/ipc/semop/semop03.c | 162 +++--- testcases/kernel/syscalls/ipc/semop/semop04.c | 177 +++--- testcases/kernel/syscalls/ipc/semop/semop05.c | 313 +++++------ .../mq_timedreceive/mq_timedreceive01.c | 92 +++- .../syscalls/mq_timedsend/mq_timedsend01.c | 96 ++-- testcases/kernel/syscalls/ppoll/ppoll01.c | 71 ++- .../sched_rr_get_interval01.c | 116 ++-- .../sched_rr_get_interval02.c | 122 ++--- .../sched_rr_get_interval03.c | 146 +++-- testcases/kernel/syscalls/select/select_var.h | 25 +- .../kernel/syscalls/sendmmsg/sendmmsg01.c | 40 +- .../kernel/syscalls/sendmmsg/sendmmsg_var.h | 55 +- .../syscalls/sigwaitinfo/sigwaitinfo01.c | 311 ++++++----- .../syscalls/timer_gettime/timer_gettime01.c | 124 ++--- .../syscalls/timer_settime/timer_settime01.c | 46 +- .../syscalls/timer_settime/timer_settime02.c | 60 +- testcases/kernel/syscalls/timerfd/timerfd01.c | 53 +- testcases/kernel/syscalls/timerfd/timerfd04.c | 51 +- .../syscalls/timerfd/timerfd_gettime01.c | 133 ++--- .../syscalls/timerfd/timerfd_settime01.c | 136 +++-- .../syscalls/timerfd/timerfd_settime02.c | 28 +- testcases/kernel/syscalls/utils/mq_timed.h | 42 +- testcases/kernel/syscalls/utimensat/Makefile | 4 - .../kernel/syscalls/utimensat/utimensat01.c | 472 ++++++++-------- .../syscalls/utimensat/utimensat_tests.sh | 517 ------------------ 52 files changed, 2562 insertions(+), 2685 deletions(-) delete mode 100644 testcases/kernel/syscalls/futex/futex_wait_bitset.h delete mode 100644 testcases/kernel/syscalls/futex/futex_wait_bitset02.c create mode 100644 testcases/kernel/syscalls/ipc/semop/semop.h delete mode 100755 testcases/kernel/syscalls/utimensat/utimensat_tests.sh