* [LTP] LTP pre-release testing and freeze
@ 2016-04-20 14:30 Cyril Hrubis
2016-04-28 10:25 ` Jan Stancek
0 siblings, 1 reply; 6+ messages in thread
From: Cyril Hrubis @ 2016-04-20 14:30 UTC (permalink / raw)
To: ltp
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?
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply [flat|nested] 6+ messages in thread
* [LTP] LTP pre-release testing and freeze
2016-04-20 14:30 [LTP] LTP pre-release testing and freeze Cyril Hrubis
@ 2016-04-28 10:25 ` Jan Stancek
2016-04-28 12:26 ` Cyril Hrubis
0 siblings, 1 reply; 6+ messages in thread
From: Jan Stancek @ 2016-04-28 10:25 UTC (permalink / raw)
To: ltp
----- Original Message -----
> From: "Cyril Hrubis" <chrubis@suse.cz>
> To: ltp@lists.linux.it
> 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?
>
> 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
>
> --
> Cyril Hrubis
> chrubis@suse.cz
>
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [LTP] LTP pre-release testing and freeze
2016-04-28 10:25 ` Jan Stancek
@ 2016-04-28 12:26 ` Cyril Hrubis
2016-05-02 9:10 ` Jan Stancek
0 siblings, 1 reply; 6+ messages in thread
From: Cyril Hrubis @ 2016-04-28 12:26 UTC (permalink / raw)
To: ltp
Hi!
> 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.
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.
> 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;
> }
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.
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply [flat|nested] 6+ messages in thread
* [LTP] LTP pre-release testing and freeze
2016-04-28 12:26 ` Cyril Hrubis
@ 2016-05-02 9:10 ` Jan Stancek
2016-05-02 9:45 ` Cyril Hrubis
0 siblings, 1 reply; 6+ messages in thread
From: Jan Stancek @ 2016-05-02 9:10 UTC (permalink / raw)
To: ltp
----- Original Message -----
> From: "Cyril Hrubis" <chrubis@suse.cz>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: ltp@lists.linux.it
> Sent: Thursday, 28 April, 2016 2:26:25 PM
> Subject: Re: [LTP] LTP pre-release testing and freeze
>
> Hi!
> > 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.
>
> 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.
>
> > 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;
> > }
>
> 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?
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
>
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [LTP] LTP pre-release testing and freeze
2016-05-02 9:10 ` Jan Stancek
@ 2016-05-02 9:45 ` Cyril Hrubis
2016-05-02 10:06 ` Jan Stancek
0 siblings, 1 reply; 6+ messages in thread
From: Cyril Hrubis @ 2016-05-02 9:45 UTC (permalink / raw)
To: ltp
Hi!
> > 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.
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply [flat|nested] 6+ messages in thread
* [LTP] LTP pre-release testing and freeze
2016-05-02 9:45 ` Cyril Hrubis
@ 2016-05-02 10:06 ` Jan Stancek
0 siblings, 0 replies; 6+ messages in thread
From: Jan Stancek @ 2016-05-02 10:06 UTC (permalink / raw)
To: ltp
----- Original Message -----
> From: "Cyril Hrubis" <chrubis@suse.cz>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: ltp@lists.linux.it
> Sent: Monday, 2 May, 2016 11:45:52 AM
> Subject: Re: [LTP] LTP pre-release testing and freeze
>
> Hi!
> > > 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
>
> --
> Cyril Hrubis
> chrubis@suse.cz
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-05-02 10:06 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-04-20 14:30 [LTP] LTP pre-release testing and freeze Cyril Hrubis
2016-04-28 10:25 ` Jan Stancek
2016-04-28 12:26 ` Cyril Hrubis
2016-05-02 9:10 ` Jan Stancek
2016-05-02 9:45 ` Cyril Hrubis
2016-05-02 10:06 ` Jan Stancek
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.