linux-kernel - Re: [PATCH 4.4 00/46] 4.4.94-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 for Android: free password hash cracker in your pocket

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

Date:   Sat, 21 Oct 2017 09:25:54 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Tom Gall <tom.gall@...aro.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 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....

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.

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?

thanks,

greg k-h