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
next prev parent reply other threads:[~2026-03-18 8:17 UTC|newest]
Thread overview: 19+ 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
2026-03-27 10:08 ` David Hildenbrand (Arm)
2026-03-27 10:52 ` Lorenzo Stoakes (Oracle)
2026-03-27 10:58 ` Lorenzo Stoakes (Oracle)
2026-03-27 11:15 ` Lorenzo Stoakes (Oracle)
2026-03-27 11:14 ` Lorenzo Stoakes (Oracle)
2026-03-31 16:32 ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.