[LTP] LTP Release preparations

[Li Wang]

On Thu, Jan 25, 2024 at 7:04 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> > Test based on the latest LTP (main-branch + libswap-patchset) results as:
>
> Thanks a lot!
>
> > splice07: rhel9.3 + kernel-6.7.0, all-arches
> >
> >     86        splice07.c:62: TINFO: /dev/zero -> ...
> >     87        splice07.c:54: TPASS: splice() on /dev/zero -> file :
> EINVAL (22)
> >     88        splice07.c:54: TPASS: splice() on /dev/zero -> O_PATH file
> : EBADF (9)
> >     89        splice07.c:54: TPASS: splice() on /dev/zero -> directory :
> EBADF (9)
> >     90        splice07.c:54: TPASS: splice() on /dev/zero -> /dev/zero :
> EBADF (9)
> >     91        splice07.c:54: TPASS: splice() on /dev/zero ->
> /proc/self/maps
> > : EBADF (9)
> >     92        splice07.c:54: TPASS: splice() on /dev/zero -> pipe read
> end : EBADF (9)
> >     93        splice07.c:54: TFAIL: splice() on /dev/zero -> pipe write
> end succeeded
>
> We see that one too, on a random set of kernels the splice from zero to
> pipe succeeds. We are trying to investigate.
>
> >     94        splice07.c:54: TPASS: splice() on /dev/zero -> unix socket
> : EINVAL (22)
> >     95        splice07.c:54: TPASS: splice() on /dev/zero -> inet socket
> : EINVAL (22)
> >
> >
> > proc_sched_rt01: rhel-9.3(5.14.0-362.8.1.el9_3), all-arches
> >
> >     10        proc_sched_rt01.c:45: TFAIL: Expect: timeslice_ms > 0 after
> > reset to default
> >     11        proc_sched_rt01.c:51: TPASS: echo 0 >
> > /proc/sys/kernel/sched_rt_period_us : EINVAL (22)
> >     12        proc_sched_rt01.c:53: TFAIL: echo -1 >
> > /proc/sys/kernel/sched_rt_period_us invalid retval 2: SUCCESS (0)
> >     13        proc_sched_rt01.c:59: TPASS: echo -2 >
> > /proc/sys/kernel/sched_rt_runtime_us : EINVAL (22)
> >     14        proc_sched_rt01.c:72: TFAIL: echo rt_period_us+1 >
> > /proc/sys/kernel/sched_rt_runtime_us invalid retval 1: SUCCESS (0)
> >
> >
> > sched_rr_get_interval01: rhel-9.3(5.14.0-362.8.1.el9_3), all-arches
> >
> >      9        sched_rr_get_interval01.c:44: TINFO: Testing variant: vDSO
> or
> > syscall with libc spec
> >     10        sched_rr_get_interval01.c:61: TPASS:
> sched_rr_get_interval() passed
> >     11        sched_rr_get_interval01.c:68: TPASS: Time quantum 0s
> 100000000ns
> >     12        sched_rr_get_interval01.c:76: TFAIL:
> > /proc/sys/kernel/sched_rr_timeslice_ms != 100 got -1
> >     13        sched_rr_get_interval01.c:44: TINFO: Testing variant:
> syscall
> > with old kernel spec
> >     14        sched_rr_get_interval01.c:61: TPASS:
> sched_rr_get_interval() passed
> >     15        sched_rr_get_interval01.c:68: TPASS: Time quantum 0s
> 100000000ns
> >     16        sched_rr_get_interval01.c:76: TFAIL:
> > /proc/sys/kernel/sched_rr_timeslice_ms != 100 got -1
>
> These are most likely missing bacports for the sysctl fixes.
>

You're right, it lacks the two kernel patches you submitted:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c1fc6484e1fb
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=079be8fc6309



>
> > sched_getattr01: rhel-9.3(5.14.0-362.8.1.el9_3), all-arches
> >
> >      7        sched_getattr01    1  TFAIL  :  sched_getattr01.c:57:
> > sched_setattr() failed: errno=EPERM(1): Operation not permitted
>
> Does this one still fail on a freshly rebooted machine? My guess is that
> if we succeed to set invalid values in the proc_sched_rt01 it may
> confuse the kernel enough to fail this test as well.
>

Thanks, I confirmed that the failure is gone after a fresh reboot.

-- 
Regards,
Li Wang