On Tue, Apr 2, 2024 at 7:57 AM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > On Mon, Apr 01 2024 at 13:17, John Stultz wrote: > > This change does seem to cherry-pick cleanly back to at least > > stable/linux-5.10.y cleanly, so it looks simple to pull this change > > back. But I wanted to make sure there wasn't anything subtle I was > > missing before sending patches. > > This test in particular exercises new functionality/behaviour, which > really has no business to be backported into stable just to make the > relevant test usable on older kernels. That's fair. I didn't have all the context around what motivated the change and the follow-on test, which is why I'm asking here. > Why would testing with latest tests against an older kernel be valid per > se? So yeah, it definitely can get fuzzy trying to split hairs between when a change in behavior is a "new feature" or a "fix". Greg could probably articulate it better, but my understanding is the main point for running newer tests on older kernels is that newer tests will have more coverage of what is expected of the kernel. For features that older kernels don't support, ideally the tests will check for that functionality like userland applications would, and skip that portion of the test if it's unsupported. This way, we're able to find issues (important enough to warrant tests having been created) that have not yet been patched in the -stable trees. In this case, there is a behavioral change combined with a compliance test, which makes it look a bit more like a fix, rather than a feature (additionally the lack of a way for userland to probe for this new "feature" makes it seem fix-like). But the intended result of this is just spurring this discussion to see if it makes sense to backport or not. Disabling/ignoring the test (maybe after Thomas' fix to avoid it from hanging :) is a fine solution too, but not one I'd want folks to do until they've synced with maintainers and had full context. thanks -john
