LTP pre-release testing and freeze

LTP Cyril Hrubis 2 participants 6 messages Apr 20, 2016 – May 2, 2016

lore

Share & tools

lore

Cyril Hrubis

author

2016-04-20 14:30 UTC #0 lore raw

Hi!
Are we ready for the git repository freeze and pre-release testing?

Are there any patches that were not reviewed/pushed yet that should be part of the next release?

Ideally I would like to proceed with the freeze at the end of this week then have at least a week for running the tests and if everything goes well the release would be carried on end of April or beginning of May. Does that sound reasonable?

Signature · 2 lines

Cyril Hrubis
[email protected]

Jan Stancek

2016-04-28 10:25 UTC #1 lore raw

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

Quoted 8 lines

From: "Cyril Hrubis" <[email protected]>
To: [email protected]
Sent: Wednesday, 20 April, 2016 4:30:31 PM
Subject: [LTP] LTP pre-release testing and freeze
Hi!
Are we ready for the git repository freeze and pre-release testing?

Quoted 7 lines

Are there any patches that were not reviewed/pushed yet that should be part of the next release?
Ideally I would like to proceed with the freeze at the end of this week then have at least a week for running the tests and if everything goes well the release would be carried on end of April or beginning of May. Does that sound reasonable?

Looks good from my side. I ran the usual set we use as smoke test (syscalls, selection of mem/io/etc.) on
RHEL6.2 through RHEL6.8 (i386, x86_64, ppc64, s390x) RHEL7.0 through RHEL7.2 (x86_64, ppc64, ppc64le, s390x, aarch64)
and ran mostly into known bugs in kernel / glibc.

Other than known issues, there were couple failures to note:

epoll_wait02
There is a tolerance, but it goes only one way (oversleep). I occasionally see it waking up a ms earlier and then testcase reports it as failure. This was new addition, so there are no historical data for comparison.

personality01
PER_LINUX32 is masked on powerpc as PER_LINUX, so this always fails.

arch/powerpc/kernel/syscalls.c:
long ppc64_personality(unsigned long personality)

{
        long ret;

        if (personality(current->personality) == PER_LINUX32
            && personality(personality) == PER_LINUX)
                personality = (personality & ~PER_MASK) | PER_LINUX32;
        ret = sys_personality(personality);
        if (personality(ret) == PER_LINUX32)
                ret = (ret & ~PER_MASK) | PER_LINUX;
        return ret;
}

Regards,
Jan

Quoted 8 lines

--
Cyril Hrubis
[email protected]
--
Mailing list info: https://lists.linux.it/listinfo/ltp

Cyril Hrubis

author

2016-04-28 12:26 UTC #2 lore raw

Hi!

Quoted 6 lines

Looks good from my side. I ran the usual set we use as smoke test (syscalls, selection of mem/io/etc.) on
RHEL6.2 through RHEL6.8 (i386, x86_64, ppc64, s390x) RHEL7.0 through RHEL7.2 (x86_64, ppc64, ppc64le, s390x, aarch64)
and ran mostly into known bugs in kernel / glibc.

Quoted 7 lines

Other than known issues, there were couple failures to note:
epoll_wait02
There is a tolerance, but it goes only one way (oversleep). I occasionally see it waking up a ms earlier and then testcase reports it as failure. This was new addition, so there are no historical data for comparison.

That may be bug, since AFAIC all POSIX timers are not allowed to wake up earlier. The epoll_wait() is Linux specific, but the manual talks only about possible overrun as well.

Quoted 6 lines

personality01
PER_LINUX32 is masked on powerpc as PER_LINUX, so this always fails.
arch/powerpc/kernel/syscalls.c:
long ppc64_personality(unsigned long personality)

Quoted 11 lines

{
        long ret;

        if (personality(current->personality) == PER_LINUX32
            && personality(personality) == PER_LINUX)
                personality = (personality & ~PER_MASK) | PER_LINUX32;
        ret = sys_personality(personality);
        if (personality(ret) == PER_LINUX32)
                ret = (ret & ~PER_MASK) | PER_LINUX;
        return ret;
}

So the fist if () makes sure that process cannot excape PER_LINUX32 while the second hides PER_LINUX32 completly. I've missed the second part when I was rewriting the testcase. Looking at kernel sources sparc64 and s390 seems to do the same but the code assumes that PER_LINUX == 0.

SYSCALL_DEFINE1(s390_personality, unsigned int, personality)

{
        unsigned int ret;

        if (personality(current->personality) == PER_LINUX32 &&
            personality(personality) == PER_LINUX)
                personality |= PER_LINUX32;
        ret = sys_personality(personality);
        if (personality(ret) == PER_LINUX32)
                ret &= ~PER_LINUX32;

        return ret;
}

Does the test fail on s390x as well?

It seems that mapping PER_LINUX32 to PER_LINUX is a common practice on 64 bit, maybe we should just skip that personality on anything than x86_64.

I'm currently working on few more fixes:

* The umount2() tests still fails with EBUSY rarely, I will have to fix the TEST(umount2()) to retry on EBUSY as well

* Another diotest fix for Btrfs

And I would like to get the isofs fix I've send to the list in before the release as well. Can you please have a look at that one?

Apart from these, the rest looks fine.

Signature · 2 lines

Cyril Hrubis
[email protected]

Jan Stancek

2016-05-02 09:10 UTC #3 lore raw

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

Quoted 21 lines

From: "Cyril Hrubis" <[email protected]>
To: "Jan Stancek" <[email protected]>
Cc: [email protected]
Sent: Thursday, 28 April, 2016 2:26:25 PM
Subject: Re: [LTP] LTP pre-release testing and freeze
Hi!
Quoted 6 lines
Looks good from my side. I ran the usual set we use as smoke test (syscalls, selection of mem/io/etc.) on
RHEL6.2 through RHEL6.8 (i386, x86_64, ppc64, s390x) RHEL7.0 through RHEL7.2 (x86_64, ppc64, ppc64le, s390x, aarch64)
and ran mostly into known bugs in kernel / glibc.
Quoted 7 lines
Other than known issues, there were couple failures to note:
epoll_wait02
There is a tolerance, but it goes only one way (oversleep). I occasionally see it waking up a ms earlier and then testcase reports it as failure. This was new addition, so there are no historical data for comparison.

Quoted 3 lines

That may be bug, since AFAIC all POSIX timers are not allowed to wake up earlier. The epoll_wait() is Linux specific, but the manual talks only about possible overrun as well.

I think it happened so far only on ppc/s390 guests, so my suspicion was that high steal time could be a factor. I'll look into how much reproducible this is with RHEL.

Quoted 39 lines

Quoted 7 lines
personality01
PER_LINUX32 is masked on powerpc as PER_LINUX, so this always fails.
arch/powerpc/kernel/syscalls.c:
long ppc64_personality(unsigned long personality)
Quoted 11 lines
{
        long ret;

        if (personality(current->personality) == PER_LINUX32
            && personality(personality) == PER_LINUX)
                personality = (personality & ~PER_MASK) | PER_LINUX32;
        ret = sys_personality(personality);
        if (personality(ret) == PER_LINUX32)
                ret = (ret & ~PER_MASK) | PER_LINUX;
        return ret;
}
So the fist if () makes sure that process cannot excape PER_LINUX32 while the second hides PER_LINUX32 completly. I've missed the second part when I was rewriting the testcase. Looking at kernel sources sparc64 and s390 seems to do the same but the code assumes that PER_LINUX == 0.
SYSCALL_DEFINE1(s390_personality, unsigned int, personality)
{
        unsigned int ret;

        if (personality(current->personality) == PER_LINUX32 &&
            personality(personality) == PER_LINUX)
                personality |= PER_LINUX32;
        ret = sys_personality(personality);
        if (personality(ret) == PER_LINUX32)
                ret &= ~PER_LINUX32;

        return ret;
}

Quoted 1 line

Does the test fail on s390x as well?

Yes, it does.

personality01    0  TINFO  :  Child process returned TPASS
personality01    1  TFAIL  :  personality01.c:80: PER_LINUX32: wrong personality read back 0 expected 8

Quoted 4 lines

It seems that mapping PER_LINUX32 to PER_LINUX is a common practice on 64 bit, maybe we should just skip that personality on anything than x86_64.

Agreed. I can send a patch.

Regards,
Jan

Cyril Hrubis

author

2016-05-02 09:45 UTC #4 lore raw

Hi!

Quoted 5 lines

Quoted 3 lines
It seems that mapping PER_LINUX32 to PER_LINUX is a common practice on 64 bit, maybe we should just skip that personality on anything than x86_64.
Agreed. I can send a patch.

That would be just one ifdef, you can push that directly to the git repo.

Signature · 2 lines

Cyril Hrubis
[email protected]

Jan Stancek

2016-05-02 10:06 UTC #5 lore raw

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

Quoted 7 lines

From: "Cyril Hrubis" <[email protected]>
To: "Jan Stancek" <[email protected]>
Cc: [email protected]
Sent: Monday, 2 May, 2016 11:45:52 AM
Subject: Re: [LTP] LTP pre-release testing and freeze
Hi!

Quoted 8 lines

Quoted 5 lines
Quoted 3 lines
It seems that mapping PER_LINUX32 to PER_LINUX is a common practice on 64 bit, maybe we should just skip that personality on anything than x86_64.
Agreed. I can send a patch.
That would be just one ifdef, you can push that directly to the git repo.

Tested (on s390) and pushed.

Regards,
Jan

Quoted 5 lines

--
Cyril Hrubis
[email protected]