Re: [PATCH 4.4 00/47] 4.4.92-stable review

[Tom Gall]

On Wed, Oct 11, 2017 at 11:47 AM, Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, Oct 11, 2017 at 11:12:15AM -0500, Tom Gall wrote:
>> Letâs try that again with less HTML stupidness â.
>>
>> On Oct 11, 2017, at 11:05 AM, Tom Gall <tom.gall@xxxxxxxxxx> wrote:
>>
>>
>> > On Oct 10, 2017, at 2:50 PM, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>> >
>> > This is the start of the stable review cycle for the 4.4.92 release.
>> > There are 47 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 Thu Oct 12 19:50:01 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.92-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
>>
>> Full test results from Linaroâs test farm for 4.4.
>>
>> Note there are some further regressions weâve seen on x15 (arm) beyond the one I reported
>> last night and that Sumit then commented on.
>>
>> Weâve also moved up to the recently released LTP.
>
> Those two sentances could not possibly be related now, right?  :)

Prior results were just the syscalls portion of LTP. When we expanded to
use all of LTP, that's when we also worked in the upgrade to latest
LTP. LTP isn't changing
that much.

All the non-syscall results data is new. There's a kink or two to work
out there as we get to a
reasonable baseline.

Anything newly reported has been top priority to triage and either get
to working to
put on a skip list and we'll come back to get it working.

> You did test the latest version of LTP on a "known good kernel/system",
> ahead of time?

We're being admittedly aggressive to expand coverage and make
results available. Release early and often.

In the future for anything new, I'll call it out.

> Are these regressions to be expected?

We'll continue to annotate when errors pop up and note if it's
something to be alarmed about.

As I did last night when something looks troubling we're going to
speak up. I'd rather
respond with "here's something" instead of keeping completely silent
and then that turning out
to really be something. You've got a deadline for comments for a reason.

Hard bugs can take time. More eyes helps.

Regardless I want a reasonable clean baseline for at least 4.14 ASAP
and then we get after 4.9 and
4.4.

> x86 doesn't even look right here:
>
>> dell-poweredge-r200 - x86_64
>> * boot - 1 pass
>> * kselftest - 44 pass - 24 known failures
>
> 1/3 failure is ok?

No it's not.

Running kselftest from the current kernel release on an old 4.4 kernel
just isn't going that well.
Tests just don't fail gracefully.  People need to care about that when
they add to ksefltest.

Let's get 4.14 in order first and then get after this stuff.

>> * libhugetlbfs - 76 pass - 1 skip
>> * ltp-cap_bounds-tests - 1 pass
>> * ltp-commands-tests - 27 pass - 13 skip - 5 known failures (ksh not in test img)
>> * ltp-containers-tests - 63 pass - 18 fail (these are being looked at looks like setup issues with veth0)
>> * ltp-fcntl-locktests-tests - 2 pass
>> * ltp-filecaps-tests - 2 pass
>> * ltp-fs-tests - 61 pass - 1 skip
>> * ltp-fs_bind-tests - 2 pass
>> * ltp-fs_perms_simple-tests - 19 pass
>> * ltp-fsx-tests - 2 pass
>> * ltp-hugetlb-tests - 22 pass
>> * ltp-io-tests - 3 pass
>> * ltp-ipc-tests - 9 pass
>> * ltp-math-tests - 11 pass
>> * ltp-nptl-tests - 2 pass
>> * ltp-pty-tests - 4 pass
>> * ltp-sched-tests - 13 pass - 1 skip
>> * ltp-securebits-tests - 4 pass
>> * ltp-syscalls-tests - 960 pass - 164 skip - 13 known failures
>
> syscalls fail?  Why skip so many?

The known failures are due to our x86 box using an NFS root file
system. That won't be the case much longer.

As far as skipping, I'll come back with an answer on that. Skipping
isn't always bad if the test isn't really doing
something interesting, or doing something that is going to take way
too long. etc etc. Anyway I'll come back
with something definitive.

> thanks,
>
> greg k-h

-- 
Regards,
Tom

Director, Linaro Mobile Group
Linaro.org â Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian