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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ