From: Hajime Tazaki <thehajime@gmail.com>
To: ljs@kernel.org
Cc: linux-mm@kvack.org, geert@linux-m68k.org, daniel@thingy.jp,
akpm@linux-foundation.org, david@kernel.org, liam@infradead.org,
vbabka@kernel.org, rppt@kernel.org, surenb@google.com,
mhocko@suse.com, shuah@kernel.org,
linux-kselftest@vger.kernel.org, linux-um@lists.infradead.org
Subject: Re: [RFC PATCH 6/6] selftests/mm: add nommu mmap and mremap behavior tests
Date: Sat, 15 Aug 2026 07:35:26 +0900 [thread overview]
Message-ID: <m2wltspbyp.wl-thehajime@gmail.com> (raw)
In-Reply-To: <an8SvW3jv3JuAFc8@lucifer>
On Fri, 14 Aug 2026 22:28:53 +0900,
Lorenzo Stoakes (ARM) wrote:
>
> On Thu, Aug 13, 2026 at 03:34:01PM +0900, Hajime Tazaki wrote:
> > Introduce a kselftest utility to validate memory mapping capabilities
> > under nommu kernels, aligned with
> > Documentation/admin-guide/mm/nommu-mmap.rst.
> >
> > The test implements basic checks into a generic architecture-agnostic
> > test matrix applicable across nommu targets. It evaluates:
> >
> > 1. MAP_FIXED allocation rejections.
> > 2. Standard MAP_PRIVATE and MAP_ANONYMOUS allocation resilience.
> > 3. MAP_UNINITIALIZED allocations via optional kernel configurations.
> > 4. Regular file mappings via standard filesystem storage.
> > 5. Memory-backed file mapping with /dev/zero
> > 6. Block device subsystem mappings (gracefully skipping if node is
> > missing).
> > 7. Shared vs Private backing discrepancies under nommu conditions.
> > 8. mremap limits, ensuring non-expandable restrictions behave properly.
>
> Thanks for adding these.
>
> It's horrible to not have the kselftest harness for these, but as established,
> fork() doesn't work for nommu (!)
>
> A lot of these tests seem to relate to functionality I'm not really happy with
> in the rest of the series so let's see how things pan out with the series
> overall I guess!
(snip)
> > diff --git a/tools/testing/selftests/mm/nommu_mremap_test.c b/tools/testing/selftests/mm/nommu_mremap_test.c
> > new file mode 100644
> > index 000000000000..b1b8a4e64b55
> > --- /dev/null
> > +++ b/tools/testing/selftests/mm/nommu_mremap_test.c
> > @@ -0,0 +1,583 @@
(snip)
> > +
> > +static int get_shared_writable_file_expected_error(const char *path)
> > +{
> > + if (get_fs_type(path) == RAMFS_MAGIC)
> > + return EPERM; /* ramfs failed */
> > +
> > + return 0;
> > +}
> > +
> > +static int pre_conf_trim_page(void)
> > +{
> > + return set_nr_trim_pages("0\n");
> > +}
> > +
> > +static int post_conf_trim_page(int value)
> > +{
> > + char buf[32];
> > +
> > + if (snprintf(buf, sizeof(buf), "%d\n", value) < 0)
> > + return -EIO;
> > +
> > + return set_nr_trim_pages(buf);
> > +}
> > +
> > +struct mremap_case_t {
> > + const char *name;
> > + const char *pathname;
> > + int open_flags;
> > + int mmap_prot;
> > + int mmap_flags;
> > + int exp_err;
> > + int (*resolve_exp_err)(const char *path);
> > + unsigned int old_pages;
> > + unsigned int new_pages;
> > + int (*pre_hook)(void);
> > + int (*post_hook)(int value);
> > +};
> > +
> > +static struct mremap_case_t mremap_cases[] = {
> > + {
> > + .name = "anonymous shrink (r--)",
> > + .pathname = NULL,
> > + .open_flags = O_CREAT | O_RDWR | O_EXCL,
> > + .mmap_prot = PROT_READ,
> > + .mmap_flags = MAP_ANONYMOUS | MAP_PRIVATE,
> > + .exp_err = 0,
> > + .resolve_exp_err = 0,
> > + },
> > + {
> > + .name = "shared file shrink (r--)",
> > + .pathname = "/tmp/ksft.nommu-remap-XXXXXX",
> > + .open_flags = O_CREAT | O_RDWR | O_EXCL,
> > + .mmap_prot = PROT_READ,
> > + .mmap_flags = MAP_SHARED,
> > + .exp_err = 0,
> > +#ifdef CONFIG_NOMMU
> > + .resolve_exp_err = get_shared_writable_file_expected_error,
> > +#else
>
> Hmm aren't these all nommu tests anyway?
those tests are indeed for nommu but also compare with mmu systems.
actually I was trying to implement test behaviors which are described
in Documentation/admin-guide/mm/nommu-mmap.rst.
this particular case ("shared file shrink (r--)") is not described in
the doc, but test with a conditional error on nommu, and expects
success on mmu kernel, which is interesting (at least for nommu folks)
to validate future regressions.
I think now if I split into several series of this patchset, I would
drop this particular chunk which is needed for other series, and keep
only basic tests for nommu kernel which is described in the doc.
-- Hajime
prev parent reply other threads:[~2026-08-14 22:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260813063401.1786548-1-thehajime@gmail.com>
2026-08-13 6:33 ` [RFC PATCH 4/6] selftests: fix build errors on alpine linux Hajime Tazaki
2026-08-14 9:34 ` Pedro Falcato
2026-08-14 12:44 ` Hajime Tazaki
2026-08-14 12:39 ` Lorenzo Stoakes (ARM)
2026-08-14 22:29 ` Hajime Tazaki
2026-08-13 6:34 ` [RFC PATCH 5/6] selftests: run tests on nommu architecture Hajime Tazaki
2026-08-14 12:50 ` Lorenzo Stoakes (ARM)
2026-08-14 14:34 ` Mark Brown
2026-08-13 6:34 ` [RFC PATCH 6/6] selftests/mm: add nommu mmap and mremap behavior tests Hajime Tazaki
2026-08-14 13:28 ` Lorenzo Stoakes (ARM)
2026-08-14 22:35 ` Hajime Tazaki [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=m2wltspbyp.wl-thehajime@gmail.com \
--to=thehajime@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=daniel@thingy.jp \
--cc=david@kernel.org \
--cc=geert@linux-m68k.org \
--cc=liam@infradead.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-um@lists.infradead.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