Skip to contentSkip to conversation

LTP release

LTP Cyril Hrubis 6 participants 16 messages Apr 24, 2017 – May 19, 2017

lore
Share & tools
lore

Cyril Hrubis

author
#0 lore raw

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?

Signature · 2 lines
Cyril Hrubis
[email protected]
#1 lore raw

Hi,

Quoted 5 lines · Cyril Hrubis

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

Signature · 3 lines
Regards,
Li Wang
Email: [email protected]
author
#2 lore raw

Hi!

Quoted 12 lines
Quoted 4 lines

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
Quoted 14 lines
# ./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.

Signature · 2 lines
Cyril Hrubis
[email protected]
#3 lore raw

----- Original Message -----

Quoted 9 lines

Hi!

Quoted 8 lines
Quoted 4 lines

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:

Quoted 3 lines

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

#4 lore raw
Quoted 19 lines · Jan Stancek

----- Original Message -----

Quoted 9 lines

Hi!

Quoted 8 lines
Quoted 4 lines

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:

Quoted 3 lines

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.

Quoted 8 lines

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:

testcases/kernel/syscalls/ioctl/ioctl06.c +2 -1
@@ -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);
Signature · 3 lines
Regards,
Li Wang
Email: [email protected]
#5 lore raw

----- Original Message -----

Quoted 37 lines · Jan Stancek
Quoted 21 lines

----- Original Message -----

Quoted 11 lines

Hi!

Quoted 10 lines
Quoted 6 lines

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:

Quoted 3 lines

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.

Quoted 8 lines

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:

testcases/kernel/syscalls/ioctl/ioctl06.c static int fd; · line 34

Quoted 4 lines
testcases/kernel/syscalls/ioctl/ioctl06.c +1 -0
@@ -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

#7 lore raw
In reply to Cyril Hrubis

Hello,

Quoted 6 lines · On Mon, 24 Apr 2017 18:25:34 +0200 "Cyril Hrubis" <[email protected]> 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.

author
#8 lore raw

Hi!

Quoted 3 lines

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.

Quoted 3 lines

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.

Signature · 2 lines
Cyril Hrubis
[email protected]
author
#9 lore raw
In reply to Cyril Hrubis

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?

Signature · 2 lines
Cyril Hrubis
[email protected]
#10 lore raw

----- Original Message -----

Quoted 15 lines

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.

Quoted 5 lines

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

Quoted 10 lines

Any other patches that should go in before the release?

--
Cyril Hrubis
[email protected]

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

author
#11 lore raw
In reply to Cyril Hrubis

Hi!

Quoted 3 lines

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

Signature · 2 lines
Cyril Hrubis
[email protected]
#12 lore raw

----- Original Message -----

Quoted 6 lines

Hi!

Quoted 3 lines

* 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

#13 lore raw

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.

Quoted 11 lines

-----Original Message-----
From: ltp [mailto:[email protected]] On Behalf Of Jan Stancek
Sent: Saturday, May 06, 2017 12:42 AM

Quoted 6 lines

Hi!

Quoted 3 lines

* 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

author
#14 lore raw

Hi!

Quoted 7 lines
Quoted 7 lines

From: ltp [mailto:[email protected]] On Behalf Of Jan Stancek
Sent: Saturday, May 06, 2017 12:42 AM

Quoted 5 lines

Hi!

Quoted 3 lines

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

Quoted 8 lines
Quoted 3 lines
Quoted 1 line

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.

Quoted 2 lines

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.

Quoted 12 lines

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?

Quoted 8 lines

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 <[email protected]>
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.

Signature · 2 lines
Cyril Hrubis
[email protected]
#15 lore raw
Quoted 3 lines

-----Original Message-----
From: Cyril Hrubis [mailto:[email protected]]
Sent: Friday, May 19, 2017 6:37 PM

...

Quoted 23 lines
Quoted 10 lines

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 <[email protected]>
Date:   Fri Apr 21 16:31:48 2017 +0200

tst_kvcmp: Add support for extra kernel versions

Quoted 8 lines

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