On Wed, Apr 08, 2026 at 03:26:14PM -0700, [email protected] wrote: > > On 4/8/26 2:02 PM, 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 > > has the effect of reducing people's motivation to run a later kernel's > > selftests on their current kernel. > > > That makes sense. It's trivial to skip the tests if MAP_DROPPABLE is not > defined so I'll do that. > >
Yeah in general, I think we best-effort try to keep them working for older kernels (but no guarantees IMO), so checking if something's implemented is cheap-and-easy. Cheers, Lorenzo
