[LTP] LTP release and code freeze
Li Wang
liwang@redhat.com
Tue Sep 26 10:51:22 CEST 2017
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
More information about the ltp
mailing list