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]
Message-ID: <20171021072554.GB18091@kroah.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ