All of lore.kernel.org
 help / color / mirror / Atom feed
* [LTP] LTP Release
@ 2018-12-14 15:09 Cyril Hrubis
  2018-12-18  9:17 ` Petr Vorel
  2019-01-02 10:28 ` Cyril Hrubis
  0 siblings, 2 replies; 197+ messages in thread
From: Cyril Hrubis @ 2018-12-14 15:09 UTC (permalink / raw)
  To: ltp

Hi!
As usuall it's time to start to prepare for a new LTP release.

My plan is to try to merge as much as possible in the first half of the
next week then to drop offline util the new year passes. Once I get back
we should start to concentrate on the release procedure.

Feel free to start pointing out which patches you think should be merged
before the release now, I will try to do the review ASAP.

And lastly but not least Merry Christmas and a Happy New Year for
everyone who will celebrate them!

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2018-12-14 15:09 [LTP] LTP Release Cyril Hrubis
@ 2018-12-18  9:17 ` Petr Vorel
  2019-01-02 10:28 ` Cyril Hrubis
  1 sibling, 0 replies; 197+ messages in thread
From: Petr Vorel @ 2018-12-18  9:17 UTC (permalink / raw)
  To: ltp

Hi Cyril, Alexey,

...
> Feel free to start pointing out which patches you think should be merged
> before the release now, I will try to do the review ASAP.
I'd like to get merged my patchset "DHCP tests and AppArmor/SELinux
improvements" [1] [2].

> And lastly but not least Merry Christmas and a Happy New Year for
> everyone who will celebrate them!
For you as well.


Kind regards,
Petr

[1] https://patchwork.ozlabs.org/project/ltp/list/?series=82472&state=*
[2] http://lists.linux.it/pipermail/ltp/2018-December/010327.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2018-12-14 15:09 [LTP] LTP Release Cyril Hrubis
  2018-12-18  9:17 ` Petr Vorel
@ 2019-01-02 10:28 ` Cyril Hrubis
  2019-01-04 15:42   ` Cyril Hrubis
  1 sibling, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2019-01-02 10:28 UTC (permalink / raw)
  To: ltp

Hi!
> Feel free to start pointing out which patches you think should be merged
> before the release now, I will try to do the review ASAP.

This is gentle reminder to point out important fixes that should be part
of the upcomming release.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-01-02 10:28 ` Cyril Hrubis
@ 2019-01-04 15:42   ` Cyril Hrubis
  2019-01-07  2:18     ` Xiao Yang
  2019-01-11 13:25     ` Cyril Hrubis
  0 siblings, 2 replies; 197+ messages in thread
From: Cyril Hrubis @ 2019-01-04 15:42 UTC (permalink / raw)
  To: ltp

Hi!
In order to proceed I would like to declare git freeze starting next
week and ask everyone for round of pre-release testing.

As for patches that should be included in the release I would like to
include fixes for:

* http://patchwork.ozlabs.org/patch/1020662/
* https://github.com/linux-test-project/ltp/pull/444

Anything else I should look into?

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-01-04 15:42   ` Cyril Hrubis
@ 2019-01-07  2:18     ` Xiao Yang
  2019-01-11 13:25     ` Cyril Hrubis
  1 sibling, 0 replies; 197+ messages in thread
From: Xiao Yang @ 2019-01-07  2:18 UTC (permalink / raw)
  To: ltp

On 2019/01/04 23:42, Cyril Hrubis wrote:
> Hi!
> In order to proceed I would like to declare git freeze starting next
> week and ask everyone for round of pre-release testing.
>
> As for patches that should be included in the release I would like to
> include fixes for:
>
> * http://patchwork.ozlabs.org/patch/1020662/
> * https://github.com/linux-test-project/ltp/pull/444
>
> Anything else I should look into?
Hi Cyril,

Can you try to review and push my patch set[1] fixing issue #408?
[1] http://patchwork.ozlabs.org/patch/1011665/
     http://patchwork.ozlabs.org/patch/1011667/
     http://patchwork.ozlabs.org/patch/1011666/

Best Regards,
Xiao Yang




^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-01-04 15:42   ` Cyril Hrubis
  2019-01-07  2:18     ` Xiao Yang
@ 2019-01-11 13:25     ` Cyril Hrubis
  2019-01-11 16:16       ` Cristian Marussi
  1 sibling, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2019-01-11 13:25 UTC (permalink / raw)
  To: ltp

Hi!
I've commited last patch that I found worth to be included in the
release. With that I would like to tag the release early next week.

In other words now is your last chance to test the latest head and
report regressions and unexpected failures that happened to slip in.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-01-11 13:25     ` Cyril Hrubis
@ 2019-01-11 16:16       ` Cristian Marussi
  2019-01-14 12:43         ` Petr Vorel
  0 siblings, 1 reply; 197+ messages in thread
From: Cristian Marussi @ 2019-01-11 16:16 UTC (permalink / raw)
  To: ltp

Hi

On 11/01/2019 13:25, Cyril Hrubis wrote:
> Hi!
> I've commited last patch that I found worth to be included in the
> release. With that I would like to tag the release early next week.
> 
> In other words now is your last chance to test the latest head and
> report regressions and unexpected failures that happened to slip in.
> 

I've just tested the tip of release candidate and spotted a regression
on cgroup (since test_5 failure was exactly what a previous patch of mine
should have fixed a few weeks ago :D)

It has been introduced probably by a typo while cleaning up the final commit for:

commit 3cac1f80d87fe7f1a6631034b82683666c80fc00
Author: Cristian Marussi <cristian.marussi@arm.com>
Date:   Fri Dec 21 18:25:16 2018 +0000

    cgroup: cgroup_regression_test.sh ported to newlib

This is the fix, which I've just pushed to the ML:

http://lists.linux.it/pipermail/ltp/2019-January/010518.html

if you could pick it up in time for release next week

Thanks

Regards

Cristian

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-01-11 16:16       ` Cristian Marussi
@ 2019-01-14 12:43         ` Petr Vorel
  0 siblings, 0 replies; 197+ messages in thread
From: Petr Vorel @ 2019-01-14 12:43 UTC (permalink / raw)
  To: ltp

Hi Cyril,

> This is the fix, which I've just pushed to the ML:
> http://lists.linux.it/pipermail/ltp/2019-January/010518.html
> if you could pick it up in time for release next week
FYI: Already merged.

Kind regards,
Petr

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP release
  2023-01-24 12:47   ` Petr Vorel
@ 2023-01-24 20:58     ` Petr Vorel
  0 siblings, 0 replies; 197+ messages in thread
From: Petr Vorel @ 2023-01-24 20:58 UTC (permalink / raw)
  To: Cyril Hrubis, ltp

> Hi all,

> > Hi!
> > I did my share of pre-release testing and apart from the statvfs01 I've
> > send a patch for there rest of results looks green.

> > I also did test the runltp-ng and we fixed a few bugs there in order to
> > have a flawless experince since it will be introduced in the LTP
> > tarball. It would be great if anyone else would do so as well.

> > And given that the mailing list is mostly silent I suppose, unless
> > anybody objects, that we can freeze the git now and declare the next
> > week as pre-release testing week. With that we would be aiming for the
> > release either at Friday 27.01. or at Monday or Tuesday 29-30.01.

> I'd be for Friday (given there is SUSE hackweek since Monday).
> I'm going to do build testing for various architectures.
> I can help to tag the release and upload files (as I did last release).

> But before I'll try to fix nft01.sh -6, which is broken on newest 1.8.9:

> nft01 2 TINFO: Use nft to DROP packets from particular IP
> nft01 2 TINFO: Rule to block icmp from ::1
> nft01 2 TFAIL: nft command failed to append new rule
> Error: syntax error, unexpected junk
> 'add rule ip6 filter INPUT meta l4proto ipv6-icmp ip6 saddr ::1 counter drop'

I'm not sure, but it looks like 83604e7f ("xlate: get rid of escape_quotes")
broke the test (not sure, because xtables-nft-multi which I compiled from
iptables git, which is a symlink to ip6tables-translate, which is used here
always fail, but since 83604e7f the error message is the same as what I see on
openSUSE Tumbleweed	iputils v1.8.9).

I'm not really sure what should be changed in this line:

		$(ip${TST_IPV6}tables-translate $@ | sed 's,\\,,g')

Kind regards,
Petr

> Kind regards,
> Petr

[1] https://git.netfilter.org/iptables/commit/?id=83604e7f7327b6b3197f98b4e579a2b88a4c7356

+++ testcases/network/iptables/iptables_lib.sh
@@ -22,7 +22,7 @@ NFRUN()
 	if [ "$use_iptables" = 1 ]; then
 		ip${TST_IPV6}tables $@
 	else
-		$(ip${TST_IPV6}tables-translate $@ | sed 's,\\,,g')
+		$(ip${TST_IPV6}tables-translate $@)
 	fi
 }
 

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP release
  2023-01-20 12:16 ` Cyril Hrubis
@ 2023-01-24 12:47   ` Petr Vorel
  2023-01-24 20:58     ` Petr Vorel
  0 siblings, 1 reply; 197+ messages in thread
From: Petr Vorel @ 2023-01-24 12:47 UTC (permalink / raw)
  To: Cyril Hrubis; +Cc: ltp

Hi all,

> Hi!
> I did my share of pre-release testing and apart from the statvfs01 I've
> send a patch for there rest of results looks green.

> I also did test the runltp-ng and we fixed a few bugs there in order to
> have a flawless experince since it will be introduced in the LTP
> tarball. It would be great if anyone else would do so as well.

> And given that the mailing list is mostly silent I suppose, unless
> anybody objects, that we can freeze the git now and declare the next
> week as pre-release testing week. With that we would be aiming for the
> release either at Friday 27.01. or at Monday or Tuesday 29-30.01.

I'd be for Friday (given there is SUSE hackweek since Monday).
I'm going to do build testing for various architectures.
I can help to tag the release and upload files (as I did last release).

But before I'll try to fix nft01.sh -6, which is broken on newest 1.8.9:

nft01 2 TINFO: Use nft to DROP packets from particular IP
nft01 2 TINFO: Rule to block icmp from ::1
nft01 2 TFAIL: nft command failed to append new rule
Error: syntax error, unexpected junk
'add rule ip6 filter INPUT meta l4proto ipv6-icmp ip6 saddr ::1 counter drop'

Kind regards,
Petr

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP release
  2023-01-16 13:31 [LTP] LTP release Cyril Hrubis
  2023-01-16 15:23 ` Richard Palethorpe
@ 2023-01-20 12:16 ` Cyril Hrubis
  2023-01-24 12:47   ` Petr Vorel
  1 sibling, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2023-01-20 12:16 UTC (permalink / raw)
  To: ltp

Hi!
I did my share of pre-release testing and apart from the statvfs01 I've
send a patch for there rest of results looks green.

I also did test the runltp-ng and we fixed a few bugs there in order to
have a flawless experince since it will be introduced in the LTP
tarball. It would be great if anyone else would do so as well.

And given that the mailing list is mostly silent I suppose, unless
anybody objects, that we can freeze the git now and declare the next
week as pre-release testing week. With that we would be aiming for the
release either at Friday 27.01. or at Monday or Tuesday 29-30.01.

-- 
Cyril Hrubis
chrubis@suse.cz

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP release
  2023-01-16 15:23 ` Richard Palethorpe
  2023-01-16 16:31   ` Petr Vorel
@ 2023-01-17 11:02   ` Richard Palethorpe
  1 sibling, 0 replies; 197+ messages in thread
From: Richard Palethorpe @ 2023-01-17 11:02 UTC (permalink / raw)
  To: Cyril Hrubis; +Cc: Andrea Cervesato, ltp

Hello,

Richard Palethorpe <rpalethorpe@suse.de> writes:

> Hello,
>
> Cyril Hrubis <chrubis@suse.cz> writes:
>
>> Hi!
>> It's about the time to start preparing for the LTP January release. Well
>> we should have started at least a week ago, but my family was sick and
>> nobody else seemd to start to work on that...
>>
>> Anyways let's start with listing patches that should be considered for
>> the release, looking at patchwork the queueu is nice and short so I
>> suppose there will not be many and that we can start with pre-release
>> testing now and do a git freeze at the start of the next week. Does that
>> sound reasonable?
>>
>> Also are there any volunteers for picking up various release tasks?
>>
>> -- 
>> Cyril Hrubis
>> chrubis@suse.cz
>
> My fix for fcntl36/34 doesn't seem to fully work for fcntl36 on 32bit
> compat. Hopefully I can fix that before next week.

Actually these tests are fine. The problem is the OpenSUSE package is
broken due to the runltp-ng Makefile. So we should fix that instead.

-- 
Thank you,
Richard.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP release
  2023-01-17  4:07     ` Wei Gao via ltp
@ 2023-01-17  8:04       ` Petr Vorel
  0 siblings, 0 replies; 197+ messages in thread
From: Petr Vorel @ 2023-01-17  8:04 UTC (permalink / raw)
  To: Wei Gao; +Cc: ltp

> On Mon, Jan 16, 2023 at 05:31:53PM +0100, Petr Vorel wrote:
> > Hi Cyril, Richie, Wei,

> > > Hello,

> > > Cyril Hrubis <chrubis@suse.cz> writes:

> > > > Hi!
> > > > It's about the time to start preparing for the LTP January release. Well
> > > > we should have started at least a week ago, but my family was sick and
> > > > nobody else seemd to start to work on that...

> > Thanks for remembering. Time flies + obviously nobody set any calendar event to
> > remember the release months.

> > > > Anyways let's start with listing patches that should be considered for
> > > > the release, looking at patchwork the queueu is nice and short so I
> > > > suppose there will not be many and that we can start with pre-release
> > > > testing now and do a git freeze at the start of the next week. Does that
> > > > sound reasonable?

> > +1

> > > > Also are there any volunteers for picking up various release tasks?

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

> > > My fix for fcntl36/34 doesn't seem to fully work for fcntl36 on 32bit
> > > compat. Hopefully I can fix that before next week.

> > +1, thanks for working on it.

> > I'd like to fix tst_rhost_run.sh failing.
> > @Wei do you plan to fix it or shell I have look into it?

> @Petr

> I create following new patch today help fix tst_rhost_run.sh fail
> https://patchwork.ozlabs.org/project/ltp/patch/20230117040132.5245-1-wegao@suse.com/

> Also i suggest also merge old PATH patch together then at least we can run single test case currently.
> https://patchwork.ozlabs.org/project/ltp/patch/20230111195231.23596-1-wegao@suse.com/

I'll reply to the patches.

Kind regards,
Petr

> Info me if any further action i need take, thanks : )


> > BTW the move of testcases/kernel/containers/share/ content to testcases/lib
> > which I suggested and we got Cyril's ack [1] is trivial, but as it's just a make
> > dependency fix, it can wait after the release. The test failure is what matters
> > more.

> > Kind regards,
> > Petr

> > [1] https://lore.kernel.org/ltp/Y8UubJZcN89y77AA@yuki/

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP release
  2023-01-16 16:31   ` Petr Vorel
@ 2023-01-17  4:07     ` Wei Gao via ltp
  2023-01-17  8:04       ` Petr Vorel
  0 siblings, 1 reply; 197+ messages in thread
From: Wei Gao via ltp @ 2023-01-17  4:07 UTC (permalink / raw)
  To: Petr Vorel; +Cc: ltp

On Mon, Jan 16, 2023 at 05:31:53PM +0100, Petr Vorel wrote:
> Hi Cyril, Richie, Wei,
> 
> > Hello,
> 
> > Cyril Hrubis <chrubis@suse.cz> writes:
> 
> > > Hi!
> > > It's about the time to start preparing for the LTP January release. Well
> > > we should have started at least a week ago, but my family was sick and
> > > nobody else seemd to start to work on that...
> 
> Thanks for remembering. Time flies + obviously nobody set any calendar event to
> remember the release months.
> 
> > > Anyways let's start with listing patches that should be considered for
> > > the release, looking at patchwork the queueu is nice and short so I
> > > suppose there will not be many and that we can start with pre-release
> > > testing now and do a git freeze at the start of the next week. Does that
> > > sound reasonable?
> 
> +1
> 
> > > Also are there any volunteers for picking up various release tasks?
> 
> > > -- 
> > > Cyril Hrubis
> > > chrubis@suse.cz
> 
> > My fix for fcntl36/34 doesn't seem to fully work for fcntl36 on 32bit
> > compat. Hopefully I can fix that before next week.
> 
> +1, thanks for working on it.
> 
> I'd like to fix tst_rhost_run.sh failing.
> @Wei do you plan to fix it or shell I have look into it?

@Petr

I create following new patch today help fix tst_rhost_run.sh fail
https://patchwork.ozlabs.org/project/ltp/patch/20230117040132.5245-1-wegao@suse.com/

Also i suggest also merge old PATH patch together then at least we can run single test case currently.
https://patchwork.ozlabs.org/project/ltp/patch/20230111195231.23596-1-wegao@suse.com/

Info me if any further action i need take, thanks : )

> 
> BTW the move of testcases/kernel/containers/share/ content to testcases/lib
> which I suggested and we got Cyril's ack [1] is trivial, but as it's just a make
> dependency fix, it can wait after the release. The test failure is what matters
> more.
> 
> Kind regards,
> Petr
> 
> [1] https://lore.kernel.org/ltp/Y8UubJZcN89y77AA@yuki/

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP release
  2023-01-16 15:23 ` Richard Palethorpe
@ 2023-01-16 16:31   ` Petr Vorel
  2023-01-17  4:07     ` Wei Gao via ltp
  2023-01-17 11:02   ` Richard Palethorpe
  1 sibling, 1 reply; 197+ messages in thread
From: Petr Vorel @ 2023-01-16 16:31 UTC (permalink / raw)
  To: Richard Palethorpe; +Cc: ltp

Hi Cyril, Richie, Wei,

> Hello,

> Cyril Hrubis <chrubis@suse.cz> writes:

> > Hi!
> > It's about the time to start preparing for the LTP January release. Well
> > we should have started at least a week ago, but my family was sick and
> > nobody else seemd to start to work on that...

Thanks for remembering. Time flies + obviously nobody set any calendar event to
remember the release months.

> > Anyways let's start with listing patches that should be considered for
> > the release, looking at patchwork the queueu is nice and short so I
> > suppose there will not be many and that we can start with pre-release
> > testing now and do a git freeze at the start of the next week. Does that
> > sound reasonable?

+1

> > Also are there any volunteers for picking up various release tasks?

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

> My fix for fcntl36/34 doesn't seem to fully work for fcntl36 on 32bit
> compat. Hopefully I can fix that before next week.

+1, thanks for working on it.

I'd like to fix tst_rhost_run.sh failing.
@Wei do you plan to fix it or shell I have look into it?

BTW the move of testcases/kernel/containers/share/ content to testcases/lib
which I suggested and we got Cyril's ack [1] is trivial, but as it's just a make
dependency fix, it can wait after the release. The test failure is what matters
more.

Kind regards,
Petr

[1] https://lore.kernel.org/ltp/Y8UubJZcN89y77AA@yuki/

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP release
  2023-01-16 13:31 [LTP] LTP release Cyril Hrubis
@ 2023-01-16 15:23 ` Richard Palethorpe
  2023-01-16 16:31   ` Petr Vorel
  2023-01-17 11:02   ` Richard Palethorpe
  2023-01-20 12:16 ` Cyril Hrubis
  1 sibling, 2 replies; 197+ messages in thread
From: Richard Palethorpe @ 2023-01-16 15:23 UTC (permalink / raw)
  To: Cyril Hrubis; +Cc: ltp

Hello,

Cyril Hrubis <chrubis@suse.cz> writes:

> Hi!
> It's about the time to start preparing for the LTP January release. Well
> we should have started at least a week ago, but my family was sick and
> nobody else seemd to start to work on that...
>
> Anyways let's start with listing patches that should be considered for
> the release, looking at patchwork the queueu is nice and short so I
> suppose there will not be many and that we can start with pre-release
> testing now and do a git freeze at the start of the next week. Does that
> sound reasonable?
>
> Also are there any volunteers for picking up various release tasks?
>
> -- 
> Cyril Hrubis
> chrubis@suse.cz

My fix for fcntl36/34 doesn't seem to fully work for fcntl36 on 32bit
compat. Hopefully I can fix that before next week.

-- 
Thank you,
Richard.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
@ 2023-01-16 13:31 Cyril Hrubis
  2023-01-16 15:23 ` Richard Palethorpe
  2023-01-20 12:16 ` Cyril Hrubis
  0 siblings, 2 replies; 197+ messages in thread
From: Cyril Hrubis @ 2023-01-16 13:31 UTC (permalink / raw)
  To: ltp

Hi!
It's about the time to start preparing for the LTP January release. Well
we should have started at least a week ago, but my family was sick and
nobody else seemd to start to work on that...

Anyways let's start with listing patches that should be considered for
the release, looking at patchwork the queueu is nice and short so I
suppose there will not be many and that we can start with pre-release
testing now and do a git freeze at the start of the next week. Does that
sound reasonable?

Also are there any volunteers for picking up various release tasks?

-- 
Cyril Hrubis
chrubis@suse.cz

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2021-05-06  7:19 [LTP] LTP Release Cyril Hrubis
                   ` (4 preceding siblings ...)
  2021-05-07 16:56 ` Petr Vorel
@ 2021-05-11 11:30 ` Cyril Hrubis
  5 siblings, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2021-05-11 11:30 UTC (permalink / raw)
  To: ltp

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2021-05-10 16:37               ` Cyril Hrubis
@ 2021-05-10 17:24                 ` Petr Vorel
  0 siblings, 0 replies; 197+ messages in thread
From: Petr Vorel @ 2021-05-10 17:24 UTC (permalink / raw)
  To: ltp

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2021-05-10 15:30           ` Martin Doucha
@ 2021-05-10 16:49             ` Petr Vorel
  2021-05-10 16:37               ` Cyril Hrubis
  0 siblings, 1 reply; 197+ messages in thread
From: Petr Vorel @ 2021-05-10 16:49 UTC (permalink / raw)
  To: ltp

> 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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2021-05-10 16:49             ` Petr Vorel
@ 2021-05-10 16:37               ` Cyril Hrubis
  2021-05-10 17:24                 ` Petr Vorel
  0 siblings, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2021-05-10 16:37 UTC (permalink / raw)
  To: ltp

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2021-05-10 14:58         ` Cyril Hrubis
@ 2021-05-10 15:30           ` Martin Doucha
  2021-05-10 16:49             ` Petr Vorel
  0 siblings, 1 reply; 197+ messages in thread
From: Martin Doucha @ 2021-05-10 15:30 UTC (permalink / raw)
  To: ltp

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2021-05-10 14:47       ` Petr Vorel
@ 2021-05-10 14:58         ` Cyril Hrubis
  2021-05-10 15:30           ` Martin Doucha
  0 siblings, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2021-05-10 14:58 UTC (permalink / raw)
  To: ltp

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2021-05-10  9:11     ` Cyril Hrubis
@ 2021-05-10 14:47       ` Petr Vorel
  2021-05-10 14:58         ` Cyril Hrubis
  0 siblings, 1 reply; 197+ messages in thread
From: Petr Vorel @ 2021-05-10 14:47 UTC (permalink / raw)
  To: ltp

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2021-05-07 14:31   ` Petr Vorel
@ 2021-05-10  9:11     ` Cyril Hrubis
  2021-05-10 14:47       ` Petr Vorel
  0 siblings, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2021-05-10  9:11 UTC (permalink / raw)
  To: ltp

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2021-05-07 16:56 ` Petr Vorel
@ 2021-05-10  7:17   ` Richard Palethorpe
  0 siblings, 0 replies; 197+ messages in thread
From: Richard Palethorpe @ 2021-05-10  7:17 UTC (permalink / raw)
  To: ltp

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.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2021-05-06  7:19 [LTP] LTP Release Cyril Hrubis
                   ` (3 preceding siblings ...)
  2021-05-07  3:10 ` Li Wang
@ 2021-05-07 16:56 ` Petr Vorel
  2021-05-10  7:17   ` Richard Palethorpe
  2021-05-11 11:30 ` Cyril Hrubis
  5 siblings, 1 reply; 197+ messages in thread
From: Petr Vorel @ 2021-05-07 16:56 UTC (permalink / raw)
  To: ltp

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/

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2021-05-06 13:02 ` Petr Vorel
@ 2021-05-07 14:31   ` Petr Vorel
  2021-05-10  9:11     ` Cyril Hrubis
  0 siblings, 1 reply; 197+ messages in thread
From: Petr Vorel @ 2021-05-07 14:31 UTC (permalink / raw)
  To: ltp

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/

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2021-05-07  3:10 ` Li Wang
@ 2021-05-07 12:40   ` Cyril Hrubis
  0 siblings, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2021-05-07 12:40 UTC (permalink / raw)
  To: ltp

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2021-05-06  7:19 [LTP] LTP Release Cyril Hrubis
                   ` (2 preceding siblings ...)
  2021-05-06 15:35 ` Martin Doucha
@ 2021-05-07  3:10 ` Li Wang
  2021-05-07 12:40   ` Cyril Hrubis
  2021-05-07 16:56 ` Petr Vorel
  2021-05-11 11:30 ` Cyril Hrubis
  5 siblings, 1 reply; 197+ messages in thread
From: Li Wang @ 2021-05-07  3:10 UTC (permalink / raw)
  To: ltp

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>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2021-05-06  7:19 [LTP] LTP Release Cyril Hrubis
  2021-05-06  8:10 ` Petr Vorel
  2021-05-06 13:02 ` Petr Vorel
@ 2021-05-06 15:35 ` Martin Doucha
  2021-05-07  3:10 ` Li Wang
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 197+ messages in thread
From: Martin Doucha @ 2021-05-06 15:35 UTC (permalink / raw)
  To: ltp

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2021-05-06  7:19 [LTP] LTP Release Cyril Hrubis
  2021-05-06  8:10 ` Petr Vorel
@ 2021-05-06 13:02 ` Petr Vorel
  2021-05-07 14:31   ` Petr Vorel
  2021-05-06 15:35 ` Martin Doucha
                   ` (3 subsequent siblings)
  5 siblings, 1 reply; 197+ messages in thread
From: Petr Vorel @ 2021-05-06 13:02 UTC (permalink / raw)
  To: ltp

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2021-05-06  7:19 [LTP] LTP Release Cyril Hrubis
@ 2021-05-06  8:10 ` Petr Vorel
  2021-05-06 13:02 ` Petr Vorel
                   ` (4 subsequent siblings)
  5 siblings, 0 replies; 197+ messages in thread
From: Petr Vorel @ 2021-05-06  8:10 UTC (permalink / raw)
  To: ltp

> 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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
@ 2021-05-06  7:19 Cyril Hrubis
  2021-05-06  8:10 ` Petr Vorel
                   ` (5 more replies)
  0 siblings, 6 replies; 197+ messages in thread
From: Cyril Hrubis @ 2021-05-06  7:19 UTC (permalink / raw)
  To: ltp

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-23 12:23       ` Xiao Yang
@ 2020-09-23 12:56         ` Li Wang
  0 siblings, 0 replies; 197+ messages in thread
From: Li Wang @ 2020-09-23 12:56 UTC (permalink / raw)
  To: ltp

On Wed, Sep 23, 2020 at 8:24 PM Xiao Yang <yangx.jy@cn.fujitsu.com> wrote:

> ? 2020/9/23 14:58, Li Wang ??:
>
>
> CC' people who touched the patches maybe give a hand.
>
> On Wed, Sep 23, 2020 at 2:50 PM Li Wang <liwang@redhat.com> wrote:
>
>>
>>
>> On Wed, Sep 23, 2020 at 2:20 AM Cyril Hrubis <chrubis@suse.cz> wrote:
>>
>>> Hi!
>>> As far as I can tell I've pushed the last patch that should have been in
>>> the release just now. With that we should have a week worth of
>>> pre-release testing since we are aiming for a release at the end of the
>>> September. If you haven't tried LTP git HEAD yet, please do so now and
>>> report any problems you find.
>>>
>>
>> We still got this persistent fail on some kernels(RHEL8, kernel-v5.9-rc4):
>>
>> ---
>> send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)
>> send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)
>> send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)
>> send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)
>>
>> ---
>> fanotify10.c:404: TFAIL: group 0 (4) got event: mask 1020 (expected 1000)
>> pid=95067 fd=12
>> fanotify10.c:404: TFAIL: group 1 (4) got event: mask 1020 (expected 1000)
>> pid=95067 fd=12
>> fanotify10.c:404: TFAIL: group 2 (4) got event: mask 1020 (expected 1000)
>> pid=95067 fd=12
>> fanotify10.c:404: TFAIL: group 0 (0) got event: mask 1020 (expected 1000)
>> pid=95067 fd=12
>> fanotify10.c:404: TFAIL: group 1 (0) got event: mask 1020 (expected 1000)
>> pid=95067 fd=12
>> fanotify10.c:404: TFAIL: group 2 (0) got event: mask 1020 (expected 1000)
>> pid=95067 fd=12
>>
> Hi Li,
>
> I didn't reproduce the issue about fanotify10 on the lastest
> kernel(kernel-v5.9-rc6+):
>

Sorry for the unclear description.
The fanotify10 failed on RHEL8, I?m now trying to see if some kernel patch
missing.
And send02 failed on kernel-v5.9-rc4.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-23  6:58     ` Li Wang
  2020-09-23  9:29       ` Petr Vorel
@ 2020-09-23 12:23       ` Xiao Yang
  2020-09-23 12:56         ` Li Wang
  1 sibling, 1 reply; 197+ messages in thread
From: Xiao Yang @ 2020-09-23 12:23 UTC (permalink / raw)
  To: ltp

? 2020/9/23 14:58, Li Wang ??:
>
> CC' people who touched the patches maybe give a hand.
>
> On Wed, Sep 23, 2020 at 2:50 PM Li Wang <liwang@redhat.com 
> <mailto:liwang@redhat.com>> wrote:
>
>
>
>     On Wed, Sep 23, 2020 at 2:20 AM Cyril Hrubis <chrubis@suse.cz
>     <mailto:chrubis@suse.cz>> wrote:
>
>         Hi!
>         As far as I can tell I've pushed the last patch that should
>         have been in
>         the release just now. With that we should have a week worth of
>         pre-release testing since we are aiming for a release at the
>         end of the
>         September. If you haven't tried LTP git HEAD yet, please do so
>         now and
>         report any problems you find.
>
>
>     We still got this persistent fail on some kernels(RHEL8,
>     kernel-v5.9-rc4):
>
>     ---
>     send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)
>     send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)
>     send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)
>     send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)
>
>     ---
>     fanotify10.c:404: TFAIL: group 0 (4) got event: mask 1020
>     (expected 1000) pid=95067 fd=12
>     fanotify10.c:404: TFAIL: group 1 (4) got event: mask 1020
>     (expected 1000) pid=95067 fd=12
>     fanotify10.c:404: TFAIL: group 2 (4) got event: mask 1020
>     (expected 1000) pid=95067 fd=12
>     fanotify10.c:404: TFAIL: group 0 (0) got event: mask 1020
>     (expected 1000) pid=95067 fd=12
>     fanotify10.c:404: TFAIL: group 1 (0) got event: mask 1020
>     (expected 1000) pid=95067 fd=12
>     fanotify10.c:404: TFAIL: group 2 (0) got event: mask 1020
>     (expected 1000) pid=95067 fd=12
>
Hi Li,

I didn't reproduce the issue about fanotify10 on the lastest 
kernel(kernel-v5.9-rc6+):
-------------------------
[root@Fedora-30 fanotify]# ./fanotify10
tst_device.c:88: TINFO: Found free device 0 '/dev/loop0'
tst_mkfs.c:89: TINFO: Formatting /dev/loop0 with ext2 opts='' extra opts=''
mke2fs 1.46-WIP (20-Mar-2020)
tst_test.c:1248: TINFO: Timeout per run is 0h 05m 00s
fanotify10.c:452: TINFO: Test #0: ignore mount events created on a 
specific file
fanotify10.c:411: TPASS: group 0 (8) got event: mask 20 pid=1981 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 20 pid=1981 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 20 pid=1981 fd=15
fanotify10.c:523: TPASS: group 0 (4) with FAN_MARK_MOUNT and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 1 (4) with FAN_MARK_MOUNT and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 2 (4) with FAN_MARK_MOUNT and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 0 (0) with FAN_MARK_MOUNT and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 1 (0) with FAN_MARK_MOUNT and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 2 (0) with FAN_MARK_MOUNT and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 0 (e00) with FAN_MARK_MOUNT and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 1 (e00) with FAN_MARK_MOUNT and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 2 (e00) with FAN_MARK_MOUNT and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:452: TINFO: Test #1: ignore exec mount events created on a 
specific file
fanotify10.c:411: TPASS: group 0 (8) got event: mask 1020 pid=1983 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 1020 pid=1983 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 1020 pid=1983 fd=15
fanotify10.c:411: TPASS: group 0 (4) got event: mask 1000 pid=1983 fd=15
fanotify10.c:411: TPASS: group 1 (4) got event: mask 1000 pid=1983 fd=15
fanotify10.c:411: TPASS: group 2 (4) got event: mask 1000 pid=1983 fd=15
fanotify10.c:411: TPASS: group 0 (0) got event: mask 1000 pid=1983 fd=15
fanotify10.c:411: TPASS: group 1 (0) got event: mask 1000 pid=1983 fd=15
fanotify10.c:411: TPASS: group 2 (0) got event: mask 1000 pid=1983 fd=15
fanotify10.c:411: TPASS: group 0 (e00) got event: mask 1000 pid=1983 
fd=4294967295
fanotify10.c:411: TPASS: group 1 (e00) got event: mask 1000 pid=1983 
fd=4294967295
fanotify10.c:411: TPASS: group 2 (e00) got event: mask 1000 pid=1983 
fd=4294967295
fanotify10.c:452: TINFO: Test #2: don't ignore mount events created on 
another file
fanotify10.c:411: TPASS: group 0 (8) got event: mask 20 pid=1984 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 20 pid=1984 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 20 pid=1984 fd=15
fanotify10.c:411: TPASS: group 0 (4) got event: mask 20 pid=1984 fd=15
fanotify10.c:411: TPASS: group 1 (4) got event: mask 20 pid=1984 fd=15
fanotify10.c:411: TPASS: group 2 (4) got event: mask 20 pid=1984 fd=15
fanotify10.c:411: TPASS: group 0 (0) got event: mask 20 pid=1984 fd=15
fanotify10.c:411: TPASS: group 1 (0) got event: mask 20 pid=1984 fd=15
fanotify10.c:411: TPASS: group 2 (0) got event: mask 20 pid=1984 fd=15
fanotify10.c:411: TPASS: group 0 (e00) got event: mask 20 pid=1984 
fd=4294967295
fanotify10.c:411: TPASS: group 1 (e00) got event: mask 20 pid=1984 
fd=4294967295
fanotify10.c:411: TPASS: group 2 (e00) got event: mask 20 pid=1984 
fd=4294967295
fanotify10.c:452: TINFO: Test #3: don't ignore exec mount events created 
on another file
fanotify10.c:411: TPASS: group 0 (8) got event: mask 1020 pid=1985 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 1020 pid=1985 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 1020 pid=1985 fd=15
fanotify10.c:411: TPASS: group 0 (4) got event: mask 1020 pid=1985 fd=15
fanotify10.c:411: TPASS: group 1 (4) got event: mask 1020 pid=1985 fd=15
fanotify10.c:411: TPASS: group 2 (4) got event: mask 1020 pid=1985 fd=15
fanotify10.c:411: TPASS: group 0 (0) got event: mask 1020 pid=1985 fd=15
fanotify10.c:411: TPASS: group 1 (0) got event: mask 1020 pid=1985 fd=15
fanotify10.c:411: TPASS: group 2 (0) got event: mask 1020 pid=1985 fd=15
fanotify10.c:411: TPASS: group 0 (e00) got event: mask 1020 pid=1985 
fd=4294967295
fanotify10.c:411: TPASS: group 1 (e00) got event: mask 1020 pid=1985 
fd=4294967295
fanotify10.c:411: TPASS: group 2 (e00) got event: mask 1020 pid=1985 
fd=4294967295
fanotify10.c:452: TINFO: Test #4: ignore inode events created on a 
specific mount point
fanotify10.c:411: TPASS: group 0 (8) got event: mask 20 pid=1986 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 20 pid=1986 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 20 pid=1986 fd=15
fanotify10.c:523: TPASS: group 0 (4) with FAN_MARK_INODE and 
FAN_MARK_MOUNT ignore mask got no event
fanotify10.c:523: TPASS: group 1 (4) with FAN_MARK_INODE and 
FAN_MARK_MOUNT ignore mask got no event
fanotify10.c:523: TPASS: group 2 (4) with FAN_MARK_INODE and 
FAN_MARK_MOUNT ignore mask got no event
fanotify10.c:523: TPASS: group 0 (0) with FAN_MARK_INODE and 
FAN_MARK_MOUNT ignore mask got no event
fanotify10.c:523: TPASS: group 1 (0) with FAN_MARK_INODE and 
FAN_MARK_MOUNT ignore mask got no event
fanotify10.c:523: TPASS: group 2 (0) with FAN_MARK_INODE and 
FAN_MARK_MOUNT ignore mask got no event
fanotify10.c:523: TPASS: group 0 (e00) with FAN_MARK_INODE and 
FAN_MARK_MOUNT ignore mask got no event
fanotify10.c:523: TPASS: group 1 (e00) with FAN_MARK_INODE and 
FAN_MARK_MOUNT ignore mask got no event
fanotify10.c:523: TPASS: group 2 (e00) with FAN_MARK_INODE and 
FAN_MARK_MOUNT ignore mask got no event
fanotify10.c:452: TINFO: Test #5: ignore exec inode events created on a 
specific mount point
fanotify10.c:411: TPASS: group 0 (8) got event: mask 1020 pid=1987 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 1020 pid=1987 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 1020 pid=1987 fd=15
fanotify10.c:411: TPASS: group 0 (4) got event: mask 1000 pid=1987 fd=15
fanotify10.c:411: TPASS: group 1 (4) got event: mask 1000 pid=1987 fd=15
fanotify10.c:411: TPASS: group 2 (4) got event: mask 1000 pid=1987 fd=15
fanotify10.c:411: TPASS: group 0 (0) got event: mask 1000 pid=1987 fd=15
fanotify10.c:411: TPASS: group 1 (0) got event: mask 1000 pid=1987 fd=15
fanotify10.c:411: TPASS: group 2 (0) got event: mask 1000 pid=1987 fd=15
fanotify10.c:411: TPASS: group 0 (e00) got event: mask 1000 pid=1987 
fd=4294967295
fanotify10.c:411: TPASS: group 1 (e00) got event: mask 1000 pid=1987 
fd=4294967295
fanotify10.c:411: TPASS: group 2 (e00) got event: mask 1000 pid=1987 
fd=4294967295
fanotify10.c:452: TINFO: Test #6: don't ignore inode events created on 
another mount point
fanotify10.c:411: TPASS: group 0 (8) got event: mask 20 pid=1988 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 20 pid=1988 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 20 pid=1988 fd=15
fanotify10.c:411: TPASS: group 0 (4) got event: mask 20 pid=1988 fd=15
fanotify10.c:411: TPASS: group 1 (4) got event: mask 20 pid=1988 fd=15
fanotify10.c:411: TPASS: group 2 (4) got event: mask 20 pid=1988 fd=15
fanotify10.c:411: TPASS: group 0 (0) got event: mask 20 pid=1988 fd=15
fanotify10.c:411: TPASS: group 1 (0) got event: mask 20 pid=1988 fd=15
fanotify10.c:411: TPASS: group 2 (0) got event: mask 20 pid=1988 fd=15
fanotify10.c:411: TPASS: group 0 (e00) got event: mask 20 pid=1988 
fd=4294967295
fanotify10.c:411: TPASS: group 1 (e00) got event: mask 20 pid=1988 
fd=4294967295
fanotify10.c:411: TPASS: group 2 (e00) got event: mask 20 pid=1988 
fd=4294967295
fanotify10.c:452: TINFO: Test #7: don't ignore exec inode events created 
on another mount point
fanotify10.c:411: TPASS: group 0 (8) got event: mask 1020 pid=1989 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 1020 pid=1989 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 1020 pid=1989 fd=15
fanotify10.c:411: TPASS: group 0 (4) got event: mask 1020 pid=1989 fd=15
fanotify10.c:411: TPASS: group 1 (4) got event: mask 1020 pid=1989 fd=15
fanotify10.c:411: TPASS: group 2 (4) got event: mask 1020 pid=1989 fd=15
fanotify10.c:411: TPASS: group 0 (0) got event: mask 1020 pid=1989 fd=15
fanotify10.c:411: TPASS: group 1 (0) got event: mask 1020 pid=1989 fd=15
fanotify10.c:411: TPASS: group 2 (0) got event: mask 1020 pid=1989 fd=15
fanotify10.c:411: TPASS: group 0 (e00) got event: mask 1020 pid=1989 
fd=4294967295
fanotify10.c:411: TPASS: group 1 (e00) got event: mask 1020 pid=1989 
fd=4294967295
fanotify10.c:411: TPASS: group 2 (e00) got event: mask 1020 pid=1989 
fd=4294967295
fanotify10.c:452: TINFO: Test #8: ignore fs events created on a specific 
file
fanotify10.c:411: TPASS: group 0 (8) got event: mask 20 pid=1990 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 20 pid=1990 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 20 pid=1990 fd=15
fanotify10.c:523: TPASS: group 0 (4) with FAN_MARK_FILESYSTEM and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 1 (4) with FAN_MARK_FILESYSTEM and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 2 (4) with FAN_MARK_FILESYSTEM and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 0 (0) with FAN_MARK_FILESYSTEM and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 1 (0) with FAN_MARK_FILESYSTEM and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 2 (0) with FAN_MARK_FILESYSTEM and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 0 (e00) with FAN_MARK_FILESYSTEM and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 1 (e00) with FAN_MARK_FILESYSTEM and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 2 (e00) with FAN_MARK_FILESYSTEM and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:452: TINFO: Test #9: ignore exec fs events created on a 
specific file
fanotify10.c:411: TPASS: group 0 (8) got event: mask 1020 pid=1991 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 1020 pid=1991 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 1020 pid=1991 fd=15
fanotify10.c:411: TPASS: group 0 (4) got event: mask 1000 pid=1991 fd=15
fanotify10.c:411: TPASS: group 1 (4) got event: mask 1000 pid=1991 fd=15
fanotify10.c:411: TPASS: group 2 (4) got event: mask 1000 pid=1991 fd=15
fanotify10.c:411: TPASS: group 0 (0) got event: mask 1000 pid=1991 fd=15
fanotify10.c:411: TPASS: group 1 (0) got event: mask 1000 pid=1991 fd=15
fanotify10.c:411: TPASS: group 2 (0) got event: mask 1000 pid=1991 fd=15
fanotify10.c:411: TPASS: group 0 (e00) got event: mask 1000 pid=1991 
fd=4294967295
fanotify10.c:411: TPASS: group 1 (e00) got event: mask 1000 pid=1991 
fd=4294967295
fanotify10.c:411: TPASS: group 2 (e00) got event: mask 1000 pid=1991 
fd=4294967295
fanotify10.c:452: TINFO: Test #10: don't ignore mount events created on 
another file
fanotify10.c:411: TPASS: group 0 (8) got event: mask 20 pid=1992 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 20 pid=1992 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 20 pid=1992 fd=15
fanotify10.c:411: TPASS: group 0 (4) got event: mask 20 pid=1992 fd=15
fanotify10.c:411: TPASS: group 1 (4) got event: mask 20 pid=1992 fd=15
fanotify10.c:411: TPASS: group 2 (4) got event: mask 20 pid=1992 fd=15
fanotify10.c:411: TPASS: group 0 (0) got event: mask 20 pid=1992 fd=15
fanotify10.c:411: TPASS: group 1 (0) got event: mask 20 pid=1992 fd=15
fanotify10.c:411: TPASS: group 2 (0) got event: mask 20 pid=1992 fd=15
fanotify10.c:411: TPASS: group 0 (e00) got event: mask 20 pid=1992 
fd=4294967295
fanotify10.c:411: TPASS: group 1 (e00) got event: mask 20 pid=1992 
fd=4294967295
fanotify10.c:411: TPASS: group 2 (e00) got event: mask 20 pid=1992 
fd=4294967295
fanotify10.c:452: TINFO: Test #11: don't ignore exec mount events 
created on another file
fanotify10.c:411: TPASS: group 0 (8) got event: mask 1020 pid=1993 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 1020 pid=1993 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 1020 pid=1993 fd=15
fanotify10.c:411: TPASS: group 0 (4) got event: mask 1020 pid=1993 fd=15
fanotify10.c:411: TPASS: group 1 (4) got event: mask 1020 pid=1993 fd=15
fanotify10.c:411: TPASS: group 2 (4) got event: mask 1020 pid=1993 fd=15
fanotify10.c:411: TPASS: group 0 (0) got event: mask 1020 pid=1993 fd=15
fanotify10.c:411: TPASS: group 1 (0) got event: mask 1020 pid=1993 fd=15
fanotify10.c:411: TPASS: group 2 (0) got event: mask 1020 pid=1993 fd=15
fanotify10.c:411: TPASS: group 0 (e00) got event: mask 1020 pid=1993 
fd=4294967295
fanotify10.c:411: TPASS: group 1 (e00) got event: mask 1020 pid=1993 
fd=4294967295
fanotify10.c:411: TPASS: group 2 (e00) got event: mask 1020 pid=1993 
fd=4294967295
fanotify10.c:452: TINFO: Test #12: ignore fs events created on a 
specific mount point
fanotify10.c:411: TPASS: group 0 (8) got event: mask 20 pid=1994 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 20 pid=1994 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 20 pid=1994 fd=15
fanotify10.c:523: TPASS: group 0 (4) with FAN_MARK_FILESYSTEM and 
FAN_MARK_MOUNT ignore mask got no event
fanotify10.c:523: TPASS: group 1 (4) with FAN_MARK_FILESYSTEM and 
FAN_MARK_MOUNT ignore mask got no event
fanotify10.c:523: TPASS: group 2 (4) with FAN_MARK_FILESYSTEM and 
FAN_MARK_MOUNT ignore mask got no event
fanotify10.c:523: TPASS: group 0 (0) with FAN_MARK_FILESYSTEM and 
FAN_MARK_MOUNT ignore mask got no event
fanotify10.c:523: TPASS: group 1 (0) with FAN_MARK_FILESYSTEM and 
FAN_MARK_MOUNT ignore mask got no event
fanotify10.c:523: TPASS: group 2 (0) with FAN_MARK_FILESYSTEM and 
FAN_MARK_MOUNT ignore mask got no event
fanotify10.c:523: TPASS: group 0 (e00) with FAN_MARK_FILESYSTEM and 
FAN_MARK_MOUNT ignore mask got no event
fanotify10.c:523: TPASS: group 1 (e00) with FAN_MARK_FILESYSTEM and 
FAN_MARK_MOUNT ignore mask got no event
fanotify10.c:523: TPASS: group 2 (e00) with FAN_MARK_FILESYSTEM and 
FAN_MARK_MOUNT ignore mask got no event
fanotify10.c:452: TINFO: Test #13: ignore exec fs events created on a 
specific mount point
fanotify10.c:411: TPASS: group 0 (8) got event: mask 1020 pid=1995 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 1020 pid=1995 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 1020 pid=1995 fd=15
fanotify10.c:411: TPASS: group 0 (4) got event: mask 1000 pid=1995 fd=15
fanotify10.c:411: TPASS: group 1 (4) got event: mask 1000 pid=1995 fd=15
fanotify10.c:411: TPASS: group 2 (4) got event: mask 1000 pid=1995 fd=15
fanotify10.c:411: TPASS: group 0 (0) got event: mask 1000 pid=1995 fd=15
fanotify10.c:411: TPASS: group 1 (0) got event: mask 1000 pid=1995 fd=15
fanotify10.c:411: TPASS: group 2 (0) got event: mask 1000 pid=1995 fd=15
fanotify10.c:411: TPASS: group 0 (e00) got event: mask 1000 pid=1995 
fd=4294967295
fanotify10.c:411: TPASS: group 1 (e00) got event: mask 1000 pid=1995 
fd=4294967295
fanotify10.c:411: TPASS: group 2 (e00) got event: mask 1000 pid=1995 
fd=4294967295
fanotify10.c:452: TINFO: Test #14: don't ignore fs events created on 
another mount point
fanotify10.c:411: TPASS: group 0 (8) got event: mask 20 pid=1996 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 20 pid=1996 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 20 pid=1996 fd=15
fanotify10.c:411: TPASS: group 0 (4) got event: mask 20 pid=1996 fd=15
fanotify10.c:411: TPASS: group 1 (4) got event: mask 20 pid=1996 fd=15
fanotify10.c:411: TPASS: group 2 (4) got event: mask 20 pid=1996 fd=15
fanotify10.c:411: TPASS: group 0 (0) got event: mask 20 pid=1996 fd=15
fanotify10.c:411: TPASS: group 1 (0) got event: mask 20 pid=1996 fd=15
fanotify10.c:411: TPASS: group 2 (0) got event: mask 20 pid=1996 fd=15
fanotify10.c:411: TPASS: group 0 (e00) got event: mask 20 pid=1996 
fd=4294967295
fanotify10.c:411: TPASS: group 1 (e00) got event: mask 20 pid=1996 
fd=4294967295
fanotify10.c:411: TPASS: group 2 (e00) got event: mask 20 pid=1996 
fd=4294967295
fanotify10.c:452: TINFO: Test #15: don't ignore exec fs events created 
on another mount point
fanotify10.c:411: TPASS: group 0 (8) got event: mask 1020 pid=1997 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 1020 pid=1997 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 1020 pid=1997 fd=15
fanotify10.c:411: TPASS: group 0 (4) got event: mask 1020 pid=1997 fd=15
fanotify10.c:411: TPASS: group 1 (4) got event: mask 1020 pid=1997 fd=15
fanotify10.c:411: TPASS: group 2 (4) got event: mask 1020 pid=1997 fd=15
fanotify10.c:411: TPASS: group 0 (0) got event: mask 1020 pid=1997 fd=15
fanotify10.c:411: TPASS: group 1 (0) got event: mask 1020 pid=1997 fd=15
fanotify10.c:411: TPASS: group 2 (0) got event: mask 1020 pid=1997 fd=15
fanotify10.c:411: TPASS: group 0 (e00) got event: mask 1020 pid=1997 
fd=4294967295
fanotify10.c:411: TPASS: group 1 (e00) got event: mask 1020 pid=1997 
fd=4294967295
fanotify10.c:411: TPASS: group 2 (e00) got event: mask 1020 pid=1997 
fd=4294967295
fanotify10.c:452: TINFO: Test #16: ignore child exec events created on a 
specific mount point
fanotify10.c:411: TPASS: group 0 (8) got event: mask 1020 pid=1998 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 1020 pid=1998 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 1020 pid=1998 fd=15
fanotify10.c:411: TPASS: group 0 (4) got event: mask 1000 pid=1998 fd=15
fanotify10.c:411: TPASS: group 1 (4) got event: mask 1000 pid=1998 fd=15
fanotify10.c:411: TPASS: group 2 (4) got event: mask 1000 pid=1998 fd=15
fanotify10.c:411: TPASS: group 0 (0) got event: mask 1000 pid=1998 fd=15
fanotify10.c:411: TPASS: group 1 (0) got event: mask 1000 pid=1998 fd=15
fanotify10.c:411: TPASS: group 2 (0) got event: mask 1000 pid=1998 fd=15
fanotify10.c:411: TPASS: group 0 (e00) got event: mask 1000 pid=1998 
fd=4294967295
fanotify10.c:411: TPASS: group 1 (e00) got event: mask 1000 pid=1998 
fd=4294967295
fanotify10.c:411: TPASS: group 2 (e00) got event: mask 1000 pid=1998 
fd=4294967295
fanotify10.c:452: TINFO: Test #17: ignore events on children of 
directory created on a specific file
fanotify10.c:411: TPASS: group 0 (8) got event: mask 20 pid=1999 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 20 pid=1999 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 20 pid=1999 fd=15
fanotify10.c:523: TPASS: group 0 (4) with FAN_MARK_INODE and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 1 (4) with FAN_MARK_INODE and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 2 (4) with FAN_MARK_INODE and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 0 (0) with FAN_MARK_INODE and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 1 (0) with FAN_MARK_INODE and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 2 (0) with FAN_MARK_INODE and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 0 (e00) with FAN_MARK_INODE and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 1 (e00) with FAN_MARK_INODE and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 2 (e00) with FAN_MARK_INODE and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:452: TINFO: Test #18: ignore events on file created inside 
a parent watching children
fanotify10.c:411: TPASS: group 0 (8) got event: mask 20 pid=2000 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 20 pid=2000 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 20 pid=2000 fd=15
fanotify10.c:523: TPASS: group 0 (4) with FAN_MARK_INODE and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 1 (4) with FAN_MARK_INODE and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 2 (4) with FAN_MARK_INODE and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 0 (0) with FAN_MARK_INODE and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 1 (0) with FAN_MARK_INODE and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 2 (0) with FAN_MARK_INODE and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 0 (e00) with FAN_MARK_INODE and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 1 (e00) with FAN_MARK_INODE and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 2 (e00) with FAN_MARK_INODE and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:452: TINFO: Test #19: don't ignore events on file created 
inside a parent not watching children
fanotify10.c:411: TPASS: group 0 (8) got event: mask 20 pid=2001 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 20 pid=2001 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 20 pid=2001 fd=15
fanotify10.c:411: TPASS: group 0 (4) got event: mask 20 pid=2001 fd=15
fanotify10.c:411: TPASS: group 1 (4) got event: mask 20 pid=2001 fd=15
fanotify10.c:411: TPASS: group 2 (4) got event: mask 20 pid=2001 fd=15
fanotify10.c:411: TPASS: group 0 (0) got event: mask 20 pid=2001 fd=15
fanotify10.c:411: TPASS: group 1 (0) got event: mask 20 pid=2001 fd=15
fanotify10.c:411: TPASS: group 2 (0) got event: mask 20 pid=2001 fd=15
fanotify10.c:411: TPASS: group 0 (e00) got event: mask 20 pid=2001 
fd=4294967295
fanotify10.c:411: TPASS: group 1 (e00) got event: mask 20 pid=2001 
fd=4294967295
fanotify10.c:411: TPASS: group 2 (e00) got event: mask 20 pid=2001 
fd=4294967295
fanotify10.c:452: TINFO: Test #20: ignore mount events created inside a 
parent watching children
fanotify10.c:411: TPASS: group 0 (8) got event: mask 20 pid=2002 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 20 pid=2002 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 20 pid=2002 fd=15
fanotify10.c:523: TPASS: group 0 (4) with FAN_MARK_MOUNT and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 1 (4) with FAN_MARK_MOUNT and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 2 (4) with FAN_MARK_MOUNT and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 0 (0) with FAN_MARK_MOUNT and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 1 (0) with FAN_MARK_MOUNT and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 2 (0) with FAN_MARK_MOUNT and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 0 (e00) with FAN_MARK_MOUNT and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 1 (e00) with FAN_MARK_MOUNT and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 2 (e00) with FAN_MARK_MOUNT and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:452: TINFO: Test #21: don't ignore mount events created 
inside a parent not watching children
fanotify10.c:411: TPASS: group 0 (8) got event: mask 20 pid=2003 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 20 pid=2003 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 20 pid=2003 fd=15
fanotify10.c:411: TPASS: group 0 (4) got event: mask 20 pid=2003 fd=15
fanotify10.c:411: TPASS: group 1 (4) got event: mask 20 pid=2003 fd=15
fanotify10.c:411: TPASS: group 2 (4) got event: mask 20 pid=2003 fd=15
fanotify10.c:411: TPASS: group 0 (0) got event: mask 20 pid=2003 fd=15
fanotify10.c:411: TPASS: group 1 (0) got event: mask 20 pid=2003 fd=15
fanotify10.c:411: TPASS: group 2 (0) got event: mask 20 pid=2003 fd=15
fanotify10.c:411: TPASS: group 0 (e00) got event: mask 20 pid=2003 
fd=4294967295
fanotify10.c:411: TPASS: group 1 (e00) got event: mask 20 pid=2003 
fd=4294967295
fanotify10.c:411: TPASS: group 2 (e00) got event: mask 20 pid=2003 
fd=4294967295
fanotify10.c:452: TINFO: Test #22: ignore fs events created inside a 
parent watching children
fanotify10.c:411: TPASS: group 0 (8) got event: mask 20 pid=2004 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 20 pid=2004 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 20 pid=2004 fd=15
fanotify10.c:523: TPASS: group 0 (4) with FAN_MARK_FILESYSTEM and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 1 (4) with FAN_MARK_FILESYSTEM and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 2 (4) with FAN_MARK_FILESYSTEM and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 0 (0) with FAN_MARK_FILESYSTEM and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 1 (0) with FAN_MARK_FILESYSTEM and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 2 (0) with FAN_MARK_FILESYSTEM and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 0 (e00) with FAN_MARK_FILESYSTEM and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 1 (e00) with FAN_MARK_FILESYSTEM and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:523: TPASS: group 2 (e00) with FAN_MARK_FILESYSTEM and 
FAN_MARK_INODE ignore mask got no event
fanotify10.c:452: TINFO: Test #23: don't ignore fs events created inside 
a parent not watching children
fanotify10.c:411: TPASS: group 0 (8) got event: mask 20 pid=2005 fd=15
fanotify10.c:411: TPASS: group 1 (8) got event: mask 20 pid=2005 fd=15
fanotify10.c:411: TPASS: group 2 (8) got event: mask 20 pid=2005 fd=15
fanotify10.c:411: TPASS: group 0 (4) got event: mask 20 pid=2005 fd=15
fanotify10.c:411: TPASS: group 1 (4) got event: mask 20 pid=2005 fd=15
fanotify10.c:411: TPASS: group 2 (4) got event: mask 20 pid=2005 fd=15
fanotify10.c:411: TPASS: group 0 (0) got event: mask 20 pid=2005 fd=15
fanotify10.c:411: TPASS: group 1 (0) got event: mask 20 pid=2005 fd=15
fanotify10.c:411: TPASS: group 2 (0) got event: mask 20 pid=2005 fd=15
fanotify10.c:411: TPASS: group 0 (e00) got event: mask 20 pid=2005 
fd=4294967295
fanotify10.c:411: TPASS: group 1 (e00) got event: mask 20 pid=2005 
fd=4294967295
fanotify10.c:411: TPASS: group 2 (e00) got event: mask 20 pid=2005 
fd=4294967295

Summary:
passed   288
failed   0
skipped  0
warnings 0
-------------------------
Is the issue fixed recently? :-)

Best Regards,
Xiao Yang
>
>
>     ---
>     recvmmsg01.c:86:9: error: request for member ?type? in something
>     not a structure or union
>       timeout.type = tv->ts_type;
>
>     Otherwise, the latest LTP test good from my side(RHEL8,
>     mainline-kernel).
>
>     -- 
>     Regards,
>     Li Wang
>
>
>
> -- 
> Regards,
> Li Wang
>
>
>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20200923/dc403799/attachment-0001.htm>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-23  9:29       ` Petr Vorel
@ 2020-09-23  9:42         ` Xiao Yang
  0 siblings, 0 replies; 197+ messages in thread
From: Xiao Yang @ 2020-09-23  9:42 UTC (permalink / raw)
  To: ltp

? 2020/9/23 17:29, Petr Vorel ??:
> Hi Li,
>
>> CC' people who touched the patches maybe give a hand.
> +1
>
>> On Wed, Sep 23, 2020 at 2:50 PM Li Wang<liwang@redhat.com>  wrote:
>>> On Wed, Sep 23, 2020 at 2:20 AM Cyril Hrubis<chrubis@suse.cz>  wrote:
>>>> Hi!
>>>> As far as I can tell I've pushed the last patch that should have been in
>>>> the release just now. With that we should have a week worth of
>>>> pre-release testing since we are aiming for a release at the end of the
>>>> September. If you haven't tried LTP git HEAD yet, please do so now and
>>>> report any problems you find.
>
>>> We still got this persistent fail on some kernels(RHEL8, kernel-v5.9-rc4):
>>> ---
>>> send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)
>>> send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)
>>> send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)
>>> send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)
> This is working on openSUSE kernel 5.9.0-rc3. I haven't checked whether there
> are some special patches or whether there is a regression in rc4.
>
>>> ---
>>> fanotify10.c:404: TFAIL: group 0 (4) got event: mask 1020 (expected 1000)
>>> pid=95067 fd=12
>>> fanotify10.c:404: TFAIL: group 1 (4) got event: mask 1020 (expected 1000)
>>> pid=95067 fd=12
>>> fanotify10.c:404: TFAIL: group 2 (4) got event: mask 1020 (expected 1000)
>>> pid=95067 fd=12
>>> fanotify10.c:404: TFAIL: group 0 (0) got event: mask 1020 (expected 1000)
>>> pid=95067 fd=12
>>> fanotify10.c:404: TFAIL: group 1 (0) got event: mask 1020 (expected 1000)
>>> pid=95067 fd=12
>>> fanotify10.c:404: TFAIL: group 2 (0) got event: mask 1020 (expected 1000)
>>> pid=95067 fd=12
> Again, working on openSUSE kernel 5.9.0-rc3.
>
>>> ---
>>> recvmmsg01.c:86:9: error: request for member ?type? in something not a
>>> structure or union
>>>    timeout.type = tv->ts_type;
> Yes, 135af8ededd4d74d32f3322801fbab1f732a259a added in recvmmsg01 broke build:
> https://travis-ci.org/github/linux-test-project/ltp/builds/729394877
> (this build is for sendto03 - next commit, but that's ok)
>
> Having a look into it.
Hi Petr, Li

I sent a patch to fix the compiler error after a quick look:
http://lists.linux.it/pipermail/ltp/2020-September/019060.html

Thanks,
Xiao Yang
>>> Otherwise, the latest LTP test good from my side(RHEL8, mainline-kernel).
> Kind regards,
> Petr
>




^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-23  6:58     ` Li Wang
@ 2020-09-23  9:29       ` Petr Vorel
  2020-09-23  9:42         ` Xiao Yang
  2020-09-23 12:23       ` Xiao Yang
  1 sibling, 1 reply; 197+ messages in thread
From: Petr Vorel @ 2020-09-23  9:29 UTC (permalink / raw)
  To: ltp

Hi Li,

> CC' people who touched the patches maybe give a hand.
+1

> On Wed, Sep 23, 2020 at 2:50 PM Li Wang <liwang@redhat.com> wrote:

> > On Wed, Sep 23, 2020 at 2:20 AM Cyril Hrubis <chrubis@suse.cz> wrote:

> >> Hi!
> >> As far as I can tell I've pushed the last patch that should have been in
> >> the release just now. With that we should have a week worth of
> >> pre-release testing since we are aiming for a release at the end of the
> >> September. If you haven't tried LTP git HEAD yet, please do so now and
> >> report any problems you find.


> > We still got this persistent fail on some kernels(RHEL8, kernel-v5.9-rc4):

> > ---
> > send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)
> > send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)
> > send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)
> > send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)
This is working on openSUSE kernel 5.9.0-rc3. I haven't checked whether there
are some special patches or whether there is a regression in rc4.

> > ---
> > fanotify10.c:404: TFAIL: group 0 (4) got event: mask 1020 (expected 1000)
> > pid=95067 fd=12
> > fanotify10.c:404: TFAIL: group 1 (4) got event: mask 1020 (expected 1000)
> > pid=95067 fd=12
> > fanotify10.c:404: TFAIL: group 2 (4) got event: mask 1020 (expected 1000)
> > pid=95067 fd=12
> > fanotify10.c:404: TFAIL: group 0 (0) got event: mask 1020 (expected 1000)
> > pid=95067 fd=12
> > fanotify10.c:404: TFAIL: group 1 (0) got event: mask 1020 (expected 1000)
> > pid=95067 fd=12
> > fanotify10.c:404: TFAIL: group 2 (0) got event: mask 1020 (expected 1000)
> > pid=95067 fd=12
Again, working on openSUSE kernel 5.9.0-rc3.

> > ---
> > recvmmsg01.c:86:9: error: request for member ?type? in something not a
> > structure or union
> >   timeout.type = tv->ts_type;
Yes, 135af8ededd4d74d32f3322801fbab1f732a259a added in recvmmsg01 broke build:
https://travis-ci.org/github/linux-test-project/ltp/builds/729394877
(this build is for sendto03 - next commit, but that's ok)

Having a look into it.

> > Otherwise, the latest LTP test good from my side(RHEL8, mainline-kernel).

Kind regards,
Petr

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-23  6:50   ` Li Wang
@ 2020-09-23  6:58     ` Li Wang
  2020-09-23  9:29       ` Petr Vorel
  2020-09-23 12:23       ` Xiao Yang
  0 siblings, 2 replies; 197+ messages in thread
From: Li Wang @ 2020-09-23  6:58 UTC (permalink / raw)
  To: ltp

CC' people who touched the patches maybe give a hand.

On Wed, Sep 23, 2020 at 2:50 PM Li Wang <liwang@redhat.com> wrote:

>
>
> On Wed, Sep 23, 2020 at 2:20 AM Cyril Hrubis <chrubis@suse.cz> wrote:
>
>> Hi!
>> As far as I can tell I've pushed the last patch that should have been in
>> the release just now. With that we should have a week worth of
>> pre-release testing since we are aiming for a release at the end of the
>> September. If you haven't tried LTP git HEAD yet, please do so now and
>> report any problems you find.
>>
>
> We still got this persistent fail on some kernels(RHEL8, kernel-v5.9-rc4):
>
> ---
> send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)
> send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)
> send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)
> send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)
>
> ---
> fanotify10.c:404: TFAIL: group 0 (4) got event: mask 1020 (expected 1000)
> pid=95067 fd=12
> fanotify10.c:404: TFAIL: group 1 (4) got event: mask 1020 (expected 1000)
> pid=95067 fd=12
> fanotify10.c:404: TFAIL: group 2 (4) got event: mask 1020 (expected 1000)
> pid=95067 fd=12
> fanotify10.c:404: TFAIL: group 0 (0) got event: mask 1020 (expected 1000)
> pid=95067 fd=12
> fanotify10.c:404: TFAIL: group 1 (0) got event: mask 1020 (expected 1000)
> pid=95067 fd=12
> fanotify10.c:404: TFAIL: group 2 (0) got event: mask 1020 (expected 1000)
> pid=95067 fd=12
>
> ---
> recvmmsg01.c:86:9: error: request for member ?type? in something not a
> structure or union
>   timeout.type = tv->ts_type;
>
> Otherwise, the latest LTP test good from my side(RHEL8, mainline-kernel).
>
> --
> Regards,
> Li Wang
>


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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-22 18:21 ` Cyril Hrubis
@ 2020-09-23  6:50   ` Li Wang
  2020-09-23  6:58     ` Li Wang
  0 siblings, 1 reply; 197+ messages in thread
From: Li Wang @ 2020-09-23  6:50 UTC (permalink / raw)
  To: ltp

On Wed, Sep 23, 2020 at 2:20 AM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> As far as I can tell I've pushed the last patch that should have been in
> the release just now. With that we should have a week worth of
> pre-release testing since we are aiming for a release at the end of the
> September. If you haven't tried LTP git HEAD yet, please do so now and
> report any problems you find.
>

We still got this persistent fail on some kernels(RHEL8, kernel-v5.9-rc4):

---
send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)
send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)
send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)
send02.c:86: FAIL: recv() error: EAGAIN/EWOULDBLOCK (11)

---
fanotify10.c:404: TFAIL: group 0 (4) got event: mask 1020 (expected 1000)
pid=95067 fd=12
fanotify10.c:404: TFAIL: group 1 (4) got event: mask 1020 (expected 1000)
pid=95067 fd=12
fanotify10.c:404: TFAIL: group 2 (4) got event: mask 1020 (expected 1000)
pid=95067 fd=12
fanotify10.c:404: TFAIL: group 0 (0) got event: mask 1020 (expected 1000)
pid=95067 fd=12
fanotify10.c:404: TFAIL: group 1 (0) got event: mask 1020 (expected 1000)
pid=95067 fd=12
fanotify10.c:404: TFAIL: group 2 (0) got event: mask 1020 (expected 1000)
pid=95067 fd=12

---
recvmmsg01.c:86:9: error: request for member ?type? in something not a
structure or union
  timeout.type = tv->ts_type;

Otherwise, the latest LTP test good from my side(RHEL8, mainline-kernel).

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-08  7:31 [LTP] LTP release Cyril Hrubis
                   ` (3 preceding siblings ...)
  2020-09-10  8:45 ` Petr Vorel
@ 2020-09-22 18:21 ` Cyril Hrubis
  2020-09-23  6:50   ` Li Wang
  4 siblings, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2020-09-22 18:21 UTC (permalink / raw)
  To: ltp

Hi!
As far as I can tell I've pushed the last patch that should have been in
the release just now. With that we should have a week worth of
pre-release testing since we are aiming for a release at the end of the
September. If you haven't tried LTP git HEAD yet, please do so now and
report any problems you find.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-18 14:57       ` Cyril Hrubis
@ 2020-09-21 18:04         ` Bird, Tim
  0 siblings, 0 replies; 197+ messages in thread
From: Bird, Tim @ 2020-09-21 18:04 UTC (permalink / raw)
  To: ltp

Just to finish answering questions...

> -----Original Message-----
> From: Cyril Hrubis <chrubis@suse.cz>
> 
> > Do you have a preferred name for the runtest file?  My proposal, just off the top
> > of my head, is: "ltp-selftest-quick", but I'm open to other suggestions.
> 
> Maybe we should call it smoketest, but I'm okay selftest as well.

I'm fine with "smoketest".

...
> >
> > This takes about 5 seconds on one of my test machines.
> 
> So I will add a network test to the set and push that before a patch
> that removes quickhit.
> 
> It would be nice to have the outliners, but that is a bit more
> complicated change, so I would like to add these after a release, is
> that okay?

Yes.  I think that's actually better.  I think a simple change now
is good.  I'd like to think some more about whether it would be good to
add things that misbehave to smoketest, or if they should be put into
a separate selftest group.  My inclination is that a smoketest should really
just be a super-quick check that should work unless something fundamental
is broken, while selftest should try as many things as possible, including weird
stuff and corner cases, to actually test specific features of runtest handling.

I'm satisfied with the current smoketest content.

> 
> > P.S. Maybe, if you're moving away from runltp and ltp-pan, it's a little late to be
> > adding some selftests to make sure they work correctly.  But Fuego is using them.
> > I don't know what other frameworks use when they invoke LTP to perform
> > tests.
> 
> I do expect that we will have ltp-pan included for compatibility reasons
> at least for a year or two once the replacement would be in place
> anyways, so having a smoketest wouldn't harm at all.
Sounds good.


^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-14 22:30     ` Bird, Tim
  2020-09-15  5:28       ` Petr Vorel
@ 2020-09-18 14:57       ` Cyril Hrubis
  2020-09-21 18:04         ` Bird, Tim
  1 sibling, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2020-09-18 14:57 UTC (permalink / raw)
  To: ltp

Hi!
> I don't think that it should be very many.  Otherwise, people will get
> the idea that it is useful for actual device testing. ;-)
> 
> The current 'quickhit' runtest file has 107 tests.  With the exception of
> qmm01 (which calls mmap001 with '-n 1') and a bunch of tests that do sub-tests
> of symlink01 (12 of them), the remaining test definitions
> just consist of the test name and the test executable (with the same names).
> I only see binary programs - no tests using shell scripts.  So there's really not much variety
> here.
> 
> Apparently a pipe is allowed in the command invocation line for a test, but there's only
> one example of this in all of the runtests, in syscalls:
> splice02 seq 1 2000 | splice02

Actually the logic in LTP pan is:

* If the command part is single string the test is executed by execve()

* Otherwise it's passed as a command to run to /bin/sh

I'm not sure it we would want to retain that behaivor for a future
though.

> Really, as an infrastructure test, I only need to run a few testcases to validate that Fuego's
> plumbing around runltp (and ltp-pan) works properly.  And it would be nice if
> the run was very short, so I could do the check quickly.
> 
> Do you want me to create a runtest for a framework/LTP integration test, by picking a
> few different "representative" tests, as a replacement for quickhit?
> 
> IMHO, the selected tests should behave the same on all possible systems, to avoid
> getting results that are inconsistent due to the system under test, rather than a
> problem with the integration between the framework and LTP.
> 
> Should I add some outlier cases:
>  - something that times out
>  - something that always fails
>  - tests that return TBROK, TCONF, TWARN, etc.
>  - something where the command doesn't exist
> 
> This would be helpful for checking that my parsing for different results works.
> 
> Do you have a preferred name for the runtest file?  My proposal, just off the top
> of my head, is: "ltp-selftest-quick", but I'm open to other suggestions.

Maybe we should call it smoketest, but I'm okay selftest as well.

> I'm also open to suggestions for possible tests.  I'd like a shell script command
> to add to the list of binary programs.  Here is what I've chosen so far:
> access01 access01
> chdir01 chdir01
> fork01 fork01
> time01 time01
> wait02 wait02
> write01 write01
> symlink01 symlink01
> stat04 symlink01 -T stat04
> utime01A symlink01 -T utime01
> rename01A symlink01 -T rename01
> splice02 seq 1 20 | splice02
> 
> This takes about 5 seconds on one of my test machines.

So I will add a network test to the set and push that before a patch
that removes quickhit.

It would be nice to have the outliners, but that is a bit more
complicated change, so I would like to add these after a release, is
that okay?

> P.S. Maybe, if you're moving away from runltp and ltp-pan, it's a little late to be
> adding some selftests to make sure they work correctly.  But Fuego is using them.
> I don't know what other frameworks use when they invoke LTP to perform
> tests.

I do expect that we will have ltp-pan included for compatibility reasons
at least for a year or two once the replacement would be in place
anyways, so having a smoketest wouldn't harm at all.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-14 17:51                     ` Bird, Tim
  2020-09-15  1:18                       ` Cixi Geng
@ 2020-09-15  9:59                       ` Cyril Hrubis
  1 sibling, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2020-09-15  9:59 UTC (permalink / raw)
  To: ltp

Hi!
> > Can we please postpone it a little bit again? I've been talking to Tim
> > Bird recenlty and he is interesting in helping to shape the interface so
> > better that it fits into existing hardware labs.
> 
> I'm very interested in this work, and how to integrate it with 
> external test frameworks that manage lab equipment (and may
> need to communicate test parameters to tests).
> 
> I'm not sure the best way to proceed.  I reviewed the device-discovery
> code on patchworks, but I'm not sure I understand the anticipated flow of
> control between the LTP test, the device discovery part, and the test
> framework.
> 
> I know you're busy with the LTP release, so I'm not sure this is the best
> time to open up a big thread asking a lot of questions about device discovery
> or describing my own proposal for this - to work towards harmonizing the two.
> 
> But I'm keen on following up on this in the short term (next 4 weeks or so).
> I'm giving a talk at Open Source Summit Europe the end of October,
> where I'll be talking about lab management APIs, and this dovetails
> into that work.
> 
> Let me know when would be a good time to try to hash this out.

I guess that I can allocate some time between pre-release testing that
will happen soon after we freeze the git.

Let me just dump what I have in mind, I guess that the proof-of-concept
and the potential directions will be easier to understand with a few
hints.

Each hardware type has a specific name that identifies it, in a case of
serial port the test requires "UART_RX" and "UART_TX" which defines an
UART loop. In a case of i2c EEPROM that would probably be
"I2C_EEPROM_ADDR" and "I2C_EEPROM_BUS" etc. This is what is going to be
used to query the lab mamagenent software and the reply would be a list
of suitable devices along with their capabilities. In a case of UART it
may be declaring supported speeds, if hardware flow is supported etc. In
a case of EEPROM it will add a device size along with the bus and
address.

The interface to the lab mamagement software was choosen to be an
executable, in the simplest cases it could be just a shell script that
enumerates all unused serial ports, in more complex cases it may connect
to a REST API on a lab management server and get the reply from there.

Once the hardware has been discovered the test will iterate over the
list of suitable devices and do a testrun for each of these. But since
some hardware needs to be possibly reserved/freed and reconfigured there
has to be hooks for that, which would be probably executables again.

The proof-of-concept that I wrote was quite simple, it includes a code
in the LTP test library that can loop over a list of available devices
returned by the discovery script and a sample empty script where the
hardware discovery code should be put into along with a UART test that
uses all that newly added functionality. There are a few open problems
with the current code though, the parameters are passed to the test via
shell variables, which is not going to work well for a more structured
data. Maybe the discovery script should return JSON which would be
translated by the shell library into a command line parameters.

Something as:

{
  "uart_tx": "/dev/ttyS0",
  "uart_rx": "/dev/ttyS1",
  "speeds": [
     "9600",
     "19200",
  ],
  "hwflow": [
   true,
   false
  ],
  "reconfigure": "/usr/bin/lab_reconfigure --connect-uart /dev/ttyS0 /dev/ttyS1"
},

Which would result in running:

	/usr/bin/lab_reconfigure --connect-uart /dev/ttyS0 /dev/ttyS1
	/opt/ltp/testcases/bin/uart01 --uart_tx "/dev/ttyS0" --uart_rx "/dev/ttyS1" --speed 9600 --hwflow true
	/opt/ltp/testcases/bin/uart01 --uart_tx "/dev/ttyS0" --uart_rx "/dev/ttyS1" --speed 9600 --hwflow false
	/opt/ltp/testcases/bin/uart01 --uart_tx "/dev/ttyS0" --uart_rx "/dev/ttyS1" --speed 19200 --hwflow true
	/opt/ltp/testcases/bin/uart01 --uart_tx "/dev/ttyS0" --uart_rx "/dev/ttyS1" --speed 19200 --hwflow false

And the test would only need to declare that it requires "UART_LOOP" or
something like that.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-14 22:30     ` Bird, Tim
@ 2020-09-15  5:28       ` Petr Vorel
  2020-09-18 14:57       ` Cyril Hrubis
  1 sibling, 0 replies; 197+ messages in thread
From: Petr Vorel @ 2020-09-15  5:28 UTC (permalink / raw)
  To: ltp

Hi Tim, Cyril,

> I'm also open to suggestions for possible tests.  I'd like a shell script command
> to add to the list of binary programs.  Here is what I've chosen so far:
> access01 access01
> chdir01 chdir01
> fork01 fork01
> time01 time01
> wait02 wait02
> write01 write01
> symlink01 symlink01
> stat04 symlink01 -T stat04
> utime01A symlink01 -T utime01
> rename01A symlink01 -T rename01
> splice02 seq 1 20 | splice02
Could we please add at least one network test program?
e.g. route tests with netlink also uses shell API and it's really quick (real
time 0m0,687s):
route6-change-netlink-dst route-change-netlink-dst.sh -6


> This takes about 5 seconds on one of my test machines.
+1

>  -- Tim

> P.S. Maybe, if you're moving away from runltp and ltp-pan, it's a little late to be
> adding some selftests to make sure they work correctly.  But Fuego is using them.
> I don't know what other frameworks use when they invoke LTP to perform
> tests.

> P.P.S How come some tests produce TPASS and some produce just PASS?
Legacy C API and shell API (both legacy and new) add T (i.e. TPASS), new C API
don't add it (i.e. PASS). It's a minor detail we could fix that.

Kind regards,
Petr

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-14 17:51                     ` Bird, Tim
@ 2020-09-15  1:18                       ` Cixi Geng
  2020-09-15  9:59                       ` Cyril Hrubis
  1 sibling, 0 replies; 197+ messages in thread
From: Cixi Geng @ 2020-09-15  1:18 UTC (permalink / raw)
  To: ltp

Thanks Bird and Cyril,  I will be waiting for work to start this work
as soon as your hava the time
to guide me
If there have anything to do before it, just tell me.

Bird, Tim <Tim.Bird@sony.com> ?2020?9?15??? ??1:51???
>
> > -----Original Message-----
> > From: Cyril Hrubis
> >
> > Hi!
> > > Can we merge the uart device driver testcase and the device-discover
> > > framework ???
> >
> > Can we please postpone it a little bit again? I've been talking to Tim
> > Bird recenlty and he is interesting in helping to shape the interface so
> > better that it fits into existing hardware labs.
>
> I'm very interested in this work, and how to integrate it with
> external test frameworks that manage lab equipment (and may
> need to communicate test parameters to tests).
>
> I'm not sure the best way to proceed.  I reviewed the device-discovery
> code on patchworks, but I'm not sure I understand the anticipated flow of
> control between the LTP test, the device discovery part, and the test
> framework.
>
> I know you're busy with the LTP release, so I'm not sure this is the best
> time to open up a big thread asking a lot of questions about device discovery
> or describing my own proposal for this - to work towards harmonizing the two.
>
> But I'm keen on following up on this in the short term (next 4 weeks or so).
> I'm giving a talk at Open Source Summit Europe the end of October,
> where I'll be talking about lab management APIs, and this dovetails
> into that work.
>
> Let me know when would be a good time to try to hash this out.
>  -- Tim
>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-14 11:15   ` Cyril Hrubis
@ 2020-09-14 22:30     ` Bird, Tim
  2020-09-15  5:28       ` Petr Vorel
  2020-09-18 14:57       ` Cyril Hrubis
  0 siblings, 2 replies; 197+ messages in thread
From: Bird, Tim @ 2020-09-14 22:30 UTC (permalink / raw)
  To: ltp



> -----Original Message-----
> From: Cyril Hrubis <chrubis@suse.cz>
> 
> Hi!
> > > What else should go in?
> > How about removing runtest/quickhit?
> > https://patchwork.ozlabs.org/project/ltp/patch/20200831094617.7764-1-chrubis@suse.cz/
> 
> I guess that we can do that if we replace it with something Tim can use
> for infrastructure tests.
> 
> Tim what are your expectation from such runtest file? How many tests
> should be in?

I don't think that it should be very many.  Otherwise, people will get
the idea that it is useful for actual device testing. ;-)

The current 'quickhit' runtest file has 107 tests.  With the exception of
qmm01 (which calls mmap001 with '-n 1') and a bunch of tests that do sub-tests
of symlink01 (12 of them), the remaining test definitions
just consist of the test name and the test executable (with the same names).
I only see binary programs - no tests using shell scripts.  So there's really not much variety
here.

Apparently a pipe is allowed in the command invocation line for a test, but there's only
one example of this in all of the runtests, in syscalls:
splice02 seq 1 2000 | splice02

Really, as an infrastructure test, I only need to run a few testcases to validate that Fuego's
plumbing around runltp (and ltp-pan) works properly.  And it would be nice if
the run was very short, so I could do the check quickly.

Do you want me to create a runtest for a framework/LTP integration test, by picking a
few different "representative" tests, as a replacement for quickhit?

IMHO, the selected tests should behave the same on all possible systems, to avoid
getting results that are inconsistent due to the system under test, rather than a
problem with the integration between the framework and LTP.

Should I add some outlier cases:
 - something that times out
 - something that always fails
 - tests that return TBROK, TCONF, TWARN, etc.
 - something where the command doesn't exist

This would be helpful for checking that my parsing for different results works.

Do you have a preferred name for the runtest file?  My proposal, just off the top
of my head, is: "ltp-selftest-quick", but I'm open to other suggestions.

I'm also open to suggestions for possible tests.  I'd like a shell script command
to add to the list of binary programs.  Here is what I've chosen so far:
access01 access01
chdir01 chdir01
fork01 fork01
time01 time01
wait02 wait02
write01 write01
symlink01 symlink01
stat04 symlink01 -T stat04
utime01A symlink01 -T utime01
rename01A symlink01 -T rename01
splice02 seq 1 20 | splice02

This takes about 5 seconds on one of my test machines.

 -- Tim

P.S. Maybe, if you're moving away from runltp and ltp-pan, it's a little late to be
adding some selftests to make sure they work correctly.  But Fuego is using them.
I don't know what other frameworks use when they invoke LTP to perform
tests.

P.P.S How come some tests produce TPASS and some produce just PASS?





^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-14 11:00                   ` Cyril Hrubis
@ 2020-09-14 17:51                     ` Bird, Tim
  2020-09-15  1:18                       ` Cixi Geng
  2020-09-15  9:59                       ` Cyril Hrubis
  0 siblings, 2 replies; 197+ messages in thread
From: Bird, Tim @ 2020-09-14 17:51 UTC (permalink / raw)
  To: ltp

> -----Original Message-----
> From: Cyril Hrubis
> 
> Hi!
> > Can we merge the uart device driver testcase and the device-discover
> > framework ???
> 
> Can we please postpone it a little bit again? I've been talking to Tim
> Bird recenlty and he is interesting in helping to shape the interface so
> better that it fits into existing hardware labs.

I'm very interested in this work, and how to integrate it with 
external test frameworks that manage lab equipment (and may
need to communicate test parameters to tests).

I'm not sure the best way to proceed.  I reviewed the device-discovery
code on patchworks, but I'm not sure I understand the anticipated flow of
control between the LTP test, the device discovery part, and the test
framework.

I know you're busy with the LTP release, so I'm not sure this is the best
time to open up a big thread asking a lot of questions about device discovery
or describing my own proposal for this - to work towards harmonizing the two.

But I'm keen on following up on this in the short term (next 4 weeks or so).
I'm giving a talk at Open Source Summit Europe the end of October,
where I'll be talking about lab management APIs, and this dovetails
into that work.

Let me know when would be a good time to try to hash this out.
 -- Tim


^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-10  8:45 ` Petr Vorel
@ 2020-09-14 11:15   ` Cyril Hrubis
  2020-09-14 22:30     ` Bird, Tim
  0 siblings, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2020-09-14 11:15 UTC (permalink / raw)
  To: ltp

Hi!
> > What else should go in?
> How about removing runtest/quickhit?
> https://patchwork.ozlabs.org/project/ltp/patch/20200831094617.7764-1-chrubis@suse.cz/

I guess that we can do that if we replace it with something Tim can use
for infrastructure tests.

Tim what are your expectation from such runtest file? How many tests
should be in?

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-14  7:52                 ` Cixi Geng
@ 2020-09-14 11:00                   ` Cyril Hrubis
  2020-09-14 17:51                     ` Bird, Tim
  0 siblings, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2020-09-14 11:00 UTC (permalink / raw)
  To: ltp

Hi!
> Can we merge the uart device driver testcase and the device-discover
> framework ???

Can we please postpone it a little bit again? I've been talking to Tim
Bird recenlty and he is interesting in helping to shape the interface so
better that it fits into existing hardware labs.

> So that we can continue write other device driver case in LTP.
> I am looking forward contribute to ltp on the driver test.

That's great looking forward to your contributions.

Also I'm sorry that I haven't been able to move this forward, I will try
to speed things up after we are done with the LTP release. Is that fine
with you?

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-10  9:22               ` Li Wang
@ 2020-09-14  7:52                 ` Cixi Geng
  2020-09-14 11:00                   ` Cyril Hrubis
  0 siblings, 1 reply; 197+ messages in thread
From: Cixi Geng @ 2020-09-14  7:52 UTC (permalink / raw)
  To: ltp

Hi Cyril:
Can we merge the uart device driver testcase and the device-discover framework ?
So that we can continue write other device driver case in LTP.
I am looking forward contribute to ltp on the driver test .

https://patchwork.ozlabs.org/project/ltp/list/?series=185240
https://patchwork.ozlabs.org/project/ltp/list/?series=195151

Li Wang <liwang@redhat.com> ?2020?9?10??? ??5:23???
>
>
>
> On Thu, Sep 10, 2020 at 3:19 PM Li Wang <liwang@redhat.com> wrote:
>>
>>
>>
>> On Wed, Sep 9, 2020 at 9:26 PM Cyril Hrubis <chrubis@suse.cz> wrote:
>>>
>>> Hi!
>>> > Also I would like to get rid of the -fno-optimize-sibling-calls in the
>>> > Makefile, this makes the test a bit fragile and less portable.
>>
>>
>> I'm not very sure, let me think/check a while.
>
>
> From the document, it could also help prevents optimization purposes.
> I think we can have a try, if no more issues, that will be great.
>
>>
>>
>>>
>>> /*
>>>  * Returns negative number if stack grows down, possitive if stack grows up
>>>  */
>>> static int stack_dir(void)
>>> {
>>>         intptr_t addr = addr_func();
>>>
>>>         printf("%p %p\n", &addr, (void*)addr);
>>
>>
>> This method may be doable, but the second %p print (nil), I don't why.
>
>
> The reason seems that the local variable is revoked after the function
> is calling, so we get NULL of the local variable address. It works as we
> expected when introducing a global pointer to save and return the '&a'.
>
> --
> Regards,
> Li Wang
>
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-10  7:19             ` Li Wang
@ 2020-09-10  9:22               ` Li Wang
  2020-09-14  7:52                 ` Cixi Geng
  0 siblings, 1 reply; 197+ messages in thread
From: Li Wang @ 2020-09-10  9:22 UTC (permalink / raw)
  To: ltp

On Thu, Sep 10, 2020 at 3:19 PM Li Wang <liwang@redhat.com> wrote:

>
>
> On Wed, Sep 9, 2020 at 9:26 PM Cyril Hrubis <chrubis@suse.cz> wrote:
>
>> Hi!
>> > Also I would like to get rid of the -fno-optimize-sibling-calls in the
>> > Makefile, this makes the test a bit fragile and less portable.
>>
>
> I'm not very sure, let me think/check a while.
>

From the document, it could also help prevents optimization purposes.
I think we can have a try, if no more issues, that will be great.


>
>
>> /*
>>  * Returns negative number if stack grows down, possitive if stack grows
>> up
>>  */
>> static int stack_dir(void)
>> {
>>         intptr_t addr = addr_func();
>>
>>         printf("%p %p\n", &addr, (void*)addr);
>>
>
> This method may be doable, but the second %p print (nil), I don't why.
>

The reason seems that the local variable is revoked after the function
is calling, so we get NULL of the local variable address. It works as we
expected when introducing a global pointer to save and return the '&a'.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-08  7:31 [LTP] LTP release Cyril Hrubis
                   ` (2 preceding siblings ...)
  2020-09-09 20:11 ` Petr Vorel
@ 2020-09-10  8:45 ` Petr Vorel
  2020-09-14 11:15   ` Cyril Hrubis
  2020-09-22 18:21 ` Cyril Hrubis
  4 siblings, 1 reply; 197+ messages in thread
From: Petr Vorel @ 2020-09-10  8:45 UTC (permalink / raw)
  To: ltp

Hi,

> What else should go in?
How about removing runtest/quickhit?
https://patchwork.ozlabs.org/project/ltp/patch/20200831094617.7764-1-chrubis@suse.cz/

And I'll try to to send next version of 'make check' soon.

Kind regards,
Petr

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-09 13:27           ` Cyril Hrubis
@ 2020-09-10  7:19             ` Li Wang
  2020-09-10  9:22               ` Li Wang
  0 siblings, 1 reply; 197+ messages in thread
From: Li Wang @ 2020-09-10  7:19 UTC (permalink / raw)
  To: ltp

On Wed, Sep 9, 2020 at 9:26 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> > Also I would like to get rid of the -fno-optimize-sibling-calls in the
> > Makefile, this makes the test a bit fragile and less portable.
>

I'm not very sure, let me think/check a while.


> /*
>  * Returns negative number if stack grows down, possitive if stack grows up
>  */
> static int stack_dir(void)
> {
>         intptr_t addr = addr_func();
>
>         printf("%p %p\n", &addr, (void*)addr);
>

This method may be doable, but the second %p print (nil), I don't why.

# ./test
0x3ffe70feb48 (nil)
418387128
-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20200910/9cc9af0d/attachment.htm>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-09 13:13         ` Cyril Hrubis
  2020-09-09 13:27           ` Cyril Hrubis
@ 2020-09-10  7:12           ` Li Wang
  1 sibling, 0 replies; 197+ messages in thread
From: Li Wang @ 2020-09-10  7:12 UTC (permalink / raw)
  To: ltp

On Wed, Sep 9, 2020 at 9:13 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> ...
> > static void split_unmapped_plus_stack(void *start, size_t size)
> > {
> >     /* start           start + size
> >     * +---------------------+----------------------+-----------+
> >     * + unmapped            | mapped               | 256 pages |
> >     * +---------------------+----------------------+-----------+
> >     *                       stack
> >     */
>
> Shouldn't the 256 pages follow the unmapped part?
>

Yes, you're right. I made a mistake on draw that. Will fix in V4.


>
> If I'm not mistaken if stack grows down the address decreases with stack
> allocations, so it should be as:
>
> | 256 pages | unmapped | mapped |
>
>
> That would also mean that we should map the stack at address start +
> total_size - size if I'm not mistaken. I guess that we can put all the
> mess into a single function as well and have just allocate_stack() that
> will find a suitable address, mmap the stack together, splitting this
> into two functions is unnecessary confusing.
>

Good point, it makes sense to me.



>
> >     stack = SAFE_MMAP(start + size, size, PROT_READ | PROT_WRITE,
> >                              MAP_FIXED | MAP_PRIVATE | MAP_ANONYMOUS |
> > MAP_GROWSDOWN,
> >                              -1, 0);
> > }
>
> Also I would like to get rid of the -fno-optimize-sibling-calls in the
> Makefile, this makes the test a bit fragile and less portable.
>
> --
> Cyril Hrubis
> chrubis@suse.cz
>
>

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-08  7:31 [LTP] LTP release Cyril Hrubis
  2020-09-08  7:37 ` Yang Xu
  2020-09-08  7:45 ` Li Wang
@ 2020-09-09 20:11 ` Petr Vorel
  2020-09-10  8:45 ` Petr Vorel
  2020-09-22 18:21 ` Cyril Hrubis
  4 siblings, 0 replies; 197+ messages in thread
From: Petr Vorel @ 2020-09-09 20:11 UTC (permalink / raw)
  To: ltp

Hi Cyril,

> As usual we should start preparing for a next release.

...
> What else should go in?

I haven't done review of Amir's fanotify tests for v5.9, but on first look they
look ok
https://patchwork.ozlabs.org/project/ltp/list/?series=200606

How about Richie's Wrapper for Syzkaller reproducers?
https://patchwork.ozlabs.org/project/ltp/patch/20200610072928.1331-1-rpalethorpe@suse.com/

I wanted to post docparser patch in next few days. But that will be probably too
late for including in this release.

Kind regards,
Petr

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-09 13:13         ` Cyril Hrubis
@ 2020-09-09 13:27           ` Cyril Hrubis
  2020-09-10  7:19             ` Li Wang
  2020-09-10  7:12           ` Li Wang
  1 sibling, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2020-09-09 13:27 UTC (permalink / raw)
  To: ltp

Hi!
> Also I would like to get rid of the -fno-optimize-sibling-calls in the
> Makefile, this makes the test a bit fragile and less portable.

What about this code:

#include <stdint.h>
#include <stdio.h>

static intptr_t addr_func(void) __attribute__((noinline));

static intptr_t addr_func(void)
{
	int a;

	return (intptr_t)&a;
}

/*
 * Returns negative number if stack grows down, possitive if stack grows up
 */
static int stack_dir(void)
{
	intptr_t addr = addr_func();

	printf("%p %p\n", &addr, (void*)addr);

	return addr - (intptr_t)&addr;
}

int main(void)
{
	printf("%i\n", stack_dir());

	return 0;
}

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-09 12:16       ` Li Wang
@ 2020-09-09 13:13         ` Cyril Hrubis
  2020-09-09 13:27           ` Cyril Hrubis
  2020-09-10  7:12           ` Li Wang
  0 siblings, 2 replies; 197+ messages in thread
From: Cyril Hrubis @ 2020-09-09 13:13 UTC (permalink / raw)
  To: ltp

Hi!
> > Sounds reasonable. I tried to reserve more space for the mapping grows,
> > and that works for me:).
> >
> 
> To precisely, we could reserve 256 pages size at the end of the free-range
> memory to let the stack keep away from a preceding mapping in its growing
> then.
> (my only concern is the stack_guard_gap can be changed via kernel command
> line, but I assume that happen rarely, so here use the default 256 pages)
> 
> If there is no objection, I'd make these changes in patch V4.
> 
> --------
> 
> static void *find_free_range(size_t size)
> {
>     void *mem;
>     long stack_guard_gap = 256 * getpageszie();
> 
>     /*
>     * Since the newer kernel does not allow a MAP_GROWSDOWN mapping to grow
>     * closer than stack_guard_gap pages away from a preceding mapping.
>     * The guard then ensures that the next-highest mapped page remains more
>     * than stack_guard_gap below the lowest stack address, and if not then
>     * it will trigger a segfault. So, here let's reserve 256 pages memory
>     * spacing for stack growing safely.
>     */
>     mem = SAFE_MMAP(NULL, size + stack_guard_gap, PROT_READ | PROT_WRITE,
>                       MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
>     SAFE_MUNMAP(mem, size + stack_guard_gap);
> 
>     return mem;
> }
> 
> static void split_unmapped_plus_stack(void *start, size_t size)
> {
>     /* start           start + size
>     * +---------------------+----------------------+-----------+
>     * + unmapped            | mapped               | 256 pages |
>     * +---------------------+----------------------+-----------+
>     *                       stack
>     */

Shouldn't the 256 pages follow the unmapped part?

If I'm not mistaken if stack grows down the address decreases with stack
allocations, so it should be as:

| 256 pages | unmapped | mapped |


That would also mean that we should map the stack at address start +
total_size - size if I'm not mistaken. I guess that we can put all the
mess into a single function as well and have just allocate_stack() that
will find a suitable address, mmap the stack together, splitting this
into two functions is unnecessary confusing.

>     stack = SAFE_MMAP(start + size, size, PROT_READ | PROT_WRITE,
>                              MAP_FIXED | MAP_PRIVATE | MAP_ANONYMOUS |
> MAP_GROWSDOWN,
>                              -1, 0);
> }

Also I would like to get rid of the -fno-optimize-sibling-calls in the
Makefile, this makes the test a bit fragile and less portable.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-09  8:46     ` Li Wang
@ 2020-09-09 12:16       ` Li Wang
  2020-09-09 13:13         ` Cyril Hrubis
  0 siblings, 1 reply; 197+ messages in thread
From: Li Wang @ 2020-09-09 12:16 UTC (permalink / raw)
  To: ltp

On Wed, Sep 9, 2020 at 4:46 PM Li Wang <liwang@redhat.com> wrote:

>
>
> On Tue, Sep 8, 2020 at 11:36 PM Cyril Hrubis <chrubis@suse.cz> wrote:
>
>> Hi!
>> > And I'd like to add the MAP_GROWSDOWN test too, but I haven't come up
>> with
>> > a way to solve the segment fault on s390x.
>> > http://lists.linux.it/pipermail/ltp/2020-August/018416.html
>>
>> Maybe we end up allocating a mapping that is too close to something
>> else, see:
>>
>>
>> https://stackoverflow.com/questions/56888725/why-is-map-growsdown-mapping-does-not-grow
>>
>> I guess that we should make the initial mmap in find_free_range() larger
>> and return and adress that is quaranteed not to have a mapping that is
>> closer than 256 pages in the direction we want to grow.
>>
>
> Sounds reasonable. I tried to reserve more space for the mapping grows,
> and that works for me:).
>

To precisely, we could reserve 256 pages size at the end of the free-range
memory to let the stack keep away from a preceding mapping in its growing
then.
(my only concern is the stack_guard_gap can be changed via kernel command
line, but I assume that happen rarely, so here use the default 256 pages)

If there is no objection, I'd make these changes in patch V4.

--------

static void *find_free_range(size_t size)
{
    void *mem;
    long stack_guard_gap = 256 * getpageszie();

    /*
    * Since the newer kernel does not allow a MAP_GROWSDOWN mapping to grow
    * closer than stack_guard_gap pages away from a preceding mapping.
    * The guard then ensures that the next-highest mapped page remains more
    * than stack_guard_gap below the lowest stack address, and if not then
    * it will trigger a segfault. So, here let's reserve 256 pages memory
    * spacing for stack growing safely.
    */
    mem = SAFE_MMAP(NULL, size + stack_guard_gap, PROT_READ | PROT_WRITE,
                      MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
    SAFE_MUNMAP(mem, size + stack_guard_gap);

    return mem;
}

static void split_unmapped_plus_stack(void *start, size_t size)
{
    /* start           start + size
    * +---------------------+----------------------+-----------+
    * + unmapped            | mapped               | 256 pages |
    * +---------------------+----------------------+-----------+
    *                       stack
    */
    stack = SAFE_MMAP(start + size, size, PROT_READ | PROT_WRITE,
                             MAP_FIXED | MAP_PRIVATE | MAP_ANONYMOUS |
MAP_GROWSDOWN,
                             -1, 0);
}

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-08 15:36   ` Cyril Hrubis
@ 2020-09-09  8:46     ` Li Wang
  2020-09-09 12:16       ` Li Wang
  0 siblings, 1 reply; 197+ messages in thread
From: Li Wang @ 2020-09-09  8:46 UTC (permalink / raw)
  To: ltp

On Tue, Sep 8, 2020 at 11:36 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> > And I'd like to add the MAP_GROWSDOWN test too, but I haven't come up
> with
> > a way to solve the segment fault on s390x.
> > http://lists.linux.it/pipermail/ltp/2020-August/018416.html
>
> Maybe we end up allocating a mapping that is too close to something
> else, see:
>
>
> https://stackoverflow.com/questions/56888725/why-is-map-growsdown-mapping-does-not-grow
>
> I guess that we should make the initial mmap in find_free_range() larger
> and return and adress that is quaranteed not to have a mapping that is
> closer than 256 pages in the direction we want to grow.
>

Sounds reasonable. I tried to reserve more space for the mapping grows, and
that works for me:).

static void *find_free_range(size_t size)
{
    void *mem;

    /*
    * To avoid the mapping grows to within a page of the high end of
    * the next lower mapping, which might result in a SIGSEGV signal.
    * Here reserve twifold memory spaces for growing, especially for s390x.
    */
    mem = SAFE_MMAP(NULL, size * 2, PROT_READ | PROT_WRITE,
    MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
    SAFE_MUNMAP(mem, size * 2);

    return mem;
}

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-08  7:45 ` Li Wang
@ 2020-09-08 15:36   ` Cyril Hrubis
  2020-09-09  8:46     ` Li Wang
  0 siblings, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2020-09-08 15:36 UTC (permalink / raw)
  To: ltp

Hi!
> And I'd like to add the MAP_GROWSDOWN test too, but I haven't come up with
> a way to solve the segment fault on s390x.
> http://lists.linux.it/pipermail/ltp/2020-August/018416.html

Maybe we end up allocating a mapping that is too close to something
else, see:

https://stackoverflow.com/questions/56888725/why-is-map-growsdown-mapping-does-not-grow

I guess that we should make the initial mmap in find_free_range() larger
and return and adress that is quaranteed not to have a mapping that is
closer than 256 pages in the direction we want to grow.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-08  7:31 [LTP] LTP release Cyril Hrubis
  2020-09-08  7:37 ` Yang Xu
@ 2020-09-08  7:45 ` Li Wang
  2020-09-08 15:36   ` Cyril Hrubis
  2020-09-09 20:11 ` Petr Vorel
                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 197+ messages in thread
From: Li Wang @ 2020-09-08  7:45 UTC (permalink / raw)
  To: ltp

On Tue, Sep 8, 2020 at 3:31 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> As usual we should start preparing for a next release.
>
> As usuall we will have a week or two where we should merge everthing
> that should go in before the release, then git freeze for another week
> and finally a release.
>
> So let's start with a list of things that should go in.
>
> For me it would be:
>
> * ptrace08 fix
>
> * if possible the shmctl() rewrite
>
+1 these rewrite looks good, I will finish my test by the end of today.


>
>
> What else should go in?
>

It may be better to fix ioctl_loop01 too.
https://github.com/linux-test-project/ltp/issues/718

And I'd like to add the MAP_GROWSDOWN test too, but I haven't come up with
a way to solve the segment fault on s390x.
http://lists.linux.it/pipermail/ltp/2020-August/018416.html

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-09-08  7:31 [LTP] LTP release Cyril Hrubis
@ 2020-09-08  7:37 ` Yang Xu
  2020-09-08  7:45 ` Li Wang
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 197+ messages in thread
From: Yang Xu @ 2020-09-08  7:37 UTC (permalink / raw)
  To: ltp

Hi Cyril


> Hi!
> As usual we should start preparing for a next release.
> 
> As usuall we will have a week or two where we should merge everthing
> that should go in before the release, then git freeze for another week
> and finally a release.
> 
> So let's start with a list of things that should go in.
> 
> For me it would be:
> 
> * ptrace08 fix
> 
> * if possible the shmctl() rewrite
> 
> 
> What else should go in?
For me, three patches:
1.syscalls/ioctl_loop07.c?Using LOOP_CONFIGURE to test lo_sizelimit field
2.syscalls/msgrcv07: Add functional test for MSG_COPY flag
3.syscalls/msgrcv03: Add error test for MSG_COPY flag

Best Regards
Yang Xu
> 



^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
@ 2020-09-08  7:31 Cyril Hrubis
  2020-09-08  7:37 ` Yang Xu
                   ` (4 more replies)
  0 siblings, 5 replies; 197+ messages in thread
From: Cyril Hrubis @ 2020-09-08  7:31 UTC (permalink / raw)
  To: ltp

Hi!
As usual we should start preparing for a next release.

As usuall we will have a week or two where we should merge everthing
that should go in before the release, then git freeze for another week
and finally a release.

So let's start with a list of things that should go in.

For me it would be:

* ptrace08 fix

* if possible the shmctl() rewrite


What else should go in?

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
       [not found] <5ebe1570.1c69fb81.46edc.a08cSMTPIN_ADDED_BROKEN@mx.google.com>
@ 2020-05-15  4:16 ` Li Wang
  0 siblings, 0 replies; 197+ messages in thread
From: Li Wang @ 2020-05-15  4:16 UTC (permalink / raw)
  To: ltp

On Fri, May 15, 2020 at 12:07 PM xuyang_jy_0410@163.com <
xuyang_jy_0410@163.com> wrote:

> Hi Li
> Can we put these attach and disattach steps into verify function like
> ioctl_loop 04.c does?
>

How does the attach/detach device cause the failure?  I actually run into
this failure without parameter "-i".

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-05-14  9:54 ` Cyril Hrubis
  2020-05-14  9:58   ` Yang Xu
@ 2020-05-15  3:37   ` Li Wang
  1 sibling, 0 replies; 197+ messages in thread
From: Li Wang @ 2020-05-15  3:37 UTC (permalink / raw)
  To: ltp

Hi Cyril,

I have finished the latest LTP test around RHEL7/8 and mainline kernel
across arches. Apart from many known issues/bugs the test looks good.

The only failure to catch my attention is the ioctl_loop05 still getting
fail on s390x with RHEL8.2 or kernel-v5.7-rc5. I haven't dig into the
details since it looks insignificant.
@Yang Xu <xuyang2018.jy@cn.fujitsu.com> Xu, do you have any idea about that?

# ./ioctl_loop05
tst_test.c:1246: INFO: Timeout per run is 0h 05m 00s
tst_device.c:88: INFO: Found free device 0 '/dev/loop0'
ioctl_loop05.c:116: INFO: /dev/loop0 default logical_block_size is 512
ioctl_loop05.c:62: INFO: Without setting lo_offset or sizelimit
ioctl_loop05.c:63: BROK: ioctl(3,LOOP_SET_DIRECT_IO,...) failed: EINVAL (22)


On Thu, May 14, 2020 at 5:54 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> This is a last call, if you think that something has to be included in
> the release speak up today.
>
> The last thing on my radar is the "syscalls: Fix issues around calling
> syscalls with old timespec" patch that should get in, after that I would
> like to proceed with the release.
>
> --
> Cyril Hrubis
> chrubis@suse.cz
>
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp
>
>

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-05-14 12:11     ` Cyril Hrubis
@ 2020-05-14 13:45       ` Xiao Yang
  0 siblings, 0 replies; 197+ messages in thread
From: Xiao Yang @ 2020-05-14 13:45 UTC (permalink / raw)
  To: ltp

On 2020/5/14 20:11, Cyril Hrubis wrote:
> Hi!
>>> This is a last call, if you think that something has to be included in
>>> the release speak up today.
>> just including two small fixes about tpci.
>
> These two looks good to me, so feel free to push them.
Hi Cyril,

They also looks good to me, but not urgent fixes.
I think you can proceed with the release directly and then I will push 
them after the release.

Best Regards,
Xiao Yang
>



^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-05-14  9:58   ` Yang Xu
@ 2020-05-14 12:11     ` Cyril Hrubis
  2020-05-14 13:45       ` Xiao Yang
  0 siblings, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2020-05-14 12:11 UTC (permalink / raw)
  To: ltp

Hi!
> > This is a last call, if you think that something has to be included in
> > the release speak up today.
> just including two small fixes about tpci.

These two looks good to me, so feel free to push them.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-05-14  9:54 ` Cyril Hrubis
@ 2020-05-14  9:58   ` Yang Xu
  2020-05-14 12:11     ` Cyril Hrubis
  2020-05-15  3:37   ` Li Wang
  1 sibling, 1 reply; 197+ messages in thread
From: Yang Xu @ 2020-05-14  9:58 UTC (permalink / raw)
  To: ltp

Hi Cyril


> Hi!
> This is a last call, if you think that something has to be included in
> the release speak up today.
just including two small fixes about tpci.

Best Regards
Yang Xu
> 
> The last thing on my radar is the "syscalls: Fix issues around calling
> syscalls with old timespec" patch that should get in, after that I would
> like to proceed with the release.
> 



^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-05-04 10:49 Cyril Hrubis
  2020-05-04 11:09 ` Martin Doucha
@ 2020-05-14  9:54 ` Cyril Hrubis
  2020-05-14  9:58   ` Yang Xu
  2020-05-15  3:37   ` Li Wang
  1 sibling, 2 replies; 197+ messages in thread
From: Cyril Hrubis @ 2020-05-14  9:54 UTC (permalink / raw)
  To: ltp

Hi!
This is a last call, if you think that something has to be included in
the release speak up today.

The last thing on my radar is the "syscalls: Fix issues around calling
syscalls with old timespec" patch that should get in, after that I would
like to proceed with the release.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-05-04 11:09 ` Martin Doucha
@ 2020-05-04 11:16   ` Cyril Hrubis
  0 siblings, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2020-05-04 11:16 UTC (permalink / raw)
  To: ltp

Hi!
> > As usually it's about a time to prepare for the May LTP release.
> > 
> > And as usally I will try to focus on finising and merging everything
> > that should land in the upcomming release this week. If there are
> > patches that you think should really be included, please point them out
> > now.
> 
> I'd like to get my LVM patchset into this release:
> https://patchwork.ozlabs.org/project/ltp/list/?series=170417
> 
> And also the fix/coverage extension for connect02:
> https://patchwork.ozlabs.org/project/ltp/patch/20200427145014.3530-1-mdoucha@suse.cz/

I will have a look.

> > Also lastly but not least, please start your pre-release testing
> > procedure to make sure that the latest git HEAD works fine in your
> > environment.
> 
> What's the earliest release date you have in mind?

If possible I would like to freeze the git for anything but fixes at the
end of the week, then we will have at least another week for pre-release
testing and bugfixing.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2020-05-04 10:49 Cyril Hrubis
@ 2020-05-04 11:09 ` Martin Doucha
  2020-05-04 11:16   ` Cyril Hrubis
  2020-05-14  9:54 ` Cyril Hrubis
  1 sibling, 1 reply; 197+ messages in thread
From: Martin Doucha @ 2020-05-04 11:09 UTC (permalink / raw)
  To: ltp

On 04. 05. 20 12:49, Cyril Hrubis wrote:
> Hi!
> As usually it's about a time to prepare for the May LTP release.
> 
> And as usally I will try to focus on finising and merging everything
> that should land in the upcomming release this week. If there are
> patches that you think should really be included, please point them out
> now.

I'd like to get my LVM patchset into this release:
https://patchwork.ozlabs.org/project/ltp/list/?series=170417

And also the fix/coverage extension for connect02:
https://patchwork.ozlabs.org/project/ltp/patch/20200427145014.3530-1-mdoucha@suse.cz/

> Also lastly but not least, please start your pre-release testing
> procedure to make sure that the latest git HEAD works fine in your
> environment.

What's the earliest release date you have in mind?

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
@ 2020-05-04 10:49 Cyril Hrubis
  2020-05-04 11:09 ` Martin Doucha
  2020-05-14  9:54 ` Cyril Hrubis
  0 siblings, 2 replies; 197+ messages in thread
From: Cyril Hrubis @ 2020-05-04 10:49 UTC (permalink / raw)
  To: ltp

Hi!
As usually it's about a time to prepare for the May LTP release.

And as usally I will try to focus on finising and merging everything
that should land in the upcomming release this week. If there are
patches that you think should really be included, please point them out
now.

Also lastly but not least, please start your pre-release testing
procedure to make sure that the latest git HEAD works fine in your
environment.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-09-10 13:05   ` Cyril Hrubis
@ 2019-09-26 10:43     ` Thadeu Lima de Souza Cascardo
  0 siblings, 0 replies; 197+ messages in thread
From: Thadeu Lima de Souza Cascardo @ 2019-09-26 10:43 UTC (permalink / raw)
  To: ltp

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-09-26  9:08         ` Cyril Hrubis
@ 2019-09-26  9:52           ` Jan Stancek
  0 siblings, 0 replies; 197+ messages in thread
From: Jan Stancek @ 2019-09-26  9:52 UTC (permalink / raw)
  To: ltp


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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-09-26  8:54       ` Jan Stancek
@ 2019-09-26  9:08         ` Cyril Hrubis
  2019-09-26  9:52           ` Jan Stancek
  0 siblings, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2019-09-26  9:08 UTC (permalink / raw)
  To: ltp

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-09-25 11:22 ` Cyril Hrubis
  2019-09-26  8:29   ` Jan Stancek
@ 2019-09-26  9:02   ` Li Wang
  1 sibling, 0 replies; 197+ messages in thread
From: Li Wang @ 2019-09-26  9:02 UTC (permalink / raw)
  To: ltp

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>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-09-26  8:33     ` Cyril Hrubis
@ 2019-09-26  8:54       ` Jan Stancek
  2019-09-26  9:08         ` Cyril Hrubis
  0 siblings, 1 reply; 197+ messages in thread
From: Jan Stancek @ 2019-09-26  8:54 UTC (permalink / raw)
  To: ltp



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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-09-26  8:29   ` Jan Stancek
@ 2019-09-26  8:33     ` Cyril Hrubis
  2019-09-26  8:54       ` Jan Stancek
  0 siblings, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2019-09-26  8:33 UTC (permalink / raw)
  To: ltp

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-09-25 11:22 ` Cyril Hrubis
@ 2019-09-26  8:29   ` Jan Stancek
  2019-09-26  8:33     ` Cyril Hrubis
  2019-09-26  9:02   ` Li Wang
  1 sibling, 1 reply; 197+ messages in thread
From: Jan Stancek @ 2019-09-26  8:29 UTC (permalink / raw)
  To: ltp



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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-09-06 13:07 [LTP] LTP Release Cyril Hrubis
                   ` (3 preceding siblings ...)
  2019-09-13 13:07 ` Petr Vorel
@ 2019-09-25 11:22 ` Cyril Hrubis
  2019-09-26  8:29   ` Jan Stancek
  2019-09-26  9:02   ` Li Wang
  4 siblings, 2 replies; 197+ messages in thread
From: Cyril Hrubis @ 2019-09-25 11:22 UTC (permalink / raw)
  To: ltp

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-09-06 13:07 [LTP] LTP Release Cyril Hrubis
                   ` (2 preceding siblings ...)
  2019-09-10  6:51 ` =?unknown-8bit?b?WWFuZy/lvpAg5p2o?=
@ 2019-09-13 13:07 ` Petr Vorel
  2019-09-25 11:22 ` Cyril Hrubis
  4 siblings, 0 replies; 197+ messages in thread
From: Petr Vorel @ 2019-09-13 13:07 UTC (permalink / raw)
  To: ltp

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/

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-09-10  6:51 ` =?unknown-8bit?b?WWFuZy/lvpAg5p2o?=
@ 2019-09-10 13:56   ` Cyril Hrubis
  0 siblings, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2019-09-10 13:56 UTC (permalink / raw)
  To: ltp

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-09-09  7:46 ` Li Wang
@ 2019-09-10 13:05   ` Cyril Hrubis
  2019-09-26 10:43     ` Thadeu Lima de Souza Cascardo
  0 siblings, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2019-09-10 13:05 UTC (permalink / raw)
  To: ltp

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-09-06 13:07 [LTP] LTP Release Cyril Hrubis
  2019-09-06 13:48 ` Richard Palethorpe
  2019-09-09  7:46 ` Li Wang
@ 2019-09-10  6:51 ` =?unknown-8bit?b?WWFuZy/lvpAg5p2o?=
  2019-09-10 13:56   ` Cyril Hrubis
  2019-09-13 13:07 ` Petr Vorel
  2019-09-25 11:22 ` Cyril Hrubis
  4 siblings, 1 reply; 197+ messages in thread
From: =?unknown-8bit?b?WWFuZy/lvpAg5p2o?= @ 2019-09-10  6:51 UTC (permalink / raw)
  To: ltp


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>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-09-06 13:07 [LTP] LTP Release Cyril Hrubis
  2019-09-06 13:48 ` Richard Palethorpe
@ 2019-09-09  7:46 ` Li Wang
  2019-09-10 13:05   ` Cyril Hrubis
  2019-09-10  6:51 ` =?unknown-8bit?b?WWFuZy/lvpAg5p2o?=
                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 197+ messages in thread
From: Li Wang @ 2019-09-09  7:46 UTC (permalink / raw)
  To: ltp

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>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-09-06 13:07 [LTP] LTP Release Cyril Hrubis
@ 2019-09-06 13:48 ` Richard Palethorpe
  2019-09-09  7:46 ` Li Wang
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 197+ messages in thread
From: Richard Palethorpe @ 2019-09-06 13:48 UTC (permalink / raw)
  To: ltp

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.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
@ 2019-09-06 13:07 Cyril Hrubis
  2019-09-06 13:48 ` Richard Palethorpe
                   ` (4 more replies)
  0 siblings, 5 replies; 197+ messages in thread
From: Cyril Hrubis @ 2019-09-06 13:07 UTC (permalink / raw)
  To: ltp

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-04-18 11:18 Cyril Hrubis
                   ` (2 preceding siblings ...)
  2019-05-14  7:16 ` Li Wang
@ 2019-05-15 13:55 ` Cyril Hrubis
  3 siblings, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2019-05-15 13:55 UTC (permalink / raw)
  To: ltp

Hi!
Anything else that should be taken care of?

I would like to tag the git and produce the release on Friday.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-05-14  7:16 ` Li Wang
@ 2019-05-14 12:23   ` Cyril Hrubis
  0 siblings, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2019-05-14 12:23 UTC (permalink / raw)
  To: ltp

Hi!
> I have completed the latest LTP testing on RHEL-7.6 and RHEL-8.0 across all
> arches(x86_64, ppc64le, ppc64, s390x, aarch64), here I post the summary FYI:

Thanks a lot for the detailed writeup!

> RHEL7.6
> ------------
> 1. crypto/af_alg01/02 (all arches - fail)
> af_alg01 failure is a kernel bug.
> af_alg02 test broken as what Christian's described in the patch. It should
> be fixed on the kernel without that commit ecaaab564978 too.

Will look into this patch.

> 2. binfmt_misc01.sh  (x86_64, s390x - fail, ppc64le/ppc64 - panic)
> It looks like a kernel bug.
> 
> RHEL8.0
> -------------
> 1. NUMA issue (ppc64le)
> Numa test failed on that machine with non-continuous NUMA nodes. Two
> patches for the problem solving has been sent to LTP-ML.

And into this as well.

> 2. HUGETLB issue (aarch64)
> hugetlb tests sometimes failed to request sufficient huge pages, even we
> try limiting to 80% of the max huge page count is still not being satisfied
> on 512MB huge page size system sometimes.

I guess that this will have to wait to be fixed after the release.


From my point of view the ioctl_ns tests failures with -m32 are worth
fixing and that together with the afl_alg02 and numa issues should be
everything that needs to be taken care of before the release.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-04-18 11:18 Cyril Hrubis
  2019-04-23  8:40 ` Petr Vorel
  2019-04-26 13:12 ` Cyril Hrubis
@ 2019-05-14  7:16 ` Li Wang
  2019-05-14 12:23   ` Cyril Hrubis
  2019-05-15 13:55 ` Cyril Hrubis
  3 siblings, 1 reply; 197+ messages in thread
From: Li Wang @ 2019-05-14  7:16 UTC (permalink / raw)
  To: ltp

Hi Cyril,

I have completed the latest LTP testing on RHEL-7.6 and RHEL-8.0 across all
arches(x86_64, ppc64le, ppc64, s390x, aarch64), here I post the summary FYI:

RHEL7.6
------------
1. crypto/af_alg01/02 (all arches - fail)
af_alg01 failure is a kernel bug.
af_alg02 test broken as what Christian's described in the patch. It should
be fixed on the kernel without that commit ecaaab564978 too.

2. binfmt_misc01.sh  (x86_64, s390x - fail, ppc64le/ppc64 - panic)
It looks like a kernel bug.

RHEL8.0
-------------
1. NUMA issue (ppc64le)
Numa test failed on that machine with non-continuous NUMA nodes. Two
patches for the problem solving has been sent to LTP-ML.

2. HUGETLB issue (aarch64)
hugetlb tests sometimes failed to request sufficient huge pages, even we
try limiting to 80% of the max huge page count is still not being satisfied
on 512MB huge page size system sometimes.

Besides these above failures, the remaining test looks pretty good.

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20190514/59eefb50/attachment.html>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-04-30  9:04         ` Cyril Hrubis
@ 2019-04-30 12:35           ` Petr Vorel
  0 siblings, 0 replies; 197+ messages in thread
From: Petr Vorel @ 2019-04-30 12:35 UTC (permalink / raw)
  To: ltp

Hi Cyril,

> > Tested-by: Petr Vorel <pvorel@suse.cz>

> > This one looks ok. Also testing with machine with 32 cores, ok as well (but it's
> > hard to trigger this bug even current master).

> Sigh, apparenlty this has patch has two obvious typos, both
> abs_top_builddir and abs_top_srcdir are spelled incorrectly, no wonder
> it does not work, sorry for that.
With this fix (used as commits [1] [2]) looks it fixed it.
21 times or fewer was needed o trigger the build on master, now ok with 33
builds. I'll keep it running during the day just for sure, but consider it
fixed.

> And the only reason why this works for in-tree build is because with
> typos we do no replace anything and the path to the Makefile is correct
> for in-tree build.

Kind regards,
Petr

[1] https://github.com/pevik/ltp/commit/22fd15ad08166dc2ec4c8e93884e51be4a46c1b6
[2] https://github.com/pevik/ltp/commit/10a783538331df8616384f1d9d62c334c117c918

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-04-29 21:07         ` Petr Vorel
@ 2019-04-30  9:05           ` Cyril Hrubis
  0 siblings, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2019-04-30  9:05 UTC (permalink / raw)
  To: ltp

Hi!
> > And I guess I found the problem.
> 
> > When I tried to fix the out-of-tree build by adding a rule to create the libs
> > directory I overlooked that there are all rules already in place and all that
> > had to be added was the dependency of libs-all on the builddir libs path. After
> > I added the rule that created the directory the libs-all targed was fulfilled
> > by a redefined target that only created the directory and haven't build the
> > libs directory before the rest of the source tree at all. We even got target
> > redefinition warnings because of that.
> 
> > Peter can you please test with this change:
> 
> Sure! While this one is ok [1], and also with previous patch [2].
> But when tested on real HW with 32 cores (with merged both commits), where it
> took me 6 iterations to trigger this error :( (5 iterations was needed to
> trigger error on the current master).

That means that the dependencies are still not correct and we still
fail to build the library before everything else.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-04-29 20:45       ` Petr Vorel
@ 2019-04-30  9:04         ` Cyril Hrubis
  2019-04-30 12:35           ` Petr Vorel
  0 siblings, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2019-04-30  9:04 UTC (permalink / raw)
  To: ltp

Hi!
> > diff --git a/include/mk/testcases.mk b/include/mk/testcases.mk
> > index 131854ec7..6d1b2d4ef 100644
> > --- a/include/mk/testcases.mk
> > +++ b/include/mk/testcases.mk
> > @@ -49,7 +49,7 @@ LTPLIBS_FILES = $(addsuffix .a, $(addprefix $(abs_top_builddir)/libs/, $(foreach
> >  MAKE_DEPS += $(LTPLIBS_FILES)
> 
> >  $(LTPLIBS_FILES): $(LTPLIBS_DIRS)
> > -       $(MAKE) -C "$^" -f "$^/Makefile" all
> > +       $(MAKE) -C "$^" -f "$(subst $(abs_top_buildir),$(abs_to_srcdir),$^)/Makefile" all
> 
> >  LDFLAGS += $(addprefix -L$(top_builddir)/libs/lib, $(LTPLIBS))
> 
> > I will have a look at the top level Makefile as well to see what has to
> > be done there.
> Tested-by: Petr Vorel <pvorel@suse.cz>
> 
> This one looks ok. Also testing with machine with 32 cores, ok as well (but it's
> hard to trigger this bug even current master).

Sigh, apparenlty this has patch has two obvious typos, both
abs_top_builddir and abs_top_srcdir are spelled incorrectly, no wonder
it does not work, sorry for that.

And the only reason why this works for in-tree build is because with
typos we do no replace anything and the path to the Makefile is correct
for in-tree build.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-04-29 11:59     ` Cyril Hrubis
@ 2019-04-30  3:09       ` Li Wang
  0 siblings, 0 replies; 197+ messages in thread
From: Li Wang @ 2019-04-30  3:09 UTC (permalink / raw)
  To: ltp

On Mon, Apr 29, 2019 at 7:59 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> > > > So as usually please go ahead and point out anything that should go
> in
> > > > before the release.
> > >
> > > Only Peter replied so far, so I suppose that we are ready to freeze git
> > > starting next week and start the pre-release testing.
> > >
> > > Or is there anything that has to be considered to be included before we
> > > do that?
> > >
> >
> > Here is a simple fix for hugepage test broken with memory shortage.
> > Consider merging?
> > http://lists.linux.it/pipermail/ltp/2019-April/011714.html
>
> The basic idea looks OK however:
>
> * the function name (reset_hugepages) is a bit confusing
>   what about "cap_hugepages" or "limit_hugepages"
>

"limit_hugepages" sounds good to me.

>
> * The MemFree: may be close to zero on long running system because of
>   cached files, AFAIK MemAvailable: would be a better choice, see:
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34e431b0ae398fc54ea69ff85ec700722c9da773
>
>   Unfortunately that one is available since 3.14 kernel, if we wanted to
>   run on older kenrnels I would propose to fall back to dropping caches
>   and using MemFree: on kernel that does not have MemAvailable: in
>   meminfo.
>

Good proposal. I will improve like this in patch V4. Thanks!

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-04-29 14:33       ` Cyril Hrubis
@ 2019-04-29 21:07         ` Petr Vorel
  2019-04-30  9:05           ` Cyril Hrubis
  0 siblings, 1 reply; 197+ messages in thread
From: Petr Vorel @ 2019-04-29 21:07 UTC (permalink / raw)
  To: ltp

Hi Cyril,

> > I will have a look at the top level Makefile as well to see what has to
> > be done there.

> And I guess I found the problem.

> When I tried to fix the out-of-tree build by adding a rule to create the libs
> directory I overlooked that there are all rules already in place and all that
> had to be added was the dependency of libs-all on the builddir libs path. After
> I added the rule that created the directory the libs-all targed was fulfilled
> by a redefined target that only created the directory and haven't build the
> libs directory before the rest of the source tree at all. We even got target
> redefinition warnings because of that.

> Peter can you please test with this change:

Sure! While this one is ok [1], and also with previous patch [2].
But when tested on real HW with 32 cores (with merged both commits), where it
took me 6 iterations to trigger this error :( (5 iterations was needed to
trigger error on the current master).

Kind regards,
Petr
[1] https://travis-ci.org/pevik/ltp/builds/526011623
[2] https://travis-ci.org/pevik/ltp/builds/526017203

> diff --git a/Makefile b/Makefile
> index c46d050ce..768ca4606 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -102,9 +102,6 @@ $(sort $(addprefix $(abs_top_builddir)/,$(BOOTSTRAP_TARGETS)) $(INSTALL_DIR) $(D
>  ## Pattern based subtarget rules.
>  lib-install: lib-all

> -$(abs_top_builddir)/libs:
> -       mkdir -m 00755 -p "$@"
> -
>  libs-all: $(abs_top_builddir)/libs

>  $(MAKE_TARGETS) include-all lib-all libs-all:

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-04-29 13:13     ` Cyril Hrubis
  2019-04-29 14:33       ` Cyril Hrubis
@ 2019-04-29 20:45       ` Petr Vorel
  2019-04-30  9:04         ` Cyril Hrubis
  1 sibling, 1 reply; 197+ messages in thread
From: Petr Vorel @ 2019-04-29 20:45 UTC (permalink / raw)
  To: ltp

Hi Cyril,

> There are two things to fix. One that the patch from Jan attempted is
> wrong path in the rule in the testcases.mk and the second one is that
> the libraries are not build from the top level Makefile first before
> everything else.

> For the first problem fixing the path to the library Makefile should fix
> the problem, something as (beware untested) this should fix it:

> diff --git a/include/mk/testcases.mk b/include/mk/testcases.mk
> index 131854ec7..6d1b2d4ef 100644
> --- a/include/mk/testcases.mk
> +++ b/include/mk/testcases.mk
> @@ -49,7 +49,7 @@ LTPLIBS_FILES = $(addsuffix .a, $(addprefix $(abs_top_builddir)/libs/, $(foreach
>  MAKE_DEPS += $(LTPLIBS_FILES)

>  $(LTPLIBS_FILES): $(LTPLIBS_DIRS)
> -       $(MAKE) -C "$^" -f "$^/Makefile" all
> +       $(MAKE) -C "$^" -f "$(subst $(abs_top_buildir),$(abs_to_srcdir),$^)/Makefile" all

>  LDFLAGS += $(addprefix -L$(top_builddir)/libs/lib, $(LTPLIBS))

> I will have a look at the top level Makefile as well to see what has to
> be done there.
Tested-by: Petr Vorel <pvorel@suse.cz>

This one looks ok. Also testing with machine with 32 cores, ok as well (but it's
hard to trigger this bug even current master).

Kind regards,
Petr

[1] https://travis-ci.org/pevik/ltp/builds/526016709

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-04-29 13:13     ` Cyril Hrubis
@ 2019-04-29 14:33       ` Cyril Hrubis
  2019-04-29 21:07         ` Petr Vorel
  2019-04-29 20:45       ` Petr Vorel
  1 sibling, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2019-04-29 14:33 UTC (permalink / raw)
  To: ltp

Hi!
> diff --git a/include/mk/testcases.mk b/include/mk/testcases.mk
> index 131854ec7..6d1b2d4ef 100644
> --- a/include/mk/testcases.mk
> +++ b/include/mk/testcases.mk
> @@ -49,7 +49,7 @@ LTPLIBS_FILES = $(addsuffix .a, $(addprefix $(abs_top_builddir)/libs/, $(foreach
>  MAKE_DEPS += $(LTPLIBS_FILES)
>  
>  $(LTPLIBS_FILES): $(LTPLIBS_DIRS)
> -       $(MAKE) -C "$^" -f "$^/Makefile" all
> +       $(MAKE) -C "$^" -f "$(subst $(abs_top_buildir),$(abs_to_srcdir),$^)/Makefile" all
>  
>  LDFLAGS += $(addprefix -L$(top_builddir)/libs/lib, $(LTPLIBS))
> 
> I will have a look at the top level Makefile as well to see what has to
> be done there.

And I guess I found the problem.

When I tried to fix the out-of-tree build by adding a rule to create the libs
directory I overlooked that there are all rules already in place and all that
had to be added was the dependency of libs-all on the builddir libs path. After
I added the rule that created the directory the libs-all targed was fulfilled
by a redefined target that only created the directory and haven't build the
libs directory before the rest of the source tree at all. We even got target
redefinition warnings because of that.

Peter can you please test with this change:

diff --git a/Makefile b/Makefile
index c46d050ce..768ca4606 100644
--- a/Makefile
+++ b/Makefile
@@ -102,9 +102,6 @@ $(sort $(addprefix $(abs_top_builddir)/,$(BOOTSTRAP_TARGETS)) $(INSTALL_DIR) $(D
 ## Pattern based subtarget rules.
 lib-install: lib-all
 
-$(abs_top_builddir)/libs:
-       mkdir -m 00755 -p "$@"
-
 libs-all: $(abs_top_builddir)/libs
 
 $(MAKE_TARGETS) include-all lib-all libs-all:



-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply related	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-04-29 10:20   ` Petr Vorel
@ 2019-04-29 13:13     ` Cyril Hrubis
  2019-04-29 14:33       ` Cyril Hrubis
  2019-04-29 20:45       ` Petr Vorel
  0 siblings, 2 replies; 197+ messages in thread
From: Cyril Hrubis @ 2019-04-29 13:13 UTC (permalink / raw)
  To: ltp

Hi!
> > > So as usually please go ahead and point out anything that should go in
> > > before the release.
> 
> > Only Peter replied so far, so I suppose that we are ready to freeze git
> > starting next week and start the pre-release testing.
> 
> > Or is there anything that has to be considered to be included before we
> > do that?
> I guess it'd be great to fix sporadic out-of-tree build failures related to
> libs. Jan's patch [1] does not fixed it. I have no idea how to fix it.
> 
> Kind regards,
> Petr
> 
> [1] https://patchwork.ozlabs.org/patch/1059002/

There are two things to fix. One that the patch from Jan attempted is
wrong path in the rule in the testcases.mk and the second one is that
the libraries are not build from the top level Makefile first before
everything else.

For the first problem fixing the path to the library Makefile should fix
the problem, something as (beware untested) this should fix it:

diff --git a/include/mk/testcases.mk b/include/mk/testcases.mk
index 131854ec7..6d1b2d4ef 100644
--- a/include/mk/testcases.mk
+++ b/include/mk/testcases.mk
@@ -49,7 +49,7 @@ LTPLIBS_FILES = $(addsuffix .a, $(addprefix $(abs_top_builddir)/libs/, $(foreach
 MAKE_DEPS += $(LTPLIBS_FILES)
 
 $(LTPLIBS_FILES): $(LTPLIBS_DIRS)
-       $(MAKE) -C "$^" -f "$^/Makefile" all
+       $(MAKE) -C "$^" -f "$(subst $(abs_top_buildir),$(abs_to_srcdir),$^)/Makefile" all
 
 LDFLAGS += $(addprefix -L$(top_builddir)/libs/lib, $(LTPLIBS))

I will have a look at the top level Makefile as well to see what has to
be done there.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply related	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-04-28  5:25   ` Li Wang
@ 2019-04-29 11:59     ` Cyril Hrubis
  2019-04-30  3:09       ` Li Wang
  0 siblings, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2019-04-29 11:59 UTC (permalink / raw)
  To: ltp

Hi!
> > > So as usually please go ahead and point out anything that should go in
> > > before the release.
> >
> > Only Peter replied so far, so I suppose that we are ready to freeze git
> > starting next week and start the pre-release testing.
> >
> > Or is there anything that has to be considered to be included before we
> > do that?
> >
> 
> Here is a simple fix for hugepage test broken with memory shortage.
> Consider merging?
> http://lists.linux.it/pipermail/ltp/2019-April/011714.html

The basic idea looks OK however:

* the function name (reset_hugepages) is a bit confusing
  what about "cap_hugepages" or "limit_hugepages"

* The MemFree: may be close to zero on long running system because of
  cached files, AFAIK MemAvailable: would be a better choice, see:

  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34e431b0ae398fc54ea69ff85ec700722c9da773

  Unfortunately that one is available since 3.14 kernel, if we wanted to
  run on older kenrnels I would propose to fall back to dropping caches
  and using MemFree: on kernel that does not have MemAvailable: in
  meminfo.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-04-26 13:12 ` Cyril Hrubis
  2019-04-28  5:25   ` Li Wang
@ 2019-04-29 10:20   ` Petr Vorel
  2019-04-29 13:13     ` Cyril Hrubis
  1 sibling, 1 reply; 197+ messages in thread
From: Petr Vorel @ 2019-04-29 10:20 UTC (permalink / raw)
  To: ltp

Hi Cyril,

> Hi!
> > So as usually please go ahead and point out anything that should go in
> > before the release.

> Only Peter replied so far, so I suppose that we are ready to freeze git
> starting next week and start the pre-release testing.

> Or is there anything that has to be considered to be included before we
> do that?
I guess it'd be great to fix sporadic out-of-tree build failures related to
libs. Jan's patch [1] does not fixed it. I have no idea how to fix it.

Kind regards,
Petr

[1] https://patchwork.ozlabs.org/patch/1059002/

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-04-26 13:12 ` Cyril Hrubis
@ 2019-04-28  5:25   ` Li Wang
  2019-04-29 11:59     ` Cyril Hrubis
  2019-04-29 10:20   ` Petr Vorel
  1 sibling, 1 reply; 197+ messages in thread
From: Li Wang @ 2019-04-28  5:25 UTC (permalink / raw)
  To: ltp

On Fri, Apr 26, 2019 at 9:13 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> > So as usually please go ahead and point out anything that should go in
> > before the release.
>
> Only Peter replied so far, so I suppose that we are ready to freeze git
> starting next week and start the pre-release testing.
>
> Or is there anything that has to be considered to be included before we
> do that?
>

Here is a simple fix for hugepage test broken with memory shortage.
Consider merging?
http://lists.linux.it/pipermail/ltp/2019-April/011714.html

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-04-18 11:18 Cyril Hrubis
  2019-04-23  8:40 ` Petr Vorel
@ 2019-04-26 13:12 ` Cyril Hrubis
  2019-04-28  5:25   ` Li Wang
  2019-04-29 10:20   ` Petr Vorel
  2019-05-14  7:16 ` Li Wang
  2019-05-15 13:55 ` Cyril Hrubis
  3 siblings, 2 replies; 197+ messages in thread
From: Cyril Hrubis @ 2019-04-26 13:12 UTC (permalink / raw)
  To: ltp

Hi!
> So as usually please go ahead and point out anything that should go in
> before the release.

Only Peter replied so far, so I suppose that we are ready to freeze git
starting next week and start the pre-release testing.

Or is there anything that has to be considered to be included before we
do that?

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2019-04-18 11:18 Cyril Hrubis
@ 2019-04-23  8:40 ` Petr Vorel
  2019-04-26 13:12 ` Cyril Hrubis
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 197+ messages in thread
From: Petr Vorel @ 2019-04-23  8:40 UTC (permalink / raw)
  To: ltp

Hi Cyril,

> Hi!
> It's about the time we start to prepare for the next LTP release.
> Ideally I would like to go for a release at the start of the second week
> in the May.

> So as usually please go ahead and point out anything that should go in
> before the release.
IMA patches (LTP reproducer on broken IMA on overlayfs) [1] are waiting for
Mimi's approval and Ignaz's testing. Not sure if they'll have time till the
release.

Kind regards,
Petr

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
@ 2019-04-18 11:18 Cyril Hrubis
  2019-04-23  8:40 ` Petr Vorel
                   ` (3 more replies)
  0 siblings, 4 replies; 197+ messages in thread
From: Cyril Hrubis @ 2019-04-18 11:18 UTC (permalink / raw)
  To: ltp

Hi!
It's about the time we start to prepare for the next LTP release.
Ideally I would like to go for a release at the start of the second week
in the May.

So as usually please go ahead and point out anything that should go in
before the release.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2018-08-30 15:53 [LTP] LTP release Cyril Hrubis
@ 2018-08-31  5:20 ` vaishnavi.d
  0 siblings, 0 replies; 197+ messages in thread
From: vaishnavi.d @ 2018-08-31  5:20 UTC (permalink / raw)
  To: ltp


Hi,
Our team has submitted the following patches for testing statx syscall and
waiting for review:

http://lists.linux.it/pipermail/ltp/2018-August/009098.html

http://lists.linux.it/pipermail/ltp/2018-August/009099.html

http://lists.linux.it/pipermail/ltp/2018-August/009058.html

Thanks & Regards,
Vaishnavi.D

> Hi!
> As usuall we should produce a release in September, which means that we
> should start with the stabilization phase in a week or two.
>
> So first of all, if there are any pending patches that should get
> reviewed ASAP so that they get to the release please let me know.
>
> --
> Cyril Hrubis
> chrubis@suse.cz
>
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp
>




^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
@ 2018-08-30 15:53 Cyril Hrubis
  2018-08-31  5:20 ` vaishnavi.d
  0 siblings, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2018-08-30 15:53 UTC (permalink / raw)
  To: ltp

Hi!
As usuall we should produce a release in September, which means that we
should start with the stabilization phase in a week or two.

So first of all, if there are any pending patches that should get
reviewed ASAP so that they get to the release please let me know.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2018-01-12 14:33         ` Cyril Hrubis
@ 2018-01-17 15:27           ` Cyril Hrubis
  0 siblings, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2018-01-17 15:27 UTC (permalink / raw)
  To: ltp

Hi!
> I will do a bit more testing next week and I would like to finish the
> release ideally at the end of the next week. Is that okay with everyone
> or do we need more time?

Can I proceed with the release tomorrow?

Has anybody something that should be considered before I tag the git?

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2018-01-12 14:46       ` Jan Stancek
@ 2018-01-14  4:28         ` Li Wang
  0 siblings, 0 replies; 197+ messages in thread
From: Li Wang @ 2018-01-14  4:28 UTC (permalink / raw)
  To: ltp

On Fri, Jan 12, 2018 at 10:46 PM, Jan Stancek <jstancek@redhat.com> wrote:

> > ​I ran LTP on the upstream kernel-4.15-rc6 across
> x86_64/ppc64(le)/s390x​,
> > and catch some failures as below, ​but currently I haven't get a chance
> to
> > look into the detail, just post here.​
> >
> >
> > migrate_pages02   FAIL  x86_64
>
> I posted patch for this, but since it's only rc kernels it can wait.
>
> > shmt02/03/04/05/06/07/08/09/10   FAIL ppc64
> > -------------------------------------------
> > shmt02      1  TFAIL  :  shmt02.c:71: shmget Failed: shmid = -1, errno =
> 22
> > shmt03      1  TFAIL  :  shmt03.c:72: shmget Failed: shmid = -1, errno =
> 22
> > ...
> > shmt10      2  TFAIL  :  shmt10.c:98: Error: shmid = -1
>
> I haven't seen this in my tests. Are you able to reproduce it?
>

That's a little bit strange, I see these failures on a kvm guest system.
But after reserving it to run by manual, I could NOT reproduce it any
more.​ :(



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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2018-01-10  2:41     ` Li Wang
  2018-01-10 11:26       ` Jan Stancek
@ 2018-01-12 14:46       ` Jan Stancek
  2018-01-14  4:28         ` Li Wang
  1 sibling, 1 reply; 197+ messages in thread
From: Jan Stancek @ 2018-01-12 14:46 UTC (permalink / raw)
  To: ltp

> ​I ran LTP on the upstream kernel-4.15-rc6 across x86_64/ppc64(le)/s390x​,
> and catch some failures as below, ​but currently I haven't get a chance to
> look into the detail, just post here.​
> 
> 
> migrate_pages02   FAIL  x86_64

I posted patch for this, but since it's only rc kernels it can wait.

> shmt02/03/04/05/06/07/08/09/10   FAIL ppc64
> -------------------------------------------
> shmt02      1  TFAIL  :  shmt02.c:71: shmget Failed: shmid = -1, errno = 22
> shmt03      1  TFAIL  :  shmt03.c:72: shmget Failed: shmid = -1, errno = 22
> ...
> shmt10      2  TFAIL  :  shmt10.c:98: Error: shmid = -1

I haven't seen this in my tests. Are you able to reproduce it?

> switch01  FAIL  ppc64(le)

Just pushed patch for this one.

Regards,
Jan

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2018-01-10 11:26       ` Jan Stancek
  2018-01-10 11:42         ` Cyril Hrubis
@ 2018-01-12 14:33         ` Cyril Hrubis
  2018-01-17 15:27           ` Cyril Hrubis
  1 sibling, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2018-01-12 14:33 UTC (permalink / raw)
  To: ltp

Hi!
Is there anything else that should be looked into before the release?

I suppose that Jan should push the fix for ppc endian switch.

I will do a bit more testing next week and I would like to finish the
release ideally at the end of the next week. Is that okay with everyone
or do we need more time?

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2018-01-12 13:32 ` Richard Palethorpe
@ 2018-01-12 13:59   ` Cyril Hrubis
  0 siblings, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2018-01-12 13:59 UTC (permalink / raw)
  To: ltp

Hi!
> This can be included:
> https://github.com/linux-test-project/ltp/pull/238

Applied.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-12-20 11:33 Cyril Hrubis
  2018-01-09 18:17 ` Cyril Hrubis
@ 2018-01-12 13:32 ` Richard Palethorpe
  2018-01-12 13:59   ` Cyril Hrubis
  1 sibling, 1 reply; 197+ messages in thread
From: Richard Palethorpe @ 2018-01-12 13:32 UTC (permalink / raw)
  To: ltp

Hello,

Cyril Hrubis writes:

> Hi!
> As usuall we will produce a release in Jan 2018.
>
> I'm offline staring tomorrow and will return on Tuesday Jan 02. Feel
> free to start with replying to this email with a list of patches that
> should be included in the release, so that I can start picking them up
> once I return from the Christmas vacation.
>
> I would expect that we will spend at least a week with merging patches
> and at least a week with a testing and if everything goes well the
> release would be ready somewhere in the middle of the Jan 2018.
>
> And lastly but not least: Merry Winter solstice & happy Counter Overflow.

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

This can be included:
https://github.com/linux-test-project/ltp/pull/238

-- 
Thank you,
Richard.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2018-01-10 11:26       ` Jan Stancek
@ 2018-01-10 11:42         ` Cyril Hrubis
  2018-01-12 14:33         ` Cyril Hrubis
  1 sibling, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2018-01-10 11:42 UTC (permalink / raw)
  To: ltp

Hi!
> > msgctl11  FAIL  s390x
> > ----------------------
> > msgctl11    0  TINFO  :  Found 32000 available message queues
> > msgctl11    0  TINFO  :  Using upto 32698 pids
> > Fork failure in the second child of child group 682
> > Fork failure in the first child of child group 9
> > Fork failure in the first child of child group 191
> > ...
> > Fork failure in the first child of child group 1490
> > Fork failure in the first child of child group 1432
> > Fork failure in the second child of child group 1326
> > Fork failure in the first child of child group 1327
> > Fork failure in the first child of child group 638
> > msgctl11    1  TFAIL  :  msgctl11.c:205: Fork failed (may be OK if under
> > stress)
> 
> I have very old note this test spawns large number of children, so
> I'm assuming this is not a regression.

This fails unless you have at lest 2GB of memory on x86_64 but may need
more depending on system page size and system overcommit settings. I
recall that at some point kernel tracking of available memory got better
which caused this test to fail (instead of causing period of heavy
swapping).

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2018-01-10  2:41     ` Li Wang
@ 2018-01-10 11:26       ` Jan Stancek
  2018-01-10 11:42         ` Cyril Hrubis
  2018-01-12 14:33         ` Cyril Hrubis
  2018-01-12 14:46       ` Jan Stancek
  1 sibling, 2 replies; 197+ messages in thread
From: Jan Stancek @ 2018-01-10 11:26 UTC (permalink / raw)
  To: ltp



----- Original Message -----
> On Wed, Jan 10, 2018 at 2:47 AM, Jan Stancek <jstancek@redhat.com> wrote:
> 
> >
> >
> > ----- Original Message -----
> > > Hi!
> > > This is just a reminder that we should start working on the January
> > > stable release.
> > >
> > > I see that we included the meltdown test which I guess was one of the
> > > important enough patches to be included.
> > >
> > > Anything else that should be taken in before we freeze the git?
> > >
> > > I've did some preliminary testing (compiling and runnign LTP on a few
> > > selected distros) and haven't found any big issues so far, so it looks
> > > like this may as well be smoothest release ever (fingers crossed).
> >
> > I ran a test couple days ago with snapshot from 20180103 on RHEL6.2/6.9
> > and RHEL7.5(beta) across i386/x86_64/ppc64(le)/s390x. I'm planning
> > to try also some recent upstream kernel, but as you said so far
> > it looks good.
> >
> 
> ​I ran LTP on the upstream kernel-4.15-rc6 across x86_64/ppc64(le)/s390x​,
> and catch some failures as below, ​but currently I haven't get a chance to
> look into the detail, just post here.​
> 
> 
> migrate_pages02   FAIL  x86_64
> ------------------------------
> migrate_pages02    0  TINFO  :  pid(15539) migrate pid 0 to node -> 0
> migrate_pages02    9  TPASS  :  pid(15539) addr 0x194f840 is on expected
> node: 0
> migrate_pages02   10  TFAIL  :  migrate_pages02.c:165: pid(15539) addr
> 0x194f840 not on expected node: 0 , expected 1
> migrate_pages02    0  TINFO  :  mem_stats pid: 15539, node: 1
> migrate_pages02    0  TINFO  :  Node id: 1, size: 2044157952, free:
> 1439322112
> migrate_pages02    0  TINFO  :  pid(15535) migrate pid 15539 to node -> 1
> migrate_pages02    9  TFAIL  :  migrate_pages02.c:129: migrate_pages
> failed ret: -1, : errno=EPERM(1): Operation not permitted
> migrate_pages02    0  TINFO  :  mem_stats pid: 15539, node: 1
> migrate_pages02    0  TINFO  :  Node id: 1, size: 2044157952, free:
> 1439358976
> migrate_pages02   10  TFAIL  :  migrate_pages02.c:301: child returns 256

numactl -H output could be helpful here.

> 
> 
> 
> msgctl11  FAIL  s390x
> ----------------------
> msgctl11    0  TINFO  :  Found 32000 available message queues
> msgctl11    0  TINFO  :  Using upto 32698 pids
> Fork failure in the second child of child group 682
> Fork failure in the first child of child group 9
> Fork failure in the first child of child group 191
> ...
> Fork failure in the first child of child group 1490
> Fork failure in the first child of child group 1432
> Fork failure in the second child of child group 1326
> Fork failure in the first child of child group 1327
> Fork failure in the first child of child group 638
> msgctl11    1  TFAIL  :  msgctl11.c:205: Fork failed (may be OK if under
> stress)

I have very old note this test spawns large number of children, so
I'm assuming this is not a regression.

> 
> 
> 
> shmt02/03/04/05/06/07/08/09/10   FAIL ppc64
> -------------------------------------------
> shmt02      1  TFAIL  :  shmt02.c:71: shmget Failed: shmid = -1, errno = 22
> shmt03      1  TFAIL  :  shmt03.c:72: shmget Failed: shmid = -1, errno = 22
> ...
> shmt10      2  TFAIL  :  shmt10.c:98: Error: shmid = -1
> 
> 
> 
> switch01  FAIL  ppc64(le)
> ------------------------
> endian_switch01    1  TFAIL  :  endian_switch01.c:127: Got SIGILL - test
> failed

This is new failure since 4.15-rc1:
  commit 727f13616c45caa72e4325c5027c1a8f41e745a9
  Author: Michael Ellerman <mpe@ellerman.id.au>
  Date:   Mon Oct 9 21:54:05 2017 +1100
    powerpc: Disable the fast-endian switch syscall by default

One way would be to check if "/boot/config-$(uname -r)" exists
and contains "CONFIG_PPC_FAST_ENDIAN_SWITCH=y".

Or perhaps we can try to make switch only (0x1ebe), check if that
returns ENOSYS. If not we run current do_le_switch(). I'll try
this latter approach.

Regards,
Jan

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2018-01-09 18:47   ` Jan Stancek
@ 2018-01-10  2:41     ` Li Wang
  2018-01-10 11:26       ` Jan Stancek
  2018-01-12 14:46       ` Jan Stancek
  0 siblings, 2 replies; 197+ messages in thread
From: Li Wang @ 2018-01-10  2:41 UTC (permalink / raw)
  To: ltp

On Wed, Jan 10, 2018 at 2:47 AM, Jan Stancek <jstancek@redhat.com> wrote:

>
>
> ----- Original Message -----
> > Hi!
> > This is just a reminder that we should start working on the January
> > stable release.
> >
> > I see that we included the meltdown test which I guess was one of the
> > important enough patches to be included.
> >
> > Anything else that should be taken in before we freeze the git?
> >
> > I've did some preliminary testing (compiling and runnign LTP on a few
> > selected distros) and haven't found any big issues so far, so it looks
> > like this may as well be smoothest release ever (fingers crossed).
>
> I ran a test couple days ago with snapshot from 20180103 on RHEL6.2/6.9
> and RHEL7.5(beta) across i386/x86_64/ppc64(le)/s390x. I'm planning
> to try also some recent upstream kernel, but as you said so far
> it looks good.
>

​I ran LTP on the upstream kernel-4.15-rc6 across x86_64/ppc64(le)/s390x​,
and catch some failures as below, ​but currently I haven't get a chance to
look into the detail, just post here.​


migrate_pages02   FAIL  x86_64
------------------------------
migrate_pages02    0  TINFO  :  pid(15539) migrate pid 0 to node -> 0
migrate_pages02    9  TPASS  :  pid(15539) addr 0x194f840 is on expected node: 0
migrate_pages02   10  TFAIL  :  migrate_pages02.c:165: pid(15539) addr
0x194f840 not on expected node: 0 , expected 1
migrate_pages02    0  TINFO  :  mem_stats pid: 15539, node: 1
migrate_pages02    0  TINFO  :  Node id: 1, size: 2044157952, free: 1439322112
migrate_pages02    0  TINFO  :  pid(15535) migrate pid 15539 to node -> 1
migrate_pages02    9  TFAIL  :  migrate_pages02.c:129: migrate_pages
failed ret: -1, : errno=EPERM(1): Operation not permitted
migrate_pages02    0  TINFO  :  mem_stats pid: 15539, node: 1
migrate_pages02    0  TINFO  :  Node id: 1, size: 2044157952, free: 1439358976
migrate_pages02   10  TFAIL  :  migrate_pages02.c:301: child returns 256



msgctl11  FAIL  s390x
----------------------
msgctl11    0  TINFO  :  Found 32000 available message queues
msgctl11    0  TINFO  :  Using upto 32698 pids
Fork failure in the second child of child group 682
Fork failure in the first child of child group 9
Fork failure in the first child of child group 191
...
Fork failure in the first child of child group 1490
Fork failure in the first child of child group 1432
Fork failure in the second child of child group 1326
Fork failure in the first child of child group 1327
Fork failure in the first child of child group 638
msgctl11    1  TFAIL  :  msgctl11.c:205: Fork failed (may be OK if under stress)



shmt02/03/04/05/06/07/08/09/10   FAIL ppc64
-------------------------------------------
shmt02      1  TFAIL  :  shmt02.c:71: shmget Failed: shmid = -1, errno = 22
shmt03      1  TFAIL  :  shmt03.c:72: shmget Failed: shmid = -1, errno = 22
...
shmt10      2  TFAIL  :  shmt10.c:98: Error: shmid = -1



switch01  FAIL  ppc64(le)
------------------------
endian_switch01    1  TFAIL  :  endian_switch01.c:127: Got SIGILL - test failed


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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2018-01-09 18:17 ` Cyril Hrubis
@ 2018-01-09 18:47   ` Jan Stancek
  2018-01-10  2:41     ` Li Wang
  0 siblings, 1 reply; 197+ messages in thread
From: Jan Stancek @ 2018-01-09 18:47 UTC (permalink / raw)
  To: ltp



----- Original Message -----
> Hi!
> This is just a reminder that we should start working on the January
> stable release.
> 
> I see that we included the meltdown test which I guess was one of the
> important enough patches to be included.
> 
> Anything else that should be taken in before we freeze the git?
> 
> I've did some preliminary testing (compiling and runnign LTP on a few
> selected distros) and haven't found any big issues so far, so it looks
> like this may as well be smoothest release ever (fingers crossed).

I ran a test couple days ago with snapshot from 20180103 on RHEL6.2/6.9
and RHEL7.5(beta) across i386/x86_64/ppc64(le)/s390x. I'm planning
to try also some recent upstream kernel, but as you said so far
it looks good.

Regards,
Jan

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-12-20 11:33 Cyril Hrubis
@ 2018-01-09 18:17 ` Cyril Hrubis
  2018-01-09 18:47   ` Jan Stancek
  2018-01-12 13:32 ` Richard Palethorpe
  1 sibling, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2018-01-09 18:17 UTC (permalink / raw)
  To: ltp

Hi!
This is just a reminder that we should start working on the January
stable release.

I see that we included the meltdown test which I guess was one of the
important enough patches to be included.

Anything else that should be taken in before we freeze the git?

I've did some preliminary testing (compiling and runnign LTP on a few
selected distros) and haven't found any big issues so far, so it looks
like this may as well be smoothest release ever (fingers crossed).

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
@ 2017-12-20 11:33 Cyril Hrubis
  2018-01-09 18:17 ` Cyril Hrubis
  2018-01-12 13:32 ` Richard Palethorpe
  0 siblings, 2 replies; 197+ messages in thread
From: Cyril Hrubis @ 2017-12-20 11:33 UTC (permalink / raw)
  To: ltp

Hi!
As usuall we will produce a release in Jan 2018.

I'm offline staring tomorrow and will return on Tuesday Jan 02. Feel
free to start with replying to this email with a list of patches that
should be included in the release, so that I can start picking them up
once I return from the Christmas vacation.

I would expect that we will spend at least a week with merging patches
and at least a week with a testing and if everything goes well the
release would be ready somewhere in the middle of the Jan 2018.

And lastly but not least: Merry Winter solstice & happy Counter Overflow.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-09-14 14:17 ` Jan Stancek
@ 2017-09-14 15:14   ` Cyril Hrubis
  0 siblings, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2017-09-14 15:14 UTC (permalink / raw)
  To: ltp

Hi!
> > It's about a time we should start preparing for another release.
> > 
> > As usuall let's start with pointing out patches that should be part of
> > it, then we will proceed with freezing the repo and round of pre-release
> > testing, etc.
> 
> I started running tests (syscalls, misc, commands, etc.) across RHELs:
> 6.2-6.10(i386,x86_64,ppc64,s390x) and 7.0-7.4(x86_64, ppc64, ppc64le, s390x).
> 
> Other than couple small issues that have been fixed, and known kernel bugs,
> it's looking good.

It's looking good on my side as well.

I still want to fix the utimensat_tests.sh before the release that fails
on stable kernels that backported the fix.

Apart from that I would consider tmpfs for EROFS patch, since that one
may be a good speed up. And possibly the synchronization library for CVE
tests, if Richard manages to send updated patchset.

And that should ideally be all, or have I missed something?

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-09-07 10:59 Cyril Hrubis
                   ` (3 preceding siblings ...)
  2017-09-12  9:39 ` Richard Palethorpe
@ 2017-09-14 14:17 ` Jan Stancek
  2017-09-14 15:14   ` Cyril Hrubis
  4 siblings, 1 reply; 197+ messages in thread
From: Jan Stancek @ 2017-09-14 14:17 UTC (permalink / raw)
  To: ltp



----- Original Message -----
> Hi!
> It's about a time we should start preparing for another release.
> 
> As usuall let's start with pointing out patches that should be part of
> it, then we will proceed with freezing the repo and round of pre-release
> testing, etc.

I started running tests (syscalls, misc, commands, etc.) across RHELs:
6.2-6.10(i386,x86_64,ppc64,s390x) and 7.0-7.4(x86_64, ppc64, ppc64le, s390x).

Other than couple small issues that have been fixed, and known kernel bugs,
it's looking good.

I'm planning on repeating the tests after the freeze.

Regards,
Jan

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-09-12  9:39 ` Richard Palethorpe
@ 2017-09-12 12:16   ` Cyril Hrubis
  0 siblings, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2017-09-12 12:16 UTC (permalink / raw)
  To: ltp

Hi!
> As you might expect, I am very keen to get the long lived thread support
> for fuzzy sync into this release:
> 
>  tst_atomic: Add load, store and use __atomic builtins   
>  tst_atomic: Add atomic store and load tests   
>  fzsync: Add long running thread support and deviation stats   
>  fzsync: Add functionality test for library   
>  Convert cve-2016-7117 test to use long running threads   
>  Convert cve-2014-0196 to use long running threads   
>  Convert cve-2017-2671 to use long running threads   
> 
> Also the following patches would be nice:
> 
>  lib: Add personality fallback and SAFE macro   
>  CVE-2012-0957: Use SAFE_PERSONALITY   
>  Test for CVE-2016-10044 mark AIO pseudo-fs noexec   
> 
>  thp01: Find largest arguments size   
> 
>  Add test for CVE-2017-7308 on a raw socket's ring buffer   
> 
>  madvise07: Increase probability of testing a supported page type   

Ack, I will look into these.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-09-07 10:59 Cyril Hrubis
                   ` (2 preceding siblings ...)
  2017-09-08  1:49 ` Li Wang
@ 2017-09-12  9:39 ` Richard Palethorpe
  2017-09-12 12:16   ` Cyril Hrubis
  2017-09-14 14:17 ` Jan Stancek
  4 siblings, 1 reply; 197+ messages in thread
From: Richard Palethorpe @ 2017-09-12  9:39 UTC (permalink / raw)
  To: ltp

Hello,

Cyril Hrubis writes:

> Hi!
> It's about a time we should start preparing for another release.
>
> As usuall let's start with pointing out patches that should be part of
> it, then we will proceed with freezing the repo and round of pre-release
> testing, etc.
>
> -- 
> Cyril Hrubis
> chrubis@suse.cz

As you might expect, I am very keen to get the long lived thread support
for fuzzy sync into this release:

 tst_atomic: Add load, store and use __atomic builtins   
 tst_atomic: Add atomic store and load tests   
 fzsync: Add long running thread support and deviation stats   
 fzsync: Add functionality test for library   
 Convert cve-2016-7117 test to use long running threads   
 Convert cve-2014-0196 to use long running threads   
 Convert cve-2017-2671 to use long running threads   

Also the following patches would be nice:

 lib: Add personality fallback and SAFE macro   
 CVE-2012-0957: Use SAFE_PERSONALITY   
 Test for CVE-2016-10044 mark AIO pseudo-fs noexec   

 thp01: Find largest arguments size   

 Add test for CVE-2017-7308 on a raw socket's ring buffer   

 madvise07: Increase probability of testing a supported page type   

-- 
Thank you,
Richard.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-09-07 10:59 Cyril Hrubis
  2017-09-07 11:37 ` Petr Vorel
  2017-09-07 19:53 ` Sandeep Patil
@ 2017-09-08  1:49 ` Li Wang
  2017-09-12  9:39 ` Richard Palethorpe
  2017-09-14 14:17 ` Jan Stancek
  4 siblings, 0 replies; 197+ messages in thread
From: Li Wang @ 2017-09-08  1:49 UTC (permalink / raw)
  To: ltp

Hi Cyril,

These two patches for ksm are very worth to LTP.

http://lists.linux.it/pipermail/ltp/2017-August/005412.html

On Thu, Sep 7, 2017 at 6:59 PM, Cyril Hrubis <chrubis@suse.cz> wrote:
> Hi!
> It's about a time we should start preparing for another release.
>
> As usuall let's start with pointing out patches that should be part of
> it, then we will proceed with freezing the repo and round of pre-release
> testing, etc.
>
> --
> Cyril Hrubis
> chrubis@suse.cz
>
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp



-- 
Li Wang
liwang@redhat.com

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-09-07 10:59 Cyril Hrubis
  2017-09-07 11:37 ` Petr Vorel
@ 2017-09-07 19:53 ` Sandeep Patil
  2017-09-08  1:49 ` Li Wang
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 197+ messages in thread
From: Sandeep Patil @ 2017-09-07 19:53 UTC (permalink / raw)
  To: ltp

On Thu, Sep 07, 2017 at 12:59:21PM +0200, Cyril Hrubis wrote:
> Hi!
> It's about a time we should start preparing for another release.
> 
> As usuall let's start with pointing out patches that should be part of
> it, then we will proceed with freezing the repo and round of pre-release
> testing, etc.

Following pending review/commit right now from me

1. [LTP][RESEND][PATCH v2] android: pty01: Fix pty01 test for Android
2. [LTP][PATCH v4] input/input06: Fix auto-repeat key test
3. [LTP][PATCH v2] android: madvise08: fix for android devices

- ssp

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-09-07 10:59 Cyril Hrubis
@ 2017-09-07 11:37 ` Petr Vorel
  2017-09-07 19:53 ` Sandeep Patil
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 197+ messages in thread
From: Petr Vorel @ 2017-09-07 11:37 UTC (permalink / raw)
  To: ltp

Hi Alexey,

> It's about a time we should start preparing for another release.

> As usuall let's start with pointing out patches that should be part of
> it, then we will proceed with freezing the repo and round of pre-release
> testing, etc.

do you consider v9 of "Simplify network setup + fix some multicast network stress tests"
[1]
patch stable enough to be merged?
I've removed everything controversial (to be solved later), but you might have found some other issue.


Kind regards,
Petr

[1] http://lists.linux.it/pipermail/ltp/2017-August/005403.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
@ 2017-09-07 10:59 Cyril Hrubis
  2017-09-07 11:37 ` Petr Vorel
                   ` (4 more replies)
  0 siblings, 5 replies; 197+ messages in thread
From: Cyril Hrubis @ 2017-09-07 10:59 UTC (permalink / raw)
  To: ltp

Hi!
It's about a time we should start preparing for another release.

As usuall let's start with pointing out patches that should be part of
it, then we will proceed with freezing the repo and round of pre-release
testing, etc.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-05-19  9:36         ` Cyril Hrubis
@ 2017-05-19  9:46           ` Daniel Sangorrin
  0 siblings, 0 replies; 197+ messages in thread
From: Daniel Sangorrin @ 2017-05-19  9:46 UTC (permalink / raw)
  To: ltp

> -----Original Message-----
> From: Cyril Hrubis [mailto:chrubis@suse.cz]
> Sent: Friday, May 19, 2017 6:37 PM
...
> > Q2: Is there any mechanism in LTP for taking care of these kernels?
> >
> > I was thinking about it and I could only think of 2 solutions:
> >   1) Add such support manually (e.g. test against kernel 4.4.27 as well).
> >   2) Add an optional parameter to LTP with the location of the kernel git repository
> >        and branch. This way LTP tests could test against the existence of specific commit ids.
> >
> > The second solution would be very generic and work for any kernel but it's kind of
> > cumbersome. The first solution requires manual work so maybe too time consuming (I could help).
> > What do you think?
> 
> We actually have a mechanism to specify distribution specific kernel
> versions.
> 
> See:
> 
> commit 882f45a8e9d321ca108495517e25778a518eb58c
> Author: Cyril Hrubis <chrubis@suse.cz>
> Date:   Fri Apr 21 16:31:48 2017 +0200
> 
>     tst_kvcmp: Add support for extra kernel versions
> 
> 
> I guess that this could be adjusted for matching against LTS kernels as well.
> 
> 
> But in this case I guess that we may as well allow the test pass with
> both EACESS and EPERM in case of slightly older kernels. I.e. kernels
> that are older than oldest LTS kernel with that patch backported expect
> EACCES, kernels newer than the vanilla version with that patch expect
> EPERM and for kernels between this two test will work with both.

Thanks Cyril. I will prepare a patch then next week.

Thanks,
Daniel



^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-05-19  4:26       ` Daniel Sangorrin
@ 2017-05-19  9:36         ` Cyril Hrubis
  2017-05-19  9:46           ` Daniel Sangorrin
  0 siblings, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2017-05-19  9:36 UTC (permalink / raw)
  To: ltp

Hi!
> > From: ltp [mailto:ltp-bounces+daniel.sangorrin=toshiba.co.jp@lists.linux.it] On Behalf Of Jan Stancek
> > Sent: Saturday, May 06, 2017 12:42 AM
> > > Hi!
> > > > * utimensat01 - We reverted the fix before the last release and started
> > > >                 discussion on LKML but it seems that nobody cares so I
> > > > 		guess that we should reapply the patch and forget.
> > >
> > > Jan will you reapply the patch?
> > 
> > Tested on 4.11 and pushed.
> 
> I read your conversation here
> http://www.spinics.net/lists/linux-fsdevel/msg106449.html
> and it seems that the final conclusion was that EPERM was the right return 
> value (that's the reason you reapplied this patch I suppose). 

It seems that nobody cares enough to actually work on the issue.

> Q1: Does the man page for utimensat need an update then?
> Ref: https://github.com/mkerrisk/man-pages/blob/master/man2/utimensat.2

I guess that this is what we will have to do in the end. There is
practically no chance that the kernel patch will be reverted now.

> This LTP patch introduces a kernel version check (if tst_kvcmp -lt "4.8.0"; then). 
> Patch: https://github.com/linux-test-project/ltp/commit/b9157aee8fdeed1ef808fb490e5910e8750d7587
> 
> That seems fine if you are testing vanilla kernels only. I was wondering what 
> happens with LTS or Distro kernels though, because they usually have many backported patches.
> In particular the linux-stable kernel branch "linux-4.4.y" does include 
> commit f2b20f6ee842313a0d681dbbf7f87b70291a6a3b and I confirmed that
> that patch alone causes the LTP utimensat to return EPERM instead of EACESS.
> # I tested it by reverting the patch and running LTP again
> 
> Q2: Is there any mechanism in LTP for taking care of these kernels?
> 
> I was thinking about it and I could only think of 2 solutions:
>   1) Add such support manually (e.g. test against kernel 4.4.27 as well).
>   2) Add an optional parameter to LTP with the location of the kernel git repository
>        and branch. This way LTP tests could test against the existence of specific commit ids.
> 
> The second solution would be very generic and work for any kernel but it's kind of 
> cumbersome. The first solution requires manual work so maybe too time consuming (I could help).
> What do you think?

We actually have a mechanism to specify distribution specific kernel
versions.

See:

commit 882f45a8e9d321ca108495517e25778a518eb58c
Author: Cyril Hrubis <chrubis@suse.cz>
Date:   Fri Apr 21 16:31:48 2017 +0200

    tst_kvcmp: Add support for extra kernel versions


I guess that this could be adjusted for matching against LTS kernels as well.


But in this case I guess that we may as well allow the test pass with
both EACESS and EPERM in case of slightly older kernels. I.e. kernels
that are older than oldest LTS kernel with that patch backported expect
EACCES, kernels newer than the vanilla version with that patch expect
EPERM and for kernels between this two test will work with both.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-05-05 15:41     ` Jan Stancek
@ 2017-05-19  4:26       ` Daniel Sangorrin
  2017-05-19  9:36         ` Cyril Hrubis
  0 siblings, 1 reply; 197+ messages in thread
From: Daniel Sangorrin @ 2017-05-19  4:26 UTC (permalink / raw)
  To: ltp

Hi,

This is my first e-mail to the list. My name is Daniel and I've been integrating LTP into
the Fuego test framework.

> -----Original Message-----
> From: ltp [mailto:ltp-bounces+daniel.sangorrin=toshiba.co.jp@lists.linux.it] On Behalf Of Jan Stancek
> Sent: Saturday, May 06, 2017 12:42 AM
> > Hi!
> > > * utimensat01 - We reverted the fix before the last release and started
> > >                 discussion on LKML but it seems that nobody cares so I
> > > 		guess that we should reapply the patch and forget.
> >
> > Jan will you reapply the patch?
> 
> Tested on 4.11 and pushed.

I read your conversation here
http://www.spinics.net/lists/linux-fsdevel/msg106449.html
and it seems that the final conclusion was that EPERM was the right return 
value (that's the reason you reapplied this patch I suppose). 

Q1: Does the man page for utimensat need an update then?
Ref: https://github.com/mkerrisk/man-pages/blob/master/man2/utimensat.2

This LTP patch introduces a kernel version check (if tst_kvcmp -lt "4.8.0"; then). 
Patch: https://github.com/linux-test-project/ltp/commit/b9157aee8fdeed1ef808fb490e5910e8750d7587

That seems fine if you are testing vanilla kernels only. I was wondering what 
happens with LTS or Distro kernels though, because they usually have many backported patches.
In particular the linux-stable kernel branch "linux-4.4.y" does include 
commit f2b20f6ee842313a0d681dbbf7f87b70291a6a3b and I confirmed that
that patch alone causes the LTP utimensat to return EPERM instead of EACESS.
# I tested it by reverting the patch and running LTP again

Q2: Is there any mechanism in LTP for taking care of these kernels?

I was thinking about it and I could only think of 2 solutions:
  1) Add such support manually (e.g. test against kernel 4.4.27 as well).
  2) Add an optional parameter to LTP with the location of the kernel git repository
       and branch. This way LTP tests could test against the existence of specific commit ids.

The second solution would be very generic and work for any kernel but it's kind of 
cumbersome. The first solution requires manual work so maybe too time consuming (I could help).
What do you think?

Thanks,
Daniel

















^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-05-05 14:41   ` Cyril Hrubis
@ 2017-05-05 15:41     ` Jan Stancek
  2017-05-19  4:26       ` Daniel Sangorrin
  0 siblings, 1 reply; 197+ messages in thread
From: Jan Stancek @ 2017-05-05 15:41 UTC (permalink / raw)
  To: ltp



----- Original Message -----
> Hi!
> > * utimensat01 - We reverted the fix before the last release and started
> >                 discussion on LKML but it seems that nobody cares so I
> > 		guess that we should reapply the patch and forget.
> 
> Jan will you reapply the patch?

Tested on 4.11 and pushed.

Regards,
Jan

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-04-28 15:47 ` Cyril Hrubis
  2017-05-03  7:02   ` Jan Stancek
@ 2017-05-05 14:41   ` Cyril Hrubis
  2017-05-05 15:41     ` Jan Stancek
  1 sibling, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2017-05-05 14:41 UTC (permalink / raw)
  To: ltp

Hi!
> * utimensat01 - We reverted the fix before the last release and started
>                 discussion on LKML but it seems that nobody cares so I
> 		guess that we should reapply the patch and forget.

Jan will you reapply the patch?

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-04-28 15:47 ` Cyril Hrubis
@ 2017-05-03  7:02   ` Jan Stancek
  2017-05-05 14:41   ` Cyril Hrubis
  1 sibling, 0 replies; 197+ messages in thread
From: Jan Stancek @ 2017-05-03  7:02 UTC (permalink / raw)
  To: ltp



----- Original Message -----
> Hi!
> Here is a short list of problems I've found by pre-release testing:
> 
> * utimensat01 - We reverted the fix before the last release and started
>                 discussion on LKML but it seems that nobody cares so I
> 		guess that we should reapply the patch and forget.
> 
> * pselect01   - There seems to be some outliners, at least on SLES where
>                 the test request 200us sleep and ends up with up to
> 		1500us, I will have to have a closer look into this.
> 
> * syslog*     - Ends up with TBROK on Tumbleweed as it does not find
>                 any syslog running, possibly systemd related, needs
> 		to be investigated.
> 
> * madvise09   - Ends up with memsg.limits_in_bytes missing on kernel
>                 with unset CONFIG_MEMCG_SWAP_ENABLED (Tumbleweed again)
> 		I will have to look into that.
> 
> Anything else?

mmapstress04 heap overwrite, I need to make v2 of patch you already
reviewed.

> 
> Any other patches that should go in before the release?
> 
> --
> Cyril Hrubis
> chrubis@suse.cz
> 
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp
> 

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-04-24 16:25 Cyril Hrubis
                   ` (2 preceding siblings ...)
  2017-04-27 13:56 ` Richard Palethorpe
@ 2017-04-28 15:47 ` Cyril Hrubis
  2017-05-03  7:02   ` Jan Stancek
  2017-05-05 14:41   ` Cyril Hrubis
  3 siblings, 2 replies; 197+ messages in thread
From: Cyril Hrubis @ 2017-04-28 15:47 UTC (permalink / raw)
  To: ltp

Hi!
Here is a short list of problems I've found by pre-release testing:

* utimensat01 - We reverted the fix before the last release and started
                discussion on LKML but it seems that nobody cares so I
		guess that we should reapply the patch and forget.

* pselect01   - There seems to be some outliners, at least on SLES where
                the test request 200us sleep and ends up with up to
		1500us, I will have to have a closer look into this.

* syslog*     - Ends up with TBROK on Tumbleweed as it does not find
                any syslog running, possibly systemd related, needs
		to be investigated.

* madvise09   - Ends up with memsg.limits_in_bytes missing on kernel
                with unset CONFIG_MEMCG_SWAP_ENABLED (Tumbleweed again)
		I will have to look into that.

Anything else?

Any other patches that should go in before the release?

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-04-27 13:56 ` Richard Palethorpe
@ 2017-04-27 14:02   ` Cyril Hrubis
  0 siblings, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2017-04-27 14:02 UTC (permalink / raw)
  To: ltp

Hi!
> On a slightly different subject, I am thinking that as soon as possible after
> this release we merge the m32 and CVE patches into master? Then we can
> probably include them in the next release.

Agreed, I wanted to get them into this release but that would be rushed
at this point.

> There are now 8 CVE tests and a small library for reproducing race conditions
> in my dev branch. I am going to organise them into a single clean patch set
> for review before writing any more.

I will look at these once we are done with the release. So far it looks
good for me. I got only one simple complilation failure (already fixed
in git) and the results from testruns I've done so far looks mostly
good.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-04-24 16:25 Cyril Hrubis
  2017-04-25  2:29 ` Li Wang
  2017-04-25  3:42 ` Eryu Guan
@ 2017-04-27 13:56 ` Richard Palethorpe
  2017-04-27 14:02   ` Cyril Hrubis
  2017-04-28 15:47 ` Cyril Hrubis
  3 siblings, 1 reply; 197+ messages in thread
From: Richard Palethorpe @ 2017-04-27 13:56 UTC (permalink / raw)
  To: ltp

Hello,

On Mon, 24 Apr 2017 18:25:34 +0200
"Cyril Hrubis" <chrubis@suse.cz> wrote:

> Hi!
> It's about a time we should prepare for another release, hence as
> usuall, lets start with pointing out any patches that should be part of
> it and I would like to start with pre-release testing at the end of this
> week. Does that sound OK to everyone?
> 

On a slightly different subject, I am thinking that as soon as possible after
this release we merge the m32 and CVE patches into master? Then we can
probably include them in the next release.

There are now 8 CVE tests and a small library for reproducing race conditions
in my dev branch. I am going to organise them into a single clean patch set
for review before writing any more.

Thank you,
Richard.


^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-04-27  2:51       ` Li Wang
@ 2017-04-27  8:52         ` Jan Stancek
  0 siblings, 0 replies; 197+ messages in thread
From: Jan Stancek @ 2017-04-27  8:52 UTC (permalink / raw)
  To: ltp



----- Original Message -----
> On Wed, Apr 26, 2017 at 8:59 PM, Jan Stancek <jstancek@redhat.com> wrote:
> >
> >
> > ----- Original Message -----
> >> Hi!
> >> > > It's about a time we should prepare for another release, hence as
> >> > > usuall, lets start with pointing out any patches that should be part
> >> > > of
> >> > > it and I would like to start with pre-release testing at the end of
> >> > > this
> >> > > week. Does that sound OK to everyone?
> >> >
> >> > ioctl06 always failed on aarch64(others PASS) with upstream
> >> > kernel-4.11-rc[1-7]. Not sure if it is a bug or not, since i'm still
> >> > on debugging way. Just report here to let you know this.
> >
> > I'm seeing it fail on ppc as well (64k pages), with older RHEL7 kernels:
> >
> >> Looks like the value is rounded to be multiple of 128, that may be just
> >> intentional limitation, but we should better check with the kernel
> >> source or ask kernel devs.
> >
> > block/ioctl.c:
> >         case BLKRASET:
> >         case BLKFRASET:
> >                 if(!capable(CAP_SYS_ADMIN))
> >                         return -EACCES;
> >                 bdev->bd_bdi->ra_pages = (arg * 512) / PAGE_SIZE;
> >                 return 0;
> >
> 
> 
> how about makes change as:
> 
> --- a/testcases/kernel/syscalls/ioctl/ioctl06.c
> +++ b/testcases/kernel/syscalls/ioctl/ioctl06.c
> @@ -31,12 +31,13 @@ static int fd;
>  static void verify_ioctl(void)
>  {
>         unsigned long ra, rab, rao;
> +       unsigned long ra_shift = getpagesize() / 512;

This is just "8" for 4k pages. I'd go with increase
by 512 bytes - which is also what blockdev(8) allows
via --setra.

Regards,
Jan

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-04-26 12:59     ` Jan Stancek
@ 2017-04-27  2:51       ` Li Wang
  2017-04-27  8:52         ` Jan Stancek
  0 siblings, 1 reply; 197+ messages in thread
From: Li Wang @ 2017-04-27  2:51 UTC (permalink / raw)
  To: ltp

On Wed, Apr 26, 2017 at 8:59 PM, Jan Stancek <jstancek@redhat.com> wrote:
>
>
> ----- Original Message -----
>> Hi!
>> > > It's about a time we should prepare for another release, hence as
>> > > usuall, lets start with pointing out any patches that should be part of
>> > > it and I would like to start with pre-release testing at the end of this
>> > > week. Does that sound OK to everyone?
>> >
>> > ioctl06 always failed on aarch64(others PASS) with upstream
>> > kernel-4.11-rc[1-7]. Not sure if it is a bug or not, since i'm still
>> > on debugging way. Just report here to let you know this.
>
> I'm seeing it fail on ppc as well (64k pages), with older RHEL7 kernels:
>
>> Looks like the value is rounded to be multiple of 128, that may be just
>> intentional limitation, but we should better check with the kernel
>> source or ask kernel devs.
>
> block/ioctl.c:
>         case BLKRASET:
>         case BLKFRASET:
>                 if(!capable(CAP_SYS_ADMIN))
>                         return -EACCES;
>                 bdev->bd_bdi->ra_pages = (arg * 512) / PAGE_SIZE;
>                 return 0;
>


how about makes change as:

--- a/testcases/kernel/syscalls/ioctl/ioctl06.c
+++ b/testcases/kernel/syscalls/ioctl/ioctl06.c
@@ -31,12 +31,13 @@ static int fd;
 static void verify_ioctl(void)
 {
        unsigned long ra, rab, rao;
+       unsigned long ra_shift = getpagesize() / 512;

        SAFE_IOCTL(fd, BLKRAGET, &rao);

        tst_res(TINFO, "BLKRAGET original value %lu", rao);

-       for (ra = 0; ra <= 512; ra += 64) {
+       for (ra = 0; ra <= ra_shift * 8; ra += ra_shift) {
                SAFE_IOCTL(fd, BLKRASET, ra);
                SAFE_IOCTL(fd, BLKRAGET, &rab);




-- 
Regards,
Li Wang
Email: liwang@redhat.com

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
       [not found] <mailman.23773.1493091760.712.ltp@lists.linux.it>
@ 2017-04-26 15:33 ` Steve Ellcey
  0 siblings, 0 replies; 197+ messages in thread
From: Steve Ellcey @ 2017-04-26 15:33 UTC (permalink / raw)
  To: ltp


> Hi!
> It's about a time we should prepare for another release, hence as
> usuall, lets start with pointing out any patches that should be part of
> it and I would like to start with pre-release testing at the end of this
> week. Does that sound OK to everyone?
> 
> -- 
> Cyril Hrubis
> chrubis@suse.cz

I would like to see these patches included:

http://lists.linux.it/pipermail/ltp/2017-April/004300.html
http://lists.linux.it/pipermail/ltp/2017-April/004309.html

Steve Ellcey
sellcey@cavium.com

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-04-26  9:08   ` Cyril Hrubis
@ 2017-04-26 12:59     ` Jan Stancek
  2017-04-27  2:51       ` Li Wang
  0 siblings, 1 reply; 197+ messages in thread
From: Jan Stancek @ 2017-04-26 12:59 UTC (permalink / raw)
  To: ltp



----- Original Message -----
> Hi!
> > > It's about a time we should prepare for another release, hence as
> > > usuall, lets start with pointing out any patches that should be part of
> > > it and I would like to start with pre-release testing at the end of this
> > > week. Does that sound OK to everyone?
> > 
> > ioctl06 always failed on aarch64(others PASS) with upstream
> > kernel-4.11-rc[1-7]. Not sure if it is a bug or not, since i'm still
> > on debugging way. Just report here to let you know this.

I'm seeing it fail on ppc as well (64k pages), with older RHEL7 kernels:

> Looks like the value is rounded to be multiple of 128, that may be just
> intentional limitation, but we should better check with the kernel
> source or ask kernel devs.

block/ioctl.c:
        case BLKRASET:
        case BLKFRASET:
                if(!capable(CAP_SYS_ADMIN))
                        return -EACCES;
                bdev->bd_bdi->ra_pages = (arg * 512) / PAGE_SIZE;
                return 0;

Regards,
Jan

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-04-25  2:29 ` Li Wang
@ 2017-04-26  9:08   ` Cyril Hrubis
  2017-04-26 12:59     ` Jan Stancek
  0 siblings, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2017-04-26  9:08 UTC (permalink / raw)
  To: ltp

Hi!
> > It's about a time we should prepare for another release, hence as
> > usuall, lets start with pointing out any patches that should be part of
> > it and I would like to start with pre-release testing at the end of this
> > week. Does that sound OK to everyone?
> 
> ioctl06 always failed on aarch64(others PASS) with upstream
> kernel-4.11-rc[1-7]. Not sure if it is a bug or not, since i'm still
> on debugging way. Just report here to let you know this.
> 
> # uname -rm
> 4.11.0-rc7 aarch64
> 
> # ./ioctl06
> tst_device.c:82: INFO: Found free device '/dev/loop1'
> tst_test.c:847: INFO: Timeout per run is 0h 05m 00s
> ioctl06.c:37: INFO: BLKRAGET original value 256
> ioctl06.c:44: PASS: BLKRASET 0 read back correctly
> ioctl06.c:46: FAIL: BLKRASET 64 read back 0
> ioctl06.c:44: PASS: BLKRASET 128 read back correctly
> ioctl06.c:46: FAIL: BLKRASET 192 read back 128
> ioctl06.c:44: PASS: BLKRASET 256 read back correctly
> ioctl06.c:46: FAIL: BLKRASET 320 read back 256
> ioctl06.c:44: PASS: BLKRASET 384 read back correctly
> ioctl06.c:46: FAIL: BLKRASET 448 read back 384
> ioctl06.c:44: PASS: BLKRASET 512 read back correctly
> ioctl06.c:49: INFO: BLKRASET restoring original value 256

Looks like the value is rounded to be multiple of 128, that may be just
intentional limitation, but we should better check with the kernel
source or ask kernel devs.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-04-24 16:25 Cyril Hrubis
  2017-04-25  2:29 ` Li Wang
@ 2017-04-25  3:42 ` Eryu Guan
  2017-04-27 13:56 ` Richard Palethorpe
  2017-04-28 15:47 ` Cyril Hrubis
  3 siblings, 0 replies; 197+ messages in thread
From: Eryu Guan @ 2017-04-25  3:42 UTC (permalink / raw)
  To: ltp

Hi Cyril,

On Mon, Apr 24, 2017 at 06:25:34PM +0200, Cyril Hrubis wrote:
> Hi!
> It's about a time we should prepare for another release, hence as
> usuall, lets start with pointing out any patches that should be part of
> it and I would like to start with pre-release testing at the end of this
> week. Does that sound OK to everyone?

Any chance to get these new splice(2) syscall tests in?

http://lists.linux.it/pipermail/ltp/2017-April/004311.html

Thanks,
Eryu

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2017-04-24 16:25 Cyril Hrubis
@ 2017-04-25  2:29 ` Li Wang
  2017-04-26  9:08   ` Cyril Hrubis
  2017-04-25  3:42 ` Eryu Guan
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 197+ messages in thread
From: Li Wang @ 2017-04-25  2:29 UTC (permalink / raw)
  To: ltp

Hi,

On Tue, Apr 25, 2017 at 12:25 AM, Cyril Hrubis <chrubis@suse.cz> wrote:
> Hi!
> It's about a time we should prepare for another release, hence as
> usuall, lets start with pointing out any patches that should be part of
> it and I would like to start with pre-release testing at the end of this
> week. Does that sound OK to everyone?

ioctl06 always failed on aarch64(others PASS) with upstream
kernel-4.11-rc[1-7]. Not sure if it is a bug or not, since i'm still
on debugging way. Just report here to let you know this.

# uname -rm
4.11.0-rc7 aarch64

# ./ioctl06
tst_device.c:82: INFO: Found free device '/dev/loop1'
tst_test.c:847: INFO: Timeout per run is 0h 05m 00s
ioctl06.c:37: INFO: BLKRAGET original value 256
ioctl06.c:44: PASS: BLKRASET 0 read back correctly
ioctl06.c:46: FAIL: BLKRASET 64 read back 0
ioctl06.c:44: PASS: BLKRASET 128 read back correctly
ioctl06.c:46: FAIL: BLKRASET 192 read back 128
ioctl06.c:44: PASS: BLKRASET 256 read back correctly
ioctl06.c:46: FAIL: BLKRASET 320 read back 256
ioctl06.c:44: PASS: BLKRASET 384 read back correctly
ioctl06.c:46: FAIL: BLKRASET 448 read back 384
ioctl06.c:44: PASS: BLKRASET 512 read back correctly
ioctl06.c:49: INFO: BLKRASET restoring original value 256

Summary:
passed   5
failed   4
skipped  0
warnings 0


-- 
Regards,
Li Wang
Email: liwang@redhat.com

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
@ 2017-04-24 16:25 Cyril Hrubis
  2017-04-25  2:29 ` Li Wang
                   ` (3 more replies)
  0 siblings, 4 replies; 197+ messages in thread
From: Cyril Hrubis @ 2017-04-24 16:25 UTC (permalink / raw)
  To: ltp

Hi!
It's about a time we should prepare for another release, hence as
usuall, lets start with pointing out any patches that should be part of
it and I would like to start with pre-release testing at the end of this
week. Does that sound OK to everyone?

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2016-09-19 12:11   ` Cyril Hrubis
@ 2016-09-19 14:08     ` Alexey Kodanev
  0 siblings, 0 replies; 197+ messages in thread
From: Alexey Kodanev @ 2016-09-19 14:08 UTC (permalink / raw)
  To: ltp

Cyril,
On 09/19/2016 03:11 PM, Cyril Hrubis wrote:
> Hi!
>> Network tests looks good, I have sent patches with new/rewritten tests
>> that could be part of release.
>> All are well tested on OL6 and OL7 except NFS multi-mount test:
>>
>> * busy_poll: new busy_poll03 test over UDP + added support for UDP in
>> tcp_fastopen (I guess we should rename it later to a more generic name):
>>     patch-set "network/tcp_fastopen: use UDP optionally"
>>
>> * arp: rewritten arp01 test + added support for IPv6 ndisc:
>>     patch-set "network/tcp_cmds/arp01: use test_net.sh and add test-cases
>> with 'ip neigh'";
>>
>> * ping: new ping02 test instead of removed perf_lan:
>>     patch-set: "network/ping01: rename file and update runtest files";
>>
>> * nfs: added support for multiple mounts in nfs_lib.sh, rewritten nfs06
>> test:
>>     patch-set "network/nfs_lib: add support for multiple mounts"
> I've commented some minor issue for the ping tests, the rest looks good
> to me.

Thank you for reviewing these patch-sets! I've corrected ping and nfs06 
tests.

Patches applied.

Best regards,
Alexey


^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2016-09-15 10:18 ` Alexey Kodanev
@ 2016-09-19 12:11   ` Cyril Hrubis
  2016-09-19 14:08     ` Alexey Kodanev
  0 siblings, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2016-09-19 12:11 UTC (permalink / raw)
  To: ltp

Hi!
> Network tests looks good, I have sent patches with new/rewritten tests 
> that could be part of release.
> All are well tested on OL6 and OL7 except NFS multi-mount test:
> 
> * busy_poll: new busy_poll03 test over UDP + added support for UDP in 
> tcp_fastopen (I guess we should rename it later to a more generic name):
>    patch-set "network/tcp_fastopen: use UDP optionally"
> 
> * arp: rewritten arp01 test + added support for IPv6 ndisc:
>    patch-set "network/tcp_cmds/arp01: use test_net.sh and add test-cases 
> with 'ip neigh'";
> 
> * ping: new ping02 test instead of removed perf_lan:
>    patch-set: "network/ping01: rename file and update runtest files";
> 
> * nfs: added support for multiple mounts in nfs_lib.sh, rewritten nfs06 
> test:
>    patch-set "network/nfs_lib: add support for multiple mounts"

I've commented some minor issue for the ping tests, the rest looks good
to me.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2016-09-14 11:29 [LTP] LTP Release Cyril Hrubis
  2016-09-14 12:59 ` Jan Stancek
  2016-09-15 10:18 ` Alexey Kodanev
@ 2016-09-16  8:22 ` Stanislav Kholmanskikh
  2 siblings, 0 replies; 197+ messages in thread
From: Stanislav Kholmanskikh @ 2016-09-16  8:22 UTC (permalink / raw)
  To: ltp



On 09/14/2016 02:29 PM, Cyril Hrubis wrote:
> Hi!
> I'm more or less finished with pre-release testing. What is the status
> for the rest of you?

Tried the latest master in my sparc setup. Didn't observe any unexpected
failures/issues. Though I use a relatively old kernel, so many test
cases finish with TCONF.

> 
> I guess that we slould fix the lsmod test failing on NFS before the
> release.

I will not be able to proceed with lsmod + NFSv4, since I'll be on
vacation next week. If nobody objects, I'd not treat this as a blocker,
and fix it sometimes after the release.

> 
> Anything else? Can we proceed with the release later this week?
> 

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2016-09-14 11:29 [LTP] LTP Release Cyril Hrubis
  2016-09-14 12:59 ` Jan Stancek
@ 2016-09-15 10:18 ` Alexey Kodanev
  2016-09-19 12:11   ` Cyril Hrubis
  2016-09-16  8:22 ` Stanislav Kholmanskikh
  2 siblings, 1 reply; 197+ messages in thread
From: Alexey Kodanev @ 2016-09-15 10:18 UTC (permalink / raw)
  To: ltp

Hi,

On 09/14/2016 02:29 PM, Cyril Hrubis wrote:
> Hi!
> I'm more or less finished with pre-release testing. What is the status
> for the rest of you?
>
> I guess that we slould fix the lsmod test failing on NFS before the
> release.
>
> Anything else? Can we proceed with the release later this week?

Network tests looks good, I have sent patches with new/rewritten tests 
that could be part of release.
All are well tested on OL6 and OL7 except NFS multi-mount test:

* busy_poll: new busy_poll03 test over UDP + added support for UDP in 
tcp_fastopen (I guess we should rename it later to a more generic name):
   patch-set "network/tcp_fastopen: use UDP optionally"

* arp: rewritten arp01 test + added support for IPv6 ndisc:
   patch-set "network/tcp_cmds/arp01: use test_net.sh and add test-cases 
with 'ip neigh'";

* ping: new ping02 test instead of removed perf_lan:
   patch-set: "network/ping01: rename file and update runtest files";

* nfs: added support for multiple mounts in nfs_lib.sh, rewritten nfs06 
test:
   patch-set "network/nfs_lib: add support for multiple mounts"

Thanks,
Alexey


^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2016-09-14 12:59 ` Jan Stancek
@ 2016-09-14 13:51   ` Cyril Hrubis
  0 siblings, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2016-09-14 13:51 UTC (permalink / raw)
  To: ltp

Hi!
> > I guess that we slould fix the lsmod test failing on NFS before the
> > release.
> > 
> > Anything else?
> 
> There was a report about readahead02 using wrong path for "read_ahead_kb",
> when running on raw partitions. Patch seems simple, I just need to test it,
> I'll try to do that today.

Ah that one. I should fix it for Btrfs as well as Btrfs uses anonymous
block devices and the sysfs is not populated for these. We have to get
link to the device from /sys/fs/btrfs/<fsid>/devices.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2016-09-14 11:29 [LTP] LTP Release Cyril Hrubis
@ 2016-09-14 12:59 ` Jan Stancek
  2016-09-14 13:51   ` Cyril Hrubis
  2016-09-15 10:18 ` Alexey Kodanev
  2016-09-16  8:22 ` Stanislav Kholmanskikh
  2 siblings, 1 reply; 197+ messages in thread
From: Jan Stancek @ 2016-09-14 12:59 UTC (permalink / raw)
  To: ltp





----- Original Message -----
> From: "Cyril Hrubis" <chrubis@suse.cz>
> To: ltp@lists.linux.it
> Sent: Wednesday, 14 September, 2016 1:29:47 PM
> Subject: [LTP] LTP Release
> 
> Hi!
> I'm more or less finished with pre-release testing. What is the status
> for the rest of you?

Results from RHEL6.2/6.7, RHEL7.0/7.1/7.3 across all arches 
look good here.

> 
> I guess that we slould fix the lsmod test failing on NFS before the
> release.
> 
> Anything else?

There was a report about readahead02 using wrong path for "read_ahead_kb",
when running on raw partitions. Patch seems simple, I just need to test it,
I'll try to do that today.

Regards,
Jan

> Can we proceed with the release later this week?
> 
> --
> Cyril Hrubis
> chrubis@suse.cz
> 
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp
> 

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
@ 2016-09-14 11:29 Cyril Hrubis
  2016-09-14 12:59 ` Jan Stancek
                   ` (2 more replies)
  0 siblings, 3 replies; 197+ messages in thread
From: Cyril Hrubis @ 2016-09-14 11:29 UTC (permalink / raw)
  To: ltp

Hi!
I'm more or less finished with pre-release testing. What is the status
for the rest of you?

I guess that we slould fix the lsmod test failing on NFS before the
release.

Anything else? Can we proceed with the release later this week?

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2016-08-16 14:25 Cyril Hrubis
@ 2016-08-17 14:42 ` Stanislav Kholmanskikh
  0 siblings, 0 replies; 197+ messages in thread
From: Stanislav Kholmanskikh @ 2016-08-17 14:42 UTC (permalink / raw)
  To: ltp



On 08/16/2016 05:25 PM, Cyril Hrubis wrote:
> Hi!
> It's about the time we start to prepare for another LTP release.
> 
> As usuall lets start with patches that should be merged before we
> declare pre-release freeze and start the testing.
> 
> So please let me know if there are any patches that should be part of
> the release.
> 

Hi!

It would be wonderful to have the two series included before the freeze:
 * waitpid part 2
   http://lists.linux.it/pipermail/ltp/2016-August/002438.html

 * memcg/functional
   http://lists.linux.it/pipermail/ltp/2016-June/002001.html

With both the series the ball is on my side though. I think I'll be able
to address your comments to the waitpid series by EOD tomorrow, and to
the memcg/functional - by EOD next Monday (Aug 22).

Thanks.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
@ 2016-08-16 14:25 Cyril Hrubis
  2016-08-17 14:42 ` Stanislav Kholmanskikh
  0 siblings, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2016-08-16 14:25 UTC (permalink / raw)
  To: ltp

Hi!
It's about the time we start to prepare for another LTP release.

As usuall lets start with patches that should be merged before we
declare pre-release freeze and start the testing.

So please let me know if there are any patches that should be part of
the release.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2016-05-09 15:59 ` Cyril Hrubis
@ 2016-05-09 16:12   ` Cyril Hrubis
  0 siblings, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2016-05-09 16:12 UTC (permalink / raw)
  To: ltp

Hi!
> I've just pushed last two patches, the fix for isofs and one obvious fix
> for netns_netlink.c that causes the test exit with reasonable error
> rather than fail silently
                           ^ in system() then later fail in recv()
-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2016-05-03 12:46 Cyril Hrubis
  2016-05-04  2:28 ` Li Wang
@ 2016-05-09 15:59 ` Cyril Hrubis
  2016-05-09 16:12   ` Cyril Hrubis
  1 sibling, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2016-05-09 15:59 UTC (permalink / raw)
  To: ltp

Hi!
I've just pushed last two patches, the fix for isofs and one obvious fix
for netns_netlink.c that causes the test exit with reasonable error
rather than fail silently in recv().

I do not want to delay the release anymore, since we are quite late
anyway. Is there something that absolutely must be part of the release
or can I proceed with the release procedure tomorrow?

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2016-05-04 11:54   ` Cyril Hrubis
@ 2016-05-05  6:13     ` Li Wang
  0 siblings, 0 replies; 197+ messages in thread
From: Li Wang @ 2016-05-05  6:13 UTC (permalink / raw)
  To: ltp

On Wed, May 04, 2016 at 01:54:32PM +0200, Cyril Hrubis wrote:
> Hi!
> > > Are there any pending issues/patches that should be solved/applied
> > > before the release?
> > 
> > How about the following patch set? are there any possible to handle
> > them before the release time?
> > 
> > http://lists.linux.it/pipermail/ltp/2016-April/001533.html
> 
> Is not executed in default_scenario so the risk of changing it just
> before the release is low. I suppose that the testcases does not work
> correctly without these changes, right?

yes, right. I'm OK to skip these fix for current LTP released.

and the other simple one as well.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2016-05-04  2:37   ` Li Wang
@ 2016-05-04 11:56     ` Cyril Hrubis
  0 siblings, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2016-05-04 11:56 UTC (permalink / raw)
  To: ltp

Hi!
> sorry, and a small one:
> http://lists.linux.it/pipermail/ltp/2016-April/001529.html

This does not seem do any visible change, therefore I would say that it
can wait after the release.

Or do I miss something?

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2016-05-04  2:28 ` Li Wang
  2016-05-04  2:37   ` Li Wang
@ 2016-05-04 11:54   ` Cyril Hrubis
  2016-05-05  6:13     ` Li Wang
  1 sibling, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2016-05-04 11:54 UTC (permalink / raw)
  To: ltp

Hi!
> > Are there any pending issues/patches that should be solved/applied
> > before the release?
> 
> How about the following patch set? are there any possible to handle
> them before the release time?
> 
> http://lists.linux.it/pipermail/ltp/2016-April/001533.html

Is not executed in default_scenario so the risk of changing it just
before the release is low. I suppose that the testcases does not work
correctly without these changes, right?

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2016-05-04  2:28 ` Li Wang
@ 2016-05-04  2:37   ` Li Wang
  2016-05-04 11:56     ` Cyril Hrubis
  2016-05-04 11:54   ` Cyril Hrubis
  1 sibling, 1 reply; 197+ messages in thread
From: Li Wang @ 2016-05-04  2:37 UTC (permalink / raw)
  To: ltp

On Wed, May 4, 2016 at 10:28 AM, Li Wang <liwang@redhat.com> wrote:
> Hi Cyril,
>
> On Tue, May 3, 2016 at 8:46 PM, Cyril Hrubis <chrubis@suse.cz> wrote:
>> Hi!
>> Are there any pending issues/patches that should be solved/applied
>> before the release?
>
> How about the following patch set? are there any possible to handle
> them before the release time?
>
> http://lists.linux.it/pipermail/ltp/2016-April/001533.html

sorry, and a small one:
http://lists.linux.it/pipermail/ltp/2016-April/001529.html

>
>>
>> I would like to get merged the fix for isofs testcase[1], if nobody objects
>> to it and that would be all from my side.
>>
>> Can we carry on with the release at the start of the next week?
>>
>>
>> [1]: [LTP] [PATCH] fs/isofs.sh: Don't use /etc/ for the image
>>
>> --
>> Cyril Hrubis
>> chrubis@suse.cz
>>
>> --
>> Mailing list info: https://lists.linux.it/listinfo/ltp
>
>
>
> --
> Regards,
> Li Wang
> Email: liwang@redhat.com



-- 
Regards,
Li Wang
Email: liwang@redhat.com

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
  2016-05-03 12:46 Cyril Hrubis
@ 2016-05-04  2:28 ` Li Wang
  2016-05-04  2:37   ` Li Wang
  2016-05-04 11:54   ` Cyril Hrubis
  2016-05-09 15:59 ` Cyril Hrubis
  1 sibling, 2 replies; 197+ messages in thread
From: Li Wang @ 2016-05-04  2:28 UTC (permalink / raw)
  To: ltp

Hi Cyril,

On Tue, May 3, 2016 at 8:46 PM, Cyril Hrubis <chrubis@suse.cz> wrote:
> Hi!
> Are there any pending issues/patches that should be solved/applied
> before the release?

How about the following patch set? are there any possible to handle
them before the release time?

http://lists.linux.it/pipermail/ltp/2016-April/001533.html

>
> I would like to get merged the fix for isofs testcase[1], if nobody objects
> to it and that would be all from my side.
>
> Can we carry on with the release at the start of the next week?
>
>
> [1]: [LTP] [PATCH] fs/isofs.sh: Don't use /etc/ for the image
>
> --
> Cyril Hrubis
> chrubis@suse.cz
>
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp



-- 
Regards,
Li Wang
Email: liwang@redhat.com

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
@ 2016-05-03 12:46 Cyril Hrubis
  2016-05-04  2:28 ` Li Wang
  2016-05-09 15:59 ` Cyril Hrubis
  0 siblings, 2 replies; 197+ messages in thread
From: Cyril Hrubis @ 2016-05-03 12:46 UTC (permalink / raw)
  To: ltp

Hi!
Are there any pending issues/patches that should be solved/applied
before the release?

I would like to get merged the fix for isofs testcase[1], if nobody objects
to it and that would be all from my side.

Can we carry on with the release at the start of the next week?


[1]: [LTP] [PATCH] fs/isofs.sh: Don't use /etc/ for the image

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2016-01-25 12:28 ` Cyril Hrubis
  2016-01-26  6:41   ` Li Wang
@ 2016-01-26  9:57   ` Stanislav Kholmanskikh
  1 sibling, 0 replies; 197+ messages in thread
From: Stanislav Kholmanskikh @ 2016-01-26  9:57 UTC (permalink / raw)
  To: ltp



On 01/25/2016 03:28 PM, Cyril Hrubis wrote:
> Hi!
>> Can we do the release on Monday or Tuesday?
>
> I've just pushed the cgroup_fj fix. Please have a look at it and ideally
> run cgroup_fj the tests today, it should take less than hour.

Executed cgroup_fj with an in-house sparc64 kernel - they all passed, 
and the current 4.1-based kernel in Linux for SPARC - the stress tests 
cause a panic (but it's a known not-yet-fixed issue in the kernel).

>
> The only two outstanding issues should now be fallocate04 and ROD with
> redirection. I will have a look at the fallocate04 patch now, then try
> to do something about the ROD redirection.
>
> If nothing else shows up I will tag the git and do the release tomorrow.
>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2016-01-25 12:28 ` Cyril Hrubis
@ 2016-01-26  6:41   ` Li Wang
  2016-01-26  9:57   ` Stanislav Kholmanskikh
  1 sibling, 0 replies; 197+ messages in thread
From: Li Wang @ 2016-01-26  6:41 UTC (permalink / raw)
  To: ltp

Hi,

On Mon, Jan 25, 2016 at 8:28 PM, Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> > Can we do the release on Monday or Tuesday?
>
> I've just pushed the cgroup_fj fix. Please have a look at it and ideally
> run cgroup_fj the tests today, it should take less than hour.
>
> The only two outstanding issues should now be fallocate04 and ROD with
> redirection. I will have a look at the fallocate04 patch now, then try
> to do something about the ROD redirection.
>

I did a quick ltp/mem[sched] test on RHEL7.2 with upstream-v4.4 kernel, it
works fine except one thp05.c fails.

looks like the issue exist so long time with any kernel on x86_64 numa
system.I just post a simple patch try to fix that.


>
> If nothing else shows up I will tag the git and do the release tomorrow.
>

Fine.


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



-- 
Regards,
Li Wang
Email: liwang@redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20160126/99982a58/attachment.html>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2016-01-21 17:41 [LTP] LTP release Cyril Hrubis
                   ` (2 preceding siblings ...)
  2016-01-25 10:47 ` Alexey Kodanev
@ 2016-01-25 12:28 ` Cyril Hrubis
  2016-01-26  6:41   ` Li Wang
  2016-01-26  9:57   ` Stanislav Kholmanskikh
  3 siblings, 2 replies; 197+ messages in thread
From: Cyril Hrubis @ 2016-01-25 12:28 UTC (permalink / raw)
  To: ltp

Hi!
> Can we do the release on Monday or Tuesday?

I've just pushed the cgroup_fj fix. Please have a look at it and ideally
run cgroup_fj the tests today, it should take less than hour.

The only two outstanding issues should now be fallocate04 and ROD with
redirection. I will have a look at the fallocate04 patch now, then try
to do something about the ROD redirection.

If nothing else shows up I will tag the git and do the release tomorrow.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2016-01-25 10:47 ` Alexey Kodanev
@ 2016-01-25 12:20   ` Cyril Hrubis
  0 siblings, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2016-01-25 12:20 UTC (permalink / raw)
  To: ltp

Hi!
> > Just now I'm testing last set of changes for cgroup_fj tests (in the end
> > these were too bugy so I've did a partial rewrite) and once that is done
> > and pushed the release is green from my side. Minus the ROD problem that
> > I've posted earlier but that can be workarounded for the release.
> >
> > What is the status from the rest of you?
> >
> > Can we do the release on Monday or Tuesday?
> 
> There is fallocate04 test that is failing on UEK1 (kernel 2.6.32).
> I think we need to apply Shuang's patch that fixes it:
> [PATCH] syscall/fallocate04:skip test02 before kernel 2.6.38
> 
> fallocate() doesn't return EOPNOTSUPP errno there, but silently proceed with
> FALLOC_FL_PUNCH_HOLE flag.

Ok. I will have a look at the patch.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2016-01-21 17:41 [LTP] LTP release Cyril Hrubis
  2016-01-22 11:16 ` Jan Stancek
  2016-01-25  9:48 ` Stanislav Kholmanskikh
@ 2016-01-25 10:47 ` Alexey Kodanev
  2016-01-25 12:20   ` Cyril Hrubis
  2016-01-25 12:28 ` Cyril Hrubis
  3 siblings, 1 reply; 197+ messages in thread
From: Alexey Kodanev @ 2016-01-25 10:47 UTC (permalink / raw)
  To: ltp

Hi,
On 01/21/2016 08:41 PM, Cyril Hrubis wrote:
> Hi!
> Just now I'm testing last set of changes for cgroup_fj tests (in the end
> these were too bugy so I've did a partial rewrite) and once that is done
> and pushed the release is green from my side. Minus the ROD problem that
> I've posted earlier but that can be workarounded for the release.
>
> What is the status from the rest of you?
>
> Can we do the release on Monday or Tuesday?

There is fallocate04 test that is failing on UEK1 (kernel 2.6.32).
I think we need to apply Shuang's patch that fixes it:
[PATCH] syscall/fallocate04:skip test02 before kernel 2.6.38

fallocate() doesn't return EOPNOTSUPP errno there, but silently proceed with
FALLOC_FL_PUNCH_HOLE flag.

Thanks,
Alexey

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2016-01-21 17:41 [LTP] LTP release Cyril Hrubis
  2016-01-22 11:16 ` Jan Stancek
@ 2016-01-25  9:48 ` Stanislav Kholmanskikh
  2016-01-25 10:47 ` Alexey Kodanev
  2016-01-25 12:28 ` Cyril Hrubis
  3 siblings, 0 replies; 197+ messages in thread
From: Stanislav Kholmanskikh @ 2016-01-25  9:48 UTC (permalink / raw)
  To: ltp

Hi!

On 01/21/2016 08:41 PM, Cyril Hrubis wrote:
> Hi!
> Just now I'm testing last set of changes for cgroup_fj tests (in the end
> these were too bugy so I've did a partial rewrite) and once that is done
> and pushed the release is green from my side. Minus the ROD problem that
> I've posted earlier but that can be workarounded for the release.
>
> What is the status from the rest of you?

I observe several failures in my environment (a sparc64 in-house 
kernel), but they look like environmental/kernel issues and should not 
be considered as blockers.

>
> Can we do the release on Monday or Tuesday?
>

Fine by me.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
  2016-01-21 17:41 [LTP] LTP release Cyril Hrubis
@ 2016-01-22 11:16 ` Jan Stancek
  2016-01-25  9:48 ` Stanislav Kholmanskikh
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 197+ messages in thread
From: Jan Stancek @ 2016-01-22 11:16 UTC (permalink / raw)
  To: ltp





----- Original Message -----
> From: "Cyril Hrubis" <chrubis@suse.cz>
> To: ltp@lists.linux.it
> Sent: Thursday, 21 January, 2016 6:41:02 PM
> Subject: [LTP] LTP release
> 
> Hi!
> Just now I'm testing last set of changes for cgroup_fj tests (in the end
> these were too bugy so I've did a partial rewrite) and once that is done
> and pushed the release is green from my side. Minus the ROD problem that
> I've posted earlier but that can be workarounded for the release.
> 
> What is the status from the rest of you?

Hi,

I did compile + run test (with subset of runtest files) on
RHEL5.6/RHEL6.2/6.7/7.2 (i386/x86_64/ppc64/s390x), which worked
OK with one exception below.

One issue I keep hitting is oom0X hang [1], but since it's there for
months we don't need to hold release for that (I don't have any
tested patch yet).

What I'm thinking is to introduce a parameter to control how many threads
we allow to race towards OOM. At the moment it's NCPU-1, which appears
to be too stressful for regular runtest files. It hangs kernels from
3.10 up to 4.4 and there's no fix atm.

[1] http://lists.linux.it/pipermail/ltp/2016-January/000807.html

> 
> Can we do the release on Monday or Tuesday?

Fine by me.

Regards,
Jan

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
@ 2016-01-21 17:41 Cyril Hrubis
  2016-01-22 11:16 ` Jan Stancek
                   ` (3 more replies)
  0 siblings, 4 replies; 197+ messages in thread
From: Cyril Hrubis @ 2016-01-21 17:41 UTC (permalink / raw)
  To: ltp

Hi!
Just now I'm testing last set of changes for cgroup_fj tests (in the end
these were too bugy so I've did a partial rewrite) and once that is done
and pushed the release is green from my side. Minus the ROD problem that
I've posted earlier but that can be workarounded for the release.

What is the status from the rest of you?

Can we do the release on Monday or Tuesday?

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP release
  2015-08-13 12:30 Cyril Hrubis
  2015-08-20 15:06 ` Cyril Hrubis
@ 2015-09-02 11:28 ` Cyril Hrubis
  1 sibling, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2015-09-02 11:28 UTC (permalink / raw)
  To: ltp-list

Hi!
I've just pushed last patch that has been requested to be included in
the relese. Unless anybody objects I will proceed with tagging the git,
uploading the tarballs, etc. tomorrow.

If you haven't tested latest git yet, now is the last chance to do so.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP release
       [not found]     ` <55E53DA4.6090005@cn.fujitsu.com>
  2015-09-01 11:42       ` Cyril Hrubis
@ 2015-09-01 15:35       ` Cyril Hrubis
  1 sibling, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2015-09-01 15:35 UTC (permalink / raw)
  To: Guangwen Feng; +Cc: ltp-list, jjaburek

Hi!
> > Now the only problem that that blocks the release on my side are
> > failures of the newly rewritten netns testcases that were discussed
> > last week.
> > 
> 
> In RHEL5.11GA, ns_ifmove.c gives compilation error since 'IFLA_NET_NS_PID'
> undeclared in the kernel.

Should be fixed in latest git, please test (don't forget to regenerate
configure script).

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP release
       [not found]         ` <1488894521.16163428.1441112961686.JavaMail.zimbra@redhat.com>
@ 2015-09-01 13:14           ` Cyril Hrubis
  0 siblings, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2015-09-01 13:14 UTC (permalink / raw)
  To: Matus Marhefka; +Cc: ltp-list, jjaburek

Hi!
> another solution could be to let ns_ifmove.c as it is (so it won't build)
> and only add a check for binaries:
> tst_check_cmds ns_create ns_exec ns_ifmove

We would have to ingore the return value from the ns_ifmove build, which
means custom rule in the Makefile, which is ugly.

> to the netns test code. On the other hand, this will produce unclear
> output from the netns testcases, you will only know that ns_ifmove
> binary is unavailable, but won't know why.
> 
> The other way, as you pointed out, would be to check for kernel version
> and propagate TCONF to the netns_helper.sh. The patch which adds what we
> need ('IFLA_NET_NS_PID') to the kernel is:
> http://lists.linuxfoundation.org/pipermail/containers/2007-September/007113.html

Kernel version is completly orthogonal problem here.

The compilation fails since the IFLA_NET_NS_PID is not present in
linux/if_link.h. I've just finished a patch that adds autoconf check for
the constant, adds ifdefs into the ns_ifmove and propagates TCONF from
ns_ifmove to the helper. This may still fail if somebody runs the test
on recent enough userspace with older kernel. But I doubt that this will
be the case, at least for any released distribution.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP release
       [not found]     ` <75454012.15990077.1441091460626.JavaMail.zimbra@redhat.com>
@ 2015-09-01 11:43       ` Cyril Hrubis
  0 siblings, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2015-09-01 11:43 UTC (permalink / raw)
  To: Matus Marhefka; +Cc: ltp-list, Jiri Jaburek

Hi!
> as you mentioned, the problem in ns_exec was setns'ing the "user" namespace,
> I think it would be sufficient to just comment/remove this line:
> rf |= open_ns_fd(argv[1], "user");
> from ns_exec.c or even all calls to open_ns_fd() function except for the network
> namespace as it is used in netns testcases. I will rewrite ns_create and ns_exec
> after the release.

I was trying to be more defensive and remove everything that is not
needed, but I can live with this solution as well.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP release
       [not found]     ` <55E53DA4.6090005@cn.fujitsu.com>
@ 2015-09-01 11:42       ` Cyril Hrubis
       [not found]         ` <1488894521.16163428.1441112961686.JavaMail.zimbra@redhat.com>
  2015-09-01 15:35       ` Cyril Hrubis
  1 sibling, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2015-09-01 11:42 UTC (permalink / raw)
  To: Guangwen Feng; +Cc: ltp-list, jjaburek

Hi!
> > I've did my release testing and pushed a few fixes, mosty minor ones.
> > 
> > Now the only problem that that blocks the release on my side are
> > failures of the newly rewritten netns testcases that were discussed
> > last week.
> > 
> 
> In RHEL5.11GA, ns_ifmove.c gives compilation error since 'IFLA_NET_NS_PID'
> undeclared in the kernel.

Looks like we need a configure check for the enum constant and way to
propagate TCONF from the ns_ifmove to the netns_helper.sh.

I will look into this.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP release
  2015-08-20 15:06 ` Cyril Hrubis
@ 2015-08-31 11:23   ` Cyril Hrubis
       [not found]     ` <55E53DA4.6090005@cn.fujitsu.com>
       [not found]     ` <75454012.15990077.1441091460626.JavaMail.zimbra@redhat.com>
  0 siblings, 2 replies; 197+ messages in thread
From: Cyril Hrubis @ 2015-08-31 11:23 UTC (permalink / raw)
  To: ltp-list; +Cc: Jiri Jaburek

Hi!
I've did my release testing and pushed a few fixes, mosty minor ones.

Now the only problem that that blocks the release on my side are
failures of the newly rewritten netns testcases that were discussed
last week.

Jiri: What about changing the ns_exec to join only net namespace for
      now and rewriting it after the release?

Everybody: If you have issues with the latest git please report them.
           And if you haven't tested it yet please do so ASAP.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP release
  2015-08-13 12:30 Cyril Hrubis
@ 2015-08-20 15:06 ` Cyril Hrubis
  2015-08-31 11:23   ` Cyril Hrubis
  2015-09-02 11:28 ` Cyril Hrubis
  1 sibling, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2015-08-20 15:06 UTC (permalink / raw)
  To: ltp-list

Hi!
> It's about the time we start preparing for another release.
> 
> I would like to get the release ready somewhere at the end of this
> month. Does everyone think that this is manageable?
> 
> So as usually if there are patches that should be part of the release or
> bugs that should be fixed before we start pre-release testing, please
> let us know.

If nobody objects I would like to freeze LTP git repository on Monday
(24. 08.) and start the pre-release testing.

If there are any patches that should be included the release, please let
me know.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
@ 2015-08-13 12:30 Cyril Hrubis
  2015-08-20 15:06 ` Cyril Hrubis
  2015-09-02 11:28 ` Cyril Hrubis
  0 siblings, 2 replies; 197+ messages in thread
From: Cyril Hrubis @ 2015-08-13 12:30 UTC (permalink / raw)
  To: ltp-list

Hi!
It's about the time we start preparing for another release.

I would like to get the release ready somewhere at the end of this
month. Does everyone think that this is manageable?

So as usually if there are patches that should be part of the release or
bugs that should be fixed before we start pre-release testing, please
let us know.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP release
       [not found]       ` <552B91F1.3050901@oracle.com>
@ 2015-04-14  9:19         ` Cyril Hrubis
  0 siblings, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2015-04-14  9:19 UTC (permalink / raw)
  To: Stanislav Kholmanskikh; +Cc: ltp-list

Hi!
> >> We have several issues in our sparc64 environment. Need a day or two to
> >> figure out whether they are test case issues or problems with our
> >> environment.
> >
> > Ok.
> >
> 
> Finally, there are only two test case issues:
>   * cpuhotplug04 fails if there is no 'online' file in 
> /sys/devices/system/cpu/cpuXX/
>   * sem_comm fails because it doesn't use 'union semun' with semctl()
> 
> Patches to the problems were sent.
> 
> I suppose that cpuhotplug* fixes may be postponed for a later time, but 
> it would be good to have the sem_comm fixes in this release.

The 'union semun' patches looks good, acked. Please push these.

And that should be, hopefully, last patches going into the release.

I will do a full testrun once these paches are pushed and if everything
works fine I will tag the release. Does everybody agree?

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP release
       [not found]   ` <5523ED09.4050509@oracle.com>
@ 2015-04-07 15:27     ` Cyril Hrubis
       [not found]       ` <552B91F1.3050901@oracle.com>
  0 siblings, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2015-04-07 15:27 UTC (permalink / raw)
  To: Stanislav Kholmanskikh; +Cc: ltp-list

Hi!
> >> It's about the time we start to prepare for next release. I will
> >> (hopefully) start runing latest git code and look for unexpected
> >> failures during this week. Everybody please try to run the latest
> >> git code and report any problems.
> >
> > I've seen email from Jan that the release is green from his side.
> > (haven't got it because we had an email outgate in the SUSE and it seems
> > some emails were lost :(, if you get errors for my suse email account do
> > not hestitate to resend).
> >
> > What is the status from the rest of you?
> >
> 
> We have several issues in our sparc64 environment. Need a day or two to 
> figure out whether they are test case issues or problems with our 
> environment.

Ok.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP release
  2015-03-23  9:43 Cyril Hrubis
@ 2015-04-02 10:09 ` Cyril Hrubis
       [not found]   ` <5523ED09.4050509@oracle.com>
  0 siblings, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2015-04-02 10:09 UTC (permalink / raw)
  To: ltp-list

Hi!
> It's about the time we start to prepare for next release. I will
> (hopefully) start runing latest git code and look for unexpected
> failures during this week. Everybody please try to run the latest
> git code and report any problems.

I've seen email from Jan that the release is green from his side.
(haven't got it because we had an email outgate in the SUSE and it seems
some emails were lost :(, if you get errors for my suse email account do
not hestitate to resend).

What is the status from the rest of you?

From my side, I've fixed a few problem I've found but there are still
two things I want to fix before the release.

One is aligment bug causing aiocp with O_DIRECT exit with EINVAL on
s390x with 4096 block size. That should be fixed with block size
autodetection for O_DIRECT.

And the second is with the rewrite of the exec* testcases (without the p
in the name). The problem is that the machinery that runs tests in SUSE
does not execute the testcases in the $LTPROOT/testcases/bin directory,
and these testcases fail to find the child binary. Solution I have in
mind is to create a function similar to tst_dataroot() that will fill a
buffer with a path to the binary (so that the tests works both in git
checkout and executed from installed tree). Is anybody opposed to this
idea?

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
@ 2015-03-23  9:43 Cyril Hrubis
  2015-04-02 10:09 ` Cyril Hrubis
  0 siblings, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2015-03-23  9:43 UTC (permalink / raw)
  To: ltp-list

Hi!
It's about the time we start to prepare for next release. I will
(hopefully) start runing latest git code and look for unexpected
failures during this week. Everybody please try to run the latest
git code and report any problems.

If there is anything that should be solved/applied before the release,
plese let us know.

(My current plan is to have a look at the power_management fixes.)

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP release
       [not found] ` <54B3FD5E.5040209@oracle.com>
@ 2015-01-13  9:53   ` Cyril Hrubis
  0 siblings, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2015-01-13  9:53 UTC (permalink / raw)
  To: Alexey Kodanev; +Cc: ltp-list

Hi!
> > I'm back at work as promised and so we should start with the release
> > preparations. Let's start with the list of patches that should go in
> > before we start pre-release testing. I've looked around and good
> > candidates for what should be merged are:
> >
> > 1. timeouts for nets tests
> > 2. tbio fixes
> >
> > Anything else?
> 
> What about network/tcp_cmds/finger fixes? Though the patch v4 has minor 
> issues, but they can be fixed before push.

I'm fine with getting it in before the release. I will look at the patch
ASAP.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
@ 2015-01-05 14:42 Cyril Hrubis
       [not found] ` <54B3FD5E.5040209@oracle.com>
  0 siblings, 1 reply; 197+ messages in thread
From: Cyril Hrubis @ 2015-01-05 14:42 UTC (permalink / raw)
  To: ltp-list

Hi!
I'm back at work as promised and so we should start with the release
preparations. Let's start with the list of patches that should go in
before we start pre-release testing. I've looked around and good
candidates for what should be merged are:

1. timeouts for nets tests
2. tbio fixes

Anything else?

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
@ 2014-12-18 13:48 Cyril Hrubis
  0 siblings, 0 replies; 197+ messages in thread
From: Cyril Hrubis @ 2014-12-18 13:48 UTC (permalink / raw)
  To: ltp-list

Hello everyone,
it's about the time we do another release, but as most of the people
(including me) will have time off around Christmas and New Year the best
course of action will be to start the release procedure once we are back
at work. I should be back at 5. 1. 2015.

Also the LWN.net article, for which I've started the survey, has been
released today. Many thanks for all the responses. (It's in the
subscriber section, so unless you have a subscription you have to wait
till it's available to public).

Lastly but not least Merry Christmas and Happy New Year to all who
celebrate them.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
@ 2014-08-27  8:14 chrubis
  0 siblings, 0 replies; 197+ messages in thread
From: chrubis @ 2014-08-27  8:14 UTC (permalink / raw)
  To: ltp-list

Good news everyone!

After numerous testruns and more than ten patches fixing various test
failures we are about to produce a stable LTP release.

If you have any regressions or fixes that should be part of the release,
you can still raise the issues today.

The git will be tagged tomorrow and the tarballs uploaded to sf.net site
shortly after.

All that is left here is to thank you all for you hard work :).

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
@ 2014-07-29 10:31 chrubis
  0 siblings, 0 replies; 197+ messages in thread
From: chrubis @ 2014-07-29 10:31 UTC (permalink / raw)
  To: ltp-list

If I'm counting right we should do a release anytime soon.

Before we do a release freeze and round of testing what patches should
go in?

I personally would like to finish conversion to the tst_acquire_device()
interface (6 tests). Anything else?

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP release
       [not found] ` <534ED26A.6040508@gmx.de>
@ 2014-04-16 18:58   ` chrubis
  0 siblings, 0 replies; 197+ messages in thread
From: chrubis @ 2014-04-16 18:58 UTC (permalink / raw)
  To: Helge Deller; +Cc: ltp-list

Hi!
> > With the last three patches for fallocate testcases the latest git head
> 
> I do have a patch for fanotify to fix it on 32bit with 64bit kernel. 
> Give me a second to send it.

No rush, I will have a look tomorrow morning ;).

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
@ 2014-04-16 18:51 chrubis
       [not found] ` <534ED26A.6040508@gmx.de>
  0 siblings, 1 reply; 197+ messages in thread
From: chrubis @ 2014-04-16 18:51 UTC (permalink / raw)
  To: ltp-list

Hi!
With the last three patches for fallocate testcases the latest git head
builds fine for me and there are no regressions on distros I watch. Does
it work for everybody else too? Is there anything that would prevent
release at the end of this week?

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP Release
       [not found]     ` <534BE117.3070008@oracle.com>
@ 2014-04-14 13:59       ` chrubis
  0 siblings, 0 replies; 197+ messages in thread
From: chrubis @ 2014-04-14 13:59 UTC (permalink / raw)
  To: Alexey Kodanev; +Cc: ltp-list

Hi!
> >> The warning was added 11 years ago and even at that time it was quite
> >> old... so gcc-2.95.3 (embedded systems?) doesn't have it.
> > Strange, it fails with gcc-3.3.3 on SLES for me. Anyway it's a matter of
> > simple configure check which I will write :).
> I did it in the following patch: 
> http://sourceforge.net/p/ltp/mailman/message/32213977

Faster than me :)

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP Release
       [not found] ` <5346F29E.7020402@oracle.com>
@ 2014-04-14 11:58   ` chrubis
       [not found]     ` <534BE117.3070008@oracle.com>
  0 siblings, 1 reply; 197+ messages in thread
From: chrubis @ 2014-04-14 11:58 UTC (permalink / raw)
  To: Alexey Kodanev; +Cc: ltp-list

Hi!
> The warning was added 11 years ago and even at that time it was quite 
> old... so gcc-2.95.3 (embedded systems?) doesn't have it.

Strange, it fails with gcc-3.3.3 on SLES for me. Anyway it's a matter of
simple configure check which I will write :).

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
@ 2014-04-10 16:52 chrubis
       [not found] ` <5346F29E.7020402@oracle.com>
  0 siblings, 1 reply; 197+ messages in thread
From: chrubis @ 2014-04-10 16:52 UTC (permalink / raw)
  To: ltp-list

Hi!
If nothing unexpected happens I would like to do a release at the end of
the next week.

What that means for you?

You should grab the latest git and make sure that it compiles and runs
fine. I've allready started with building latest git and found that we
need a autoconf check for -Wold-style-definition that is not supported
by old gcc.

Also consider the git repository frozen (minus the things I've promised
to merge before the release) for anything but fixes for serious bugs
regressions, compilation failures, etc.


That said, let's aim for a good quality release :)

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP release
  2014-04-01 13:50 [LTP] LTP release Joseph Beckenbach
@ 2014-04-01 14:22 ` chrubis
  0 siblings, 0 replies; 197+ messages in thread
From: chrubis @ 2014-04-01 14:22 UTC (permalink / raw)
  To: Joseph Beckenbach; +Cc: ltp-list

Hi!
> As one of the guys provoking this release, I'll take it upon myself to
> investigate how to update this package in Debian, package it, and get
> it released through to Debian for distribution.  The packages there
> claim to refer to LTP sources as of 2009-12-31 at latest.

That sounds great :).

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP release
@ 2014-04-01 13:50 Joseph Beckenbach
  2014-04-01 14:22 ` chrubis
  0 siblings, 1 reply; 197+ messages in thread
From: Joseph Beckenbach @ 2014-04-01 13:50 UTC (permalink / raw)
  To: ltp-list

As one of the guys provoking this release, I'll take it upon myself to investigate how to update this package in Debian, package it, and get it released through to Debian for distribution.
The packages there claim to refer to LTP sources as of 2009-12-31 at latest.

Thanks!

Joseph
Joseph Beckenbach, senior QA engineer : Automation
Lancope, Inc.

------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP Release
       [not found] ` <533A5F9C.6000907@oracle.com>
@ 2014-04-01 10:58   ` chrubis
  0 siblings, 0 replies; 197+ messages in thread
From: chrubis @ 2014-04-01 10:58 UTC (permalink / raw)
  To: Alexey Kodanev; +Cc: ltp-list

Hi!
> > Looking at the pending patches there are at least two patches that
> > should be sorted out. The out-of-tree build and the bashism in
> > testcases. I will make sure these two issues are handled soon.
> >
> > Are there any other patches that should be part of the next release?
> >
> Could you please look at the TCP Fast Open patch, I've recently sent 
> version 7 <http://sourceforge.net/p/ltp/mailman/message/32147204/> where 
> I moved some of the common code to the shell library: "lib/test_net.sh: 
> add network help script 
> <http://sourceforge.net/p/ltp/mailman/message/32141161/>". The last one 
> is the stopper for vxlan test as well.

Noted, I will look into these two as well.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP Release
@ 2014-03-31 16:03 chrubis
       [not found] ` <533A5F9C.6000907@oracle.com>
  0 siblings, 1 reply; 197+ messages in thread
From: chrubis @ 2014-03-31 16:03 UTC (permalink / raw)
  To: ltp-list

Hi!
If I'm counting right, we should start preparations for next LTP release.

Looking at the pending patches there are at least two patches that
should be sorted out. The out-of-tree build and the bashism in
testcases. I will make sure these two issues are handled soon.

Are there any other patches that should be part of the next release?

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [LTP] LTP release
  2014-01-14 12:05 [LTP] LTP release chrubis
@ 2014-01-14 15:54 ` chrubis
  0 siblings, 0 replies; 197+ messages in thread
From: chrubis @ 2014-01-14 15:54 UTC (permalink / raw)
  To: ltp-list

Hi!
> I've just commited a latest pack of fixes to LTP. The last commit
> included in the release will likely be 6f22494.
> 
> I will do one more build and testrun before this is final, because Mike
> commited a few fixes and changes in lib looks serious enough to be
> retested. You can check that the lastest git works for you too.
> 
> If nothing serious shows up (which should really be the case) I will
> ping Shubham to tag the release and upload the tarballs in the
> evening.

Everything looks OK. Shubham please go ahead and do the release.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [LTP] LTP release
@ 2014-01-14 12:05 chrubis
  2014-01-14 15:54 ` chrubis
  0 siblings, 1 reply; 197+ messages in thread
From: chrubis @ 2014-01-14 12:05 UTC (permalink / raw)
  To: ltp-list

Hi!
I've just commited a latest pack of fixes to LTP. The last commit
included in the release will likely be 6f22494.

I will do one more build and testrun before this is final, because Mike
commited a few fixes and changes in lib looks serious enough to be
retested. You can check that the lastest git works for you too.

If nothing serious shows up (which should really be the case) I will
ping Shubham to tag the release and upload the tarballs in the
evening.

Lastly but not least big thanks to everybody who helped with LTP
development. :)

PS: Please refrain from commiting anything to git until the release is
    finished.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply	[flat|nested] 197+ messages in thread

end of thread, other threads:[~2023-01-24 20:58 UTC | newest]

Thread overview: 197+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-14 15:09 [LTP] LTP Release Cyril Hrubis
2018-12-18  9:17 ` Petr Vorel
2019-01-02 10:28 ` Cyril Hrubis
2019-01-04 15:42   ` Cyril Hrubis
2019-01-07  2:18     ` Xiao Yang
2019-01-11 13:25     ` Cyril Hrubis
2019-01-11 16:16       ` Cristian Marussi
2019-01-14 12:43         ` Petr Vorel
  -- strict thread matches above, loose matches on Subject: below --
2023-01-16 13:31 [LTP] LTP release Cyril Hrubis
2023-01-16 15:23 ` Richard Palethorpe
2023-01-16 16:31   ` Petr Vorel
2023-01-17  4:07     ` Wei Gao via ltp
2023-01-17  8:04       ` Petr Vorel
2023-01-17 11:02   ` Richard Palethorpe
2023-01-20 12:16 ` Cyril Hrubis
2023-01-24 12:47   ` Petr Vorel
2023-01-24 20:58     ` Petr Vorel
2021-05-06  7:19 [LTP] LTP Release Cyril Hrubis
2021-05-06  8:10 ` Petr Vorel
2021-05-06 13:02 ` Petr Vorel
2021-05-07 14:31   ` Petr Vorel
2021-05-10  9:11     ` Cyril Hrubis
2021-05-10 14:47       ` Petr Vorel
2021-05-10 14:58         ` Cyril Hrubis
2021-05-10 15:30           ` Martin Doucha
2021-05-10 16:49             ` Petr Vorel
2021-05-10 16:37               ` Cyril Hrubis
2021-05-10 17:24                 ` Petr Vorel
2021-05-06 15:35 ` Martin Doucha
2021-05-07  3:10 ` Li Wang
2021-05-07 12:40   ` Cyril Hrubis
2021-05-07 16:56 ` Petr Vorel
2021-05-10  7:17   ` Richard Palethorpe
2021-05-11 11:30 ` Cyril Hrubis
2020-09-08  7:31 [LTP] LTP release Cyril Hrubis
2020-09-08  7:37 ` Yang Xu
2020-09-08  7:45 ` Li Wang
2020-09-08 15:36   ` Cyril Hrubis
2020-09-09  8:46     ` Li Wang
2020-09-09 12:16       ` Li Wang
2020-09-09 13:13         ` Cyril Hrubis
2020-09-09 13:27           ` Cyril Hrubis
2020-09-10  7:19             ` Li Wang
2020-09-10  9:22               ` Li Wang
2020-09-14  7:52                 ` Cixi Geng
2020-09-14 11:00                   ` Cyril Hrubis
2020-09-14 17:51                     ` Bird, Tim
2020-09-15  1:18                       ` Cixi Geng
2020-09-15  9:59                       ` Cyril Hrubis
2020-09-10  7:12           ` Li Wang
2020-09-09 20:11 ` Petr Vorel
2020-09-10  8:45 ` Petr Vorel
2020-09-14 11:15   ` Cyril Hrubis
2020-09-14 22:30     ` Bird, Tim
2020-09-15  5:28       ` Petr Vorel
2020-09-18 14:57       ` Cyril Hrubis
2020-09-21 18:04         ` Bird, Tim
2020-09-22 18:21 ` Cyril Hrubis
2020-09-23  6:50   ` Li Wang
2020-09-23  6:58     ` Li Wang
2020-09-23  9:29       ` Petr Vorel
2020-09-23  9:42         ` Xiao Yang
2020-09-23 12:23       ` Xiao Yang
2020-09-23 12:56         ` Li Wang
     [not found] <5ebe1570.1c69fb81.46edc.a08cSMTPIN_ADDED_BROKEN@mx.google.com>
2020-05-15  4:16 ` Li Wang
2020-05-04 10:49 Cyril Hrubis
2020-05-04 11:09 ` Martin Doucha
2020-05-04 11:16   ` Cyril Hrubis
2020-05-14  9:54 ` Cyril Hrubis
2020-05-14  9:58   ` Yang Xu
2020-05-14 12:11     ` Cyril Hrubis
2020-05-14 13:45       ` Xiao Yang
2020-05-15  3:37   ` Li Wang
2019-09-06 13:07 [LTP] LTP Release Cyril Hrubis
2019-09-06 13:48 ` Richard Palethorpe
2019-09-09  7:46 ` Li Wang
2019-09-10 13:05   ` Cyril Hrubis
2019-09-26 10:43     ` Thadeu Lima de Souza Cascardo
2019-09-10  6:51 ` =?unknown-8bit?b?WWFuZy/lvpAg5p2o?=
2019-09-10 13:56   ` Cyril Hrubis
2019-09-13 13:07 ` Petr Vorel
2019-09-25 11:22 ` Cyril Hrubis
2019-09-26  8:29   ` Jan Stancek
2019-09-26  8:33     ` Cyril Hrubis
2019-09-26  8:54       ` Jan Stancek
2019-09-26  9:08         ` Cyril Hrubis
2019-09-26  9:52           ` Jan Stancek
2019-09-26  9:02   ` Li Wang
2019-04-18 11:18 Cyril Hrubis
2019-04-23  8:40 ` Petr Vorel
2019-04-26 13:12 ` Cyril Hrubis
2019-04-28  5:25   ` Li Wang
2019-04-29 11:59     ` Cyril Hrubis
2019-04-30  3:09       ` Li Wang
2019-04-29 10:20   ` Petr Vorel
2019-04-29 13:13     ` Cyril Hrubis
2019-04-29 14:33       ` Cyril Hrubis
2019-04-29 21:07         ` Petr Vorel
2019-04-30  9:05           ` Cyril Hrubis
2019-04-29 20:45       ` Petr Vorel
2019-04-30  9:04         ` Cyril Hrubis
2019-04-30 12:35           ` Petr Vorel
2019-05-14  7:16 ` Li Wang
2019-05-14 12:23   ` Cyril Hrubis
2019-05-15 13:55 ` Cyril Hrubis
2018-08-30 15:53 [LTP] LTP release Cyril Hrubis
2018-08-31  5:20 ` vaishnavi.d
2017-12-20 11:33 Cyril Hrubis
2018-01-09 18:17 ` Cyril Hrubis
2018-01-09 18:47   ` Jan Stancek
2018-01-10  2:41     ` Li Wang
2018-01-10 11:26       ` Jan Stancek
2018-01-10 11:42         ` Cyril Hrubis
2018-01-12 14:33         ` Cyril Hrubis
2018-01-17 15:27           ` Cyril Hrubis
2018-01-12 14:46       ` Jan Stancek
2018-01-14  4:28         ` Li Wang
2018-01-12 13:32 ` Richard Palethorpe
2018-01-12 13:59   ` Cyril Hrubis
2017-09-07 10:59 Cyril Hrubis
2017-09-07 11:37 ` Petr Vorel
2017-09-07 19:53 ` Sandeep Patil
2017-09-08  1:49 ` Li Wang
2017-09-12  9:39 ` Richard Palethorpe
2017-09-12 12:16   ` Cyril Hrubis
2017-09-14 14:17 ` Jan Stancek
2017-09-14 15:14   ` Cyril Hrubis
     [not found] <mailman.23773.1493091760.712.ltp@lists.linux.it>
2017-04-26 15:33 ` Steve Ellcey
2017-04-24 16:25 Cyril Hrubis
2017-04-25  2:29 ` Li Wang
2017-04-26  9:08   ` Cyril Hrubis
2017-04-26 12:59     ` Jan Stancek
2017-04-27  2:51       ` Li Wang
2017-04-27  8:52         ` Jan Stancek
2017-04-25  3:42 ` Eryu Guan
2017-04-27 13:56 ` Richard Palethorpe
2017-04-27 14:02   ` Cyril Hrubis
2017-04-28 15:47 ` Cyril Hrubis
2017-05-03  7:02   ` Jan Stancek
2017-05-05 14:41   ` Cyril Hrubis
2017-05-05 15:41     ` Jan Stancek
2017-05-19  4:26       ` Daniel Sangorrin
2017-05-19  9:36         ` Cyril Hrubis
2017-05-19  9:46           ` Daniel Sangorrin
2016-09-14 11:29 [LTP] LTP Release Cyril Hrubis
2016-09-14 12:59 ` Jan Stancek
2016-09-14 13:51   ` Cyril Hrubis
2016-09-15 10:18 ` Alexey Kodanev
2016-09-19 12:11   ` Cyril Hrubis
2016-09-19 14:08     ` Alexey Kodanev
2016-09-16  8:22 ` Stanislav Kholmanskikh
2016-08-16 14:25 Cyril Hrubis
2016-08-17 14:42 ` Stanislav Kholmanskikh
2016-05-03 12:46 Cyril Hrubis
2016-05-04  2:28 ` Li Wang
2016-05-04  2:37   ` Li Wang
2016-05-04 11:56     ` Cyril Hrubis
2016-05-04 11:54   ` Cyril Hrubis
2016-05-05  6:13     ` Li Wang
2016-05-09 15:59 ` Cyril Hrubis
2016-05-09 16:12   ` Cyril Hrubis
2016-01-21 17:41 [LTP] LTP release Cyril Hrubis
2016-01-22 11:16 ` Jan Stancek
2016-01-25  9:48 ` Stanislav Kholmanskikh
2016-01-25 10:47 ` Alexey Kodanev
2016-01-25 12:20   ` Cyril Hrubis
2016-01-25 12:28 ` Cyril Hrubis
2016-01-26  6:41   ` Li Wang
2016-01-26  9:57   ` Stanislav Kholmanskikh
2015-08-13 12:30 Cyril Hrubis
2015-08-20 15:06 ` Cyril Hrubis
2015-08-31 11:23   ` Cyril Hrubis
     [not found]     ` <55E53DA4.6090005@cn.fujitsu.com>
2015-09-01 11:42       ` Cyril Hrubis
     [not found]         ` <1488894521.16163428.1441112961686.JavaMail.zimbra@redhat.com>
2015-09-01 13:14           ` Cyril Hrubis
2015-09-01 15:35       ` Cyril Hrubis
     [not found]     ` <75454012.15990077.1441091460626.JavaMail.zimbra@redhat.com>
2015-09-01 11:43       ` Cyril Hrubis
2015-09-02 11:28 ` Cyril Hrubis
2015-03-23  9:43 Cyril Hrubis
2015-04-02 10:09 ` Cyril Hrubis
     [not found]   ` <5523ED09.4050509@oracle.com>
2015-04-07 15:27     ` Cyril Hrubis
     [not found]       ` <552B91F1.3050901@oracle.com>
2015-04-14  9:19         ` Cyril Hrubis
2015-01-05 14:42 Cyril Hrubis
     [not found] ` <54B3FD5E.5040209@oracle.com>
2015-01-13  9:53   ` Cyril Hrubis
2014-12-18 13:48 Cyril Hrubis
2014-08-27  8:14 chrubis
2014-07-29 10:31 [LTP] LTP Release chrubis
2014-04-16 18:51 [LTP] LTP release chrubis
     [not found] ` <534ED26A.6040508@gmx.de>
2014-04-16 18:58   ` chrubis
2014-04-10 16:52 [LTP] LTP Release chrubis
     [not found] ` <5346F29E.7020402@oracle.com>
2014-04-14 11:58   ` chrubis
     [not found]     ` <534BE117.3070008@oracle.com>
2014-04-14 13:59       ` chrubis
2014-04-01 13:50 [LTP] LTP release Joseph Beckenbach
2014-04-01 14:22 ` chrubis
2014-03-31 16:03 [LTP] LTP Release chrubis
     [not found] ` <533A5F9C.6000907@oracle.com>
2014-04-01 10:58   ` chrubis
2014-01-14 12:05 [LTP] LTP release chrubis
2014-01-14 15:54 ` chrubis

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.