linux-kernel - kselftest backports?

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-next>] [day] [month] [year] [list]

Message-ID: <CAOfXc9FMwPUPVdgC-0f4qzUyjNaptGQGP9-ZZvAh2B+30bw4rg@mail.gmail.com>
Date:   Thu, 8 Jun 2017 10:37:55 -0500
From:   Tom Gall <tom.gall@...aro.org>
To:     stable@...r.kernel.org, linux-kernel@...r.kernel.org,
        shuah@...nel.org
Subject: kselftest backports?

We've been running kselftests for ARM and x86 hardware in an effort to
detect regressions in various kernels including LTS and candidate
patches.

One general question we've had is what's the right thing to do when it
comes to running kselftest on older LTS kernels. Let's pick on 4.4 for
the purposes of this discussion tho obviously the example applies to
other versions.

1) Run current top of tree, kselftest on a 4.4 LTS?
2) Run kselftest from 4.4 on 4.4 LTS?

#1 gets latest greatest set of tests but obviously there can be
breakage because of how the kernel evolves over time.
#2 misses tests that are later developed but otherwise fine

Regardless of the right answer, some obvious questions but I'll ask anyway:
-) Shouldn't new additions to kselftest that work on older kernels be
backported and submitted on the stable list?
-) In the case where some test is kernel version specific for whatever
reason, I presume building in version detection into kselftest makes
sense?

Thanks.

-- 
Regards,
Tom

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

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