[LTP] LTP Release

[LTP] LTP Release

[Cyril Hrubis]

Hi!
As usually we should start prepare for a release somewhere at the end of
the September.

I will try to review as much patches as possible next week, then I would
like to start the pre-release testing. So if there is something that
really should go in before the release let me know.

I would personally like to get the eBPF tests in, it would be nice if
anyone could ack the v5.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP Release

[Richard Palethorpe]

Hello,

Cyril Hrubis <chrubis@suse.cz> writes:

> Hi!
> As usually we should start prepare for a release somewhere at the end of
> the September.
>
> I will try to review as much patches as possible next week, then I would
> like to start the pre-release testing. So if there is something that
> really should go in before the release let me know.
>
> I would personally like to get the eBPF tests in, it would be nice if
> anyone could ack the v5.

I would also like bpf_prog02 and the capability API unless someone has
serious problems with these.

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


-- 
Thank you,
Richard.

[LTP] LTP Release

[Li Wang]

On Fri, Sep 6, 2019 at 9:07 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> As usually we should start prepare for a release somewhere at the end of
> the September.
>
> I will try to review as much patches as possible next week, then I would
> like to start the pre-release testing. So if there is something that
> really should go in before the release let me know.
>

The one to print errno number.
    [PATCH] tst_res: Print errno number in addition to error name


Some test failures:
==============

acct02 (s390x):
acct02.c:174: INFO: Verifying using 'struct acct_v3'
acct02.c:140: INFO: Number of accounting file entries tested: 2
acct02.c:145: FAIL: acct() wrote incorrect file contents!

timer_create01 (s390x, ppc64le, aarch64):
timer_create01.c:48: INFO: Testing notification type: SIGEV_THREAD_ID
timer_create01.c:93: PASS: Timer successfully created for CLOCK_REALTIME
timer_create01.c:93: PASS: Timer successfully created for CLOCK_MONOTONIC
timer_create01.c:93: PASS: Timer successfully created for
CLOCK_PROCESS_CPUTIME_ID
timer_create01.c:93: PASS: Timer successfully created for
CLOCK_THREAD_CPUTIME_ID
timer_create01.c:93: PASS: Timer successfully created for CLOCK_BOOTTIME
timer_create01.c:87: FAIL: Failed to create timer for CLOCK_BOOTTIME_ALARM:
???
timer_create01.c:87: FAIL: Failed to create timer for CLOCK_REALTIME_ALARM:
???
timer_create01.c:93: PASS: Timer successfully created for CLOCK_TAI

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20190909/8fb3bd75/attachment-0001.htm>

[LTP] LTP Release

[=?unknown-8bit?b?WWFuZy/lvpAg5p2o?=]

on 2019/09/06 21:07, Cyril Hrubis wrote:

> Hi!
> As usually we should start prepare for a release somewhere at the end of
> the September.
>
> I will try to review as much patches as possible next week, then I would
> like to start the pre-release testing. So if there is something that
> really should go in before the release let me know.

Hi Cyril

I think my patch[1][2] to fix statx04 and ueven03 should be merged before the release.
Also my patch[3] to fix cgroup case should be reviewed if you have free time.

[1]https://patchwork.ozlabs.org/patch/1149792
[2]https://patchwork.ozlabs.org/patch/1158763
[3]https://patchwork.ozlabs.org/patch/1113680

Thanks
Yang Xu

>
> I would personally like to get the eBPF tests in, it would be nice if
> anyone could ack the v5.
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20190910/5e36f5a6/attachment.htm>

[LTP] LTP Release

[Cyril Hrubis]

Hi!
> The one to print errno number.
>     [PATCH] tst_res: Print errno number in addition to error name

Pushed the patch as it was, I do not think that reordering the
statements was important enough.

> Some test failures:
> ==============
> 
> acct02 (s390x):
> acct02.c:174: INFO: Verifying using 'struct acct_v3'
> acct02.c:140: INFO: Number of accounting file entries tested: 2
> acct02.c:145: FAIL: acct() wrote incorrect file contents!

I can reproduce it here as well, no idea what is wrong there. I guess
that modifying the test to be more verbose, i.e. to print if we haven't
matched the pid or if the contents of the structure were wrong would be
a good start.

> timer_create01 (s390x, ppc64le, aarch64):
> timer_create01.c:48: INFO: Testing notification type: SIGEV_THREAD_ID
> timer_create01.c:93: PASS: Timer successfully created for CLOCK_REALTIME
> timer_create01.c:93: PASS: Timer successfully created for CLOCK_MONOTONIC
> timer_create01.c:93: PASS: Timer successfully created for
> CLOCK_PROCESS_CPUTIME_ID
> timer_create01.c:93: PASS: Timer successfully created for
> CLOCK_THREAD_CPUTIME_ID
> timer_create01.c:93: PASS: Timer successfully created for CLOCK_BOOTTIME
> timer_create01.c:87: FAIL: Failed to create timer for CLOCK_BOOTTIME_ALARM:
> ???
> timer_create01.c:87: FAIL: Failed to create timer for CLOCK_REALTIME_ALARM:
> ???
> timer_create01.c:93: PASS: Timer successfully created for CLOCK_TAI

I'm pretty sure that we concluded that this is a kernel bug since it
returns kernel internal errno.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP Release

[Cyril Hrubis]

Hi!
> [1]https://patchwork.ozlabs.org/patch/1149792

I'm okay with this applied but we have to make sure that these flags are
enabled for new enough kernels for defined set of filesystems, which is
what I replied to the patch.

> [2]https://patchwork.ozlabs.org/patch/1158763
> [3]https://patchwork.ozlabs.org/patch/1113680

I will have a look at these two ASAP.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP Release

[Petr Vorel]

Hi Cyril,

> Hi!
> As usually we should start prepare for a release somewhere at the end of
> the September.

> I will try to review as much patches as possible next week, then I would
> like to start the pre-release testing. So if there is something that
> really should go in before the release let me know.
I'd like to have shell timeout fixes + enhancements [1].
I hope I'll send route shell tests rewrite v5, tst_res return exit value [2] is a preparation
for it (if acceptable).

Kind regards,
Petr

[1] https://patchwork.ozlabs.org/project/ltp/list/?series=130562&state=*
[2] https://patchwork.ozlabs.org/patch/1161773/

[LTP] acct02 failure [was: Re: LTP Release]

[Petr Vorel]

Hi,

> > acct02 (s390x):
> > acct02.c:174: INFO: Verifying using 'struct acct_v3'
> > acct02.c:140: INFO: Number of accounting file entries tested: 2
> > acct02.c:145: FAIL: acct() wrote incorrect file contents!

> I can reproduce it here as well, no idea what is wrong there. I guess
> that modifying the test to be more verbose, i.e. to print if we haven't
> matched the pid or if the contents of the structure were wrong would be
> a good start.

I discovered failure on x86_64 on kernel 5.3.0-rc6-3.g8b30bf3-default (openSUSE)
and 5.2.9 (Debian), which or might not be related.

Kind regards,
Petr

[LTP] LTP Release

[Cyril Hrubis]

Hi!
I did a few testruns and so far it looks good.

I've send one patch for acct02, which is mostly cosmetic, that I would
like to get merged.

I would still consider merging the eBPF regression test, does anybody
have a strong opinion on this?

Apart from this preadv203 sometimes fails to trigger EAGAIN on virtual
machines, but I doubt we can fix this before the release, I will try to
do so later on.

The rest seems to be good, i.e. failures does not seem to be bugs in
tests.

What is the status from rest of you? Is there anything that should be
considered for the release? Is something failing unexpectedly?

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP Release

[Jan Stancek]

----- Original Message -----
> Hi!
> I did a few testruns and so far it looks good.
> 
> I've send one patch for acct02, which is mostly cosmetic, that I would
> like to get merged.
> 
> I would still consider merging the eBPF regression test, does anybody
> have a strong opinion on this?
> 
> Apart from this preadv203 sometimes fails to trigger EAGAIN on virtual
> machines, but I doubt we can fix this before the release, I will try to
> do so later on.
> 
> The rest seems to be good, i.e. failures does not seem to be bugs in
> tests.
> 
> What is the status from rest of you? Is there anything that should be
> considered for the release? Is something failing unexpectedly?

I'm thinking if we should patch BPF tests to increase max lock memory
to +1MB. On Fedora30 default limit is '64', and I found couple
systems which by default come very close to that limit right after boot.
So even one iteration of BPF tests will hit a failure.

# lscpu 
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
Address sizes:       40 bits physical, 48 bits virtual
CPU(s):              16
On-line CPU(s) list: 0-15
Thread(s) per core:  2
Core(s) per socket:  4
Socket(s):           2
NUMA node(s):        2
Vendor ID:           GenuineIntel
CPU family:          6
Model:               26
Model name:          Intel(R) Xeon(R) CPU           E5530  @ 2.40GHz
Stepping:            5
CPU MHz:             1596.091
CPU max MHz:         2395.0000
CPU min MHz:         1596.0000
BogoMIPS:            4788.26
Virtualization:      VT-x
L1d cache:           32K
L1i cache:           32K
L2 cache:            256K
L3 cache:            8192K
NUMA node0 CPU(s):   0,2,4,6,8,10,12,14
NUMA node1 CPU(s):   1,3,5,7,9,11,13,15
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm pti tpr_shadow vnmi flexpriority ept vpid dtherm ida

# uname -r
5.3.0-351c8a0.cki

# cat /etc/redhat-release 
Fedora release 30 (Thirty)

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

[LTP] LTP Release

[Cyril Hrubis]

Hi!
> > I did a few testruns and so far it looks good.
> > 
> > I've send one patch for acct02, which is mostly cosmetic, that I would
> > like to get merged.
> > 
> > I would still consider merging the eBPF regression test, does anybody
> > have a strong opinion on this?
> > 
> > Apart from this preadv203 sometimes fails to trigger EAGAIN on virtual
> > machines, but I doubt we can fix this before the release, I will try to
> > do so later on.
> > 
> > The rest seems to be good, i.e. failures does not seem to be bugs in
> > tests.
> > 
> > What is the status from rest of you? Is there anything that should be
> > considered for the release? Is something failing unexpectedly?
> 
> I'm thinking if we should patch BPF tests to increase max lock memory
> to +1MB. On Fedora30 default limit is '64', and I found couple
> systems which by default come very close to that limit right after boot.
> So even one iteration of BPF tests will hit a failure.

I've seen them fail on ppc64le, because of 64k pages as well. Maybe we
shouldn't workaround the failure but rather print a TINFO message that
the limit is too low and the test is likely to fail. Then I will write
the email to kernel developers once the release is done and we will do
something about them later on.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP Release

[Jan Stancek]

----- Original Message -----
> Hi!
> > > I did a few testruns and so far it looks good.
> > > 
> > > I've send one patch for acct02, which is mostly cosmetic, that I would
> > > like to get merged.
> > > 
> > > I would still consider merging the eBPF regression test, does anybody
> > > have a strong opinion on this?
> > > 
> > > Apart from this preadv203 sometimes fails to trigger EAGAIN on virtual
> > > machines, but I doubt we can fix this before the release, I will try to
> > > do so later on.
> > > 
> > > The rest seems to be good, i.e. failures does not seem to be bugs in
> > > tests.
> > > 
> > > What is the status from rest of you? Is there anything that should be
> > > considered for the release? Is something failing unexpectedly?
> > 
> > I'm thinking if we should patch BPF tests to increase max lock memory
> > to +1MB. On Fedora30 default limit is '64', and I found couple
> > systems which by default come very close to that limit right after boot.
> > So even one iteration of BPF tests will hit a failure.
> 
> I've seen them fail on ppc64le, because of 64k pages as well. Maybe we
> shouldn't workaround the failure but rather print a TINFO message that
> the limit is too low and the test is likely to fail. Then I will write
> the email to kernel developers once the release is done and we will do
> something about them later on.

This appears to be known, and some tools like perf started auto-bumping limit:
  https://lkml.org/lkml/2019/7/17/714

I'd prefer LTP does that too, we can always revert later when it's
fixed/changed on kernel side.

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

[LTP] LTP Release

[Li Wang]

On Wed, Sep 25, 2019 at 7:22 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> I did a few testruns and so far it looks good.
>
> I've send one patch for acct02, which is mostly cosmetic, that I would
> like to get merged.
>
> I would still consider merging the eBPF regression test, does anybody
> have a strong opinion on this?
>
> Apart from this preadv203 sometimes fails to trigger EAGAIN on virtual
> machines, but I doubt we can fix this before the release, I will try to
> do so later on.
>
> The rest seems to be good, i.e. failures does not seem to be bugs in
> tests.
>
> What is the status from rest of you? Is there anything that should be
> considered for the release? Is something failing unexpectedly?
>

No more failure from my side except the known issues(timer_create01,
acct02). It's time to release a new package since now is already ending in
September.

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20190926/26a8384c/attachment.htm>

[LTP] LTP Release

[Cyril Hrubis]

Hi!
> > > I'm thinking if we should patch BPF tests to increase max lock memory
> > > to +1MB. On Fedora30 default limit is '64', and I found couple
> > > systems which by default come very close to that limit right after boot.
> > > So even one iteration of BPF tests will hit a failure.
> > 
> > I've seen them fail on ppc64le, because of 64k pages as well. Maybe we
> > shouldn't workaround the failure but rather print a TINFO message that
> > the limit is too low and the test is likely to fail. Then I will write
> > the email to kernel developers once the release is done and we will do
> > something about them later on.
> 
> This appears to be known, and some tools like perf started auto-bumping limit:
>   https://lkml.org/lkml/2019/7/17/714
> 
> I'd prefer LTP does that too, we can always revert later when it's
> fixed/changed on kernel side.

Agreed then, will you prepare the patch?

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP Release

[Jan Stancek]

----- Original Message -----
> Hi!
> > > > I'm thinking if we should patch BPF tests to increase max lock memory
> > > > to +1MB. On Fedora30 default limit is '64', and I found couple
> > > > systems which by default come very close to that limit right after
> > > > boot.
> > > > So even one iteration of BPF tests will hit a failure.
> > > 
> > > I've seen them fail on ppc64le, because of 64k pages as well. Maybe we
> > > shouldn't workaround the failure but rather print a TINFO message that
> > > the limit is too low and the test is likely to fail. Then I will write
> > > the email to kernel developers once the release is done and we will do
> > > something about them later on.
> > 
> > This appears to be known, and some tools like perf started auto-bumping
> > limit:
> >   https://lkml.org/lkml/2019/7/17/714
> > 
> > I'd prefer LTP does that too, we can always revert later when it's
> > fixed/changed on kernel side.
> 
> Agreed then, will you prepare the patch?

Sure, I'll post it today.

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

[LTP] LTP Release

[Thadeu Lima de Souza Cascardo]

On Tue, Sep 10, 2019 at 03:05:53PM +0200, Cyril Hrubis wrote:
> Hi!
> > The one to print errno number.
> >     [PATCH] tst_res: Print errno number in addition to error name
> 
> Pushed the patch as it was, I do not think that reordering the
> statements was important enough.
> 
> > Some test failures:
> > ==============
> > 
> > acct02 (s390x):
> > acct02.c:174: INFO: Verifying using 'struct acct_v3'
> > acct02.c:140: INFO: Number of accounting file entries tested: 2
> > acct02.c:145: FAIL: acct() wrote incorrect file contents!
> 
> I can reproduce it here as well, no idea what is wrong there. I guess
> that modifying the test to be more verbose, i.e. to print if we haven't
> matched the pid or if the contents of the structure were wrong would be
> a good start.
> 
> > timer_create01 (s390x, ppc64le, aarch64):
> > timer_create01.c:48: INFO: Testing notification type: SIGEV_THREAD_ID
> > timer_create01.c:93: PASS: Timer successfully created for CLOCK_REALTIME
> > timer_create01.c:93: PASS: Timer successfully created for CLOCK_MONOTONIC
> > timer_create01.c:93: PASS: Timer successfully created for
> > CLOCK_PROCESS_CPUTIME_ID
> > timer_create01.c:93: PASS: Timer successfully created for
> > CLOCK_THREAD_CPUTIME_ID
> > timer_create01.c:93: PASS: Timer successfully created for CLOCK_BOOTTIME
> > timer_create01.c:87: FAIL: Failed to create timer for CLOCK_BOOTTIME_ALARM:
> > ???
> > timer_create01.c:87: FAIL: Failed to create timer for CLOCK_REALTIME_ALARM:
> > ???
> > timer_create01.c:93: PASS: Timer successfully created for CLOCK_TAI
> 
> I'm pretty sure that we concluded that this is a kernel bug since it
> returns kernel internal errno.
> 

And a pull request has already been sent to Linus to fix this. [1]

Now, the test also needs to check for EOPNOTSUPP instead of only EINVAL. I'll
prepare a patch.

[1] https://lore.kernel.org/lkml/156864062018.3407.10822767012822306757.tglx@nanos.tec.linutronix.de/

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