linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Pedro Falcato <pfalcato@suse.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: anthony.yznaga@oracle.com, linux-mm@kvack.org,
	 linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	david@kernel.org,  ljs@kernel.org, Liam.Howlett@oracle.com,
	vbabka@kernel.org, rppt@kernel.org,  surenb@google.com,
	mhocko@suse.com, jannh@google.com, Jason@zx2c4.com,
	 shuah@kernel.org
Subject: Re: [PATCH v2 2/2] selftests/mm: verify droppable mappings cannot be locked
Date: Thu, 9 Apr 2026 09:51:49 +0100	[thread overview]
Message-ID: <urtokyyat4gw3zvfffdpz5yq6pvwrzjvc3cttpps2xiuucflzz@ujutvveagq2l> (raw)
In-Reply-To: <20260408140251.6158aa7a56f71128471f327e@linux-foundation.org>

On Wed, Apr 08, 2026 at 02:02:51PM -0700, Andrew Morton wrote:
> On Wed, 8 Apr 2026 13:35:42 -0700 anthony.yznaga@oracle.com wrote:
> 
> > 
> > On 4/3/26 12:31 PM, Andrew Morton wrote:
> > > On Thu,  2 Apr 2026 16:59:33 -0700 Anthony Yznaga <anthony.yznaga@oracle.com> 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/20260402235933.10588-1-anthony.yznaga@oracle.com
> > 
> > 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


  parent reply	other threads:[~2026-04-09  8:51 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-02 23:59 [PATCH v2 0/2] fix MAP_DROPPABLE not supported errno Anthony Yznaga
2026-04-02 23:59 ` [PATCH v2 1/2] mm: fix mmap errno value when MAP_DROPPABLE is not supported Anthony Yznaga
2026-04-03 18:16   ` Vlastimil Babka (SUSE)
2026-04-06  8:35   ` Pedro Falcato
2026-04-07 10:05   ` Lorenzo Stoakes (Oracle)
2026-04-02 23:59 ` [PATCH v2 2/2] selftests/mm: verify droppable mappings cannot be locked Anthony Yznaga
2026-04-03 19:31   ` Andrew Morton
2026-04-08 20:35     ` anthony.yznaga
2026-04-08 21:02       ` Andrew Morton
2026-04-08 22:26         ` anthony.yznaga
2026-04-09  8:03           ` Lorenzo Stoakes
2026-04-09  8:51         ` Pedro Falcato [this message]
2026-04-03 17:37 ` [PATCH v2 0/2] fix MAP_DROPPABLE not supported errno Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2026-03-10 15:58 [PATCH v2 1/2] mm: prevent droppable mappings from being locked Anthony Yznaga
2026-03-10 15:58 ` [PATCH v2 2/2] selftests/mm: verify droppable mappings cannot be locked Anthony Yznaga
2026-03-11  9:56   ` Pedro Falcato
2026-03-11 11:25   ` Lorenzo Stoakes (Oracle)
2026-03-31 13:17   ` Mark Brown
2026-03-31 21:17     ` Andrew Morton
2026-04-01 11:17       ` Mark Brown
2026-04-01 20:27         ` Andrew Morton
2026-03-31 22:45     ` anthony.yznaga

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=urtokyyat4gw3zvfffdpz5yq6pvwrzjvc3cttpps2xiuucflzz@ujutvveagq2l \
    --to=pfalcato@suse.de \
    --cc=Jason@zx2c4.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=anthony.yznaga@oracle.com \
    --cc=david@kernel.org \
    --cc=jannh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=rppt@kernel.org \
    --cc=shuah@kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@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