[LTP] LTP release preparations

[LTP] LTP release preparations

[Cyril Hrubis]

Hi!
It's time to start working on pre-release preparations. As usually we
should start by considering patches that should be applied before we
freeze the git.

As for me I would like to get the runtime patchset in if possible.

What else should be considered for the release?

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] LTP release preparations

[Petr Vorel]

Hi Cyril,

> What else should be considered for the release?

Fixes (worth to merge before)
* if-mtu-change.sh: Fix using functions
https://patchwork.ozlabs.org/project/ltp/patch/20220509094322.10959-1-pvorel@suse.cz/

* Fix constant redefinition
https://patchwork.ozlabs.org/project/ltp/list/?series=298174

I'd also like to post rebased
* shell: Fixes for disabled IPv6
https://patchwork.ozlabs.org/project/ltp/list/?series=284532
* shell: Add $TST_MOUNT_DEVICE support
https://patchwork.ozlabs.org/project/ltp/list/?series=291724

Could we decide whether this fix is worth of merging?
* Fix tst_search_driver for x86-64 modules
https://patchwork.ozlabs.org/project/ltp/list/?series=290523

2 additions to runtest/smoketest
* smoketest: Add macsec02.sh
https://patchwork.ozlabs.org/project/ltp/patch/20220310104457.764-1-pvorel@suse.cz/
* smoketest: Add df01.sh
https://patchwork.ozlabs.org/project/ltp/patch/20220322165042.20658-1-pvorel@suse.cz/

I guess we can postpone switching to bionic after the release
* ci: Ubuntu xenial -> bionic
https://patchwork.ozlabs.org/project/ltp/patch/20220316150429.2873-1-pvorel@suse.cz/

also remove rup and rusers can be decided after the release (although it's not
working on my VMs and I don't think it's worth to fix them)
* Remove RPC rup and rusers tests
https://patchwork.ozlabs.org/project/ltp/list/?series=297407

Kind regards,
Petr

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

Re: [LTP] LTP release preparations

[Li Wang]

[-- Attachment #1.1: Type: text/plain, Size: 757 bytes --]

On Mon, May 9, 2022 at 8:48 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> It's time to start working on pre-release preparations. As usually we
> should start by considering patches that should be applied before we
> freeze the git.
>
> As for me I would like to get the runtime patchset in if possible.
>

+1, I will add my review ASAP.



> What else should be considered for the release?
>


1628025 New          [v2] rtc02: loosen the compare precision with few
seconds
1625610 New          [1/2] lapi/mount.h: Remove <linux/mount.h>
1625609 New          [2/2] Remove duplicate include of <sys/mount.h>

also, I vote for adding expand Cgroup library from Luke's patchset, but
if time is hurrying I'm fine without it as well.



-- 
Regards,
Li Wang

[-- Attachment #1.2: Type: text/html, Size: 2055 bytes --]

[-- Attachment #2: Type: text/plain, Size: 60 bytes --]


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

Re: [LTP] LTP release preparations

[Cyril Hrubis]

Hi!
> > As for me I would like to get the runtime patchset in if possible.
> >
> 
> +1, I will add my review ASAP.

Thx.

> > What else should be considered for the release?
> >
> 
> 
> 1628025 New          [v2] rtc02: loosen the compare precision with few
> seconds
> 1625610 New          [1/2] lapi/mount.h: Remove <linux/mount.h>
> 1625609 New          [2/2] Remove duplicate include of <sys/mount.h>
> 
> also, I vote for adding expand Cgroup library from Luke's patchset, but
> if time is hurrying I'm fine without it as well.

I would vote for getting the cgroup patchset in as well here, even if
that would delay the release by a few days.

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] LTP release preparations

[Martin Doucha]

On 09. 05. 22 14:50, Cyril Hrubis wrote:
> Hi!
> It's time to start working on pre-release preparations. As usually we
> should start by considering patches that should be applied before we
> freeze the git.
> 
> As for me I would like to get the runtime patchset in if possible.
> 
> What else should be considered for the release?

I'd like to add the two KVM patches - memory access helper functions and
multiple iteration support. I can't finish the KVM documentation until
they're merged.

-- 
Martin Doucha   mdoucha@suse.cz
QA Engineer for Software Maintenance
SUSE LINUX, s.r.o.
CORSO IIa
Krizikova 148/34
186 00 Prague 8
Czech Republic

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

Re: [LTP] LTP release preparations

[Cyril Hrubis]

Hi!
> I'd like to add the two KVM patches - memory access helper functions and
> multiple iteration support. I can't finish the KVM documentation until
> they're merged.

I will have a look.

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] LTP release preparations

[Cyril Hrubis]

Hi!
I've finally pushed the runtest patchset, many thanks for reviews
especially Li for his careful review and tests.

Other than that I will have a look at the KVM documentation by Martin,
since it would be nice to include documentation for the newly added
library and as this is not a code change it will be safe for the
release.

With that I would like to release at the end of the week, which gives us
chance to re-test with the runtime patches on the top. I will run a few
testruns myself just to make sure that everything is fine.

-- 
Cyril Hrubis
chrubis@suse.cz

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

[LTP] [PATCH] preadv203: set max_runtime to 270s

[Li Wang]

Before the runtime patchset preadv203 use 5min as default timeout
per fs, that's really long enough for prepare_device(). But after
that, its now only has 30s which might be short for a slower system
to do preparation work.

Let's set max_runtime to 270s to make the timeout at least equal
to previously.

  ==== Before =====
  # ./preadv203
  ...
  tst_test.c:1459: TINFO: Timeout per run is 0h 05m 00s
  preadv203.c:143: TINFO: Number of full_reads 2567, short reads 10, zero len reads 0, EAGAIN(s) 2530185
  preadv203.c:180: TINFO: Number of writes 682740
  preadv203.c:194: TINFO: Cache dropped 114 times
  preadv203.c:223: TPASS: Got some EAGAIN
  tst_test.c:1531: TINFO: Testing on ext3
  tst_test.c:999: TINFO: Formatting /dev/loop0 with ext3 opts='' extra opts=''
  mke2fs 1.46.5 (30-Dec-2021)
  tst_test.c:1459: TINFO: Timeout per run is 0h 05m 00s
  ...

  ==== After =====
  # time ./preadv203
  tst_device.c:89: TINFO: Found free device 0 '/dev/loop0'
  tst_test.c:1524: TINFO: Timeout per run is 0h 00m 30s
  tst_supported_fs_types.c:89: TINFO: Kernel supports ext2
  ...
  tst_test.c:1597: TINFO: Testing on ext2
  tst_test.c:1062: TINFO: Formatting /dev/loop0 with ext2 opts='' extra opts=''
  mke2fs 1.46.5 (30-Dec-2021)
  Test timeouted, sending SIGKILL!
  tst_test.c:1575: TINFO: If you are running on slow machine, try exporting LTP_TIMEOUT_MUL > 1
  tst_test.c:1577: TBROK: Test killed! (timeout?)

  Summary:
  passed   0
  failed   0
  broken   1
  skipped  0
  warnings 0

  real	0m36.246s
  user	0m0.706s
  sys	1m2.965s

Signed-off-by: Li Wang <liwang@redhat.com>
Cc: Cyril Hrubis <chrubis@suse.cz>
---

Notes:
    Another fixe way is going with define DEFAULT_TIMEOUT to 60, that
    generally extends all timeout for each fs to perform prepare_device().
    And this will impact all test cases with setting .all_filesystems.

 testcases/kernel/syscalls/preadv2/preadv203.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/testcases/kernel/syscalls/preadv2/preadv203.c b/testcases/kernel/syscalls/preadv2/preadv203.c
index 01622ad15..46bb39ef1 100644
--- a/testcases/kernel/syscalls/preadv2/preadv203.c
+++ b/testcases/kernel/syscalls/preadv2/preadv203.c
@@ -279,5 +279,6 @@ static struct tst_test test = {
 	.mntpoint = MNTPOINT,
 	.mount_device = 1,
 	.all_filesystems = 1,
+	.max_runtime = 270,
 	.needs_root = 1,
 };
-- 
2.31.1


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

Re: [LTP] [PATCH] preadv203: set max_runtime to 270s

[Cyril Hrubis]

Hi!
> Before the runtime patchset preadv203 use 5min as default timeout
> per fs, that's really long enough for prepare_device(). But after
> that, its now only has 30s which might be short for a slower system
> to do preparation work.
> 
> Let's set max_runtime to 270s to make the timeout at least equal
> to previously.

Isn't the main reason why the test fails that the verify_preadv2()
function spins for at most 60 seconds?

I guess that the proper solution should be:

diff --git a/testcases/kernel/syscalls/preadv2/preadv203.c b/testcases/kernel/syscalls/preadv2/preadv203.c
index 01622ad15..e9377071e 100644
--- a/testcases/kernel/syscalls/preadv2/preadv203.c
+++ b/testcases/kernel/syscalls/preadv2/preadv203.c
@@ -199,7 +199,6 @@ static void *cache_dropper(void *unused)
 static void verify_preadv2(void)
 {
        pthread_t reader, dropper, writer;
-       unsigned int max_runtime = 600;
        void *eagains;

        stop = 0;
@@ -210,7 +209,7 @@ static void verify_preadv2(void)
        SAFE_PTHREAD_CREATE(&reader, NULL, nowait_reader, NULL);
        SAFE_PTHREAD_CREATE(&writer, NULL, writer_thread, NULL);

-       while (!stop && max_runtime-- > 0)
+       while (!stop && tst_remaining_runtime())
                usleep(100000);

        stop = 1;
@@ -280,4 +279,5 @@ static struct tst_test test = {
        .mount_device = 1,
        .all_filesystems = 1,
        .needs_root = 1,
+       .max_runtime = 60,
 };

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] [PATCH] preadv203: set max_runtime to 270s

[Li Wang]

[-- Attachment #1.1: Type: text/plain, Size: 724 bytes --]

Cyril Hrubis <chrubis@suse.cz> wrote:

Hi!
> > Before the runtime patchset preadv203 use 5min as default timeout
> > per fs, that's really long enough for prepare_device(). But after
> > that, its now only has 30s which might be short for a slower system
> > to do preparation work.
> >
> > Let's set max_runtime to 270s to make the timeout at least equal
> > to previously.
>
> Isn't the main reason why the test fails that the verify_preadv2()
> function spins for at most 60 seconds?
>

Ah, you're right!
I overlooked that spins 60s but wrongly blame the default timeout in the
library.

>
> I guess that the proper solution should be:
>

This patch works for me. I will send V2 as your suggestion.

-- 
Regards,
Li Wang

[-- Attachment #1.2: Type: text/html, Size: 1672 bytes --]

[-- Attachment #2: Type: text/plain, Size: 60 bytes --]


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

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]

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

[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

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

[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

[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

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

[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

[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 Edward,

thanks for your fixes. Unfortunately I already released LTP earlier in Friday.
Next time we notify the community earlier and specify also expected hour when we release.

Kind regards,
Petr

> Hi Petr,

> Sorry for the last minute reply.  Just sent two minor patches for pipe07 and
> getpgid01 that were failing on Android.  Other than that it looks good so far.

> Thanks for all your hard work.

> Cheers
> Edward

> On Tue, Sep 26, 2023 at 3:50 AM Petr Vorel <pvorel@suse.cz> wrote:

> > Hi testing community,

> > > Hi!
> > > As usuall we are supposed the release LTP at the end of the month. In
> > > order to get at least two weeks of pre-release testing I would like to
> > > freeze the git starting next week. I will try to review and merge as
> > > much as possible till the end of this week. If there is anything that
> > > you think should go into the release let me know so that I can have a
> > > look.

> > FYI we plan to release LTP this week on Friday. It's not much time left, but if
> > you have time, please try to do some LTP pre-release testing on your favourite
> > distro.

> > Thanks!

> > Kind regards,
> > Petr

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

Re: [LTP] LTP Release preparations

[Edward Liaw via ltp]

Hi Petr,

Sorry for the last minute reply.  Just sent two minor patches for pipe07 and
getpgid01 that were failing on Android.  Other than that it looks good so far.

Thanks for all your hard work.

Cheers
Edward

On Tue, Sep 26, 2023 at 3:50 AM Petr Vorel <pvorel@suse.cz> wrote:
>
> Hi testing community,
>
> > Hi!
> > As usuall we are supposed the release LTP at the end of the month. In
> > order to get at least two weeks of pre-release testing I would like to
> > freeze the git starting next week. I will try to review and merge as
> > much as possible till the end of this week. If there is anything that
> > you think should go into the release let me know so that I can have a
> > look.
>
> FYI we plan to release LTP this week on Friday. It's not much time left, but if
> you have time, please try to do some LTP pre-release testing on your favourite
> distro.
>
> Thanks!
>
> Kind regards,
> Petr

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

Re: [LTP] LTP Release preparations

[Petr Vorel]

Hi Li,

> Hi Petr,

> On Tue, Sep 26, 2023 at 6:50 PM Petr Vorel <pvorel@suse.cz> wrote:

> > Hi testing community,

> > > Hi!
> > > As usuall we are supposed the release LTP at the end of the month. In
> > > order to get at least two weeks of pre-release testing I would like to
> > > freeze the git starting next week. I will try to review and merge as
> > > much as possible till the end of this week. If there is anything that
> > > you think should go into the release let me know so that I can have a
> > > look.

> > FYI we plan to release LTP this week on Friday. It's not much time left,
> > but if
> > you have time, please try to do some LTP pre-release testing on your
> > favourite
> > distro.


> ACK.

> My pre-release test result looks good on our RHEL8/9. Just some minor
> error/timedout issue which have already been tracked.

Thanks a lot for your time to test!

> (Thanks for your work on the release, I'm already on vacation this week,
> specially come to reply to you for adding confidence in the new package:).

Ah, I appreciate that a lot, thank you!

Kind regards,
Petr

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

Re: [LTP] LTP Release preparations

[Li Wang]

Hi Petr,

On Tue, Sep 26, 2023 at 6:50 PM Petr Vorel <pvorel@suse.cz> wrote:

> Hi testing community,
>
> > Hi!
> > As usuall we are supposed the release LTP at the end of the month. In
> > order to get at least two weeks of pre-release testing I would like to
> > freeze the git starting next week. I will try to review and merge as
> > much as possible till the end of this week. If there is anything that
> > you think should go into the release let me know so that I can have a
> > look.
>
> FYI we plan to release LTP this week on Friday. It's not much time left,
> but if
> you have time, please try to do some LTP pre-release testing on your
> favourite
> distro.
>

ACK.

My pre-release test result looks good on our RHEL8/9. Just some minor
error/timedout issue which have already been tracked.

(Thanks for your work on the release, I'm already on vacation this week,
specially come to reply to you for adding confidence in the new package:).


-- 
Regards,
Li Wang

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

Re: [LTP] LTP Release preparations

[Petr Vorel]

Hi testing community,

> Hi!
> As usuall we are supposed the release LTP at the end of the month. In
> order to get at least two weeks of pre-release testing I would like to
> freeze the git starting next week. I will try to review and merge as
> much as possible till the end of this week. If there is anything that
> you think should go into the release let me know so that I can have a
> look.

FYI we plan to release LTP this week on Friday. It's not much time left, but if
you have time, please try to do some LTP pre-release testing on your favourite
distro.

Thanks!

Kind regards,
Petr

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

Re: [LTP] LTP Release preparations

[Richard Palethorpe]

Hello,

Petr Vorel <pvorel@suse.cz> writes:

> Hi all,
>
> Richie suggested [1] to merge my fix for zram01.sh [2] [3].
> If we agree on this, I'll send v2 with renamed function
> check_read_mem_used_total() as Li suggested [4].

Sorry didn't see this, I have already done that and merged it.

>
> Kind regards,
> Petr
>
> [1] https://lore.kernel.org/ltp/87a5tjhl24.fsf@suse.de/
> [2] https://lore.kernel.org/ltp/20221107191136.18048-2-pvorel@suse.cz/
> [3] https://patchwork.ozlabs.org/project/ltp/patch/20221107191136.18048-2-pvorel@suse.cz/
> [4]
> https://lore.kernel.org/ltp/CAEemH2fYv_=9UWdWB7VDiFOd8EC89qdCbxnPcTPAtGnkwLOYFg@mail.gmail.com/


-- 
Thank you,
Richard.

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

Re: [LTP] LTP Release preparations

[Petr Vorel]

Hi all,

Richie suggested [1] to merge my fix for zram01.sh [2] [3].
If we agree on this, I'll send v2 with renamed function
check_read_mem_used_total() as Li suggested [4].

Kind regards,
Petr

[1] https://lore.kernel.org/ltp/87a5tjhl24.fsf@suse.de/
[2] https://lore.kernel.org/ltp/20221107191136.18048-2-pvorel@suse.cz/
[3] https://patchwork.ozlabs.org/project/ltp/patch/20221107191136.18048-2-pvorel@suse.cz/
[4]
https://lore.kernel.org/ltp/CAEemH2fYv_=9UWdWB7VDiFOd8EC89qdCbxnPcTPAtGnkwLOYFg@mail.gmail.com/

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

Re: [LTP] LTP Release preparations

[Cyril Hrubis]

Hi!
> it would be nice to add the ltx tool into the next release.
> https://github.com/acerv/ltx

So this is the tool for kirk (aka runltp-ng ng) used for the parallel
execution.

I suppose that we should add it as another LTP submodule, right?

But firstly I guess that we should move that under the
linux-test-project umbrela, since this is part of the kirk.

-- 
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!
> > > As usuall we are supposed the release LTP at the end of the month. In
> > > order to get at least two weeks of pre-release testing I would like to
> > > freeze the git starting next week. I will try to review and merge as
> > > much as possible till the end of this week. If there is anything that
> > > you think should go into the release let me know so that I can have a
> > > look.

> I also wonder if we could add LTP version patchset [1].

> Cyril raised concern to add -V (not sure why, maybe not to took -V for program
> specific getopt), instead he suggested to put this to -h or to both. [2]

> As I stated [3], I'm ok with both options. Unless anybody gives any input I'll
> send a patch which implements printing version in -h (i.e. not introduce -V).

I'm sorry, I didn't notice the LTP version patchset was already accepted. Thank you!

Kind regards,
Petr

> Kind regards,
> Petr

> [1] https://patchwork.ozlabs.org/project/ltp/list/?series=364651&state=*
> [2] https://lore.kernel.org/ltp/ZL-5kfsRIzh1ZkNd@yuki/
> [3] https://lore.kernel.org/ltp/20230725122325.GB12613@pevik/

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

Re: [LTP] LTP Release preparations

[Andrea Cervesato via ltp]

Hi!

it would be nice to add the ltx tool into the next release.
https://github.com/acerv/ltx

Regards,
Andrea Cervesato

On 9/13/23 10:56, Cyril Hrubis wrote:
> Hi!
> As usuall we are supposed the release LTP at the end of the month. In
> order to get at least two weeks of pre-release testing I would like to
> freeze the git starting next week. I will try to review and merge as
> much as possible till the end of this week. If there is anything that
> you think should go into the release let me know so that I can have a
> look.
>


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

Re: [LTP] LTP Release preparations

[Petr Vorel]

Hi Cyril, all,

> > Hi!
> > As usuall we are supposed the release LTP at the end of the month. In
> > order to get at least two weeks of pre-release testing I would like to
> > freeze the git starting next week. I will try to review and merge as
> > much as possible till the end of this week. If there is anything that
> > you think should go into the release let me know so that I can have a
> > look.

I also wonder if we could add LTP version patchset [1].

Cyril raised concern to add -V (not sure why, maybe not to took -V for program
specific getopt), instead he suggested to put this to -h or to both. [2]

As I stated [3], I'm ok with both options. Unless anybody gives any input I'll
send a patch which implements printing version in -h (i.e. not introduce -V).

Kind regards,
Petr

[1] https://patchwork.ozlabs.org/project/ltp/list/?series=364651&state=*
[2] https://lore.kernel.org/ltp/ZL-5kfsRIzh1ZkNd@yuki/
[3] https://lore.kernel.org/ltp/20230725122325.GB12613@pevik/

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

Re: [LTP] LTP Release preparations

[Petr Vorel]

Hi Cyril, all,

> Hi!
> As usuall we are supposed the release LTP at the end of the month. In
> order to get at least two weeks of pre-release testing I would like to
> freeze the git starting next week. I will try to review and merge as
> much as possible till the end of this week. If there is anything that
> you think should go into the release let me know so that I can have a
> look.

I'd like to merge first patch [1] of Amir's fanotify13 patchset (Richie noticed
it's not v6.5 related and I tested it correctly TCONF on older kernels). The
other two patches should be merged after v6.6 is released (they test v6.6
functionality).

I'd also like to get merged my patchset TST_SKIP_IN_{LOCKDOWN,SECUREBOOT}=1 for
shell [2]. It follows the same approach we chose for C  based tests.

I also want to have a closer look on ipneigh01.sh related fix [3].

Kind regards,
Petr

[1] https://patchwork.ozlabs.org/project/ltp/patch/20230903111558.2603332-2-amir73il@gmail.com/
[2] https://patchwork.ozlabs.org/project/ltp/list/?series=366240&state=*
[3] https://patchwork.ozlabs.org/project/ltp/patch/20230815085706.1077725-1-xusenmiao@huawei.com/

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

Re: [LTP] LTP Release preparations

[Cyril Hrubis]

Hi!
> > As usuall we are supposed the release LTP at the end of the month. In
> > order to get at least two weeks of pre-release testing I would like to
> > freeze the git starting next week. I will try to review and merge as
> > much as possible till the end of this week. If there is anything that
> > you think should go into the release let me know so that I can have a
> > look.
> >
> It would be nice to push mqns_03/mqns_04 since they have been already 
> reviewed by Petr Vorel.
> In this way we can finally remove libclone library from LTP containers 
> testing suite.

The v8 has been set to 'changes requested' in patchwork, hence it got
lost from from my radar, I will have a look.

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] LTP Release preparations

[Andrea Cervesato via ltp]

Hi!

On 9/13/23 10:56, Cyril Hrubis wrote:
> Hi!
> As usuall we are supposed the release LTP at the end of the month. In
> order to get at least two weeks of pre-release testing I would like to
> freeze the git starting next week. I will try to review and merge as
> much as possible till the end of this week. If there is anything that
> you think should go into the release let me know so that I can have a
> look.
>
It would be nice to push mqns_03/mqns_04 since they have been already 
reviewed by Petr Vorel.
In this way we can finally remove libclone library from LTP containers 
testing suite.

Andrea


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

Re: [LTP] LTP Release preparations

[Martin Doucha]

On 13. 09. 23 10:56, Cyril Hrubis wrote:
> Hi!
> As usuall we are supposed the release LTP at the end of the month. In
> order to get at least two weeks of pre-release testing I would like to
> freeze the git starting next week. I will try to review and merge as
> much as possible till the end of this week. If there is anything that
> you think should go into the release let me know so that I can have a
> look.

Hi,
I'd like to include my tcindex01 simplification patch in the release.

-- 
Martin Doucha   mdoucha@suse.cz
SW Quality Engineer
SUSE LINUX, s.r.o.
CORSO IIa
Krizikova 148/34
186 00 Prague 8
Czech Republic


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

[LTP] LTP Release preparations

[Cyril Hrubis]

Hi!
As usuall we are supposed the release LTP at the end of the month. In
order to get at least two weeks of pre-release testing I would like to
freeze the git starting next week. I will try to review and merge as
much as possible till the end of this week. If there is anything that
you think should go into the release let me know 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

[Petr Vorel]

> Hi all,

> > Hi Cyril,

> > > Hi!
> > > > I'll can do, what I did previously:
> > > > 	- new release commit and tag and create release in github from it
> > > >     - uploading tarballs
> > > > 	- release notes for shell API (mostly network shell API)

> > > > It'd be big help if Cyril managed to do release notes and the announcement.

> > > I'm ready at my side. Peter can you please proceed with tagging the git
> > > and tarball upload?

> > Sure, I'm about to do it now.

> I've tagged LTP, created release on Github, where I uploaded tarballs, checksums
> and html metadata. I'll upload pdf metadata shortly.

OK, PDF metadata has 19 MB, let's not upload it. FYI HTML metadata has 2.3 MB.

Kind regards,
Petr

> @Cyril please post the announcement and add it to the release (or let me know if
> I should add it from your mail).

> Kind regards,
> Petr

> > Kind regards,
> > Petr

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

Re: [LTP] LTP release preparations

[Petr Vorel]

Hi all,

> Hi Cyril,

> > Hi!
> > > I'll can do, what I did previously:
> > > 	- new release commit and tag and create release in github from it
> > >     - uploading tarballs
> > > 	- release notes for shell API (mostly network shell API)

> > > It'd be big help if Cyril managed to do release notes and the announcement.

> > I'm ready at my side. Peter can you please proceed with tagging the git
> > and tarball upload?

> Sure, I'm about to do it now.

I've tagged LTP, created release on Github, where I uploaded tarballs, checksums
and html metadata. I'll upload pdf metadata shortly.

@Cyril please post the announcement and add it to the release (or let me know if
I should add it from your mail).

Kind regards,
Petr

> Kind regards,
> Petr

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

Re: [LTP] LTP release preparations

[Petr Vorel]

Hi Cyril,

> Hi!
> > I'll can do, what I did previously:
> > 	- new release commit and tag and create release in github from it
> >     - uploading tarballs
> > 	- release notes for shell API (mostly network shell API)

> > It'd be big help if Cyril managed to do release notes and the announcement.

> I'm ready at my side. Peter can you please proceed with tagging the git
> and tarball upload?

Sure, I'm about to do it now.

Kind regards,
Petr

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

Re: [LTP] LTP release preparations

[Cyril Hrubis]

Hi!
> I'll can do, what I did previously:
> 	- new release commit and tag and create release in github from it
>     - uploading tarballs
> 	- release notes for shell API (mostly network shell API)
> 
> It'd be big help if Cyril managed to do release notes and the announcement.

I'm ready at my side. Peter can you please proceed with tagging the git
and tarball upload?

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] LTP release preparations

[Li Wang]

On Wed, May 10, 2023 at 9:03 PM Petr Vorel <pvorel@suse.cz> wrote:

> Hi Cyril, Li, others,
>
> I see we're still discussing hugemmap test issues with FILE_PRINTF().
> Do we want to solve these before release?
>

I have merged the quick fix with Cryil's ack. So FILE_PRINTF() improvement
work can be delayed after release.



>
> Because if we want to release on Friday, we should start writing release
> notes
> and announcement. We're on a LABS conference next week. But not sure if
> it's a
> good idea to postpone (Cyril is and will be even more busy, I'll be away
> for few
> weeks before the end of the month).
>

IMO, it's OK to release on Friday, new test based on the latest commit
looks good.



>
> From the list we agreed previously [1]:
>
>     - announcement email,
>     - collecting patch lists for a new release,
>     - writing release notes, or paperwork,
>         - new release commit and tag and create release in github from it
> (not in [1], but obvious)
>     - uploading tarballs
>     - pre-testing against different Linux distribution
>
> I'll can do, what I did previously:
>         - new release commit and tag and create release in github from it
>     - uploading tarballs
>         - release notes for shell API (mostly network shell API)
>
> It'd be big help if Cyril managed to do release notes and the announcement.
>
> Kind regards,
> Petr
>
> [1]
> https://lore.kernel.org/ltp/CAEemH2eSJQ-_30_Y3A567oqBFSOo=1tt7LJMtPq_BodjVNsm8w@mail.gmail.com/
>
>

-- 
Regards,
Li Wang

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

Re: [LTP] LTP release preparations

[Cyril Hrubis]

Hi!
Pushed, thanks.

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] LTP release preparations

[Petr Vorel]

Hi Cyril, Li, others,

I see we're still discussing hugemmap test issues with FILE_PRINTF().
Do we want to solve these before release?

Because if we want to release on Friday, we should start writing release notes
and announcement. We're on a LABS conference next week. But not sure if it's a
good idea to postpone (Cyril is and will be even more busy, I'll be away for few
weeks before the end of the month).

From the list we agreed previously [1]:

    - announcement email,
    - collecting patch lists for a new release,
    - writing release notes, or paperwork,
	- new release commit and tag and create release in github from it (not in [1], but obvious)
    - uploading tarballs
    - pre-testing against different Linux distribution

I'll can do, what I did previously:
	- new release commit and tag and create release in github from it
    - uploading tarballs
	- release notes for shell API (mostly network shell API)

It'd be big help if Cyril managed to do release notes and the announcement.

Kind regards,
Petr

[1] https://lore.kernel.org/ltp/CAEemH2eSJQ-_30_Y3A567oqBFSOo=1tt7LJMtPq_BodjVNsm8w@mail.gmail.com/

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

Re: [LTP] LTP release preparations

[Martin Doucha]

On 26. 04. 23 11:17, Cyril Hrubis wrote:
> Hi!
> I would like to start with LTP pre-release preparations a bit sooner
> than usuall, since quite a lot of things have accumulated in May, e.g.
> there is a SUSE Labs conference right in the middle of the month.
> 
> I would like to start with reviewe of patches that should go in now,
> freeze the git somewhere at the end of the first week of May and aim for
> a release somewhere in the middle of the month. Does that sound Ok to
> everyone?
> 
> Either way if you have patches that should land in the upcomming
> release, please point them out now, so that we have a chance to review
> them.

Hi,
I've sent two patches fixing new failures in the rewritten 
kernel/containers tests. The failures are caused by getpid() return 
value being cached in older glibc versions because child processes 
created by SAFE_CLONE() cannot update the PID cache. Thus getpid() will 
keep returning the parent PID instead of the correct one. Newer glibc 
versions are not affected.

The patches:
- Add tst_getpid() helper function
- containers/pidns*: Fix PID checks

Please merge them before release.

-- 
Martin Doucha   mdoucha@suse.cz
QA Engineer for Software Maintenance
SUSE LINUX, s.r.o.
CORSO IIa
Krizikova 148/34
186 00 Prague 8
Czech Republic


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

Re: [LTP] LTP release preparations

[Li Wang]

Hi Cyril,

On Tue, May 9, 2023 at 5:34 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> > > More widely LTP pre-release test will be deployed base on RHEL products
> > > as well.
> > >
> >
> > I have completed the LTP pre-release test against RHEL 8 and 9,
> > all looks good except one test warning as below, but I suppose
> > it's a tiny problem caused by the ppc64le configuration.
> >
> > This only observed on ppc64le arch:
> >
> > 3 cmdline="hugemmap32"
> >
> >      4        contacts=""
> >      5        analysis=exit
> >      6        <<<test_output>>>
> >      7        tst_test.c:1558: TINFO: Timeout per run is 0h 01m 00s
> >      8        hugemmap32.c:34: TWARN: Failed to close FILE
> > '/sys/kernel/mm/hugepages/hugepages-16777216kB/nr_hugepages'
> >      9        hugemmap32.c:35: TCONF: Can't update the gigantic
> hugepages.
> >
> > 10 hugemmap32.c:69: TWARN: Failed to close FILE
> > '/sys/kernel/mm/hugepages/hugepages-16777216kB/nr_hugepages': EINVAL (22)
>
> Looking at the file_printf() the test uses it does produce a warning
> when we fail to write to the file.
>
> Also we seems to be using FILE_PRINTF() exactly in these tests:
>
> testcases/kernel/device-drivers/cpufreq/cpufreq_boost.c
> testcases/kernel/mem/hugetlb/hugemmap/hugemmap32.c
> testcases/kernel/mem/hugetlb/hugeshmget/hugeshmget03.c
> testcases/kernel/syscalls/fcntl/fcntl33.c
> testcases/kernel/syscalls/readahead/readahead02.c
>
> In three cases we use the FILE_PRINTF() in the test cleanup, which does
> not matter, since we do not break test on TBROK when we run in the test
> cleanup.
>
> That leaves us just hugemmap32 and readahead02 in both cases I think
> that generating TWARN in just plain wrong.
>
> So what about:
>
> * changing FILE_PRINTF() to SAFE_FILE_PRINTF() in test cleanup
> * changing TWARN to TINFO in FILE_PRINTF()
>
> I guess that we should have been using TINFO in the file_fprintf() from
> the start.
>

Yes, sure. I think this will be better for the FILE_PRINTF macro use.
Should we change that in a separate patch after the release?

But, I suppose that we still need to check the available memory in
hugemmap32, because that might be the reason, is unable to
write to the '.../nr_hugepages' file even with zero.

# cat /sys/kernel/mm/hugepages/hugepages-16777216kB/nr_hugepages
0

# echo 0 >/sys/kernel/mm/hugepages/hugepages-16777216kB/nr_hugepages
-bash: echo: write error: Invalid argument

-- 
Regards,
Li Wang

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

Re: [LTP] LTP release preparations

[Cyril Hrubis]

Hi!
> > More widely LTP pre-release test will be deployed base on RHEL products
> > as well.
> >
> 
> I have completed the LTP pre-release test against RHEL 8 and 9,
> all looks good except one test warning as below, but I suppose
> it's a tiny problem caused by the ppc64le configuration.
> 
> This only observed on ppc64le arch:
> 
> 3 cmdline="hugemmap32"
> 
>      4	contacts=""
>      5	analysis=exit
>      6	<<<test_output>>>
>      7	tst_test.c:1558: TINFO: Timeout per run is 0h 01m 00s
>      8	hugemmap32.c:34: TWARN: Failed to close FILE
> '/sys/kernel/mm/hugepages/hugepages-16777216kB/nr_hugepages'
>      9	hugemmap32.c:35: TCONF: Can't update the gigantic hugepages.
> 
> 10 hugemmap32.c:69: TWARN: Failed to close FILE
> '/sys/kernel/mm/hugepages/hugepages-16777216kB/nr_hugepages': EINVAL (22)

Looking at the file_printf() the test uses it does produce a warning
when we fail to write to the file.

Also we seems to be using FILE_PRINTF() exactly in these tests:

testcases/kernel/device-drivers/cpufreq/cpufreq_boost.c
testcases/kernel/mem/hugetlb/hugemmap/hugemmap32.c
testcases/kernel/mem/hugetlb/hugeshmget/hugeshmget03.c
testcases/kernel/syscalls/fcntl/fcntl33.c
testcases/kernel/syscalls/readahead/readahead02.c

In three cases we use the FILE_PRINTF() in the test cleanup, which does
not matter, since we do not break test on TBROK when we run in the test
cleanup.

That leaves us just hugemmap32 and readahead02 in both cases I think
that generating TWARN in just plain wrong.

So what about:

* changing FILE_PRINTF() to SAFE_FILE_PRINTF() in test cleanup
* changing TWARN to TINFO in FILE_PRINTF()

I guess that we should have been using TINFO in the file_fprintf() from
the start.

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] LTP release preparations

[Li Wang]

Hi All,

Li Wang <liwang@redhat.com> wrote:


> More widely LTP pre-release test will be deployed base on RHEL products
> as well.
>

I have completed the LTP pre-release test against RHEL 8 and 9,
all looks good except one test warning as below, but I suppose
it's a tiny problem caused by the ppc64le configuration.

This only observed on ppc64le arch:

3 cmdline="hugemmap32"

     4	contacts=""
     5	analysis=exit
     6	<<<test_output>>>
     7	tst_test.c:1558: TINFO: Timeout per run is 0h 01m 00s
     8	hugemmap32.c:34: TWARN: Failed to close FILE
'/sys/kernel/mm/hugepages/hugepages-16777216kB/nr_hugepages'
     9	hugemmap32.c:35: TCONF: Can't update the gigantic hugepages.

10 hugemmap32.c:69: TWARN: Failed to close FILE
'/sys/kernel/mm/hugepages/hugepages-16777216kB/nr_hugepages': EINVAL (22)


-- 
Regards,
Li Wang

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

Re: [LTP] LTP release preparations

[Yang Xu (Fujitsu)]

Hi Cyril

> Hi!
>> I prefer to include my STATX_DIO_ALIGN and mlock cleanup patchset before
>> release.
> 
> I merged mlock04. I'm unsure about the mlock03 removal, it seems to be a
> regression test after all.

Thanks, I just back from a long and happy holidy, I will submit a v3 for 
mlock03.

> 
> As for STAT_DIO_ALIGN I suppose that we need v5, right?

Yes, I will add some meaningful comment and modify to use in-tree 
definition on V5.

Best Regards
Yang Xu
> 

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

Re: [LTP] LTP release preparations

[Petr Vorel]

Hi all,

I suggest to merge these:

* Martin's patchset (first and second commit; the third one I dared to merge as
it's just doc fix)
https://patchwork.ozlabs.org/project/ltp/patch/20230505145626.2537-1-mdoucha@suse.cz/
https://patchwork.ozlabs.org/project/ltp/patch/20230505145626.2537-2-mdoucha@suse.cz/

* endian_switch01: Add HAVE_GETAUXVAL guarder
https://patchwork.ozlabs.org/project/ltp/patch/20230505162822.15676-1-pvorel@suse.cz/
Build fix for uclibc toolchains (Jan already acked that)

I'd also consider merging these 2 fixes:

* [v2] syscalls/sockioctl: Make buf a struct ifreq array
https://patchwork.ozlabs.org/project/ltp/patch/20230327110234.266785-1-teo.coupriediaz@arm.com/

* testcases:Fix the failure of shell script to get path
https://patchwork.ozlabs.org/project/ltp/patch/6b2a7ceb.4466.1874a537430.Coremail.crawler2015@163.com/

Kind regards,
Petr

> Hi!
> I would like to start with LTP pre-release preparations a bit sooner
> than usuall, since quite a lot of things have accumulated in May, e.g.
> there is a SUSE Labs conference right in the middle of the month.

> I would like to start with reviewe of patches that should go in now,
> freeze the git somewhere at the end of the first week of May and aim for
> a release somewhere in the middle of the month. Does that sound Ok to
> everyone?

> Either way if you have patches that should land in the upcomming
> release, please point them out now, so that we have a chance to review
> them.

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

Re: [LTP] LTP release preparations

[Petr Vorel]

> Hi!
> > > > * nfslock01.sh: Don't test on NFS v3 on TCP
> > > > https://patchwork.ozlabs.org/project/ltp/patch/20230502075921.3614794-1-pvorel@suse.cz/
> > > > => IMHO should go in to increase NFS tests stability

> > > The discussion around it sounds like this is a kernel problem after all.

> > I didn't get if we want to keep this *not* merged.

> That goes against "do not work around real bugs in tests", if possible I
> wouldn't apply any workarounds even if there is no upstream fix yet,
> maybe just a message that this is a known bug.

Fair enough, I rejected my patch. If no fix come out of the suggestion, I'd be
for adding a TINFO message, but let's wait.

> > > > * NFS: test on all filesystems
> > > > https://patchwork.ozlabs.org/project/ltp/list/?series=352840&state=*

> > > This is rather big change, is this important enough to get it in just
> > > before the git freeze?

> > There is v5 which tests only btrfs, ext4 and xfs. That should be safe to merge.
> > https://patchwork.ozlabs.org/project/ltp/list/?series=353495

> I will have a look.

Thanks.

Kind regards,
Petr

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

Re: [LTP] LTP release preparations

[Cyril Hrubis]

Hi!
> > > * nfslock01.sh: Don't test on NFS v3 on TCP
> > > https://patchwork.ozlabs.org/project/ltp/patch/20230502075921.3614794-1-pvorel@suse.cz/
> > > => IMHO should go in to increase NFS tests stability
> 
> > The discussion around it sounds like this is a kernel problem after all.
> 
> I didn't get if we want to keep this *not* merged.

That goes against "do not work around real bugs in tests", if possible I
wouldn't apply any workarounds even if there is no upstream fix yet,
maybe just a message that this is a known bug.

> > > * NFS: test on all filesystems
> > > https://patchwork.ozlabs.org/project/ltp/list/?series=352840&state=*
> 
> > This is rather big change, is this important enough to get it in just
> > before the git freeze?
> 
> There is v5 which tests only btrfs, ext4 and xfs. That should be safe to merge.
> https://patchwork.ozlabs.org/project/ltp/list/?series=353495

I will have a look.

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] LTP release preparations

[Petr Vorel]

Hi all,

> Hi!
> > * IMHO Martin's KVM patchset should be merged
> > https://patchwork.ozlabs.org/project/ltp/list/?series=351921&state=*

> Feel free to merge with my ack as long as it passes basic testsing.

> > * nfslock01.sh: Don't test on NFS v3 on TCP
> > https://patchwork.ozlabs.org/project/ltp/patch/20230502075921.3614794-1-pvorel@suse.cz/
> > => IMHO should go in to increase NFS tests stability

> The discussion around it sounds like this is a kernel problem after all.

I didn't get if we want to keep this *not* merged.

> > * NFS: test on all filesystems
> > https://patchwork.ozlabs.org/project/ltp/list/?series=352840&state=*

> This is rather big change, is this important enough to get it in just
> before the git freeze?

There is v5 which tests only btrfs, ext4 and xfs. That should be safe to merge.
https://patchwork.ozlabs.org/project/ltp/list/?series=353495

Kind regards,
Petr

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

Re: [LTP] LTP release preparations

[Petr Vorel]

> > Hi!
> > > * nfs08.sh: Skip on vfat
> > > https://patchwork.ozlabs.org/project/ltp/patch/20230502151348.3677809-1-pvorel@suse.cz/

> > This is workaround for bugs found by the "run nfs on all fs" patch,
> > right?

> Well, this is the problem which was found by this patchset. If you use TMPDIR
> with vfat or exfat (unlikely, I know) on current master, it will fail.
> I tested it on both loop device (demonstrated below) and on separate disc in VM.

> dd if=/dev/zero of=/tmp/dev bs=1M count=500
> losetup /dev/loop0 /tmp/dev
> mkfs.exfat /dev/loop0
> mkdir -p /export
> mount /dev/loop0 /export
> df -hT /export/
> Filesystem     Type  Size  Used Avail Use% Mounted on
> /dev/loop0     vfat  500M     0  500M   0% /export

> PATH="/opt/ltp/testcases/bin:$PATH" TMPDIR=/export nfs08.sh -v 4 -t tcp
> ...
> nfs08 1 TINFO: timeout per run is 0h 5m 0s
> nfs08 1 TINFO: mount.nfs: (linux nfs-utils 2.6.3)
> nfs08 1 TINFO: setup NFSv4, socket type tcp
> nfs08 1 TINFO: Mounting NFS: mount -v -t nfs -o proto=tcp,vers=4 10.0.0.2:/export/LTP_nfs08.R9JOL8zozk/4/tcp /export/LTP_nfs08.R9JOL8zozk/4/0
> nfs08 1 TINFO: testing NFS cache invalidation for directories
> 1
> nfs08 1 TPASS: ls | grep 1 passed as expected
> nfs08 1 TFAIL: ls | grep 2 failed unexpectedly

> Actually, nfs08.sh not working on vfat and exfat
> => therefore nfs_lib.sh should be without TST_SKIP_FILESYSTEMS (currently all tests whitelists exfat)
> and nfs08.sh should have: TST_SKIP_FILESYSTEMS="exfat,vfat"

> umount /export
> umount: /export: target is busy.

> fuser -vm /dev/loop0
>                      USER        PID ACCESS COMMAND
> /dev/loop0:          root     kernel mount /export
>                      root     kernel knfsd /export

> => Forced me to umount with -l or reboot, regardless used filesystem on
> /dev/loop0.  This is fixed in this patchset which uses TST_ALL_FILESYSTEMS,
> but I'd prefer to merge it instead of fixing master.

> This is reproducible even if I just add new device (i.e. not a loop device) to VM.

> > I suppose that it may be better not to enable nfs on all filesystems for
> > this release so that we have time to figure out what is wrong before
> > next release.

> > I really do not like applying "temporary" workarounds for real bugs in
> > the LTP codebase. There is always danger of "temporary" being forgotten
> > and we end up masking the real bug for eternity.

> We're masking the problems, because by default we test on what's on /tmp
> (often tmpfs, which is unlikely to be used for NFS or ext4 or btrfs).

> I need to test more old distros, I suspect that nfs-utils 1.3.3 has problems
> with vfat, exfat, tmpfs and fuse, which is in Debian 11 (bullseye).

> => Maybe, as a start we could decide to run nfs_lib.sh only on modern linux
> filesystems: i.e. btrfs, ext4, xfs
> We could have:
> TST_SKIP_FILESYSTEMS="btrfs,exfat,ext2,ext3,fuse,ntfs,vfat,tmpfs"

I meant here
TST_SKIP_FILESYSTEMS="exfat,ext2,ext3,fuse,ntfs,vfat,tmpfs"
(i.e. to run on btrfs, ext4, xfs only)

Kind regards,
Petr

> That would shorten the runtime and have more test coverage.
> WDYT? I'm about to send v5 and run tests in the loop. Shell I include this
> change?

> Kind regards,
> Petr

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

Re: [LTP] LTP release preparations

[Petr Vorel]

> Hi!
> > * nfs08.sh: Skip on vfat
> > https://patchwork.ozlabs.org/project/ltp/patch/20230502151348.3677809-1-pvorel@suse.cz/

> This is workaround for bugs found by the "run nfs on all fs" patch,
> right?

Well, this is the problem which was found by this patchset. If you use TMPDIR
with vfat or exfat (unlikely, I know) on current master, it will fail.
I tested it on both loop device (demonstrated below) and on separate disc in VM.

dd if=/dev/zero of=/tmp/dev bs=1M count=500
losetup /dev/loop0 /tmp/dev
mkfs.exfat /dev/loop0
mkdir -p /export
mount /dev/loop0 /export
df -hT /export/
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/loop0     vfat  500M     0  500M   0% /export

PATH="/opt/ltp/testcases/bin:$PATH" TMPDIR=/export nfs08.sh -v 4 -t tcp
...
nfs08 1 TINFO: timeout per run is 0h 5m 0s
nfs08 1 TINFO: mount.nfs: (linux nfs-utils 2.6.3)
nfs08 1 TINFO: setup NFSv4, socket type tcp
nfs08 1 TINFO: Mounting NFS: mount -v -t nfs -o proto=tcp,vers=4 10.0.0.2:/export/LTP_nfs08.R9JOL8zozk/4/tcp /export/LTP_nfs08.R9JOL8zozk/4/0
nfs08 1 TINFO: testing NFS cache invalidation for directories
1
nfs08 1 TPASS: ls | grep 1 passed as expected
nfs08 1 TFAIL: ls | grep 2 failed unexpectedly

Actually, nfs08.sh not working on vfat and exfat
=> therefore nfs_lib.sh should be without TST_SKIP_FILESYSTEMS (currently all tests whitelists exfat)
and nfs08.sh should have: TST_SKIP_FILESYSTEMS="exfat,vfat"

umount /export
umount: /export: target is busy.

fuser -vm /dev/loop0
                     USER        PID ACCESS COMMAND
/dev/loop0:          root     kernel mount /export
                     root     kernel knfsd /export

=> Forced me to umount with -l or reboot, regardless used filesystem on
/dev/loop0.  This is fixed in this patchset which uses TST_ALL_FILESYSTEMS,
but I'd prefer to merge it instead of fixing master.

This is reproducible even if I just add new device (i.e. not a loop device) to VM.

> I suppose that it may be better not to enable nfs on all filesystems for
> this release so that we have time to figure out what is wrong before
> next release.

> I really do not like applying "temporary" workarounds for real bugs in
> the LTP codebase. There is always danger of "temporary" being forgotten
> and we end up masking the real bug for eternity.

We're masking the problems, because by default we test on what's on /tmp
(often tmpfs, which is unlikely to be used for NFS or ext4 or btrfs).

I need to test more old distros, I suspect that nfs-utils 1.3.3 has problems
with vfat, exfat, tmpfs and fuse, which is in Debian 11 (bullseye).

=> Maybe, as a start we could decide to run nfs_lib.sh only on modern linux
filesystems: i.e. btrfs, ext4, xfs
We could have:
TST_SKIP_FILESYSTEMS="btrfs,exfat,ext2,ext3,fuse,ntfs,vfat,tmpfs"
That would shorten the runtime and have more test coverage.
WDYT? I'm about to send v5 and run tests in the loop. Shell I include this
change?

Kind regards,
Petr

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

Re: [LTP] LTP release preparations

[Petr Vorel]

Hi Cyril, all,

> Hi!
> > * IMHO Martin's KVM patchset should be merged
> > https://patchwork.ozlabs.org/project/ltp/list/?series=351921&state=*

> Feel free to merge with my ack as long as it passes basic testsing.

I merged the first four patches, but the final patch (the test itself) has
warnings. I hope they are trivial enough to be fixed so that we can merge it.

https://lore.kernel.org/ltp/20230503124240.GA3738345@pevik/

> > * nfslock01.sh: Don't test on NFS v3 on TCP
> > https://patchwork.ozlabs.org/project/ltp/patch/20230502075921.3614794-1-pvorel@suse.cz/
> > => IMHO should go in to increase NFS tests stability

> The discussion around it sounds like this is a kernel problem after all.

Yes (kernel and rpcbind). I'd be for merging it, at least until the fix is
released and we can give hints for update. Will you please post your ack to the
patch?

> > * NFS: test on all filesystems
> > https://patchwork.ozlabs.org/project/ltp/list/?series=352840&state=*

> This is rather big change, is this important enough to get it in just
> before the git freeze?

Neil Brown asked me to cover more underlaying filesystems in NFS testing.
I'm about to send new version, which increases timeouts a bit.
I did test it quite a lot (and will do some more tests today) and believe I'd be
able to fix potential problems before release. I started to work on
TST_ALL_FILESYSTEMS for shell API a year ago, it got merged in September.
That's quite long time for quite simple change, that's why I'm a bit impatient
to postpone it yet for another release.

Kind regards,
Petr

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

Re: [LTP] LTP release preparations

[Cyril Hrubis]

Hi!
> * nfs08.sh: Skip on vfat
> https://patchwork.ozlabs.org/project/ltp/patch/20230502151348.3677809-1-pvorel@suse.cz/

This is workaround for bugs found by the "run nfs on all fs" patch,
right?

I suppose that it may be better not to enable nfs on all filesystems for
this release so that we have time to figure out what is wrong before
next release.

I really do not like applying "temporary" workarounds for real bugs in
the LTP codebase. There is always danger of "temporary" being forgotten
and we end up masking the real bug for eternity.

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] LTP release preparations

[Cyril Hrubis]

Hi!
> * IMHO Martin's KVM patchset should be merged
> https://patchwork.ozlabs.org/project/ltp/list/?series=351921&state=*

Feel free to merge with my ack as long as it passes basic testsing.

> * nfslock01.sh: Don't test on NFS v3 on TCP
> https://patchwork.ozlabs.org/project/ltp/patch/20230502075921.3614794-1-pvorel@suse.cz/
> => IMHO should go in to increase NFS tests stability

The discussion around it sounds like this is a kernel problem after all.

> * NFS: test on all filesystems
> https://patchwork.ozlabs.org/project/ltp/list/?series=352840&state=*

This is rather big change, is this important enough to get it in just
before the git freeze?

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] LTP release preparations

[Petr Vorel]

Hi all,

Also this one should be merged:

* nfs08.sh: Skip on vfat
https://patchwork.ozlabs.org/project/ltp/patch/20230502151348.3677809-1-pvorel@suse.cz/

> * IMHO Martin's KVM patchset should be merged
> https://patchwork.ozlabs.org/project/ltp/list/?series=351921&state=*

> * nfslock01.sh: Don't test on NFS v3 on TCP
> https://patchwork.ozlabs.org/project/ltp/patch/20230502075921.3614794-1-pvorel@suse.cz/
> => IMHO should go in to increase NFS tests stability

> * NFS: test on all filesystems
> https://patchwork.ozlabs.org/project/ltp/list/?series=352840&state=*

> Kind regards,
> Petr

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

Re: [LTP] LTP release preparations

[Petr Vorel]

Hi all,

* IMHO Martin's KVM patchset should be merged
https://patchwork.ozlabs.org/project/ltp/list/?series=351921&state=*

* nfslock01.sh: Don't test on NFS v3 on TCP
https://patchwork.ozlabs.org/project/ltp/patch/20230502075921.3614794-1-pvorel@suse.cz/
=> IMHO should go in to increase NFS tests stability

* NFS: test on all filesystems
https://patchwork.ozlabs.org/project/ltp/list/?series=352840&state=*

Kind regards,
Petr

> Hi!
> I would like to start with LTP pre-release preparations a bit sooner
> than usuall, since quite a lot of things have accumulated in May, e.g.
> there is a SUSE Labs conference right in the middle of the month.

> I would like to start with reviewe of patches that should go in now,
> freeze the git somewhere at the end of the first week of May and aim for
> a release somewhere in the middle of the month. Does that sound Ok to
> everyone?

> Either way if you have patches that should land in the upcomming
> release, please point them out now, so that we have a chance to review
> them.

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

Re: [LTP] LTP release preparations

[Cyril Hrubis]

Hi!
> I prefer to include my STATX_DIO_ALIGN and mlock cleanup patchset before 
> release.

I merged mlock04. I'm unsure about the mlock03 removal, it seems to be a
regression test after all.

As for STAT_DIO_ALIGN I suppose that we need v5, right?

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] LTP release preparations

[Yang Xu (Fujitsu)]

Hi Cyril

> Hi!
> I would like to start with LTP pre-release preparations a bit sooner
> than usuall, since quite a lot of things have accumulated in May, e.g.
> there is a SUSE Labs conference right in the middle of the month.
> 
> I would like to start with reviewe of patches that should go in now,
> freeze the git somewhere at the end of the first week of May and aim for
> a release somewhere in the middle of the month. Does that sound Ok to
> everyone?
> 
> Either way if you have patches that should land in the upcomming
> release, please point them out now, so that we have a chance to review
> them.

I prefer to include my STATX_DIO_ALIGN and mlock cleanup patchset before 
release.

Bes Regards
Yang Xu
> 

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

Re: [LTP] LTP release preparations

[Andrea Cervesato via ltp]

Hi,

there's still one more patch to apply if we want to remove 
ltp_clone_quick deprecated function. That's "[v2] Remove ltp_clone_quick 
usage from pidns suite". Then we can safely remove libclone library 
which is not used anymore.
There's also one patch which can be useful in the next release and it's 
"[PATCH v2] Support return value in TST_* macros", which add return code 
to some of the most used TST_* macros.

Regards,
Andrea Cervesato

On 4/26/23 11:17, Cyril Hrubis wrote:
> Hi!
> I would like to start with LTP pre-release preparations a bit sooner
> than usuall, since quite a lot of things have accumulated in May, e.g.
> there is a SUSE Labs conference right in the middle of the month.
>
> I would like to start with reviewe of patches that should go in now,
> freeze the git somewhere at the end of the first week of May and aim for
> a release somewhere in the middle of the month. Does that sound Ok to
> everyone?
>
> Either way if you have patches that should land in the upcomming
> release, please point them out now, so that we have a chance to review
> them.
>


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

Re: [LTP] LTP release preparations

[Li Wang]

On Wed, Apr 26, 2023 at 6:01 PM Li Wang <liwang@redhat.com> wrote:

>
>
> On Wed, Apr 26, 2023 at 5:19 PM Cyril Hrubis <chrubis@suse.cz> wrote:
>
>> Hi!
>> I would like to start with LTP pre-release preparations a bit sooner
>> than usuall, since quite a lot of things have accumulated in May, e.g.
>> there is a SUSE Labs conference right in the middle of the month.
>>
>> I would like to start with reviewe of patches that should go in now,
>> freeze the git somewhere at the end of the first week of May and aim for
>> a release somewhere in the middle of the month. Does that sound Ok to
>> everyone?
>>
>
> Basically agree, but it'd be better if we extend one more week in May.
> Since the first week is China's public holiday, I don't wanna miss the
> release this time again.
>

Ah, your plan should be well, I just check my calendar, the holiday is
only three days in May (1-3). That wouldn't impact a lot, sorry.



>
>
>
>>
>> Either way if you have patches that should land in the upcomming
>> release, please point them out now, so that we have a chance to review
>> them.
>>
>
> I'll be working on the hugemmap24 failure you pointed out before,
> to send an effective fixing patch.
> https://lists.linux.it/pipermail/ltp/2023-March/033117.html
>
> Also, I'd vote for the cgroup_core03.c test, which basically gets passed
> on my review and testing.
> I will additionally start a separate patch on new improvements based on
> Wei's patchset to let LTP Cgroup test avoid V1nV2 mixing test.
> https://lists.linux.it/pipermail/ltp/2023-April/033604.html
> https://lists.linux.it/pipermail/ltp/2023-April/033605.html
>
> More widely LTP LTP pre-release will be deployed base on RHEL products as
> well.
>

===> LTP pre-release test.

sorry for the typos.


-- 
Regards,
Li Wang

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

Re: [LTP] LTP release preparations

[Teo Couprie Diaz]

Hi Cyril,

On 26/04/2023 10:17, Cyril Hrubis wrote:
> Hi!
> I would like to start with LTP pre-release preparations a bit sooner
> than usuall, since quite a lot of things have accumulated in May, e.g.
> there is a SUSE Labs conference right in the middle of the month.
>
> I would like to start with reviewe of patches that should go in now,
> freeze the git somewhere at the end of the first week of May and aim for
> a release somewhere in the middle of the month. Does that sound Ok to
> everyone?
>
> Either way if you have patches that should land in the upcomming
> release, please point them out now, so that we have a chance to review
> them.
>
It's not critical in the slightest, but we would appreciate if my
setpgid series[0] could land for the release.

Happy to allocate a bit more time for quickly turning around
additional versions if needed. It's a rather small series anyway.

Thanks very much in advance for the release !
Best regards,
Téo

[0]: https://lists.linux.it/pipermail/ltp/2023-April/033574.html


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

Re: [LTP] LTP release preparations

[Li Wang]

On Wed, Apr 26, 2023 at 5:19 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> I would like to start with LTP pre-release preparations a bit sooner
> than usuall, since quite a lot of things have accumulated in May, e.g.
> there is a SUSE Labs conference right in the middle of the month.
>
> I would like to start with reviewe of patches that should go in now,
> freeze the git somewhere at the end of the first week of May and aim for
> a release somewhere in the middle of the month. Does that sound Ok to
> everyone?
>

Basically agree, but it'd be better if we extend one more week in May.
Since the first week is China's public holiday, I don't wanna miss the
release this time again.



>
> Either way if you have patches that should land in the upcomming
> release, please point them out now, so that we have a chance to review
> them.
>

I'll be working on the hugemmap24 failure you pointed out before,
to send an effective fixing patch.
https://lists.linux.it/pipermail/ltp/2023-March/033117.html

Also, I'd vote for the cgroup_core03.c test, which basically gets passed
on my review and testing.
I will additionally start a separate patch on new improvements based on
Wei's patchset to let LTP Cgroup test avoid V1nV2 mixing test.
https://lists.linux.it/pipermail/ltp/2023-April/033604.html
https://lists.linux.it/pipermail/ltp/2023-April/033605.html

More widely LTP LTP pre-release will be deployed base on RHEL products as
well.

-- 
Regards,
Li Wang

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

[LTP] LTP release preparations

[Cyril Hrubis]

Hi!
I would like to start with LTP pre-release preparations a bit sooner
than usuall, since quite a lot of things have accumulated in May, e.g.
there is a SUSE Labs conference right in the middle of the month.

I would like to start with reviewe of patches that should go in now,
freeze the git somewhere at the end of the first week of May and aim for
a release somewhere in the middle of the month. Does that sound Ok to
everyone?

Either way if you have patches that should land in the upcomming
release, please point them out now, so that we have a chance to review
them.

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] LTP Release preparations

[Cyril Hrubis]

Hi!
This is a last call, if there is something that should be part of the
upcomming release let me know ASAP. The plan is to freeze the git for a
week at the end of the day today.

Also if you haven't started yet with a pre-release testing, please do so
now.

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] LTP Release preparations

[Cyril Hrubis]

Hi!
> > Also if there are patches that you think should be merged before the
> > release let me know ASAP so we can have a look soon enough.
> 
> Maybe could consider the concept of the test max_runtime series?
> https://patchwork.ozlabs.org/project/ltp/list/?series=268799

I want to make some changes there, as Ritchie pointed out some
interesting ideas about how runtime and timeout should coexist. I will
make sure to redo the patchset after the release has been finalized.

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] LTP Release preparations

[Li Wang]

[-- Attachment #1.1: Type: text/plain, Size: 881 bytes --]

On Wed, Jan 5, 2022 at 7:35 PM Cyril Hrubis <chrubis@suse.cz> wrote:
>
> Hi!
> As usuall it's time to start preparing for the next release.
>
> Given the amount patches waiting for the review I guess that we should
> try to get reviewed and merged as much as possible in the next few days.
> I would go for git freeze at 14. 1. as that would give us a week for
> pre-release testing and the release would be, as usuall, finalized
> around the 21. 1. Feel free to reply if you think that the schedulle
> should be different.

Sounds good, I'd kick start pre-release testing on 17.1 from my side.

>
> Also if there are patches that you think should be merged before the
> release let me know ASAP so we can have a look soon enough.

Maybe could consider the concept of the test max_runtime series?
https://patchwork.ozlabs.org/project/ltp/list/?series=268799


-- 
Regards,
Li Wang

[-- Attachment #1.2: Type: text/html, Size: 1180 bytes --]

[-- Attachment #2: Type: text/plain, Size: 60 bytes --]


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

Re: [LTP] LTP Release preparations

[xuyang2018.jy]

Hi Cyril
> Hi!
> As usuall it's time to start preparing for the next release.
>
> Given the amount patches waiting for the review I guess that we should
> try to get reviewed and merged as much as possible in the next few days.
> I would go for git freeze at 14. 1. as that would give us a week for
> pre-release testing and the release would be, as usuall, finalized
> around the 21. 1. Feel free to reply if you think that the schedulle
> should be different.
>
> Also if there are patches that you think should be merged before the
> release let me know ASAP so we can have a look soon enough.
I think the following two patchsets can be merged before this release.

1) remaining quotactl_fd patchset
2) shell kconfig API patchset

[1]https://patchwork.ozlabs.org/project/ltp/list/?series=276474
[2]https://patchwork.ozlabs.org/project/ltp/list/?series=279588

Best Regards
Yang Xu
>

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

Re: [LTP] LTP Release preparations

[Petr Vorel]

> Hi!
> > > As usuall it's time to start preparing for the next release.

> > > Given the amount patches waiting for the review I guess that we should
> > > try to get reviewed and merged as much as possible in the next few days.
> > > I would go for git freeze at 14. 1. as that would give us a week for
> > > pre-release testing and the release would be, as usuall, finalized
> > > around the 21. 1. Feel free to reply if you think that the schedulle
> > > should be different.

> > > Also if there are patches that you think should be merged before the
> > > release let me know ASAP so we can have a look soon enough.


> > Maybe that's a good time to say I did not understand the resolution on the
> > discussion [1] about timing of merging tests for new (i.e. v5.16) features.
Good point, I hoped we'd release LTP after v5.16 to get fanotify and IMA [1]
testes merged before release anyway.

> I guess that's because we haven't ended up with one as the discussion
> faded away before christmas break. I guess I will read that again and
> try to do something about it.
+1 thanks Cyril!


Kind regards,
Petr

[1] https://patchwork.ozlabs.org/project/ltp/list/?series=265664

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

Re: [LTP] LTP Release preparations

[Cyril Hrubis]

Hi!
> > As usuall it's time to start preparing for the next release.
> >
> > Given the amount patches waiting for the review I guess that we should
> > try to get reviewed and merged as much as possible in the next few days.
> > I would go for git freeze at 14. 1. as that would give us a week for
> > pre-release testing and the release would be, as usuall, finalized
> > around the 21. 1. Feel free to reply if you think that the schedulle
> > should be different.
> >
> > Also if there are patches that you think should be merged before the
> > release let me know ASAP so we can have a look soon enough.
> >
> 
> Maybe that's a good time to say I did not understand the resolution on the
> discussion [1] about timing of merging tests for new (i.e. v5.16) features.

I guess that's because we haven't ended up with one as the discussion
faded away before christmas break. I guess I will read that again and
try to do something about it.

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] LTP Release preparations

[Amir Goldstein]

On Wed, Jan 5, 2022 at 1:35 PM Cyril Hrubis <chrubis@suse.cz> wrote:
>
> Hi!
> As usuall it's time to start preparing for the next release.
>
> Given the amount patches waiting for the review I guess that we should
> try to get reviewed and merged as much as possible in the next few days.
> I would go for git freeze at 14. 1. as that would give us a week for
> pre-release testing and the release would be, as usuall, finalized
> around the 21. 1. Feel free to reply if you think that the schedulle
> should be different.
>
> Also if there are patches that you think should be merged before the
> release let me know ASAP so we can have a look soon enough.
>

Maybe that's a good time to say I did not understand the resolution on the
discussion [1] about timing of merging tests for new (i.e. v5.16) features.

Specifically, I am referring to the FAN_FS_ERROR tests [2].

Thanks,
Amir.

[1] https://lore.kernel.org/ltp/Ybc5QJSZM3YIji70@yuki/
[2] https://lore.kernel.org/ltp/YcDGZ+eNcQ5fPsmN@pevik/

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

[LTP] LTP Release preparations

[Cyril Hrubis]

Hi!
As usuall it's time to start preparing for the next release.

Given the amount patches waiting for the review I guess that we should
try to get reviewed and merged as much as possible in the next few days.
I would go for git freeze at 14. 1. as that would give us a week for
pre-release testing and the release would be, as usuall, finalized
around the 21. 1. Feel free to reply if you think that the schedulle
should be different.

Also if there are patches that you think should be merged before the
release let me know ASAP so we can have a look soon enough.

-- 
Cyril Hrubis
chrubis@suse.cz

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

[LTP] LTP Release preparations

[Cyril Hrubis]

Hi!
> The pending issues for the release are the compilation fix from Jan and
> the perf_event_open02 fix I've send.

As nobody objected, or commented so far I'm going to commit this one
next week.

> Anything else to consider?

Li pinged the migrate_pages02 patch from Jan, anything else?

I would like to proceed with the release next week so if you have
anything that should be dealt with speak up please.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP Release preparations

[Petr Vorel]

Hi,

> Hi!
> > I would like to go for freezing the git at the end of the week and
> > start with a pre-release testing next week. Is that OK with everyone?

> I'm in the middle of pre-release tesing, so far it looks good.

> The pending issues for the release are the compilation fix from Jan and
> the perf_event_open02 fix I've send.

> Anything else to consider?
I'll have a look at Alexey's patch v3 "sctp_big_chunk: make INIT packet in the test"
+ I'm going to send small fix in net in a minute.


Kind regards,
Petr

[LTP] LTP Release preparations

[Alexey Kodanev]

On 05/03/2018 12:28 PM, Cyril Hrubis wrote:
> Hi!

Hi Cyril,

>> I would like to go for freezing the git at the end of the week and
>> start with a pre-release testing next week. Is that OK with everyone?
> 
> I'm in the middle of pre-release tesing, so far it looks good.
> 
> The pending issues for the release are the compilation fix from Jan and
> the perf_event_open02 fix I've send.
> 
> Anything else to consider?
> 

Any objections against patch v3 "sctp_big_chunk: make INIT packet in the test" [1]?
It should fix the test on the kernels 4.17-rc2+.

[1] http://lists.linux.it/pipermail/ltp/2018-April/007933.html

Thanks,
Alexey

[LTP] LTP Release preparations

[Cyril Hrubis]

Hi!
> I would like to go for freezing the git at the end of the week and
> start with a pre-release testing next week. Is that OK with everyone?

I'm in the middle of pre-release tesing, so far it looks good.

The pending issues for the release are the compilation fix from Jan and
the perf_event_open02 fix I've send.

Anything else to consider?

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP Release preparations

[Petr Vorel]

Hi Mimi, Cyril,

> Peter how is it with the IMA testsuite, should we merge the patchset and
> call it incremental improvement over the previous code?
Yes. There ale still some issues, current patches are improvement and I'm not aware about
any regression.
So I'm going to merge patches 1,3-10 on Friday afternoon. Is that ok for you or should I
merge it earlier.
The only patch I'm not going to merge is the second one ("security/ima: Change order of
tests") [1]

Mimi, any chance you to have a look into patches till Friday?


Kind regards,
Petr

[1] https://lists.linux.it/pipermail/ltp/2018-April/007783.html

[LTP] LTP Release preparations

[Cyril Hrubis]

Hi!
> That worked for me, though I missed only 2 defines:
> XFRMNLGRP_NONE
> XFRM_MSG_GETPOLICY
> 
> Are you missing three after you drop linux/xfrm.h?

I just grepped the file for XFRM_ and expect these macros to be defined
in the xfrm header, looking closer the NETLINK_XFRM is indeed defined in
the netlink header.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP Release preparations

[Jan Stancek]

----- Original Message -----
> Hi!
> > I started testing and so far ran into problem with building
> > cve-2017-16939.c
> > on RHEL7.2:
> > 
> > gcc -g -O2 -g -O2 -fno-strict-aliasing -pipe -Wall -W
> > -Wold-style-definition -D_GNU_SOURCE -D_FORTIFY_SOURCE=2 -I../../include
> > -I../../include -I../../include/old/   -L../../lib  cve-2017-16939.c
> > -lltp -o cve-2017-16939
> > In file included from /usr/include/linux/xfrm.h:4:0,
> >                  from cve-2017-16939.c:33:
> > /usr/include/linux/in6.h:30:8: error: redefinition of ???struct in6_addr???
> >  struct in6_addr {
> >         ^
> > In file included from cve-2017-16939.c:31:0:
> > /usr/include/netinet/in.h:197:8: note: originally defined here
> >  struct in6_addr
> >         ^
> > In file included from /usr/include/linux/xfrm.h:4:0,
> >                  from cve-2017-16939.c:33:
> > /usr/include/linux/in6.h:41:8: error: redefinition of ???struct
> > sockaddr_in6???
> >  struct sockaddr_in6 {
> >         ^
> > In file included from cve-2017-16939.c:29:0:
> > /usr/include/sys/socket.h:91:17: note: originally defined here
> >  typedef union { __SOCKADDR_ALLTYPES
> >                  ^
> > In file included from /usr/include/linux/xfrm.h:4:0,
> >                  from cve-2017-16939.c:33:
> > /usr/include/linux/in6.h:49:8: error: redefinition of ???struct
> > ipv6_mreq???
> >  struct ipv6_mreq {
> >         ^
> > In file included from cve-2017-16939.c:31:0:
> > /usr/include/netinet/in.h:274:8: note: originally defined here
> >  struct ipv6_mreq
> >         ^
> > make: *** [cve-2017-16939] Error 1
> 
> This seems to be very strange problem with mixing linux and libc
> headers. I've tried to remove the netinet/in.h header from the test and
> build it on different distros, buy that seemed to actually cause more
> problems than when it's included.
> 
> And actually I haven't been able to reproduce the build problem failure
> the original code, but I build-test only small mumber of RHEL and Fedora
> builds here.
> 
> I guess that the easiest solution here may be to declare the three XFRM
> macros somewhere in lapi header and include it here instead fo the
> linux/xfrm.h.

That worked for me, though I missed only 2 defines:
XFRMNLGRP_NONE
XFRM_MSG_GETPOLICY

Are you missing three after you drop linux/xfrm.h?

> 
> --
> Cyril Hrubis
> chrubis@suse.cz
> 

[LTP] LTP Release preparations

[Cyril Hrubis]

Hi!
> I started testing and so far ran into problem with building cve-2017-16939.c
> on RHEL7.2:
> 
> gcc -g -O2 -g -O2 -fno-strict-aliasing -pipe -Wall -W -Wold-style-definition -D_GNU_SOURCE -D_FORTIFY_SOURCE=2 -I../../include -I../../include -I../../include/old/   -L../../lib  cve-2017-16939.c   -lltp -o cve-2017-16939
> In file included from /usr/include/linux/xfrm.h:4:0,
>                  from cve-2017-16939.c:33:
> /usr/include/linux/in6.h:30:8: error: redefinition of ???struct in6_addr???
>  struct in6_addr {
>         ^
> In file included from cve-2017-16939.c:31:0:
> /usr/include/netinet/in.h:197:8: note: originally defined here
>  struct in6_addr
>         ^
> In file included from /usr/include/linux/xfrm.h:4:0,
>                  from cve-2017-16939.c:33:
> /usr/include/linux/in6.h:41:8: error: redefinition of ???struct sockaddr_in6???
>  struct sockaddr_in6 {
>         ^
> In file included from cve-2017-16939.c:29:0:
> /usr/include/sys/socket.h:91:17: note: originally defined here
>  typedef union { __SOCKADDR_ALLTYPES
>                  ^
> In file included from /usr/include/linux/xfrm.h:4:0,
>                  from cve-2017-16939.c:33:
> /usr/include/linux/in6.h:49:8: error: redefinition of ???struct ipv6_mreq???
>  struct ipv6_mreq {
>         ^
> In file included from cve-2017-16939.c:31:0:
> /usr/include/netinet/in.h:274:8: note: originally defined here
>  struct ipv6_mreq
>         ^
> make: *** [cve-2017-16939] Error 1

This seems to be very strange problem with mixing linux and libc
headers. I've tried to remove the netinet/in.h header from the test and
build it on different distros, buy that seemed to actually cause more
problems than when it's included.

And actually I haven't been able to reproduce the build problem failure
the original code, but I build-test only small mumber of RHEL and Fedora
builds here.

I guess that the easiest solution here may be to declare the three XFRM
macros somewhere in lapi header and include it here instead fo the
linux/xfrm.h.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP Release preparations

[Jan Stancek]

----- Original Message -----
> Hi!
> > I suppose that we should get in the fix for the read_all testcase along
> > with the exponential back off.
> > 
> > Also I would like to get in the needs_rofs patchset.
> > 
> > There is also patch for converting our python code to be python3
> > compatible that is worth looking into.
> 
> That has been done.
> 
> I've also send a patch for long-standing problem with perf_event_open02
> testcase that would be a good candidate for the release.
> 
> Peter how is it with the IMA testsuite, should we merge the patchset and
> call it incremental improvement over the previous code?
> 
> Anything else to be merged?
> 
> I would like to go for freezing the git at the end of the week and
> start with a pre-release testing next week. Is that OK with everyone?

I started testing and so far ran into problem with building cve-2017-16939.c
on RHEL7.2:

gcc -g -O2 -g -O2 -fno-strict-aliasing -pipe -Wall -W -Wold-style-definition -D_GNU_SOURCE -D_FORTIFY_SOURCE=2 -I../../include -I../../include -I../../include/old/   -L../../lib  cve-2017-16939.c   -lltp -o cve-2017-16939
In file included from /usr/include/linux/xfrm.h:4:0,
                 from cve-2017-16939.c:33:
/usr/include/linux/in6.h:30:8: error: redefinition of ‘struct in6_addr’
 struct in6_addr {
        ^
In file included from cve-2017-16939.c:31:0:
/usr/include/netinet/in.h:197:8: note: originally defined here
 struct in6_addr
        ^
In file included from /usr/include/linux/xfrm.h:4:0,
                 from cve-2017-16939.c:33:
/usr/include/linux/in6.h:41:8: error: redefinition of ‘struct sockaddr_in6’
 struct sockaddr_in6 {
        ^
In file included from cve-2017-16939.c:29:0:
/usr/include/sys/socket.h:91:17: note: originally defined here
 typedef union { __SOCKADDR_ALLTYPES
                 ^
In file included from /usr/include/linux/xfrm.h:4:0,
                 from cve-2017-16939.c:33:
/usr/include/linux/in6.h:49:8: error: redefinition of ‘struct ipv6_mreq’
 struct ipv6_mreq {
        ^
In file included from cve-2017-16939.c:31:0:
/usr/include/netinet/in.h:274:8: note: originally defined here
 struct ipv6_mreq
        ^
make: *** [cve-2017-16939] Error 1


> 
> --
> Cyril Hrubis
> chrubis@suse.cz
> 
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp
> 

[LTP] LTP Release preparations

[Cyril Hrubis]

Hi!
> I suppose that we should get in the fix for the read_all testcase along
> with the exponential back off.
> 
> Also I would like to get in the needs_rofs patchset.
> 
> There is also patch for converting our python code to be python3
> compatible that is worth looking into.

That has been done.

I've also send a patch for long-standing problem with perf_event_open02
testcase that would be a good candidate for the release.

Peter how is it with the IMA testsuite, should we merge the patchset and
call it incremental improvement over the previous code?

Anything else to be merged?

I would like to go for freezing the git at the end of the week and
start with a pre-release testing next week. Is that OK with everyone?

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP Release preparations

[Petr Vorel]

Hi,

> Hi!
> > It's about the time we should slowly prepare for the next release, as
> > usuall let's start with a list of patches that should go in before we
> > enter the stabilization phase.

> > As for me I would like to get the two speedup patchsets in, one of them
> > only waits for ack from Jan, the second one would probably benefit from
> > some more review. I will try to merge everything that is good to go and
> > just waiting for a review ASAP.

> > Anything else that should really go in?

> Ping.
...

> Anything else?

I hope to get my IMA patches merged to the release.


Kind regards,
Petr

[LTP] LTP Release preparations

[Li Wang]

On Thu, Apr 19, 2018 at 10:17 PM, Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> > It's about the time we should slowly prepare for the next release, as
> > usuall let's start with a list of patches that should go in before we
> > enter the stabilization phase.
> >
> > As for me I would like to get the two speedup patchsets in, one of them
> > only waits for ack from Jan, the second one would probably benefit from
> > some more review. I will try to merge everything that is good to go and
> > just waiting for a review ASAP.
> >
> > Anything else that should really go in?
>
> Ping.
>
> I suppose that we should get in the fix for the read_all testcase along
> with the exponential back off.
>

​I'm hesitating if we should abandon the old patch[1] and re-rewrite a new
one
(which base on the new TST_RETRY_FUNC macro) to fix the problem.

​[1]​ http://lists.linux.it/pipermail/ltp/2018-April/007704.html

-----------------
something new like:

--- a/testcases/kernel/fs/read_all/read_all.c
+++ b/testcases/kernel/fs/read_all/read_all.c
@@ -265,23 +265,14 @@ static void spawn_workers(void)
 static void stop_workers(void)
 {
        const char stop_code[1] = { '\0' };
-       int i, stop_attempts;
+       int i;

        if (!workers)
                return;

        for (i = 0; i < worker_count; i++) {
-               stop_attempts = 0xffff;
-               if (workers[i].q) {
-               if (workers[i].q) {
-                       while (!queue_push(workers[i].q, stop_code)) {
-                               if (--stop_attempts < 0) {
-                                       tst_brk(TBROK,
-                                               "Worker %d is stalled",
-                                               workers[i].pid);
-                                       break;
-                               }
-                       }
-               }
+               if (workers[i].q)
+                       TST_RETRY_FUNC(queue_push(workers[i].q, stop_code),
1);
        }

        for (i = 0; i < worker_count; i++) {
@@ -292,33 +283,15 @@ static void stop_workers(void)
        }
 }

-static void sched_work(const char *path)
-{
-       static int cur;
-       int push_attempts = 0, pushed;
-
-       while (1) {
-               pushed = queue_push(workers[cur].q, path);
-
-               if (++cur >= worker_count)
-                       cur = 0;
-
-               if (pushed)
-                       break;
-
-               if (++push_attempts > worker_count) {
-                       usleep(100);
-                       push_attempts = 0;
-               }
-       }
-}
-
 static void rep_sched_work(const char *path, int rep)
 {
-       int i;
+       int i, j;

-       for (i = 0; i < rep; i++)
-               sched_work(path);
+       for (i = j = 0; i < rep; i++, j++) {
+               if (j >= 15)
+                       j = 0;
+               TST_RETRY_FUNC(queue_push(workers[j].q, path), 1);
+       }
 }



-- 
Li Wang
liwang@redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20180420/1ae8918e/attachment-0001.html>

[LTP] LTP Release preparations

[Cyril Hrubis]

Hi!
> It's about the time we should slowly prepare for the next release, as
> usuall let's start with a list of patches that should go in before we
> enter the stabilization phase.
> 
> As for me I would like to get the two speedup patchsets in, one of them
> only waits for ack from Jan, the second one would probably benefit from
> some more review. I will try to merge everything that is good to go and
> just waiting for a review ASAP.
> 
> Anything else that should really go in?

Ping.

I suppose that we should get in the fix for the read_all testcase along
with the exponential back off.

Also I would like to get in the needs_rofs patchset.

There is also patch for converting our python code to be python3
compatible that is worth looking into.

Anything else?

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP Release preparations

[Cyril Hrubis]

Hi!
It's about the time we should slowly prepare for the next release, as
usuall let's start with a list of patches that should go in before we
enter the stabilization phase.

As for me I would like to get the two speedup patchsets in, one of them
only waits for ack from Jan, the second one would probably benefit from
some more review. I will try to merge everything that is good to go and
just waiting for a review ASAP.

Anything else that should really go in?

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP release preparations

[Cyril Hrubis]

Hi!
So far I plan to look at the new kernel input testcases and cgroup_fj
fixes before the repository gets frozen before the release.

Is there anything else that should go in?

-- 
Cyril Hrubis
chrubis@suse.cz