public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Tom Gall <tom.gall@linaro.org>
Cc: stable@vger.kernel.org, linux-kernel@vger.kernel.org, shuah@kernel.org
Subject: Re: kselftest backports?
Date: Thu, 8 Jun 2017 18:44:10 +0200	[thread overview]
Message-ID: <20170608164410.GA10597@kroah.com> (raw)
In-Reply-To: <CAOfXc9FMwPUPVdgC-0f4qzUyjNaptGQGP9-ZZvAh2B+30bw4rg@mail.gmail.com>

On Thu, Jun 08, 2017 at 10:37:55AM -0500, Tom Gall wrote:
> 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.

Really?  What breaks?

> #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?

No, that would be a new feature, and new features are not allowed in the
stable kernel releases, right?

And as the kernel/user api is "stable", there should never be any
problem with running new tests from newer kernel releases on older
kernel, right?  If so, I think that would be a bug and the test should
be fixed.  Right now we have a lot of tests that properly "degrade" if
the requested feature is not present, so I think things already work
properly today.

Do you know of any kselftests from 4.12-rc4 that are failing on 4.4
because of bugs in the tests?

> -) In the case where some test is kernel version specific for whatever
> reason, I presume building in version detection into kselftest makes
> sense?

No, it's a feature detection issue, look at how lots of tests already
degrade if a specific syscall is not present.  That should never be a
kernel release number detection as that would break horribly on things
like the "enterprise" Linux distro kernels who backport all sorts of new
features, and yet keep an old kernel version to make people feel warm
and fuzzy.

thanks,

greg k-h

  reply	other threads:[~2017-06-08 16:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-08 15:37 kselftest backports? Tom Gall
2017-06-08 16:44 ` Greg KH [this message]
2017-06-08 17:46   ` Sumit Semwal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170608164410.GA10597@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shuah@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tom.gall@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox