public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
* Clarifying stable kernel rule on selftest backporting
@ 2025-03-20 14:31 Shung-Hsi Yu
  2025-03-20 14:47 ` Greg Kroah-Hartman
  0 siblings, 1 reply; 2+ messages in thread
From: Shung-Hsi Yu @ 2025-03-20 14:31 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin; +Cc: stable

Hi,

Do we have any rule regarding whether a patch that adds a new test case
in tools/testing/selftests/ can be considered for backport?

For example, consider commit 0a5d2efa3827 ("selftests/bpf: Add test case
for the freeing of bpf_timer"), it adds a test case for the issue
addressed in the same series -- commit 58f038e6d209 ("bpf: Cancel the
running bpf_timer through kworker for PREEMPT_RT"). The latter has been
backported to 6.12.y.

Would commit 0a5d2efa3827 be a worthwhile add to 6.12.y as well?

IMO having such test case added would be helpful to check whether the
backported fix really works (assuming someone is willing to do the extra
work of finding, testing, and sending such tests); yet it does not seem
to fit into the current stable kernel rule set of:
- It or an equivalent fix must already exist in Linux mainline (upstream).
- It must be obviously correct and tested.
- It cannot be bigger than 100 lines, with context.
- It must follow the Documentation/process/submitting-patches.rst rules.
- It must either fix a real bug that bothers people or just add a device ID

Appreciate any clarification and/or feedback on this matter.

Thanks,
Shung-Hsi Yu

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2025-03-20 14:49 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-03-20 14:31 Clarifying stable kernel rule on selftest backporting Shung-Hsi Yu
2025-03-20 14:47 ` Greg Kroah-Hartman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox