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?
Signature · 2 lines
Cyril Hrubis [email protected]
----- Original Message -----
Quoted 11 lines
From: "Cyril Hrubis" <[email protected]>
To: [email protected]
Sent: Thursday, 12 January, 2017 3:28:29 PM
Subject: [LTP] LTP release statusHi!
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: Addtst_kernel_bits()patchset and possibly fix the issue https://github.com/linux-test-project/ltp/issues/124.
Quoted 5 lines
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
Quoted 8 lines
--
Cyril Hrubis
[email protected]--
Mailing list info: https://lists.linux.it/listinfo/ltp
Hi!
Quoted 6 lines
Quoted 3 lines
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.
Signature · 2 lines
Cyril Hrubis [email protected]
----- Original Message -----
Quoted 11 lines
From: "Cyril Hrubis" <[email protected]>
To: "Jan Stancek" <[email protected]>
Cc: [email protected]
Sent: Thursday, 12 January, 2017 4:39:18 PM
Subject: Re: [LTP] LTP release statusHi!
Quoted 4 lines
Quoted 3 lines
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?
Quoted 5 lines
Quoted 3 lines
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
Hi!
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
Couple more days would be great. I'll try to schedule tests on various RHELs
tomorrow, but some reserve would be nice to have.
Quoted 8 lines
Quoted 1 line
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?
Signature · 2 lines
Cyril Hrubis [email protected]
----- Original Message -----
Quoted 26 lines
From: "Cyril Hrubis" <[email protected]>
To: "Jan Stancek" <[email protected]>
Cc: [email protected]
Sent: Monday, 16 January, 2017 2:02:38 PM
Subject: Re: [LTP] LTP release statusHi!
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
Couple more days would be great. I'll try to schedule tests on various RHELs
tomorrow, but some reserve would be nice to have.Quoted 8 lines
Quoted 1 line
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 systemsGood. 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.
Quoted 5 lines
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.
Quoted 3 lines
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
Quoted 5 lines
--
Cyril Hrubis
[email protected]
Cyril Hrubis
Reviewed-by Jan StancekHi!
Quoted 4 lines
Quoted 2 lines
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 <[email protected]> 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.
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?
Signature · 2 lines
Cyril Hrubis [email protected]
----- Original Message -----
Quoted 30 lines
From: "Cyril Hrubis" <[email protected]>
To: "Jan Stancek" <[email protected]>
Cc: [email protected]
Sent: Monday, 16 January, 2017 2:30:24 PM
Subject: Re: [LTP] LTP release statusHi!
Quoted 4 lines
Quoted 2 lines
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
8cc1e10d725c9104c0fc2a31527be8b1d9baa252Author: Artem Savkov <[email protected]> Date: Thu Sep 1 11:06:13 2016 +0200utimensat: 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 <[email protected]>Reviewed-by Jan Stancek <[email protected]>
Quoted 5 lines
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
Quoted 5 lines
--
Cyril Hrubis
[email protected]
Hi!
Quoted 2 lines
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.
Signature · 2 lines
Cyril Hrubis [email protected]
----- Original Message -----
Quoted 6 lines
From: "Cyril Hrubis" <[email protected]>
To: "Jan Stancek" <[email protected]>
Cc: [email protected], "Artem Savkov" <[email protected]>, "Eryu Guan" <[email protected]>
Sent: Monday, 16 January, 2017 3:13:26 PM
Subject: Re: [LTP] LTP release status
Quoted 6 lines
Hi!
Quoted 3 lines
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".
Quoted 5 lines
--
Cyril Hrubis
[email protected]
Hi!
Quoted 3 lines
Quoted 1 line
Sounds good. Go ahead and revert it with my ack.
Reverted along with "
utimensat_tests: Make use oftst_kvcmp".
Good, I will start finalizing the release then.
Signature · 2 lines
Cyril Hrubis [email protected]
Quoted 39 lines · Jan Stancek
----- Original Message -----
Quoted 30 lines
From: "Cyril Hrubis" <[email protected]>
To: "Jan Stancek" <[email protected]>
Cc: [email protected]
Sent: Monday, 16 January, 2017 2:30:24 PM
Subject: Re: [LTP] LTP release statusHi!
Quoted 4 lines
Quoted 2 lines
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
8cc1e10d725c9104c0fc2a31527be8b1d9baa252Author: Artem Savkov <[email protected]> Date: Thu Sep 1 11:06:13 2016 +0200utimensat: 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 <[email protected]>Reviewed-by Jan Stancek <[email protected]>Quoted 5 lines
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?
Quoted 6 lines
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
Hi!
Quoted 1 line
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.
Signature · 2 lines
Cyril Hrubis [email protected]
Quoted 5 lines · Cyril Hrubis
Hi!
Quoted 1 line
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
----- Original Message -----
Quoted 78 lines
From: "Eryu Guan" <[email protected]>
To: "Jan Stancek" <[email protected]>
Cc: "Cyril Hrubis" <[email protected]>, [email protected], "Artem Savkov" <[email protected]>
Sent: Monday, 16 January, 2017 4:25:32 PM
Subject: Re: [LTP] LTP release statusQuoted 43 lines · Jan Stancek
----- Original Message -----
Quoted 32 lines
From: "Cyril Hrubis" <[email protected]>
To: "Jan Stancek" <[email protected]>
Cc: [email protected]
Sent: Monday, 16 January, 2017 2:30:24 PM
Subject: Re: [LTP] LTP release statusHi!
Quoted 4 lines
Quoted 2 lines
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
8cc1e10d725c9104c0fc2a31527be8b1d9baa252Author: Artem Savkov <[email protected]> Date: Thu Sep 1 11:06:13 2016 +0200utimensat: 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 <[email protected]>Reviewed-by Jan Stancek <[email protected]>Quoted 7 lines
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?Quoted 8 lines
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_APPENDflag 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)).
Quoted 7 lines
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
Quoted 4 lines
Thanks,
Eryu
Hi Cyril,
Quoted 11 lines · 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: Addtst_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