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:   Sat, 21 Oct 2017 09:37:57 -0500
From:   Tom Gall <tom.gall@...aro.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     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>
Subject: Re: [PATCH 4.4 00/46] 4.4.94-stable review


> On Oct 21, 2017, at 2:25 AM, Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
> 
> On Fri, Oct 20, 2017 at 11:54:38AM -0500, Tom Gall wrote:
>> On Fri, Oct 20, 2017 at 1:26 AM, Greg Kroah-Hartman
>>>> fcntl36 and raw_skew we’ll looking into.
>>>> 
>>>> ltp-timers-tests:
>>>>   * leapsec_timer
>>>>   * runltp_timers
>>>> 
>>>>   * test src: git://github.com/linux-test-project/ltp.git
>>>> 
>>>> This one has been working and just failed with this RC cycle. It’s only failing on 32 bit arm.
>>>> 
>>>> Needs to be looked into.
>>> 
>>> When you say "Needs to be looked into", does that mean that you are
>>> pointing this out for someone else to do this (i.e. help, someone look
>>> at this!), or are you going to be working to figure it out?
>> 
>> Help is always great. We've got it covered.
>> 
>> One of the team that works on this board has been looking into it.
>> 
>> As of this second, and looking within the context of 4.4, 4.9 and mainline data
>> what we're looking at is intermitted failures involving raw_skew from
>> kselftest and leapsec_timer
>> from ltp_timers that is present across all those 3 kernel version and
>> their respective streams.
>> (by stream I mean FOO, FOO-rc1, FOO+1, FOO+1-rc1, etc)
>> 
>> As such we can rule these out detecting a regression in the new RC
>> patches. Likely it's board
>> specific.
> 
> Side note, your use of \n is still really odd.  I strongly recommend
> getting a decent email client, or an sane editor that knows what to do
> here….

That email client has been sacked.

> Anyway, if you have board-specific issues, that are not -rc issues, can
> you say so really obviously so I don't worry that I broke something?
> Otherwise it's pretty annoying, as your email implies that I did
> something wrong, and only a few emails in the thread later will it come
> out that this is flaky hardware/tests so there's nothing to worry about.

Reports are pretty new & shiny yet so yes I’m over explaining the logic. 
To me, showing your work applies to other places besides math.

> The kernel.ci reports are a bit like this, I glance at them and only
> worry if the reporter tells me to worry.  Should I do the same thing
> here as well?  When can these tests/reports start to be trusted?

Exactly and no surprise as number of those involved in all of this helped 
get kernelci off the ground. 

Our aim is to have quick summaries either appended with the gory 
details or pointers to it for those that care.

For me the x86 and arm64 results are trustable. We’re working on
getting 4.14-rc runs clean and then we’ll get after the ‘known
errors with 4.4 and 4.9 as well.

32 bit arm results are a bit new/shiny yet.  That’s where I’m most
skeptical when something pops up.

Hope the perspective helps.

> thanks,
> 
> greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ