Linux kernel -stable discussions
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Brett Sheffield <brett@librecast.net>
Cc: stable@vger.kernel.org
Subject: Re: Backporting Selftests to Stable Kernels?
Date: Sat, 23 Aug 2025 15:51:05 +0200	[thread overview]
Message-ID: <2025082352-hefty-humorous-700d@gregkh> (raw)
In-Reply-To: <aKm8qmts_2Cp4j2p@karahi.gladserv.com>

On Sat, Aug 23, 2025 at 03:05:46PM +0200, Brett Sheffield wrote:
> Dear Stable Maintainers,
> 
> When a bugfix is backported to stable kernels, should we be backporting the
> associated selftest(s)?

If you want to, sure!

> eg.
> 
> 9e30ecf23b1b ("net: ipv4: fix incorrect MTU in broadcast routes")
> was backported to stable, but the selftest was not:
> 5777d1871bf6 ("selftests: net: add test for variable PMTU in broadcast routes")
> 
> Does stable policy say whether it should be?

It's up to the subsystem/maintainer/developer/whomever if they wish to
do that or not.  Some subsystems want to do this, others don't, others
don't care.

> It does not fix a bug, per se, but it does enable those of us running stable
> kernel tests to more thoroughly test stable RCs.

Note that you should always be running the latest selftests for older
kernels, and I think that's what many of the CI systems are already
doing, so maybe that's why you don't notice stuff like this?

That's the only "rule" we have, all new selftests need to work properly
for older kernels.

> Should mainline authors be encouraged to mark related tests for backporting?

Again, it's up to them if they want to or not.  I will point out mptcp
as one subsystem that does mark selftests to backport, and provides
backports for when they do not apply correctly.

hope this helps,

greg k-h

  reply	other threads:[~2025-08-23 13:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-23 13:05 Backporting Selftests to Stable Kernels? Brett Sheffield
2025-08-23 13:51 ` Greg KH [this message]
2025-08-23 13:59   ` Brett A C Sheffield

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=2025082352-hefty-humorous-700d@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=brett@librecast.net \
    --cc=stable@vger.kernel.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