* [LTP] LTP release and code freeze
@ 2017-09-19 8:48 Cyril Hrubis
2017-09-19 18:26 ` Sandeep Patil
2017-09-27 13:17 ` Cyril Hrubis
0 siblings, 2 replies; 9+ messages in thread
From: Cyril Hrubis @ 2017-09-19 8:48 UTC (permalink / raw)
To: ltp
Hi!
We are getting closer to a release, here is the status as I see it.
Blockers:
* thp01 failing on newer kernels
- I'm waiting for v4 from Ritchie
* utimensat01 failing on stable kernels
- That thread on ML is kind of stuck,
I guess that we will have to accept
both errors for some range of kernels
Nice to have:
* The clone09 patch to disable it on old kernels looks sane to me
- I will merge that one
* CVE synchronization library
- depends if Ritchie can fix it fast enough
* The .needs_rofs patchset looks good to me as well I guess that
it's safe enough to be included in the release as well
Is there anything else I've missing?
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply [flat|nested] 9+ messages in thread* [LTP] LTP release and code freeze
2017-09-19 8:48 [LTP] LTP release and code freeze Cyril Hrubis
@ 2017-09-19 18:26 ` Sandeep Patil
2017-09-27 13:17 ` Cyril Hrubis
1 sibling, 0 replies; 9+ messages in thread
From: Sandeep Patil @ 2017-09-19 18:26 UTC (permalink / raw)
To: ltp
On Tue, Sep 19, 2017 at 10:48:49AM +0200, Cyril Hrubis wrote:
> Hi!
> We are getting closer to a release, here is the status as I see it.
>
> Blockers:
>
> * thp01 failing on newer kernels
> - I'm waiting for v4 from Ritchie
>
> * utimensat01 failing on stable kernels
> - That thread on ML is kind of stuck,
> I guess that we will have to accept
> both errors for some range of kernels
>
>
> Nice to have:
>
> * The clone09 patch to disable it on old kernels looks sane to me
> - I will merge that one
>
> * CVE synchronization library
> - depends if Ritchie can fix it fast enough
>
> * The .needs_rofs patchset looks good to me as well I guess that
> it's safe enough to be included in the release as well
Yes, thanks for this. It unblocks a bunch of tests for us in Android.
I'll respond with a small list to your question in the patch thread.
>
>
> Is there anything else I've missing?
FWIW, I will work to merge the release and report any new, discovered
failures on Android and track to fix it post-release. If you want me (us) to
do the same on an -rc, let me know.
- ssp
>
> --
> Cyril Hrubis
> chrubis@suse.cz
>
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 9+ messages in thread
* [LTP] LTP release and code freeze
2017-09-19 8:48 [LTP] LTP release and code freeze Cyril Hrubis
2017-09-19 18:26 ` Sandeep Patil
@ 2017-09-27 13:17 ` Cyril Hrubis
1 sibling, 0 replies; 9+ messages in thread
From: Cyril Hrubis @ 2017-09-27 13:17 UTC (permalink / raw)
To: ltp
Hi!
Here is a status update for the release:
o the cve patchset will not make it
o I tested the utimensat patch I've done and it seems to work fine
- it would be nice if anybody else could have a look before it gets
commited
o the cpuset should be considered for merge as well
Other than that I do not see any blockers.
I would like to release LTP on Friday once the two outstanding issues
are fixed. Is that OK with everyone?
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply [flat|nested] 9+ messages in thread
* [LTP] LTP release and code freeze
@ 2017-09-18 7:21 Naresh Kamboju
2017-09-19 8:04 ` Cyril Hrubis
0 siblings, 1 reply; 9+ messages in thread
From: Naresh Kamboju @ 2017-09-18 7:21 UTC (permalink / raw)
To: ltp
Hi,
Greetings from Linaro !
Regarding the LTP September 2017 release,
Identifying bugs / issues / limitation / pre-requirements of LTP
testing on ARM64 architecture is crucial at our end. We would like to
test LTP pre-release candidate on ARM64 architecture.
Please announce code freeze and allow time to validate test code.
Best regards
Naresh Kamboju
^ permalink raw reply [flat|nested] 9+ messages in thread
* [LTP] LTP release and code freeze
2017-09-18 7:21 Naresh Kamboju
@ 2017-09-19 8:04 ` Cyril Hrubis
2017-09-25 20:00 ` Naresh Kamboju
0 siblings, 1 reply; 9+ messages in thread
From: Cyril Hrubis @ 2017-09-19 8:04 UTC (permalink / raw)
To: ltp
Hi!
> Regarding the LTP September 2017 release,
> Identifying bugs / issues / limitation / pre-requirements of LTP
> testing on ARM64 architecture is crucial at our end. We would like to
> test LTP pre-release candidate on ARM64 architecture.
> Please announce code freeze and allow time to validate test code.
I guess that you can start with the validation now. We haven't declared
the freeze formally yet, but there are only a few possible changes that
may get in the release. The thp01 is broken on new kernels, that one
should get in for sure. Then possibly something like ten tests may end
up affected by possible changes in the CVE tests, which should be easy
enough to retest if needed.
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply [flat|nested] 9+ messages in thread
* [LTP] LTP release and code freeze
2017-09-19 8:04 ` Cyril Hrubis
@ 2017-09-25 20:00 ` Naresh Kamboju
2017-09-26 8:51 ` Li Wang
0 siblings, 1 reply; 9+ messages in thread
From: Naresh Kamboju @ 2017-09-25 20:00 UTC (permalink / raw)
To: ltp
Hi Cyril,
On 19 September 2017 at 01:04, Cyril Hrubis <chrubis@suse.cz> wrote:
> Hi!
>> Regarding the LTP September 2017 release,
>> Identifying bugs / issues / limitation / pre-requirements of LTP
>> testing on ARM64 architecture is crucial at our end. We would like to
>> test LTP pre-release candidate on ARM64 architecture.
>> Please announce code freeze and allow time to validate test code.
>
> I guess that you can start with the validation now. We haven't declared
> the freeze formally yet, but there are only a few possible changes that
> may get in the release. The thp01 is broken on new kernels, that one
> should get in for sure. Then possibly something like ten tests may end
> up affected by possible changes in the CVE tests, which should be easy
> enough to retest if needed.
Tested LTP syscalls on ARM64 architecture and the results looks good
on 4.12 and 4.13 kernel.
Summary,
Total Tests: 1136
Total Skipped Tests: 115
Total Failures: 0
Machine Architecture: aarch64
The reason for 115 skip are due to $(testcase)_16 and libnuma/NUMA
related tests were skipped.
- Naresh
>
> --
> Cyril Hrubis
> chrubis@suse.cz
^ permalink raw reply [flat|nested] 9+ messages in thread
* [LTP] LTP release and code freeze
2017-09-25 20:00 ` Naresh Kamboju
@ 2017-09-26 8:51 ` Li Wang
2017-09-26 19:18 ` Naresh Kamboju
0 siblings, 1 reply; 9+ messages in thread
From: Li Wang @ 2017-09-26 8:51 UTC (permalink / raw)
To: ltp
On Tue, Sep 26, 2017 at 4:00 AM, Naresh Kamboju
<naresh.kamboju@linaro.org> wrote:
> Hi Cyril,
>
> On 19 September 2017 at 01:04, Cyril Hrubis <chrubis@suse.cz> wrote:
>> Hi!
>>> Regarding the LTP September 2017 release,
>>> Identifying bugs / issues / limitation / pre-requirements of LTP
>>> testing on ARM64 architecture is crucial at our end. We would like to
>>> test LTP pre-release candidate on ARM64 architecture.
>>> Please announce code freeze and allow time to validate test code.
>>
>> I guess that you can start with the validation now. We haven't declared
>> the freeze formally yet, but there are only a few possible changes that
>> may get in the release. The thp01 is broken on new kernels, that one
>> should get in for sure. Then possibly something like ten tests may end
>> up affected by possible changes in the CVE tests, which should be easy
>> enough to retest if needed.
>
> Tested LTP syscalls on ARM64 architecture and the results looks good
> on 4.12 and 4.13 kernel.
FYI:
I run the latest LTP on x86_64 arch and only get 1
failure(madvise08.c) on 4.14-rc1 kernel.
# ./madvise08
tst_test.c:908: INFO: Timeout per run is 0h 05m 00s
madvise08.c:87: INFO: System core pattern is 'core'
madvise08.c:91: INFO: Temporary core pattern is '/tmp/H9HNr1/dump-%p'
madvise08.c:133: INFO: Dump file should be dump-1368
madvise08.c:215: FAIL: Found sequence in dump when MADV_DONTDUMP set
madvise08.c:133: INFO: Dump file should be dump-1369
madvise08.c:221: PASS: madvise(..., MADV_DODUMP)
Summary:
passed 1
failed 1
skipped 0
warnings 0
After do some research, I found that is a kernel regression bug which
has been fixed by an unmerge patch in LKML:
https://lkml.org/lkml/2017/9/18/541
A simple reproducer:
$ cat test.c
#include <signal.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/mman.h>
#define SIZE 10*1024*1024
int main()
{
char *addr;
addr = mmap(NULL, SIZE,
PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE,
-1, 0);
*addr = 'y';
madvise(addr, SIZE, MADV_DONTDUMP);
abort();
}
$ gcc test.c
$ ./a.out
Aborted (core dumped)
$ ll -h core*
-rw-------. 1 root root 15M Sep 26 04:25 core.1362
Here we can see the core.1362 dump file size included the 10MB memory
with MADV_DONTDUMP flag. After apply the patch this issue is gone!
Just share about this if someone is still on debugging the madvise08 issue.
--
Li Wang
liwang@redhat.com
^ permalink raw reply [flat|nested] 9+ messages in thread* [LTP] LTP release and code freeze
2017-09-26 8:51 ` Li Wang
@ 2017-09-26 19:18 ` Naresh Kamboju
2017-09-27 1:52 ` Li Wang
0 siblings, 1 reply; 9+ messages in thread
From: Naresh Kamboju @ 2017-09-26 19:18 UTC (permalink / raw)
To: ltp
On 26 September 2017 at 01:51, Li Wang <liwang@redhat.com> wrote:
> On Tue, Sep 26, 2017 at 4:00 AM, Naresh Kamboju
> <naresh.kamboju@linaro.org> wrote:
>> Hi Cyril,
>>
>> On 19 September 2017 at 01:04, Cyril Hrubis <chrubis@suse.cz> wrote:
>>> Hi!
>>>> Regarding the LTP September 2017 release,
>>>> Identifying bugs / issues / limitation / pre-requirements of LTP
>>>> testing on ARM64 architecture is crucial at our end. We would like to
>>>> test LTP pre-release candidate on ARM64 architecture.
>>>> Please announce code freeze and allow time to validate test code.
>>>
>>> I guess that you can start with the validation now. We haven't declared
>>> the freeze formally yet, but there are only a few possible changes that
>>> may get in the release. The thp01 is broken on new kernels, that one
>>> should get in for sure. Then possibly something like ten tests may end
>>> up affected by possible changes in the CVE tests, which should be easy
>>> enough to retest if needed.
>>
>> Tested LTP syscalls on ARM64 architecture and the results looks good
>> on 4.12 and 4.13 kernel.
>
> FYI:
>
> I run the latest LTP on x86_64 arch and only get 1
> failure(madvise08.c) on 4.14-rc1 kernel.
>
> # ./madvise08
> tst_test.c:908: INFO: Timeout per run is 0h 05m 00s
> madvise08.c:87: INFO: System core pattern is 'core'
> madvise08.c:91: INFO: Temporary core pattern is '/tmp/H9HNr1/dump-%p'
> madvise08.c:133: INFO: Dump file should be dump-1368
> madvise08.c:215: FAIL: Found sequence in dump when MADV_DONTDUMP set
> madvise08.c:133: INFO: Dump file should be dump-1369
> madvise08.c:221: PASS: madvise(..., MADV_DODUMP)
>
> Summary:
> passed 1
> failed 1
> skipped 0
> warnings 0
>
On 4.14.0.rc2 on ARM64 architecture the madvise08 test pass.
Kernel Version: 4.14.0-rc2-00044-ge365806
Machine Architecture: aarch64
LTP version: 20170516-277-g247466a63
tst_test.c:908: INFO: Timeout per run is 0h 05m 00s
madvise08.c:87: INFO: System core pattern is '|/bin/false'
madvise08.c:91: INFO: Temporary core pattern is
'/tmp/ltp-InS0HOqMuy/14UUcU/dump-%p'
madvise08.c:133: INFO: Dump file should be dump-5076
madvise08.c:217: PASS: madvise(..., MADV_DONTDUMP)
madvise08.c:133: INFO: Dump file should be dump-5077
madvise08.c:221: PASS: madvise(..., MADV_DODUMP)
Summary:
passed 2
failed 0
skipped 0
warnings 0
> After do some research, I found that is a kernel regression bug which
> has been fixed by an unmerge patch in LKML:
> https://lkml.org/lkml/2017/9/18/541
Is it merged in -rc2 ?
>
> A simple reproducer:
>
> $ cat test.c
> #include <signal.h>
> #include <stdlib.h>
> #include <stdio.h>
> #include <sys/mman.h>
>
> #define SIZE 10*1024*1024
>
> int main()
> {
> char *addr;
>
> addr = mmap(NULL, SIZE,
> PROT_READ | PROT_WRITE,
> MAP_ANONYMOUS | MAP_PRIVATE,
> -1, 0);
>
> *addr = 'y';
>
> madvise(addr, SIZE, MADV_DONTDUMP);
>
> abort();
> }
>
> $ gcc test.c
> $ ./a.out
> Aborted (core dumped)
> $ ll -h core*
> -rw-------. 1 root root 15M Sep 26 04:25 core.1362
>
>
> Here we can see the core.1362 dump file size included the 10MB memory
> with MADV_DONTDUMP flag. After apply the patch this issue is gone!
Alright !
>
> Just share about this if someone is still on debugging the madvise08 issue.
>
> --
> Li Wang
> liwang@redhat.com
^ permalink raw reply [flat|nested] 9+ messages in thread* [LTP] LTP release and code freeze
2017-09-26 19:18 ` Naresh Kamboju
@ 2017-09-27 1:52 ` Li Wang
0 siblings, 0 replies; 9+ messages in thread
From: Li Wang @ 2017-09-27 1:52 UTC (permalink / raw)
To: ltp
On Wed, Sep 27, 2017 at 3:18 AM, Naresh Kamboju
<naresh.kamboju@linaro.org> wrote:
> On 26 September 2017 at 01:51, Li Wang <liwang@redhat.com> wrote:
>> On Tue, Sep 26, 2017 at 4:00 AM, Naresh Kamboju
>> <naresh.kamboju@linaro.org> wrote:
>>> Hi Cyril,
>>>
>>> On 19 September 2017 at 01:04, Cyril Hrubis <chrubis@suse.cz> wrote:
>>>> Hi!
>>>>> Regarding the LTP September 2017 release,
>>>>> Identifying bugs / issues / limitation / pre-requirements of LTP
>>>>> testing on ARM64 architecture is crucial at our end. We would like to
>>>>> test LTP pre-release candidate on ARM64 architecture.
>>>>> Please announce code freeze and allow time to validate test code.
>>>>
>>>> I guess that you can start with the validation now. We haven't declared
>>>> the freeze formally yet, but there are only a few possible changes that
>>>> may get in the release. The thp01 is broken on new kernels, that one
>>>> should get in for sure. Then possibly something like ten tests may end
>>>> up affected by possible changes in the CVE tests, which should be easy
>>>> enough to retest if needed.
>>>
>>> Tested LTP syscalls on ARM64 architecture and the results looks good
>>> on 4.12 and 4.13 kernel.
>>
>> FYI:
>>
>> I run the latest LTP on x86_64 arch and only get 1
>> failure(madvise08.c) on 4.14-rc1 kernel.
>>
>> # ./madvise08
>> tst_test.c:908: INFO: Timeout per run is 0h 05m 00s
>> madvise08.c:87: INFO: System core pattern is 'core'
>> madvise08.c:91: INFO: Temporary core pattern is '/tmp/H9HNr1/dump-%p'
>> madvise08.c:133: INFO: Dump file should be dump-1368
>> madvise08.c:215: FAIL: Found sequence in dump when MADV_DONTDUMP set
>> madvise08.c:133: INFO: Dump file should be dump-1369
>> madvise08.c:221: PASS: madvise(..., MADV_DODUMP)
>>
>> Summary:
>> passed 1
>> failed 1
>> skipped 0
>> warnings 0
>>
>
> On 4.14.0.rc2 on ARM64 architecture the madvise08 test pass.
>
> Kernel Version: 4.14.0-rc2-00044-ge365806
> Machine Architecture: aarch64
> LTP version: 20170516-277-g247466a63
>
> tst_test.c:908: INFO: Timeout per run is 0h 05m 00s
> madvise08.c:87: INFO: System core pattern is '|/bin/false'
> madvise08.c:91: INFO: Temporary core pattern is
> '/tmp/ltp-InS0HOqMuy/14UUcU/dump-%p'
> madvise08.c:133: INFO: Dump file should be dump-5076
> madvise08.c:217: PASS: madvise(..., MADV_DONTDUMP)
> madvise08.c:133: INFO: Dump file should be dump-5077
> madvise08.c:221: PASS: madvise(..., MADV_DODUMP)
>
> Summary:
> passed 2
> failed 0
> skipped 0
> warnings 0
>
>
>> After do some research, I found that is a kernel regression bug which
>> has been fixed by an unmerge patch in LKML:
>> https://lkml.org/lkml/2017/9/18/541
>
> Is it merged in -rc2 ?
No, It have not be merged.
This BUG is actually a coredump bug, and only found on x86_64 arch
with kernel configuration 'CONFIG_X86_INTEL_MPX' enabled.
The fallback is like:
elf_core_dump -> vma_dump_size -> always_dump_vma -> arch_vma_name
since the VM_MPX define to wrong number, arch_vma_name() return [mpx]
for all private memory, so vma_dump_size() goto whole dump branch and
our MADV_DONTDUMP was ignore there.
--
Li Wang
liwang@redhat.com
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-09-27 13:17 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-09-19 8:48 [LTP] LTP release and code freeze Cyril Hrubis
2017-09-19 18:26 ` Sandeep Patil
2017-09-27 13:17 ` Cyril Hrubis
-- strict thread matches above, loose matches on Subject: below --
2017-09-18 7:21 Naresh Kamboju
2017-09-19 8:04 ` Cyril Hrubis
2017-09-25 20:00 ` Naresh Kamboju
2017-09-26 8:51 ` Li Wang
2017-09-26 19:18 ` Naresh Kamboju
2017-09-27 1:52 ` Li Wang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox