From: Audra Mitchell <audra@redhat.com>
To: "David Hildenbrand (Arm)" <david@kernel.org>
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: Tue, 17 Mar 2026 11:08:37 -0400 [thread overview]
Message-ID: <abludfGu4upPcyRI@fedora> (raw)
In-Reply-To: <c1b6f8eb-602b-4306-ad60-7a181fd94a45@kernel.org>
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:
# --------------------
# 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!
> 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")
Thanks a bunch!
-- Audra Mitchell
next prev parent reply other threads:[~2026-03-17 15:08 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 [this message]
2026-03-18 8:17 ` David Hildenbrand (Arm)
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=abludfGu4upPcyRI@fedora \
--to=audra@redhat.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--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.