[LTP] LTP Release

[LTP] LTP Release

[Cyril Hrubis]

Hi!
It's about time for another LTP release. So as usuall let's start with
the list of patches that should go in before the release.

First of all I will have to fix the docparser JSON string escape patch,
I will do so ASAP.

Also I would like to get the CGroup API rewrite in, since that fixes
real problems and is, as far as I can tell, ready to go.

The rtnetlink patchset from Martin is nearly ready as well. I would
apply it as well if we manage to get to final version soon enough.

That is all for me, if there is anything else please reply ASAP.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP Release

[Petr Vorel]

> Hi!
> It's about time for another LTP release. So as usuall let's start with
> the list of patches that should go in before the release.

> First of all I will have to fix the docparser JSON string escape patch,
> I will do so ASAP.
+1

> Also I would like to get the CGroup API rewrite in, since that fixes
> real problems and is, as far as I can tell, ready to go.
+1

> The rtnetlink patchset from Martin is nearly ready as well. I would
> apply it as well if we manage to get to final version soon enough.
+1

> That is all for me, if there is anything else please reply ASAP.
netns_netlink fix + rewrite [1] would be nice to get in.
BTW I plan to add check for ip version, but as part of general approach
proposal (not yet finished), thus after release.

And only if you have time: docparse generation improvements [2].

Kind regards,
Petr

[1] https://patchwork.ozlabs.org/project/ltp/patch/20210401141210.9536-1-pvorel@suse.cz/
[2] https://patchwork.ozlabs.org/project/ltp/list/?series=242088

[LTP] LTP Release

[Petr Vorel]

Hi Cyril,

also solving Shell API timeout sleep orphan processes would be good [1]
There is already C patch [2] + Li suggested to fix the shell implementation
using trap in subshell [3].

Kind regards,
Petr

[1] https://lists.linux.it/pipermail/ltp/2021-May/022350.html
[2] https://patchwork.ozlabs.org/project/ltp/list/?series=242439
[3] https://lists.linux.it/pipermail/ltp/2021-May/022453.html

[LTP] LTP Release

[Petr Vorel]

Hi Cyril,

> Hi Cyril,

> also solving Shell API timeout sleep orphan processes would be good [1]
> There is already C patch [2] + Li suggested to fix the shell implementation
> using trap in subshell [3].
OK there is shell implementation to fix orphan processes [4] from Joerg, which
would be worth do fix it, Li already did a review, I'll look into it today.

I'd like to rebase and send to ML IMA dm-crypt test for testing. If Mimi, Tushar
or Lakshmi find time to test it, I'd like to have it in the release.

I try to have a look on few cleanup patches today from Martin [6], Xie and Zhao.

Kind regards,
Petr

> Kind regards,
> Petr

> [1] https://lists.linux.it/pipermail/ltp/2021-May/022350.html
> [2] https://patchwork.ozlabs.org/project/ltp/list/?series=242439
> [3] https://lists.linux.it/pipermail/ltp/2021-May/022453.html
[4] https://patchwork.ozlabs.org/project/ltp/list/?series=242665
[5] https://patchwork.ozlabs.org/project/ltp/list/?series=230766
[6] https://patchwork.ozlabs.org/project/ltp/patch/20210505153847.6106-2-mdoucha@suse.cz/

[LTP] LTP Release

[Cyril Hrubis]

Hi!
> > also solving Shell API timeout sleep orphan processes would be good [1]
> > There is already C patch [2] + Li suggested to fix the shell implementation
> > using trap in subshell [3].
> OK there is shell implementation to fix orphan processes [4] from Joerg, which
> would be worth do fix it, Li already did a review, I'll look into it today.

I would like to get to a git freeze soon. I will have a look as well but
if it's not ready in the first half of this week I would just postpone
it rather than rush it.

> I'd like to rebase and send to ML IMA dm-crypt test for testing. If Mimi, Tushar
> or Lakshmi find time to test it, I'd like to have it in the release.

Here as well, if things are tested and ready soon enough then go ahead
and apply it.

I would like to freeze the git and start pre release testing, if
possible, in the second half of this week. If there is anything else
that should be fixed please speak up now.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP Release

[Petr Vorel]

> Hi!
> > > also solving Shell API timeout sleep orphan processes would be good [1]
> > > There is already C patch [2] + Li suggested to fix the shell implementation
> > > using trap in subshell [3].
> > OK there is shell implementation to fix orphan processes [4] from Joerg, which
> > would be worth do fix it, Li already did a review, I'll look into it today.

> I would like to get to a git freeze soon. I will have a look as well but
> if it's not ready in the first half of this week I would just postpone
> it rather than rush it.

> > I'd like to rebase and send to ML IMA dm-crypt test for testing. If Mimi, Tushar
> > or Lakshmi find time to test it, I'd like to have it in the release.

> Here as well, if things are tested and ready soon enough then go ahead
> and apply it.
I was wrong, the last bit has not been upstreamed, thus only first commit can be
merged.

> I would like to freeze the git and start pre release testing, if
> possible, in the second half of this week. If there is anything else
> that should be fixed please speak up now.
Good to know.

I suppose you're going to merge Martin's (rt)netlink patchset [1]
(I'd prefer to get it merged).

My netns_netlink rewrite + fix for recent ip [2] would be nice to get merged.
In the future I'll add a check for that prehistoric iproute 100519.

Kind regards,
Petr

[1] https://patchwork.ozlabs.org/project/ltp/list/?series=242146
[2] https://patchwork.ozlabs.org/project/ltp/patch/20210401141210.9536-1-pvorel@suse.cz/

[LTP] LTP Release

[Cyril Hrubis]

Hi!
> > Here as well, if things are tested and ready soon enough then go ahead
> > and apply it.
> I was wrong, the last bit has not been upstreamed, thus only first commit can be
> merged.
> 
> > I would like to freeze the git and start pre release testing, if
> > possible, in the second half of this week. If there is anything else
> > that should be fixed please speak up now.
> Good to know.
> 
> I suppose you're going to merge Martin's (rt)netlink patchset [1]
> (I'd prefer to get it merged).

That one is stalled by my question if we can do more active polling
instead of the sleep and unless we get a reply soon it's not going to
get in...

> My netns_netlink rewrite + fix for recent ip [2] would be nice to get merged.
> In the future I'll add a check for that prehistoric iproute 100519.

I will have a look.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP Release

[Martin Doucha]

On 10. 05. 21 16:58, Cyril Hrubis wrote:
>> I suppose you're going to merge Martin's (rt)netlink patchset [1]
>> (I'd prefer to get it merged).
> 
> That one is stalled by my question if we can do more active polling
> instead of the sleep and unless we get a reply soon it's not going to
> get in...

That question only applies to patch 6. You don't need to wait with
merging patches 1-5. It won't break any tests since the new code will be
unused anyway.

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

[LTP] LTP Release

[Petr Vorel]

> On 10. 05. 21 16:58, Cyril Hrubis wrote:
> >> I suppose you're going to merge Martin's (rt)netlink patchset [1]
> >> (I'd prefer to get it merged).

> > That one is stalled by my question if we can do more active polling
> > instead of the sleep and unless we get a reply soon it's not going to
> > get in...

> That question only applies to patch 6. You don't need to wait with
> merging patches 1-5. It won't break any tests since the new code will be
> unused anyway.
Yep, I'd vote for merging 1-5.

Kind regards,
Petr

[LTP] LTP Release

[Cyril Hrubis]

Hi!
> > That question only applies to patch 6. You don't need to wait with
> > merging patches 1-5. It won't break any tests since the new code will be
> > unused anyway.
> Yep, I'd vote for merging 1-5.

Then go ahead and apply these.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP Release

[Petr Vorel]

Hi,

> Hi!
> > > That question only applies to patch 6. You don't need to wait with
> > > merging patches 1-5. It won't break any tests since the new code will be
> > > unused anyway.
> > Yep, I'd vote for merging 1-5.

> Then go ahead and apply these.

1-5 merged.
Thanks both!

Kind regards,
Petr

[LTP] LTP Release

[Martin Doucha]

On 06. 05. 21 9:19, Cyril Hrubis wrote:
> Hi!
> It's about time for another LTP release. So as usuall let's start with
> the list of patches that should go in before the release.
> 
> First of all I will have to fix the docparser JSON string escape patch,
> I will do so ASAP.
> 
> Also I would like to get the CGroup API rewrite in, since that fixes
> real problems and is, as far as I can tell, ready to go.
> 
> The rtnetlink patchset from Martin is nearly ready as well. I would
> apply it as well if we manage to get to final version soon enough.
> 
> That is all for me, if there is anything else please reply ASAP.

Well, I don't really mind if the rtnetlink patches get delayed until
after the release. But just a reminder that I'm planning to resubmit
patch 6 only after the library changes get merged.

On the other hand, I'd like to get the inotify06 fixes into the next
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

[LTP] LTP Release

[Li Wang]

Hi Cyril,

I vote to fix the brk02 FAIL as Liam suggests way (just removing
'PROT_WRITE|PROT_EXEC'), but I'm still a bit hesitant if that's wise
for the test, or we can leave this problem for a long time to investigate.

https://lists.linux.it/pipermail/ltp/2021-May/022474.html


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

[LTP] LTP Release

[Cyril Hrubis]

Hi!
> I vote to fix the brk02 FAIL as Liam suggests way (just removing
> 'PROT_WRITE|PROT_EXEC'), but I'm still a bit hesitant if that's wise
> for the test, or we can leave this problem for a long time to investigate.
> 
> https://lists.linux.it/pipermail/ltp/2021-May/022474.html

I would be fine with changing the test to mprotect() with just PROT_READ
and if we are going to do that we should do it ASAP since we are going
to start pre-release testing anytime soon.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP Release

[Petr Vorel]

Hi,

Can anybody have look on "[v2] controllers/cpuset: Restore the value of
cpuset.sched_load_balance" patch [1]?

Kind regards,
Petr

[1] https://patchwork.ozlabs.org/project/ltp/patch/1619684694-116827-1-git-send-email-wangxin410@huawei.com/

[LTP] LTP Release

[Richard Palethorpe]

Hello,

Petr Vorel <pvorel@suse.cz> writes:

> Hi,
>
> Can anybody have look on "[v2] controllers/cpuset: Restore the value of
> cpuset.sched_load_balance" patch [1]?
>
> Kind regards,
> Petr
>
> [1] https://patchwork.ozlabs.org/project/ltp/patch/1619684694-116827-1-git-send-email-wangxin410@huawei.com/

Looks fine except for existing issues with those tests.

-- 
Thank you,
Richard.

[LTP] LTP Release

[Cyril Hrubis]

Hi!
This is a last call, if there is anything that should get in before we
freeze git, speak up now.

Once git is frozen only bugfixes for failing tests will be able to go
in.

Ideally I would like to freeze the git either tomorrow or on thursday
and with that we will have a week for pre-release testing of the latest
git HEAD. If all goes well the release would be finalized around 20th of
this month. Is everyone fine with this schedulle?

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP pre-release git freeze and call for testing

[Cyril Hrubis]

Hi!
As previously planned LTP git is now frozen for anything but imporatnt
fixes and the (ideally) week of pre-release testing starts now.

If you haven't tested latest LTP git please do so now.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] [Automated-testing] LTP pre-release git freeze and call for testing

[Petr Vorel]

> Hi!
> As previously planned LTP git is now frozen for anything but imporatnt
> fixes and the (ideally) week of pre-release testing starts now.
As release fixes, I'd like to merge these netlink detection support fixes for
old kernels and fix and tonight send also add lapi/if_addr.h with IFA_FLAGS
(to fix compilation on some old kernels).

Last thing which I'd like is to state which version we support in this release
(as document to doc/ and wiki). After release we can discuss which support we
can drop.

Kind regards,
Petr

> If you haven't tested latest LTP git please do so now.

[LTP] LTP pre-release git freeze and call for testing

[Li Wang]

> Hi!
> As previously planned LTP git is now frozen for anything but imporatnt
> fixes and the (ideally) week of pre-release testing starts now.
>
> If you haven't tested latest LTP git please do so now.

FYI:

Tested the latest LTP branch on RHEL8 (with itself kernel-4.18~ and
mainline kernel-v5.13-rc1), the result looks pretty good to me.

Mainline kernel:
  mkswap01 6 TBROK: "check_for_file /dev/disk/by-label/ltp_testswap" timed out
    - looks like hit the race condition issue as before
  hugemmap05.c:84: TBROK: mmap((nil),2147483648,3,1,3,0) failed: ENOMEM (12)
    - seems caused by memory fragmentation, not a big deal

RHEL8:
  mkswap01: same as above
  bpf_prog05: known unfix bug
  semctl09: known glibc bug
  fanotify09/10: known unfix bug


-- 
Regards,
Li Wang

[LTP] LTP pre-release git freeze and call for testing

[Cyril Hrubis]

Hi!
> Tested the latest LTP branch on RHEL8 (with itself kernel-4.18~ and
> mainline kernel-v5.13-rc1), the result looks pretty good to me.

Thanks a lot!

> Mainline kernel:
>   mkswap01 6 TBROK: "check_for_file /dev/disk/by-label/ltp_testswap" timed out
>     - looks like hit the race condition issue as before
>   hugemmap05.c:84: TBROK: mmap((nil),2147483648,3,1,3,0) failed: ENOMEM (12)
>     - seems caused by memory fragmentation, not a big deal

This should be probably changed to TCONF but that can wait after the
release.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] [Automated-testing] LTP pre-release git freeze and call for testing

[Cyril Hrubis]

Hi!
> As previously planned LTP git is now frozen for anything but imporatnt
> fixes and the (ideally) week of pre-release testing starts now.
> 
> If you haven't tested latest LTP git please do so now.

So far things looks calm enough, so I would like to proceed with the
release on Monday 24.

-- 
Cyril Hrubis
chrubis@suse.cz