[LTP] LTP Release preparations

[LTP] LTP Release preparations

[Cyril Hrubis]

Hi!
Firstly happy new year to everyone.

Secondly as usually we are supposed to produce a release at the end of
the month. I will start by going over patchwork this week and try to
review and merge as much as possible. Given that it's the start of the
January we have about two weeks for this before we have to declare a git
freeze and start pre-release testing. Does that sound fine to everyone?

If you have any patches that should be reviewed before the release,
please let me know.

I do have one patch this time, please have a look if you have time:

http://patchwork.ozlabs.org/project/ltp/patch/20231031125114.5879-1-chrubis@suse.cz/

I would like to finish the tst_fd iterator patchset if possible, but
depending on the amount of patches that I will have to review I may not
make it.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] LTP Release preparations

[Petr Vorel]

Hi Cyril, all,

> Hi!
> Firstly happy new year to everyone.
:)

> Secondly as usually we are supposed to produce a release at the end of
> the month. I will start by going over patchwork this week and try to
> review and merge as much as possible. Given that it's the start of the
> January we have about two weeks for this before we have to declare a git
> freeze and start pre-release testing. Does that sound fine to everyone?

> If you have any patches that should be reviewed before the release,
> please let me know.

I would like to have these patchsets merged:

* Add support bcachefs filesystem
https://patchwork.ozlabs.org/project/ltp/list/?series=385735&state=*
We have 6.7-rc8, fanotify were fixed by fix from Jan Kara:
8bf771972b84 ("bcachefs: Fix determining required file handle length").

statvfs01.c ENAMETOOLONG issue is still failing, but there are fixes pending
[1], but even with it (bcachefs-2024-01-01) it does not fix the problem.
I'll report it to the patch itself.

* net: tst_netload_compare(): Ignore performance failures
https://patchwork.ozlabs.org/project/ltp/patch/20231219123709.339435-1-pvorel@suse.cz/

* .modprobe_module
I'm not sure about .modprobe_module [2]. I have draft of v3, but I'm not sure if
it's needed. My motivation was to fix setsockopt08.c failure on openSUSE
Tumbleweed, but that turns out to be procps package issue due broken symlink
(bsc#1217990). Calling modprobe is is needed on these tests:

 ** testcases/network/can/cve/can_bcm01.c
	modprobe on can_bcm01.c is required to fix failures on sle-12-SP3 which uses
	4.4 based kernel (I'm not sure if the problem is on mainline as well):
	can_bcm01.c:44: TBROK: Failed to create vcan device ltp_vcan0: EOPNOTSUPP
	can_bcm01.c:126: TWARN: Failed to remove netdevice ltp_vcan0: ENODEV

	Maybe we should call modprobe only on kernel <= 4.4 (to test automatic
	module loading on newer kernels where it's supposed to work), but it would
	not be possible to implement it via .modprobe_module. Adding
	tst_modprobe_module(), which I was asked by Li would allow to call it only
	for older kernel.

 ** testcases/kernel/syscalls/madvise/madvise11.c
	.modprobe_module does a lot of simplification here (I should verify, if it
	really detects a bug on kernels with reverted d4ae9916ea29).

    BTW madvise11.c writes to /dev/kmsg, which is also done in kmsg01.c (+
	deprecated ltp-pan.c). I'm not sure if it's worth to move this code to
	library when only 2 tests use it, but generic code like this certainly
	belongs to the library. Maybe we could write starting of the test in
	/dev/kmsg in the library for tests which runs under root (getuid() == 0 or
	on tests with .needs_root = 1).

Also I mentioned in the pathset tests which use modprobe but using
.modprobe_module is not usable:

 ** kvm_pagefault01.c would require module parameters, which can be actually
	useful. But it also uses reloading module (via test specific reload_module()
	function), e.g. something used only in this test.

 ** zram03.c, zram_lib.sh (too complicated check due /sys/class/zram-control
	introduced in v4.2-rc1 vs. the old API, but maybe this could be simplified).
	Again, tst_modprobe_module() would remove code duplication.

 ** netstress.c (used only when testing dccp, which is determined by getopts)
	=> use tst_modprobe_module()

Implementing tst_modprobe_module() in the library would reduce some code, I'll
probably implement it.

What about .modprobe_module?  We have tests which load kernel modules from LTP
via insmod and rmmod via tst_module_load(), tst_module_unload() (at least
delete_module03.c needs it, possibly others). Maybe rename them to
tst_insmod_module() and tst_rmmod_module() and create tst_module_unload() which
would use "modprobe -r" which would be used in can_bcm01.c, madvise11.c,
netstress.c, zram03.c and in .modprobe_module (in cleanup phase) if implemented?

> I do have one patch this time, please have a look if you have time:

> http://patchwork.ozlabs.org/project/ltp/patch/20231031125114.5879-1-chrubis@suse.cz/

I'll try to have look in next days.

> I would like to finish the tst_fd iterator patchset if possible, but
> depending on the amount of patches that I will have to review I may not
> make it.

+1

Kind regards,
Petr

[1] https://lore.kernel.org/linux-bcachefs/o7py4ia3s75popzz7paf3c6347te6h3qms675lz3s2k5eltskl@cklacfnvxb7k/
[2] https://patchwork.ozlabs.org/project/ltp/list/?series=377451&state=*

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] LTP Release preparations

[Petr Vorel]

Hi Cyril, all,

> Hi Cyril, all,
...
> * .modprobe_module
> I'm not sure about .modprobe_module [2]. I have draft of v3, but I'm not sure if
> it's needed. My motivation was to fix setsockopt08.c failure on openSUSE
> Tumbleweed, but that turns out to be procps package issue due broken symlink
> (bsc#1217990). Calling modprobe is is needed on these tests:

It looks like also keyctl05 requires modprobe for part of the functionality
https://lore.kernel.org/ltp/20240110175931.GA1766165@pevik/
=> it would be another user of .modprobe_module (unless there is a way to
trigger automatic loading of dns_resolver module).

Kind regards,
Petr

>  ** testcases/network/can/cve/can_bcm01.c
> 	modprobe on can_bcm01.c is required to fix failures on sle-12-SP3 which uses
> 	4.4 based kernel (I'm not sure if the problem is on mainline as well):
> 	can_bcm01.c:44: TBROK: Failed to create vcan device ltp_vcan0: EOPNOTSUPP
> 	can_bcm01.c:126: TWARN: Failed to remove netdevice ltp_vcan0: ENODEV

> 	Maybe we should call modprobe only on kernel <= 4.4 (to test automatic
> 	module loading on newer kernels where it's supposed to work), but it would
> 	not be possible to implement it via .modprobe_module. Adding
> 	tst_modprobe_module(), which I was asked by Li would allow to call it only
> 	for older kernel.

>  ** testcases/kernel/syscalls/madvise/madvise11.c
> 	.modprobe_module does a lot of simplification here (I should verify, if it
> 	really detects a bug on kernels with reverted d4ae9916ea29).

>     BTW madvise11.c writes to /dev/kmsg, which is also done in kmsg01.c (+
> 	deprecated ltp-pan.c). I'm not sure if it's worth to move this code to
> 	library when only 2 tests use it, but generic code like this certainly
> 	belongs to the library. Maybe we could write starting of the test in
> 	/dev/kmsg in the library for tests which runs under root (getuid() == 0 or
> 	on tests with .needs_root = 1).

> Also I mentioned in the pathset tests which use modprobe but using
> .modprobe_module is not usable:

>  ** kvm_pagefault01.c would require module parameters, which can be actually
> 	useful. But it also uses reloading module (via test specific reload_module()
> 	function), e.g. something used only in this test.

>  ** zram03.c, zram_lib.sh (too complicated check due /sys/class/zram-control
> 	introduced in v4.2-rc1 vs. the old API, but maybe this could be simplified).
> 	Again, tst_modprobe_module() would remove code duplication.

>  ** netstress.c (used only when testing dccp, which is determined by getopts)
> 	=> use tst_modprobe_module()

> Implementing tst_modprobe_module() in the library would reduce some code, I'll
> probably implement it.

> What about .modprobe_module?  We have tests which load kernel modules from LTP
> via insmod and rmmod via tst_module_load(), tst_module_unload() (at least
> delete_module03.c needs it, possibly others). Maybe rename them to
> tst_insmod_module() and tst_rmmod_module() and create tst_module_unload() which
> would use "modprobe -r" which would be used in can_bcm01.c, madvise11.c,
> netstress.c, zram03.c and in .modprobe_module (in cleanup phase) if implemented?
...

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] LTP Release preparations

[Petr Vorel]

Hi Cyril, all,
> ...
> > * .modprobe_module
> > I'm not sure about .modprobe_module [2]. I have draft of v3, but I'm not sure if
> > it's needed. My motivation was to fix setsockopt08.c failure on openSUSE
> > Tumbleweed, but that turns out to be procps package issue due broken symlink
> > (bsc#1217990). Calling modprobe is is needed on these tests:

> It looks like also keyctl05 requires modprobe for part of the functionality
> https://lore.kernel.org/ltp/20240110175931.GA1766165@pevik/
> => it would be another user of .modprobe_module (unless there is a way to
> trigger automatic loading of dns_resolver module).

keyctl05 modprobe implemented, this should be merged before the release:

https://lore.kernel.org/ltp/20240111094530.1893262-1-pvorel@suse.cz/

NOTE: These rare cases where automatic module loading is not possible to detect
justify .modprobe_module, but I'd keep it as a last result. If possible
.needs_drivers should be used. I'll add it to upcoming version (probably not for
this release).

I also wonder if naming is not misleading, we have:

1) .needs_drivers (in shell API $TST_NEEDS_DRIVERS) - expect we find kernel
   module in standard location, e.g. in /lib/modules/$(uname -r)
   => IMHO it should be .needs_module (and $TST_NEEDS_MODULE in shell), but that
   would somehow clash with already used $TST_NEEDS_MODULE (see below)

2) .modprobe_module (again, kernel module in standard location, but just loaded,
   not yet implemented)

3) tst_require_module() in shell API only hooked via $TST_NEEDS_MODULE, which
  tries to load module build by LTP (out-of-tree module), used in insmod01.sh
  (ltp_insmod01.ko). There is no equivalent functionality for C API
  ({delete,finit,init}_module tests just use tst_module.h, but there is no
  helper in struct tst_test.
  => could we come up with better name for current $TST_NEEDS_MODULE?
  If we rename it, we could then use "needs_module" for 1).

Kind regards,
Petr

> Kind regards,
> Petr

> >  ** testcases/network/can/cve/can_bcm01.c
> > 	modprobe on can_bcm01.c is required to fix failures on sle-12-SP3 which uses
> > 	4.4 based kernel (I'm not sure if the problem is on mainline as well):
> > 	can_bcm01.c:44: TBROK: Failed to create vcan device ltp_vcan0: EOPNOTSUPP
> > 	can_bcm01.c:126: TWARN: Failed to remove netdevice ltp_vcan0: ENODEV

> > 	Maybe we should call modprobe only on kernel <= 4.4 (to test automatic
> > 	module loading on newer kernels where it's supposed to work), but it would
> > 	not be possible to implement it via .modprobe_module. Adding
> > 	tst_modprobe_module(), which I was asked by Li would allow to call it only
> > 	for older kernel.

> >  ** testcases/kernel/syscalls/madvise/madvise11.c
> > 	.modprobe_module does a lot of simplification here (I should verify, if it
> > 	really detects a bug on kernels with reverted d4ae9916ea29).

> >     BTW madvise11.c writes to /dev/kmsg, which is also done in kmsg01.c (+
> > 	deprecated ltp-pan.c). I'm not sure if it's worth to move this code to
> > 	library when only 2 tests use it, but generic code like this certainly
> > 	belongs to the library. Maybe we could write starting of the test in
> > 	/dev/kmsg in the library for tests which runs under root (getuid() == 0 or
> > 	on tests with .needs_root = 1).

> > Also I mentioned in the pathset tests which use modprobe but using
> > .modprobe_module is not usable:

> >  ** kvm_pagefault01.c would require module parameters, which can be actually
> > 	useful. But it also uses reloading module (via test specific reload_module()
> > 	function), e.g. something used only in this test.

> >  ** zram03.c, zram_lib.sh (too complicated check due /sys/class/zram-control
> > 	introduced in v4.2-rc1 vs. the old API, but maybe this could be simplified).
> > 	Again, tst_modprobe_module() would remove code duplication.

> >  ** netstress.c (used only when testing dccp, which is determined by getopts)
> > 	=> use tst_modprobe_module()

> > Implementing tst_modprobe_module() in the library would reduce some code, I'll
> > probably implement it.

> > What about .modprobe_module?  We have tests which load kernel modules from LTP
> > via insmod and rmmod via tst_module_load(), tst_module_unload() (at least
> > delete_module03.c needs it, possibly others). Maybe rename them to
> > tst_insmod_module() and tst_rmmod_module() and create tst_module_unload() which
> > would use "modprobe -r" which would be used in can_bcm01.c, madvise11.c,
> > netstress.c, zram03.c and in .modprobe_module (in cleanup phase) if implemented?
> ...

> Kind regards,
> Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] Kirk update [was Re: LTP Release preparations]

[Petr Vorel]

Hi Cyril, Andrea,

...
> If you have any patches that should be reviewed before the release,
> please let me know.

We use kirk c47d3d9311b1b429f385e8d2b35da96dd4330df5 (which is newer than the
only kirk release v1.1).

Andrea, how about release new kirk version and update it in LTP?
It could be either current HEAD (bcb2df815d3fdbca470c1ff6ab14ac9cb2f9e3b7) or
some older commit (there are several fixes).

We should update kirk in LTP before git freeze, to avoid last minute errors.

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] Kirk update [was Re: LTP Release preparations]

[Andrea Cervesato via ltp]

HiPetr,

On 1/2/24 22:07, Petr Vorel wrote:
> Hi Cyril, Andrea,
>
> ...
>> If you have any patches that should be reviewed before the release,
>> please let me know.
> We use kirk c47d3d9311b1b429f385e8d2b35da96dd4330df5 (which is newer than the
> only kirk release v1.1).
>
> Andrea, how about release new kirk version and update it in LTP?
> It could be either current HEAD (bcb2df815d3fdbca470c1ff6ab14ac9cb2f9e3b7) or
> some older commit (there are several fixes).
>
> We should update kirk in LTP before git freeze, to avoid last minute errors.
>
> Kind regards,
> Petr
>
sure I can do that. Let me discuss about some features which have to be 
implemented also.

Best regards,
Andrea


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] LTP Release preparations

[Petr Vorel]

Hi all,

I would prefer also to merge before release "remove UCLINUX" patchset (unless
nobody complains).

https://lore.kernel.org/ltp/20240103015240.1065284-1-pvorel@suse.cz/

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] LTP Release preparations

[Yang Xu (Fujitsu)]

Hi Cyril, all,


> Hi!
> Firstly happy new year to everyone.
> 
> Secondly as usually we are supposed to produce a release at the end of
> the month. I will start by going over patchwork this week and try to
> review and merge as much as possible. Given that it's the start of the
> January we have about two weeks for this before we have to declare a git
> freeze and start pre-release testing. Does that sound fine to everyone?
> 
> If you have any patches that should be reviewed before the release,
> please let me know.
> 
I would like to have this patchset merged before the release:

libltpswap: Add get_maxswapfiles api
https://patchwork.ozlabs.org/project/ltp/list/?series=387814

Best Regards，
Yang Xu

> I do have one patch this time, please have a look if you have time:
> 
> http://patchwork.ozlabs.org/project/ltp/patch/20231031125114.5879-1-chrubis@suse.cz/
> 
> I would like to finish the tst_fd iterator patchset if possible, but
> depending on the amount of patches that I will have to review I may not
> make it.
> 

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] LTP Release preparations

[Petr Vorel]

Hi Cyril, all,

> If you have any patches that should be reviewed before the release,
> please let me know.

Could anybody have look on:

* swapon01: Test on all filesystems
https://patchwork.ozlabs.org/project/ltp/list/?series=377167&state=*
https://lore.kernel.org/ltp/20231011162428.583911-1-pvorel@suse.cz/
(already reviewed by Marius)

* v2 net: tst_netload_compare(): Ignore performance failures
https://lore.kernel.org/ltp/20240104121001.1155491-1-pvorel@suse.cz/
https://patchwork.ozlabs.org/project/ltp/patch/20240104121001.1155491-1-pvorel@suse.cz/

* Cleanup environment variables prefixes (TST_ => LTP_)
https://lore.kernel.org/ltp/20240104122308.1158487-1-pvorel@suse.cz/
https://patchwork.ozlabs.org/project/ltp/list/?series=388855&state=*

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] LTP Release preparations

[Cyril Hrubis]

Hi!
> > If you have any patches that should be reviewed before the release,
> > please let me know.
> 
> Could anybody have look on:
> 
> * swapon01: Test on all filesystems
> https://patchwork.ozlabs.org/project/ltp/list/?series=377167&state=*
> https://lore.kernel.org/ltp/20231011162428.583911-1-pvorel@suse.cz/
> (already reviewed by Marius)
> 
> * v2 net: tst_netload_compare(): Ignore performance failures
> https://lore.kernel.org/ltp/20240104121001.1155491-1-pvorel@suse.cz/
> https://patchwork.ozlabs.org/project/ltp/patch/20240104121001.1155491-1-pvorel@suse.cz/
> 
> * Cleanup environment variables prefixes (TST_ => LTP_)
> https://lore.kernel.org/ltp/20240104122308.1158487-1-pvorel@suse.cz/
> https://patchwork.ozlabs.org/project/ltp/list/?series=388855&state=*

I will, I'm currently cleaning up github issues and merging stuff that
has been ready and waiting there for quite some time.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] LTP Release preparations

[Cyril Hrubis]

Hi!
As we are nearing the end of the month I would like to get to a git
freeze and start with a pre-release tesing. Ideally I would like to
freeze the git this Friday 19.

If there is anything I should have a look at before the freeze or that I
have missed please point it out so that I can have a look.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] LTP Release preparations

[Li Wang]

Hi All,

On Thu, Jan 18, 2024 at 10:44 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> As we are nearing the end of the month I would like to get to a git
> freeze and start with a pre-release tesing. Ideally I would like to
> freeze the git this Friday 19.
>
> If there is anything I should have a look at before the freeze or that I
> have missed please point it out so that I can have a look.
>

Test based on the latest LTP (main-branch + libswap-patchset) results as:

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
    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


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


-- 
Regards,
Li Wang

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] LTP Release preparations

[Cyril Hrubis]

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.

> 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.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [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

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp