linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: anthony.yznaga@oracle.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Cc: akpm@linux-foundation.org, ljs@kernel.org,
	Liam.Howlett@oracle.com, vbabka@kernel.org, rppt@kernel.org,
	surenb@google.com, mhocko@suse.com, jannh@google.com,
	pfalcato@suse.de, Jason@zx2c4.com, shuah@kernel.org
Subject: Re: [PATCH v3 2/2] selftests/mm: verify droppable mappings cannot be locked
Date: Tue, 14 Apr 2026 12:01:56 +0200	[thread overview]
Message-ID: <f1cfb1c4-9b7b-40db-9105-570936b61203@kernel.org> (raw)
In-Reply-To: <ae78cbdd-e9b3-4586-b492-89ecffae30fc@oracle.com>

On 4/13/26 23:54, anthony.yznaga@oracle.com wrote:
> 
> On 4/13/26 12:46 PM, David Hildenbrand (Arm) wrote:
>>> It's correct though mlock2 would also work since it's been in glibc for
>>> several years now. I just matched the existing tests. mlock2_ is a
>>> simple wrapper around syscall in tools/testing/selftests/mm/mlock2.h,
>>> and it was introduced when the mlock2 syscall was introduced. A trailing
>>> rather than a preceding underscore is...unfortunate.
>> Interesting ... and confusing :)
>>
>>>
>>> The intent was to skip the tests if compiled with headers where
>>> MAP_DROPPABLE isn't defined rather than force the value and get EINVAL
>>> because the kernel doesn't know about it. This way EINVAL can be flagged
>>> as a test failure and not skipped since it would likely indicate a test
>>> or kernel bug.
>> Note that the kernel headers you are compiling against don't imply
>> anything about the kernel that is actually running! So the argument
>> regarding EINVAL doesn't really hold.
> 
> Yes, I see that now.
> 
> 
>>
>> But note that we, in general, try to compile against the in-tree headers.
>>
>> See
>>
>> commit 75d60eb30daafb966db0e45f38e4cdeb5e5ed79c
>> Author: Lorenzo Stoakes <ljs@kernel.org>
>> Date:   Mon Oct 28 14:13:30 2024 +0000
>>
>>      tools: testing: update tools UAPI header for mman-common.h
>>
>>      Import the new MADV_GUARD_INSTALL/REMOVE madvise flags.
>>
>> And looking into it, I already see MAP_DROPPABLE there as well, so is
>> any special handling here even needed?
>>
> I'd say no special handling is needed.

Right, so the #ifdef is not required at all.

> If this test is compiled on with
> a kernel that has MAP_DROPPABLE but run on an older kernel without
> MAP_DROPPABLE, should it fail? Or should it interpret the EINVAL as a
> sufficient reason to assume MAP_DROPPABLE is not supported and to skip
> the result? My current thinking is it should fail because the EINVAL
> could have another cause.
Ah, you want to sense for MAP_DROPPABLE support in older kernels.

I guess treating -EINVAL as "not supported on old kernel" is good enough.

Looking at tools/testing/selftests/mm/droppable.c, we seem to not
perform any such checks ... unfortunately.

-- 
Cheers,

David


      reply	other threads:[~2026-04-14 10:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-09 23:49 [PATCH v3 0/2] fix MAP_DROPPABLE not supported errno Anthony Yznaga
2026-04-09 23:49 ` [PATCH v3 1/2] mm: fix mmap errno value when MAP_DROPPABLE is not supported Anthony Yznaga
2026-04-09 23:49 ` [PATCH v3 2/2] selftests/mm: verify droppable mappings cannot be locked Anthony Yznaga
2026-04-10  7:57   ` David Hildenbrand (Arm)
2026-04-10 19:06     ` anthony.yznaga
2026-04-13 19:46       ` David Hildenbrand (Arm)
2026-04-13 21:54         ` anthony.yznaga
2026-04-14 10:01           ` David Hildenbrand (Arm) [this message]

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=f1cfb1c4-9b7b-40db-9105-570936b61203@kernel.org \
    --to=david@kernel.org \
    --cc=Jason@zx2c4.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=anthony.yznaga@oracle.com \
    --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=pfalcato@suse.de \
    --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