On Wed, Apr 08, 2026 at 02:02:51PM -0700, Andrew Morton wrote: > On Wed, 8 Apr 2026 13:35:42 -0700 [email protected] wrote: > > > > > On 4/3/26 12:31 PM, Andrew Morton wrote: > > > On Thu, 2 Apr 2026 16:59:33 -0700 Anthony Yznaga > > > <[email protected]> wrote: > > > > > >> For configs that support MAP_DROPPABLE verify that a mapping created > > >> with MAP_DROPPABLE cannot be locked via mlock(), and that it will not > > >> be locked if it's created after mlockall(MCL_FUTURE). > > > There are a few queries from the AI reviewbot; > > > > > > https://sashiko.dev/#/patchset/[email protected] > > > > Interesting. Of the two issues, one is certainly legit. I need to add an > > munlockall() on early return from test_mlockall_future_droppable(). > > Cool. > > > For the other, the question posed was whether the tests should handle > > possibly being run on an older kernel that doesn't implement > > MAP_DROPPABLE. It seems to me to that a selftest should not be expected > > to work (or even necessarily compile) on kernels older than when the > > selftest was introduced, but I don't want to assume. > > I don't know that there's any policy on that. My attitude is that > selftests are not intended to be forward- or backward-compatible. > That's why we ship them with the kernel source! > > If we get a selftests fixup then I do like to backport that into > earlier kernels if appropriate, to keep those in good shape. And that
/me puts on his gecko-shaped distro kernel hat Yeah, adding selftests and selftests fixes to (upstream) stable is great. Particularly when it comes to bugfixes (or CVEs) they are quite handy to verify the fix is in place and works properly. > has the effect of reducing people's motivation to run a later kernel's > selftests on their current kernel. > Yeah. Some people do that but... to each, their own :) It should not be supported upstream. -- Pedro
