public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Audra Mitchell <audra@redhat.com>
Cc: linux-kselftest@vger.kernel.org, akpm@linux-foundation.org,
	lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com,
	vbabka@suse.cz, rppt@kernel.org, surenb@google.com,
	mhocko@suse.com, shuah@kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] selftests/mm: Fix soft-dirty kselftest supported check
Date: Wed, 18 Mar 2026 09:17:41 +0100	[thread overview]
Message-ID: <f635585f-7488-4bfe-8566-1c19f493c6a3@kernel.org> (raw)
In-Reply-To: <abludfGu4upPcyRI@fedora>

On 3/17/26 16:08, Audra Mitchell wrote:
> Sorry! I missed this email so never responded!
> 
> On Tue, Feb 24, 2026 at 05:15:14PM +0100, David Hildenbrand (Arm) wrote:
>> On 2/18/26 19:42, Audra Mitchell wrote:
>>> On architectures with separate user address space, such as s390 or
>>> those without an MMU, the call to __access_ok will return true.
>>
>> Where is this __access_ok() you mention here? Somewhere in
>> fs/proc/task_mmu.c?
>>
>> Where in the soft-dirty test is that triggered?
>>
>> I'm wondering whether the soft-dirty test should be adjusted, but I did
>> not yet understand from where this behavior is triggered.
> 
> The problem arises when we are checking to see what features/categories are
> supported. The call chain for the soft-dirty program goes:
> 
>   main()
>     ->test_simple()
>       ->pagemap_is_softdirty()
>         ->page_entry_is()
>           ->pagemap_scan_supported()
>             ->__pagemap_scan_get_categories()
>               ->ioctl()
>   
> We enter the kernel with an ioctl, expecting to have an EFAULT returned (see
> the comment from pagemap_scan_get_categories():
>     
>           /* Provide an invalid address in order to trigger EFAULT. */
>         ret = __pagemap_scan_get_categories(fd, start, (struct page_region *) ~0UL);
> 
> Once we enter the kernel, we will check the arguments passed which includes the
> call to access_ok: 
> 
>   do_pagemap_cmd()
>     ->do_pagemap_scan()
>       ->pagemap_scan_get_args()
>         ->access_ok()
> 
> Here is the path within pagemap_scan_get_args where we expect to fail return
> the EFAULT:
> 
>         if (arg->vec && !access_ok((void __user *)(long)arg->vec,
>                                    size_mul(arg->vec_len, sizeof(struct page_region))))
>                 return -EFAULT;
>                 
> However, if CONFIG_ALTERNATE_USER_ADDRESS_SPACE is enabled or if CONFIG_MMU is
> NOT enabled, then we just return true:
> 
>         if (IS_ENABLED(CONFIG_ALTERNATE_USER_ADDRESS_SPACE) ||
>             !IS_ENABLED(CONFIG_MMU))
>                 return true;
> 
> The intent appears to be just getting the categories available to us and
> verifying that we have the feature available for testing. However, this corner
> case means the soft-dirty test will fail with the following:
> 

Thanks for the information, we should clarify that in the patch description.

>   # --------------------
>   # running ./soft-dirty
>   # --------------------
>   # TAP version 13
>   # 1..15
>   # Bail out! PAGEMAP_SCAN succeeded unexpectedly
>   # # Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0
>   # [FAIL]
>   not ok 1 soft-dirty # exit=1
>   # SUMMARY: PASS=0 SKIP=0 FAIL=1
>   1..1
>   
> Since the intent is just to validate that the features are available to us for
> testing, I think we can just modify the check so that we don't fail if we
> return 0.
>   
> Let me know what you think, or if you have more questions!

What about simply testing for success on a test area, wouldn't that be more reliable
and clearer?

diff --git a/tools/testing/selftests/mm/vm_util.c b/tools/testing/selftests/mm/vm_util.c
index a6d4ff7dfdc0..489a8d4d915d 100644
--- a/tools/testing/selftests/mm/vm_util.c
+++ b/tools/testing/selftests/mm/vm_util.c
@@ -67,21 +67,26 @@ static uint64_t pagemap_scan_get_categories(int fd, char *start)
 }
 
 /* `start` is any valid address. */
-static bool pagemap_scan_supported(int fd, char *start)
+static bool pagemap_scan_supported(int fd)
 {
+	const size_t pagesize = getpagesize();
 	static int supported = -1;
-	int ret;
+	struct page_region r;
+	void *test_area;
 
 	if (supported != -1)
 		return supported;
 
-	/* Provide an invalid address in order to trigger EFAULT. */
-	ret = __pagemap_scan_get_categories(fd, start, (struct page_region *) ~0UL);
-	if (ret == 0)
-		ksft_exit_fail_msg("PAGEMAP_SCAN succeeded unexpectedly\n");
-
-	supported = errno == EFAULT;
-
+	test_area = mmap(0, pagesize, PROT_READ | PROT_WRITE,
+		    MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
+	if (test_area == MAP_FAILED) {
+		ksft_print_msg("WARN: mmap() failed: %s\n", strerror(errno));
+		supported = 0;
+	} else {
+		supported = __pagemap_scan_get_categories(fd, test_area, &r) >= 0;
+		ksft_print_msg("errno: %d\n", errno);
+		munmap(test_area, pagesize);
+	}
 	return supported;
 }
 
@@ -90,7 +95,7 @@ static bool page_entry_is(int fd, char *start, char *desc,
 {
 	bool m = pagemap_get_entry(fd, start) & pagemap_flags;
 
-	if (pagemap_scan_supported(fd, start)) {
+	if (pagemap_scan_supported(fd)) {
 		bool s = pagemap_scan_get_categories(fd, start) & pagescan_flags;
 
 		if (m == s)
-- 
2.43.0


> 
>> Do we have a Fixes: tag?
> 
> I always hesistate to add a Fixes tag on situations like this since this is a
> corner case that was not considered by the original author. If we need a
> fixes tag, then it would be:
> 
> Fixes: 600bca580579 ("selftests/mm: check that PAGEMAP_SCAN returns correct categories")

Yes, please add that. We nowadays also add proper Fixes tags for tests.

-- 
Cheers,

David


  reply	other threads:[~2026-03-18  8:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-18 18:42 [PATCH] selftests/mm: Fix soft-dirty kselftest supported check Audra Mitchell
2026-02-24 16:15 ` David Hildenbrand (Arm)
2026-03-17 15:08   ` Audra Mitchell
2026-03-18  8:17     ` David Hildenbrand (Arm) [this message]
2026-03-19 18:59       ` Audra Mitchell
2026-03-20 11:26         ` David Hildenbrand (Arm)
2026-03-20 18:39           ` [PATCH V2] " Audra Mitchell
2026-03-20 18:39             ` [PATCH] " Audra Mitchell
2026-03-20 20:53               ` Andrew Morton
2026-03-23 11:56               ` David Hildenbrand (Arm)
2026-03-24 23:23                 ` Andrew Morton
2026-03-24 23:24                   ` Andrew Morton
2026-03-25 16:23                     ` Audra Mitchell

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=f635585f-7488-4bfe-8566-1c19f493c6a3@kernel.org \
    --to=david@kernel.org \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=audra@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mhocko@suse.com \
    --cc=rppt@kernel.org \
    --cc=shuah@kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    /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