[LTP] September LTP release

[LTP] September LTP release

[Cyril Hrubis]

Hi!
It's time to start working on LTP September relelase.

First of all I'm thinking of increasing the bus factor for LTP so if
there is anyone who wants to drive the release process instead of me
please sign up ASAP. I will of course review patches and help with the
release, but it would nice if someone else tried to do all the little
things for release as sending emails, deciding what should go to release
after freeze, preparing release notes, uploading tarballs on github,
etc.

And in order not to delay things further, please start pointing out
patches that should go in before the release. I guess Martin runtime
fixes should go in. Anything else?

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] September LTP release

[Li Wang]

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

On Fri, Sep 9, 2022 at 4:47 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> It's time to start working on LTP September relelase.
>
> First of all I'm thinking of increasing the bus factor for LTP so if
> there is anyone who wants to drive the release process instead of me
> please sign up ASAP. I will of course review patches and help with the
> release, but it would nice if someone else tried to do all the little
> things for release as sending emails, deciding what should go to release
> after freeze, preparing release notes, uploading tarballs on github,
> etc.


Maye split this work into pieces? something like:
    - announcement email,
    - collecting patch lists for a new release,
    - writing release notes, or paperwork,
    - uploading tarballs
    - pre-testing against different Linux distribution

You can still send the announcement email, and other volunteers do the rest.
(if applicable, I can take patch reviews or upload tarballs work)

Btw, I'll also cover the full pre-test against the RHEL series before
release.


> And in order not to delay things further, please start pointing out
> patches that should go in before the release. I guess Martin runtime
> fixes should go in. Anything else?
>

The "Track minimal size per filesystem" from Petr should be included as
well.
(I guess it is still WIP)


-- 
Regards,
Li Wang

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

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


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

Re: [LTP] September LTP release

[Cyril Hrubis]

Hi!
> Maye split this work into pieces? something like:
>     - announcement email,
>     - collecting patch lists for a new release,
>     - writing release notes, or paperwork,
>     - uploading tarballs
>     - pre-testing against different Linux distribution
> 
> You can still send the announcement email, and other volunteers do the rest.
> (if applicable, I can take patch reviews or upload tarballs work)

I guess that would work too, as long as we have volunteers.

> Btw, I'll also cover the full pre-test against the RHEL series before
> release.
> 
> 
> > And in order not to delay things further, please start pointing out
> > patches that should go in before the release. I guess Martin runtime
> > fixes should go in. Anything else?
> >
> 
> The "Track minimal size per filesystem" from Petr should be included as
> well.
> (I guess it is still WIP)

Ah, right, we have to do something about xfs, I guess that if we do not
manage until the release a minimal fix would be to increase the minimal
device size.

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] September LTP release

[Petr Vorel]

Hi all,

[ Cc automated-testing ML ]

> Hi!
> > Maye split this work into pieces? something like:
> >     - announcement email,
> >     - collecting patch lists for a new release,
> >     - writing release notes, or paperwork,
> >     - uploading tarballs
> >     - pre-testing against different Linux distribution

> > You can still send the announcement email, and other volunteers do the rest.
> > (if applicable, I can take patch reviews or upload tarballs work)

> I guess that would work too, as long as we have volunteers.
I could do part of work as well. I volunteer to upload the tarballs.
I also try to help with reviewing and testing pre release fixes.
I usually do network tests changelog, which is tiny part of whole changelog.

I try to do at least some of runtime tests on SLES and Tumbleweed, I suppose
Martin helps with it as usually. Obviously more people should do pre-release
testing.

And in my non work time build testing on Buildroot (finds various build problems
on other libc and generally the embedded world).

> > Btw, I'll also cover the full pre-test against the RHEL series before
> > release.


> > > And in order not to delay things further, please start pointing out
> > > patches that should go in before the release. I guess Martin runtime
> > > fixes should go in. Anything else?


> > The "Track minimal size per filesystem" from Petr should be included as
> > well.
> > (I guess it is still WIP)
Yes, it's still in WIP.  I'll finish the "Track minimal size per filesystem"
patchset after merging $TST_ALL_FILESYSTEMS.

I'd really prefer to get reviewed and merged "v5 shell: df01.sh:
$TST_ALL_FILESYSTEMS (.all_filesystems)" [1] [2]. Martin has suggested for v4 to
use 2 different enums (TST_FS_UNAVAILABLE and TST_FS_UNSUPPORTED instead of
TST_FS_UNSUPPORTED) [3]. I'm willing to implement that in Monday if are others
ok and hope this is the last change and whole thing can be merged.

> Ah, right, we have to do something about xfs, I guess that if we do not
> manage until the release a minimal fix would be to increase the minimal
> device size.

I don't mind to merge "Fix mkfs.xfs 300MB min size requirement (v5.19.0)" [4]
[5] as a temporary fix before release.

Kind regards,
Petr


[1] https://patchwork.ozlabs.org/project/ltp/list/?series=317639
[2] https://lore.kernel.org/ltp/20220909141840.18327-1-pvorel@suse.cz/
[3] https://lore.kernel.org/ltp/70df29e7-0097-c698-b6ba-e3f87da3893f@suse.cz/
[4] https://patchwork.ozlabs.org/project/ltp/list/?series=314303&state=*
[5] https://lore.kernel.org/ltp/20220818100945.7935-1-pvorel@suse.cz/

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

Re: [LTP] September LTP release

[Petr Vorel]

Hi all,

FYI in minor fanotify cleanup I just wait to get acked TST_EXP_FD_ERRNO [1]
It might be usable only in fanotify, but I'd keep it in tst_test_macros.h
Sooner or later it will be usable by other tests.
I'm also not sure about the name.

If you like this idea, in the future we might
add more TST_EXP_*_ERRNO(SCALL, ERRNO, ...) macros, i.e. calling TST_EXP_FAIL or TST_EXP_PASS
(thus name could be TST_EXP_PASS_FAIL).

I wanted to add some documentation for tst_test_macros.h but that will happen
after the release.

Kind regards,
Petr

[1] https://lore.kernel.org/ltp/20220906092615.15116-2-pvorel@suse.cz/

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

Re: [LTP] September LTP release

[Cyril Hrubis]

Hi!
> FYI in minor fanotify cleanup I just wait to get acked TST_EXP_FD_ERRNO [1]
> It might be usable only in fanotify, but I'd keep it in tst_test_macros.h
> Sooner or later it will be usable by other tests.
> I'm also not sure about the name.

Since it's calling TST_EXP_FD() or TST_EXP_FAIL() the logical name for
it would be TST_EXP_FD_OR_FAIL()

> If you like this idea, in the future we might
> add more TST_EXP_*_ERRNO(SCALL, ERRNO, ...) macros, i.e. calling TST_EXP_FAIL or TST_EXP_PASS
> (thus name could be TST_EXP_PASS_FAIL).

Without _OR_ between PASS and FAIL the name is kind of confusing. And
it's not that much better even as TST_EXP_PASS_OR_FAIL() but I cannot
think of anything better at the moment.

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] September LTP release

[Petr Vorel]

> Hi!
> > FYI in minor fanotify cleanup I just wait to get acked TST_EXP_FD_ERRNO [1]
> > It might be usable only in fanotify, but I'd keep it in tst_test_macros.h
> > Sooner or later it will be usable by other tests.
> > I'm also not sure about the name.

> Since it's calling TST_EXP_FD() or TST_EXP_FAIL() the logical name for
> it would be TST_EXP_FD_OR_FAIL()

I guess I should use TST_EXP_FD_OR_FAIL(). If anybody objects can I merge it
with your ack? Of course I can send proper v2 and wait after the release.

> > If you like this idea, in the future we might
> > add more TST_EXP_*_ERRNO(SCALL, ERRNO, ...) macros, i.e. calling TST_EXP_FAIL or TST_EXP_PASS
> > (thus name could be TST_EXP_PASS_FAIL).

> Without _OR_ between PASS and FAIL the name is kind of confusing. And
> it's not that much better even as TST_EXP_PASS_OR_FAIL() but I cannot
> think of anything better at the moment.
TST_EXP_PASS_OR_FAIL() sounds good. I'll try to add it with some tests converted
(after the release).

Kind regards,
Petr

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

Re: [LTP] September LTP release

[Li Wang]

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

On Fri, Sep 9, 2022 at 10:36 PM Petr Vorel <pvorel@suse.cz> wrote:

> Hi all,
>
> [ Cc automated-testing ML ]
>
> > Hi!
> > > Maye split this work into pieces? something like:
> > >     - announcement email,
> > >     - collecting patch lists for a new release,
> > >     - writing release notes, or paperwork,
> > >     - uploading tarballs
> > >     - pre-testing against different Linux distribution
>
> > > You can still send the announcement email, and other volunteers do the
> rest.
> > > (if applicable, I can take patch reviews or upload tarballs work)
>
> > I guess that would work too, as long as we have volunteers.
> I could do part of work as well. I volunteer to upload the tarballs.
> I also try to help with reviewing and testing pre release fixes.
> I usually do network tests changelog, which is tiny part of whole
> changelog.
>
> I try to do at least some of runtime tests on SLES and Tumbleweed, I
> suppose
> Martin helps with it as usually. Obviously more people should do
> pre-release
> testing.
>
> And in my non work time build testing on Buildroot (finds various build
> problems
> on other libc and generally the embedded world).
>

Well, if more than three people are involved in the release work,
I think that the release workflow should be arranged in time order,
otherwise, we're easily going to fall into chaos. e.g.

Assumption work starting from the second week of the release month:

1. Collecting the patch list for a new release, like this email does (Cyril)

2. Reviewing and merging the patch list of step1 (All maintainers,
LTP-users)

3. Pre-release widely testing, we need to explicitly post results in step1
email (Petr, Li Wang)

4. Tiny fix according to pre-release testing result (All maintainers, users)

5. Writing release note (Cyril)

6. Uploading tarballs (Petr)

7. Announcement email of LTP release (Cyril)


Does this look useful? or anything else?

IMO if any more volunteers hope to be involved, they just need
to pick up any step they are interested in.


-- 
Regards,
Li Wang

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

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


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

Re: [LTP] September LTP release

[xuyang2018.jy]

Hi Cyril


> Hi!
> It's time to start working on LTP September relelase.
> 
> First of all I'm thinking of increasing the bus factor for LTP so if
> there is anyone who wants to drive the release process instead of me
> please sign up ASAP. I will of course review patches and help with the
> release, but it would nice if someone else tried to do all the little
> things for release as sending emails, deciding what should go to release
> after freeze, preparing release notes, uploading tarballs on github,
> etc.
> 
> And in order not to delay things further, please start pointing out
> patches that should go in before the release. I guess Martin runtime
> fixes should go in. Anything else?

How about merging the setgid fixes part[1]? Also include PR_SET_TSC part[2].

[1]https://patchwork.ozlabs.org/project/ltp/list/?series=313791
[2]https://patchwork.ozlabs.org/project/ltp/patch/1657106160-2126-1-git-send-email-xuyang2018.jy@fujitsu.com/

Best Regards
Yang Xu
> 

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

Re: [LTP] September LTP release

[Cyril Hrubis]

Hi!
> [1]https://patchwork.ozlabs.org/project/ltp/list/?series=313791
> [2]https://patchwork.ozlabs.org/project/ltp/patch/1657106160-2126-1-git-send-email-xuyang2018.jy@fujitsu.com/

I will have a look.

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] September LTP release

[Cyril Hrubis]

Hi!
> Well, if more than three people are involved in the release work,
> I think that the release workflow should be arranged in time order,
> otherwise, we're easily going to fall into chaos. e.g.
> 
> Assumption work starting from the second week of the release month:
> 
> 1. Collecting the patch list for a new release, like this email does (Cyril)
> 
> 2. Reviewing and merging the patch list of step1 (All maintainers,
> LTP-users)
> 
> 3. Pre-release widely testing, we need to explicitly post results in step1
> email (Petr, Li Wang)
> 
> 4. Tiny fix according to pre-release testing result (All maintainers, users)
> 
> 5. Writing release note (Cyril)
> 
> 6. Uploading tarballs (Petr)
> 
> 7. Announcement email of LTP release (Cyril)
> 
> 
> Does this look useful? or anything else?

Thanks a lot for writing this down. Agree on all points, lets get to
work so that we actually manage to produce the release at the end of the
month.

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] September LTP release

[Petr Vorel]

Hi all,

FYI my patchset "v6 shell: df01.sh: $TST_ALL_FILESYSTEMS]" introduced a
regression in ima_keys.sh and follow-up IMA/EVM related tests.
I'm sorry, I'll fix it ASAP, hopefully this week.

ima_keys 1 TINFO: $TMPDIR is on tmpfs => run on loop device
ima_keys 1 TINFO: Formatting ext3 with opts='/dev/loop0'
ima_keys 1 TINFO: Mounting device: mount -t ext3 /dev/loop0 /tmp/LTP_ima_keys.YArl935DCg/mntpoint
ima_keys 1 TCONF: IMA policy does not specify '^measure.*func=KEY_CHECK'
tst_device.c:255: TWARN: ioctl(/dev/loop0, LOOP_CLR_FD, 0) no ENXIO for too long

Kind regards,
Petr

[1] https://patchwork.ozlabs.org/project/ltp/list/?series=318458&state=*


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

Re: [LTP] September LTP release

[Petr Vorel]

Hi all,

> ima_keys 1 TINFO: $TMPDIR is on tmpfs => run on loop device
> ima_keys 1 TINFO: Formatting ext3 with opts='/dev/loop0'
> ima_keys 1 TINFO: Mounting device: mount -t ext3 /dev/loop0 /tmp/LTP_ima_keys.YArl935DCg/mntpoint
> ima_keys 1 TCONF: IMA policy does not specify '^measure.*func=KEY_CHECK'
> tst_device.c:255: TWARN: ioctl(/dev/loop0, LOOP_CLR_FD, 0) no ENXIO for too long

FYI I've fixed this in patchset "IMA + shell API fixes on umount" [1] [2]
which depends on 2 other patchsets.

Kind regards,
Petr

[1] https://lore.kernel.org/ltp/20220923105554.28942-1-pvorel@suse.cz/
[2] https://patchwork.ozlabs.org/project/ltp/list/?series=319753&state=*

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

Re: [LTP] September LTP release

[Cyril Hrubis]

Hi!
> > ima_keys 1 TINFO: $TMPDIR is on tmpfs => run on loop device
> > ima_keys 1 TINFO: Formatting ext3 with opts='/dev/loop0'
> > ima_keys 1 TINFO: Mounting device: mount -t ext3 /dev/loop0 /tmp/LTP_ima_keys.YArl935DCg/mntpoint
> > ima_keys 1 TCONF: IMA policy does not specify '^measure.*func=KEY_CHECK'
> > tst_device.c:255: TWARN: ioctl(/dev/loop0, LOOP_CLR_FD, 0) no ENXIO for too long
> 
> FYI I've fixed this in patchset "IMA + shell API fixes on umount" [1] [2]
> which depends on 2 other patchsets.

Will have a look.

I've tried to merge several smaller fixes during the week. Is there
anything else to consider for inclusion?

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] September LTP release

[Petr Vorel]

> Hi!
> > > ima_keys 1 TINFO: $TMPDIR is on tmpfs => run on loop device
> > > ima_keys 1 TINFO: Formatting ext3 with opts='/dev/loop0'
> > > ima_keys 1 TINFO: Mounting device: mount -t ext3 /dev/loop0 /tmp/LTP_ima_keys.YArl935DCg/mntpoint
> > > ima_keys 1 TCONF: IMA policy does not specify '^measure.*func=KEY_CHECK'
> > > tst_device.c:255: TWARN: ioctl(/dev/loop0, LOOP_CLR_FD, 0) no ENXIO for too long

> > FYI I've fixed this in patchset "IMA + shell API fixes on umount" [1] [2]
> > which depends on 2 other patchsets.

> Will have a look.

> I've tried to merge several smaller fixes during the week. Is there
> anything else to consider for inclusion?

I wonder, if we want to document in C/shell API docs, that for skipping ext[2-4]
on tests which run on single filesystem we one needs to specify "ext2/ext3/ext4.
It has not been needed so far, thus may not be needed. I understood we're not
going to change this.

Kind regards,
Petr

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

Re: [LTP] September LTP release

[Cyril Hrubis]

Hi!
> I wonder, if we want to document in C/shell API docs, that for skipping ext[2-4]
> on tests which run on single filesystem we one needs to specify "ext2/ext3/ext4.
> It has not been needed so far, thus may not be needed. I understood we're not
> going to change this.

I would keep this after the release.

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] September LTP release

[Cyril Hrubis]

Hi!
> Well, if more than three people are involved in the release work,
> I think that the release workflow should be arranged in time order,
> otherwise, we're easily going to fall into chaos. e.g.
> 
> Assumption work starting from the second week of the release month:
> 
> 1. Collecting the patch list for a new release, like this email does (Cyril)
> 
> 2. Reviewing and merging the patch list of step1 (All maintainers,
> LTP-users)
> 
> 3. Pre-release widely testing, we need to explicitly post results in step1
> email (Petr, Li Wang)
> 
> 4. Tiny fix according to pre-release testing result (All maintainers, users)
> 
> 5. Writing release note (Cyril)
> 
> 6. Uploading tarballs (Petr)
> 
> 7. Announcement email of LTP release (Cyril)

Lets move on with the plannig, I would say that we are done with step 2.
and we should move to step 3.

Also I would go for a release date at the end of the month that is 30.9.

Does everyone agree?

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] September LTP release

[Li Wang]

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

On Mon, Sep 26, 2022 at 5:56 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> > Well, if more than three people are involved in the release work,
> > I think that the release workflow should be arranged in time order,
> > otherwise, we're easily going to fall into chaos. e.g.
> >
> > Assumption work starting from the second week of the release month:
> >
> > 1. Collecting the patch list for a new release, like this email does
> (Cyril)
> >
> > 2. Reviewing and merging the patch list of step1 (All maintainers,
> > LTP-users)
> >
> > 3. Pre-release widely testing, we need to explicitly post results in
> step1
> > email (Petr, Li Wang)
> >
> > 4. Tiny fix according to pre-release testing result (All maintainers,
> users)
> >
> > 5. Writing release note (Cyril)
> >
> > 6. Uploading tarballs (Petr)
> >
> > 7. Announcement email of LTP release (Cyril)
>
> Lets move on with the plannig, I would say that we are done with step 2.
> and we should move to step 3.
>
> Also I would go for a release date at the end of the month that is 30.9.
>

Sounds good to me. Thanks!



>
> Does everyone agree?
>

I agree, and the more test the better.

I'd test on RHEL8, RHEL9, RHEL9 + mainline-kernel-6.0-rc7,
and will post the results here if anything needs improvement.

P.s. actually I already did some pre-test last week, and let's
see how today's new merge patches performing.


-- 
Regards,
Li Wang

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

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


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

Re: [LTP] September LTP release

[Petr Vorel]

> Hi!
> > Well, if more than three people are involved in the release work,
> > I think that the release workflow should be arranged in time order,
> > otherwise, we're easily going to fall into chaos. e.g.

> > Assumption work starting from the second week of the release month:

> > 1. Collecting the patch list for a new release, like this email does (Cyril)

> > 2. Reviewing and merging the patch list of step1 (All maintainers,
> > LTP-users)

> > 3. Pre-release widely testing, we need to explicitly post results in step1
> > email (Petr, Li Wang)

> > 4. Tiny fix according to pre-release testing result (All maintainers, users)

> > 5. Writing release note (Cyril)

> > 6. Uploading tarballs (Petr)

> > 7. Announcement email of LTP release (Cyril)

> Lets move on with the plannig, I would say that we are done with step 2.
> and we should move to step 3.
+1

> Also I would go for a release date at the end of the month that is 30.9.
+1

> Does everyone agree?

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

Re: [LTP] September LTP release

[Petr Vorel]

Hi all,

> Lets move on with the plannig, I would say that we are done with step 2.
> and we should move to step 3.
FYI I plan to implement simple binary emulating fsfreeze, which is needed for
df01.sh on kernel >= 5.19 [1], but that will be after the release (i.e. we have
known failure, fix would be quick, but it's minor and we want to concentrate on
the release).

Kind regards,
Petr

> Also I would go for a release date at the end of the month that is 30.9.

> Does everyone agree?

[1] https://lore.kernel.org/linux-xfs/Yv+ziab2IiVIsqN6@pevik/

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

Re: [LTP] September LTP release

[Petr Vorel]

Hi all,

also zram01.sh has problem with XFS on 5.19.
I guess we could fix it similar way as for btrfs.
(btrfs it requires 384M, that would be enough for XFS;
or we can be precise and use just 301 MB).

Kind regards,
Petr

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

Re: [LTP] September LTP release

[Li Wang]

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

On Mon, Sep 26, 2022 at 6:13 PM Li Wang <liwang@redhat.com> wrote:


> > 1. Collecting the patch list for a new release, like this email does
>> (Cyril)
>> >
>> > 2. Reviewing and merging the patch list of step1 (All maintainers,
>> > LTP-users)
>> >
>> > 3. Pre-release widely testing, we need to explicitly post results in
>> step1
>> > email (Petr, Li Wang)
>> >
>> > 4. Tiny fix according to pre-release testing result (All maintainers,
>> users)
>> >
>> > 5. Writing release note (Cyril)
>> >
>> > 6. Uploading tarballs (Petr)
>> >
>> > 7. Announcement email of LTP release (Cyril)
>>
>> Lets move on with the plannig, I would say that we are done with step 2.
>> and we should move to step 3.
>
>
Pre-release testing briefly summary:

RHEL8 and RHEL9:
The latest LTP test is pretty good (only reports three kernel known issues).

Upstream kernel-v6.0-rc5:
1. readahead02 still occasionally timed out with a slower IO machine
(ppc64le)

    ...
    37	readahead02.c:295: TPASS: readahead saved some I/O
    38	readahead02.c:303: TINFO: cache can hold at least: 264320 kB
    39	readahead02.c:304: TINFO: read_testfile(0) used cache: 131968 kB
    40	readahead02.c:305: TINFO: read_testfile(1) used cache: 62400 kB
    41	readahead02.c:313: TPASS: using cache as expected
    42	readahead02.c:223: TINFO: Test #2: POSIX_FADV_WILLNEED on file
    43	readahead02.c:128: TINFO: creating test file of size: 67108864
    44	readahead02.c:242: TINFO: read_testfile(0)
    45	readahead02.c:253: TINFO: read_testfile(1)
    46	readahead02.c:177: TINFO: readahead calls made: 32
    47	readahead02.c:183: TPASS: offset is still at 0 as expected
    48	Test timeouted, sending SIGKILL!
    49	tst_test.c:1577: TINFO: If you are running on slow machine, try
exporting LTP_TIMEOUT_MUL > 1
    50	tst_test.c:1579: TBROK: Test killed! (timeout?)


2. df01 got strange failures on XFS (I was unable to reproduce it manually)

    71 df01 37 TINFO: === Testing on xfs ===
    72 df01 37 TINFO: Formatting xfs with opts='/dev/loop0'
    73 df01 37 TINFO: Mounting device: mount -t xfs /dev/loop0
/mnt/testarea/ltp-pgxzTJRwdG/LTP_df01.IFAhWHNrYb/mntpoint
    74 df01 37 TINFO: timeout per run is 0h 10m 0s
    75 df01 37 TPASS: 'df -P' passed.
    76 total: 301728, used: 17736
    77 df saved output:
   ...
   135 df01 38 TFAIL: 'df -a -P' failed, not expected.
   136 df01 39 TPASS: 'df -i -P' passed.
   ...
   160 df01 40 TFAIL: 'df -k -P' failed, not expected.
   161 df01 41 TPASS: 'df -t xfs -P' passed.
   ...
   185 df01 42 TFAIL: 'df -T -P' failed, not expected.
   186 df01 43 TPASS: 'df -v /dev/loop0 -P' passed.
   187 df01 44 TPASS: 'df -h' passed.
   188 df01 45 TPASS: 'df -H' passed.
   189 df01 46 TPASS: 'df -m' passed.
   190 df01 47 TPASS: 'df --version' passed.
   191 df01 48 TPASS: 'df -x xfs -P' passed.

3. two io_uring test hit memory permission denied issue (on all arches)

     7	tst_buffers.c:55: TINFO: Test is using guarded buffers
     8	tst_test.c:1526: TINFO: Timeout per run is 0h 01m 00s
     9	io_uring01.c:80: TPASS: io_uring_setup() passed
    10	io_uring01.c:89: TBROK: mmap((nil),388,3,32769,3,0) failed: EACCES (13)


     7	tst_test.c:1526: TINFO: Timeout per run is 0h 01m 00s
     8	io_uring02.c:213: TBROK: mmap((nil),19072,3,32769,5,0) failed:
EACCES (13)


-- 
Regards,
Li Wang

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

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


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

Re: [LTP] September LTP release

[Petr Vorel]

Hi Li,

...
> 2. df01 got strange failures on XFS (I was unable to reproduce it manually)

>     71 df01 37 TINFO: === Testing on xfs ===
>     72 df01 37 TINFO: Formatting xfs with opts='/dev/loop0'
>     73 df01 37 TINFO: Mounting device: mount -t xfs /dev/loop0
> /mnt/testarea/ltp-pgxzTJRwdG/LTP_df01.IFAhWHNrYb/mntpoint
>     74 df01 37 TINFO: timeout per run is 0h 10m 0s
>     75 df01 37 TPASS: 'df -P' passed.
>     76 total: 301728, used: 17736
>     77 df saved output:
>    ...
>    135 df01 38 TFAIL: 'df -a -P' failed, not expected.
>    136 df01 39 TPASS: 'df -i -P' passed.
>    ...
>    160 df01 40 TFAIL: 'df -k -P' failed, not expected.
>    161 df01 41 TPASS: 'df -t xfs -P' passed.
>    ...
>    185 df01 42 TFAIL: 'df -T -P' failed, not expected.
>    186 df01 43 TPASS: 'df -v /dev/loop0 -P' passed.
>    187 df01 44 TPASS: 'df -h' passed.
>    188 df01 45 TPASS: 'df -H' passed.
>    189 df01 46 TPASS: 'df -m' passed.
>    190 df01 47 TPASS: 'df --version' passed.
>    191 df01 48 TPASS: 'df -x xfs -P' passed.
This is known:
https://lore.kernel.org/linux-xfs/YvZTpQFinpkB06p9@pevik/

I've mention that yesterday, that I'll fix it after the release
https://lore.kernel.org/ltp/YzGDdC76DLmrJyys@pevik/
I'll try to send a patch soon and we can decide whether we merge it before
release or not.

And zram01.sh fails due XFS minimal size. I also try to send a patch soon.

Kind regards,
Petr

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

Re: [LTP] September LTP release

[Li Wang]

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

Petr Vorel <pvorel@suse.cz> wrote:

>    185 df01 42 TFAIL: 'df -T -P' failed, not expected.
>
> This is known:
> https://lore.kernel.org/linux-xfs/YvZTpQFinpkB06p9@pevik/
>
> I've mention that yesterday, that I'll fix it after the release
> https://lore.kernel.org/ltp/YzGDdC76DLmrJyys@pevik/
> I'll try to send a patch soon and we can decide whether we merge it before
> release or not.
>

Ah, yes, I shouldn't skip reading emails so careless :).
Thanks for the upcoming fix, let's see what it looks like and then decide
to merge or not.

And zram01.sh fails due XFS minimal size. I also try to send a patch soon.
>

Thanks! Next, I will only investigate the io_uring failures.


-- 
Regards,
Li Wang

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

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


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

Re: [LTP] September LTP release

[Petr Vorel]

Hi all,

OK, we have another regression in 1f6bd6e66 ("tst_test.sh: Add
$TST_ALL_FILESYSTEMS"). I'll reply to release thread.

tst_brk TCONF in network tests causes broken tests.
I'll try to send patch soon, it's up to you if we release with known issue
or fix it before release.

Kind regards,
Petr

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

Re: [LTP] September LTP release

[Petr Vorel]

Hi Li,

> Petr Vorel <pvorel@suse.cz> wrote:

> >    185 df01 42 TFAIL: 'df -T -P' failed, not expected.

> > This is known:
> > https://lore.kernel.org/linux-xfs/YvZTpQFinpkB06p9@pevik/

> > I've mention that yesterday, that I'll fix it after the release
> > https://lore.kernel.org/ltp/YzGDdC76DLmrJyys@pevik/
> > I'll try to send a patch soon and we can decide whether we merge it before
> > release or not.

FYI It looks like this has been fixed, it works on machine with Tumbleweed,
kernel 6.0.0-rc7-1.g74aafe0-default, mkfs.xfs version 5.19.0. It also works on
Tumbleweed with stable kernel 5.19.10-1-default. I started to bisect, but
haven't found first broken commit (too lazy to get deeper into this).

Kind regards,
Petr


> Ah, yes, I shouldn't skip reading emails so careless :).
> Thanks for the upcoming fix, let's see what it looks like and then decide
> to merge or not.

> And zram01.sh fails due XFS minimal size. I also try to send a patch soon.


> Thanks! Next, I will only investigate the io_uring failures.

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