From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] LTP pre-release testing and freeze
Date: Mon, 2 May 2016 05:10:08 -0400 (EDT) [thread overview]
Message-ID: <1274865023.2004095.1462180208523.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20160428122625.GA25587@rei>
----- 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
next prev parent reply other threads:[~2016-05-02 9:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2016-05-02 9:45 ` Cyril Hrubis
2016-05-02 10:06 ` Jan Stancek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1274865023.2004095.1462180208523.JavaMail.zimbra@redhat.com \
--to=jstancek@redhat.com \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox