[LTP] LTP release and code freeze

[LTP] LTP release and code freeze

[Naresh Kamboju]

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

[LTP] LTP release and code freeze

[Cyril Hrubis]

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

[LTP] LTP release and code freeze

[Naresh Kamboju]

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

[LTP] LTP release and code freeze

[Li Wang]

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

[LTP] LTP release and code freeze

[Naresh Kamboju]

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

[LTP] LTP release and code freeze

[Li Wang]

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

[LTP] LTP release and code freeze

[Cyril Hrubis]

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

[LTP] LTP release and code freeze

[Sandeep Patil]

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

[LTP] LTP release and code freeze

[Cyril Hrubis]

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