[LTP] LTP release status

[LTP] LTP release status

[Cyril Hrubis]

Hi!
I'm done with pre-release testing. The last thing I would like to
include are fixes for running 32bit LTP on 64bit kernel, particulary
[PATCH 1/4] lib: Add tst_kernel_bits() patchset and possibly fix the
issue https://github.com/linux-test-project/ltp/issues/124.

Anything else?

I would like to finally do the release at the start of the next week, is
that OK with everyone or do we need some more time for pre-release
testruns?

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP release status

[Jan Stancek]

----- Original Message -----
> From: "Cyril Hrubis" <chrubis@suse.cz>
> To: ltp@lists.linux.it
> Sent: Thursday, 12 January, 2017 3:28:29 PM
> Subject: [LTP] LTP release status
> 
> Hi!
> I'm done with pre-release testing. The last thing I would like to
> include are fixes for running 32bit LTP on 64bit kernel, particulary
> [PATCH 1/4] lib: Add tst_kernel_bits() patchset and possibly fix the
> issue https://github.com/linux-test-project/ltp/issues/124.
> 
> Anything else?
> 
> I would like to finally do the release at the start of the next week, is
> that OK with everyone or do we need some more time for pre-release
> testruns?

Couple more days would be great. I'll try to schedule tests on various RHELs
tomorrow, but some reserve would be nice to have.

Regards,
Jan

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

[LTP] LTP release status

[Cyril Hrubis]

Hi!
> > I would like to finally do the release at the start of the next week, is
> > that OK with everyone or do we need some more time for pre-release
> > testruns?
> 
> Couple more days would be great. I'll try to schedule tests on various RHELs
> tomorrow, but some reserve would be nice to have.

Okay then, just let me know once we are ready.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP release status

[Alexey Kodanev]

Hi Cyril,
On 12.01.2017 17:28, Cyril Hrubis wrote:
> Hi!
> I'm done with pre-release testing. The last thing I would like to
> include are fixes for running 32bit LTP on 64bit kernel, particulary
> [PATCH 1/4] lib: Add tst_kernel_bits() patchset and possibly fix the
> issue https://github.com/linux-test-project/ltp/issues/124.
>
> Anything else?
>
> I would like to finally do the release at the start of the next week, is
> that OK with everyone or do we need some more time for pre-release
> testruns?

OK for me. There are NFS test group issues with netns setup, the same as 
found by Petr with telnet test. Don't have working solution right now,  
defer to the next release.

Thanks,
Alexey

[LTP] LTP release status

[Jan Stancek]

----- Original Message -----
> From: "Cyril Hrubis" <chrubis@suse.cz>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: ltp@lists.linux.it
> Sent: Thursday, 12 January, 2017 4:39:18 PM
> Subject: Re: [LTP] LTP release status
> 
> Hi!
> > > I would like to finally do the release at the start of the next week, is
> > > that OK with everyone or do we need some more time for pre-release
> > > testruns?
> > 
> > Couple more days would be great. I'll try to schedule tests on various
> > RHELs
> > tomorrow, but some reserve would be nice to have.
> 
> Okay then, just let me know once we are ready.

Looks good over here, I've been running tests on RHEL6.2 up to 7.3,
plus a RHEL7.3 with recent upstream kernel.

I found only 2 problems (and sent 2 patches) for:
- tst_resm_hexd
- quotactl01 on big endian systems

Regards,
Jan

[LTP] LTP release status

[Cyril Hrubis]

Hi!
> > > Couple more days would be great. I'll try to schedule tests on various
> > > RHELs
> > > tomorrow, but some reserve would be nice to have.
> > 
> > Okay then, just let me know once we are ready.
> 
> Looks good over here, I've been running tests on RHEL6.2 up to 7.3,
> plus a RHEL7.3 with recent upstream kernel.
> 
> I found only 2 problems (and sent 2 patches) for:
> - tst_resm_hexd
> - quotactl01 on big endian systems

Good. I've acked these two already.

And also pushed the fix for unprobable munmap_2-1 failure from Richie
since I'm pretty sure that it will not break anything and that it fixes
real segfaults.

I have one more problem, zram01 fails on ppc64le since minimal btrfs
size there is larger due to larger page size. I think that I may be able
to parse mkfs.btrfs output to get the minimal size and adjust the size
of the zram device in the test setup but I consider this too risky for
the release.

So I guess I should tag the git and write the release notes once you
push your patches, okay?

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP release status

[Jan Stancek]

----- Original Message -----
> From: "Cyril Hrubis" <chrubis@suse.cz>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: ltp@lists.linux.it
> Sent: Monday, 16 January, 2017 2:02:38 PM
> Subject: Re: [LTP] LTP release status
> 
> Hi!
> > > > Couple more days would be great. I'll try to schedule tests on various
> > > > RHELs
> > > > tomorrow, but some reserve would be nice to have.
> > > 
> > > Okay then, just let me know once we are ready.
> > 
> > Looks good over here, I've been running tests on RHEL6.2 up to 7.3,
> > plus a RHEL7.3 with recent upstream kernel.
> > 
> > I found only 2 problems (and sent 2 patches) for:
> > - tst_resm_hexd
> > - quotactl01 on big endian systems
> 
> Good. I've acked these two already.
> 
> And also pushed the fix for unprobable munmap_2-1 failure from Richie
> since I'm pretty sure that it will not break anything and that it fixes
> real segfaults.
> 
> I have one more problem, zram01 fails on ppc64le since minimal btrfs
> size there is larger due to larger page size. I think that I may be able
> to parse mkfs.btrfs output to get the minimal size and adjust the size
> of the zram device in the test setup but I consider this too risky for
> the release.

I recall running into something similar in one non-LTP test.
I had to bump (back in 2013) ramdisk (brd) size to 384M on ppc systems.

> 
> So I guess I should tag the git and write the release notes once you
> push your patches, okay?

Fine by me. I'm going to look at pushing those 2 patches.

Regards,
Jan

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

[LTP] LTP release status

[Cyril Hrubis]

Hi!
> > So I guess I should tag the git and write the release notes once you
> > push your patches, okay?
> 
> Fine by me. I'm going to look at pushing those 2 patches.

And I've just stumbled over:

commit 8cc1e10d725c9104c0fc2a31527be8b1d9baa252
Author: Artem Savkov <asavkov@redhat.com>
Date:   Thu Sep 1 11:06:13 2016 +0200

    utimensat: fix immutable file retcodes for 4.8.0 and newer.

    Kernel 4.8.0 contains patch "337684a fs: return EPERM on immutable inode" that
    makes operations on immutable files return EPERM instead of EACCESS.

    Adjust utimensat test to check new retcode for kernels 4.8.0 and newer.

    Signed-off-by: Artem Savkov <asavkov@redhat.com>
    Reviewed-by: Jan Stancek <jstancek@redhat.com>


Looking closely at the manual page it explicitly says that immutable file with
NULL times must return EACCESS. So as far as I can tell this either hides a
kernel bug or the manual page is wrong. We may want to revert this for the
release, what do you think?

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP release status

[Jan Stancek]

----- Original Message -----
> From: "Cyril Hrubis" <chrubis@suse.cz>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: ltp@lists.linux.it
> Sent: Monday, 16 January, 2017 2:30:24 PM
> Subject: Re: [LTP] LTP release status
> 
> Hi!
> > > So I guess I should tag the git and write the release notes once you
> > > push your patches, okay?
> > 
> > Fine by me. I'm going to look at pushing those 2 patches.
> 
> And I've just stumbled over:
> 
> commit 8cc1e10d725c9104c0fc2a31527be8b1d9baa252
> Author: Artem Savkov <asavkov@redhat.com>
> Date:   Thu Sep 1 11:06:13 2016 +0200
> 
>     utimensat: fix immutable file retcodes for 4.8.0 and newer.
> 
>     Kernel 4.8.0 contains patch "337684a fs: return EPERM on immutable inode"
>     that
>     makes operations on immutable files return EPERM instead of EACCESS.
> 
>     Adjust utimensat test to check new retcode for kernels 4.8.0 and newer.
> 
>     Signed-off-by: Artem Savkov <asavkov@redhat.com>
>     Reviewed-by: Jan Stancek <jstancek@redhat.com>
> 
> 
> Looking closely at the manual page it explicitly says that immutable file
> with
> NULL times must return EACCESS. So as far as I can tell this either hides a
> kernel bug or the manual page is wrong. We may want to revert this for the
> release, what do you think?

I'm thinking revert until we figure out which one is correct. I checked man-pages
mailing list, but I don't see any patches for utimensat.

@Eryu: kernel commit 337684a mentions setxattr03, do you recall if it changed
also utimensat errno code on purpose? We seem to have a conflict with man
page at the moment.

Regards,
Jan

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

[LTP] LTP release status

[Cyril Hrubis]

Hi!
> I'm thinking revert until we figure out which one is correct. I checked man-pages
> mailing list, but I don't see any patches for utimensat.

Sounds good. Go ahead and revert it with my ack.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP release status

[Jan Stancek]

----- Original Message -----
> From: "Cyril Hrubis" <chrubis@suse.cz>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: ltp@lists.linux.it, "Artem Savkov" <asavkov@redhat.com>, "Eryu Guan" <eguan@redhat.com>
> Sent: Monday, 16 January, 2017 3:13:26 PM
> Subject: Re: [LTP] LTP release status
> 
> Hi!
> > I'm thinking revert until we figure out which one is correct. I checked
> > man-pages
> > mailing list, but I don't see any patches for utimensat.
> 
> Sounds good. Go ahead and revert it with my ack.

Reverted along with "utimensat_tests: Make use of tst_kvcmp".

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

[LTP] LTP release status

[Cyril Hrubis]

Hi!
> > Sounds good. Go ahead and revert it with my ack.
> 
> Reverted along with "utimensat_tests: Make use of tst_kvcmp".

Good, I will start finalizing the release then.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP release status

[Eryu Guan]

On Mon, Jan 16, 2017 at 09:09:56AM -0500, Jan Stancek wrote:
> 
> 
> ----- Original Message -----
> > From: "Cyril Hrubis" <chrubis@suse.cz>
> > To: "Jan Stancek" <jstancek@redhat.com>
> > Cc: ltp@lists.linux.it
> > Sent: Monday, 16 January, 2017 2:30:24 PM
> > Subject: Re: [LTP] LTP release status
> > 
> > Hi!
> > > > So I guess I should tag the git and write the release notes once you
> > > > push your patches, okay?
> > > 
> > > Fine by me. I'm going to look at pushing those 2 patches.
> > 
> > And I've just stumbled over:
> > 
> > commit 8cc1e10d725c9104c0fc2a31527be8b1d9baa252
> > Author: Artem Savkov <asavkov@redhat.com>
> > Date:   Thu Sep 1 11:06:13 2016 +0200
> > 
> >     utimensat: fix immutable file retcodes for 4.8.0 and newer.
> > 
> >     Kernel 4.8.0 contains patch "337684a fs: return EPERM on immutable inode"
> >     that
> >     makes operations on immutable files return EPERM instead of EACCESS.
> > 
> >     Adjust utimensat test to check new retcode for kernels 4.8.0 and newer.
> > 
> >     Signed-off-by: Artem Savkov <asavkov@redhat.com>
> >     Reviewed-by: Jan Stancek <jstancek@redhat.com>
> > 
> > 
> > Looking closely at the manual page it explicitly says that immutable file
> > with
> > NULL times must return EACCESS. So as far as I can tell this either hides a
> > kernel bug or the manual page is wrong. We may want to revert this for the
> > release, what do you think?
> 
> I'm thinking revert until we figure out which one is correct. I checked man-pages
> mailing list, but I don't see any patches for utimensat.
> 
> @Eryu: kernel commit 337684a mentions setxattr03, do you recall if it changed
> also utimensat errno code on purpose? We seem to have a conflict with man
> page at the moment.

Yes, I changed all errno to EPERM on immutable inode so that we return
the consistent errno. But I failed to reference a explicit standard to
say what we really should return on immutable inode, just that in most
places EPERM are returned on immutable or append-only inode, and
fcntl(2) manpage says (it doesn't mention immutable inode):

EPERM  Attempted to clear the O_APPEND flag on a file that has the
append-only attribute set.

I think immutable inode should be treated the same as append-only inode,
they're both file attribute.

OTOH, utimensat(2) manpage seems inconsistent/vague on immutable inode,
it says:

EACCES ...
...
	*  the file is marked immutable (see chattr(1)).

then

EPERM ...
...
	*  the file is marked append-only or immutable (see chattr(1)).

Perhaps the manpage should be updated.

Thanks,
Eryu

[LTP] LTP release status

[Cyril Hrubis]

Hi!
> OTOH, utimensat(2) manpage seems inconsistent/vague on immutable inode,

Read it once more, there are exact conditions specified where EACCES and
where EPERM should be returned.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] LTP release status

[Jan Stancek]

----- Original Message -----
> From: "Eryu Guan" <eguan@redhat.com>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: "Cyril Hrubis" <chrubis@suse.cz>, ltp@lists.linux.it, "Artem Savkov" <asavkov@redhat.com>
> Sent: Monday, 16 January, 2017 4:25:32 PM
> Subject: Re: [LTP] LTP release status
> 
> On Mon, Jan 16, 2017 at 09:09:56AM -0500, Jan Stancek wrote:
> > 
> > 
> > ----- Original Message -----
> > > From: "Cyril Hrubis" <chrubis@suse.cz>
> > > To: "Jan Stancek" <jstancek@redhat.com>
> > > Cc: ltp@lists.linux.it
> > > Sent: Monday, 16 January, 2017 2:30:24 PM
> > > Subject: Re: [LTP] LTP release status
> > > 
> > > Hi!
> > > > > So I guess I should tag the git and write the release notes once you
> > > > > push your patches, okay?
> > > > 
> > > > Fine by me. I'm going to look at pushing those 2 patches.
> > > 
> > > And I've just stumbled over:
> > > 
> > > commit 8cc1e10d725c9104c0fc2a31527be8b1d9baa252
> > > Author: Artem Savkov <asavkov@redhat.com>
> > > Date:   Thu Sep 1 11:06:13 2016 +0200
> > > 
> > >     utimensat: fix immutable file retcodes for 4.8.0 and newer.
> > > 
> > >     Kernel 4.8.0 contains patch "337684a fs: return EPERM on immutable
> > >     inode"
> > >     that
> > >     makes operations on immutable files return EPERM instead of EACCESS.
> > > 
> > >     Adjust utimensat test to check new retcode for kernels 4.8.0 and
> > >     newer.
> > > 
> > >     Signed-off-by: Artem Savkov <asavkov@redhat.com>
> > >     Reviewed-by: Jan Stancek <jstancek@redhat.com>
> > > 
> > > 
> > > Looking closely at the manual page it explicitly says that immutable file
> > > with
> > > NULL times must return EACCESS. So as far as I can tell this either hides
> > > a
> > > kernel bug or the manual page is wrong. We may want to revert this for
> > > the
> > > release, what do you think?
> > 
> > I'm thinking revert until we figure out which one is correct. I checked
> > man-pages
> > mailing list, but I don't see any patches for utimensat.
> > 
> > @Eryu: kernel commit 337684a mentions setxattr03, do you recall if it
> > changed
> > also utimensat errno code on purpose? We seem to have a conflict with man
> > page at the moment.
> 
> Yes, I changed all errno to EPERM on immutable inode so that we return
> the consistent errno. But I failed to reference a explicit standard to
> say what we really should return on immutable inode, just that in most
> places EPERM are returned on immutable or append-only inode, and
> fcntl(2) manpage says (it doesn't mention immutable inode):
> 
> EPERM  Attempted to clear the O_APPEND flag on a file that has the
> append-only attribute set.
> 
> I think immutable inode should be treated the same as append-only inode,
> they're both file attribute.
> 
> OTOH, utimensat(2) manpage seems inconsistent/vague on immutable inode,
> it says:
> 
> EACCES ...
> ...
> 	*  the file is marked immutable (see chattr(1)).
> 
> then
> 
> EPERM ...
> ...
> 	*  the file is marked append-only or immutable (see chattr(1)).
> 
> Perhaps the manpage should be updated.

I'm going to ask on fsdevel mailing list.

Regards,
Jan


> 
> Thanks,
> Eryu
> 

[LTP] LTP release status

[Eryu Guan]

On Mon, Jan 16, 2017 at 04:31:19PM +0100, Cyril Hrubis wrote:
> Hi!
> > OTOH, utimensat(2) manpage seems inconsistent/vague on immutable inode,
> 
> Read it once more, there are exact conditions specified where EACCES and
> where EPERM should be returned.

Ah, you're right, I read it too quickly.. But still, returning a
consistent errno makes more sense to me.

Thanks,
Eryu

[LTP] LTP release status

[Cyril Hrubis]

Hi!
As you may have seen from the commits to the LTP repo I've did a
numerous LTP builds and runs and fixed most of the problems I've found.

One of the last things on my TODO is to look at the cgroup_fj testcases.
Since some of them still fail on older distributions (and we have still
fixes waiting on ML) and evenmore they take a lot of time since they do
sleep 1 on numerous places (some of them looks pointless to me).

Anyway I will try to make most of the cgroup_fj testcases starting next
week and then I would like to finally proceed with the release.

Now the important part: if you haven't tried the latest LTP git yourself
please do so now and report any problems you find so that we have nice
stable release.

Also if there are any important fixes that you think should be part of
the release please let me know as well. I will have a look.

-- 
Cyril Hrubis
chrubis@suse.cz