linux-kernel - Re: [PATCH 4.4 00/56] 4.4.98-stable review

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJrz+7KVkPMcSo4xHPOv17_7w=gs2ASAMQXYfUJE1x=w-m5Xcw@mail.gmail.com>
Date:   Wed, 15 Nov 2017 10:14:55 +0000
From:   Milosz Wasilewski <milosz.wasilewski@...aro.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Tom Gall <tom.gall@...aro.org>,
        LKML <linux-kernel@...r.kernel.org>,
        torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
        Guenter Roeck <linux@...ck-us.net>,
        Shuah Khan <shuahkh@....samsung.com>, patches@...nelci.org,
        Ben Hutchings <ben.hutchings@...ethink.co.uk>,
        linux- stable <stable@...r.kernel.org>,
        Naresh Kamboju <naresh.kamboju@...aro.org>
Subject: Re: [PATCH 4.4 00/56] 4.4.98-stable review

On 15 November 2017 at 08:59, Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
> On Tue, Nov 14, 2017 at 03:31:18PM -0600, Tom Gall wrote:
>>
>>
>> > On Nov 13, 2017, at 6:55 AM, Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
>> >
>> > This is the start of the stable review cycle for the 4.4.98 release.
>> > There are 56 patches in this series, all will be posted as a response
>> > to this one.  If anyone has any issues with these being applied, please
>> > let me know.
>> >
>> > Responses should be made by Wed Nov 15 12:55:32 UTC 2017.
>> > Anything received after that time might be too late.
>> >
>> > The whole patch series can be found in one patch at:
>> >     kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.98-rc1.gz
>> > or in the git tree and branch at:
>> >  git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
>> > and the diffstat can be found below.
>> >
>> > thanks,
>> >
>> > greg k-h
>> >
>>
>> Results from Linaro’s test farm. One regression detected on x86. We’re doing some re-runs to see if it’s a solid failure or intermittent. It is however a testcase which hasn’t failed in the past.  Also as per usual the HiKey results are reported separate because the platform support isn’t in tree.
>
> I thought I gave you enough \n in the past, did you use all of them up?  :(
>
> Anyway, what is the new x86 failure?
>
> Is it this:
>
>> * ltp-syscalls-tests - skip: 164, fail: 4, pass: 957

It's
readahead02    0  TINFO  :  creating test file of size: 67108864
readahead02    0  TINFO  :  read_testfile(0)
readahead02    0  TINFO  :  read_testfile(1)
readahead02    0  TINFO  :  max ra estimate: 262144
readahead02    0  TINFO  :  readahead calls made: 256
readahead02    1  TPASS  :  offset is still at 0 as expected
readahead02    0  TINFO  :  read_testfile(0) took: 951656 usec
readahead02    0  TINFO  :  read_testfile(1) took: 921704 usec
readahead02    0  TINFO  :  read_testfile(0) read: 67108864 bytes
readahead02    0  TINFO  :  read_testfile(1) read: 51257344 bytes
readahead02    2  TPASS  :  readahead saved some I/O
readahead02    0  TINFO  :  cache can hold at least: 86180 kB
readahead02    0  TINFO  :  read_testfile(0) used cache: 65308 kB
readahead02    0  TINFO  :  read_testfile(1) used cache: 15332 kB
readahead02    0  TWARN  :  readahead02.c:351: using less cache than expected

Source of the test:
https://github.com/linux-test-project/ltp/blob/20170929/testcases/kernel/syscalls/readahead/readahead02.c#L351

It's the first time this test failed since we started running it. I'll
ask Naresh to look into it.

>
> If so, any pointers to the specific log messages, and which tests are
> failing?  Digging through the web site isn't the easiest...
>
> And kselftests should have gotten less failures this time around, given
> that some of them were patched in this -rc, why didn't that number go
> down?

Do you mean the tests were patched or the kernel code that was
exercised? If it's the former, it won't have effect as we're using the
kselftests sources from 4.13

milosz