Linux Test Project
 help / color / mirror / Atom feed
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


  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