* [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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox