From: Hajime Tazaki <thehajime@gmail.com>
To: daniel@thingy.jp
Cc: ljs@kernel.org, akpm@linux-foundation.org, dhowells@redhat.com,
linux-kernel@vger.kernel.org, sashiko-bot@kernel.org
Subject: Re: [PATCH] ramfs: nommu: fix error rollback and reader races in ramfs_nommu_expand_for_mapping()
Date: Tue, 14 Jul 2026 02:26:56 +0200 [thread overview]
Message-ID: <m15x2ia01b.wl-thehajime@gmail.com> (raw)
In-Reply-To: <CAFr9PXmMD+uX1dXZYmSE8Ghh7ZXpukK1dQtEg9O7KPR_HpU6DA@mail.gmail.com>
On Tue, 14 Jul 2026 01:36:21 +0200,
Daniel Palmer wrote:
>
> > so I was wondering if it is still interesting to support the syscall
> > (memfd_createfd) on nommu even the fcntl always fails.
>
> I think these fcntls will also fail on MMU=y where the full tmpfs is
> not enabled for size reasons. I'm not sure if it's actually possible
> to detect if tmpfs is really tmpfs or not. (I have this exact issue
> with a test for nolibc).
thanks, I'll look into detail.
> memfd_createfd is still useful because it basically allows you to
> create anonymous temporary files that you can pass to another process
> and mmap() in both.
> I use this for doing DNS resolution in my nolibc system: A process
> that needs DNS resolution creates an memfd for the result and then
> forks the resolver which mmap()s the memfd, fills in the result and
> then exits. This avoids having the big resolver code in everything
> that needs it since I don't have any shared libraries :).
I understand, this might be a good test case with the actual use.
> BTW: Could you share a link to your LTP fork? I will add it to my m68k
> environment.
forgive me in advance :)
links are only the current working tree; it might be renamed/removed
in future.
here is a fork/branch of ltp:
https://github.com/thehajime/ltp/tree/fix-nommu
it is triggered from my UML branch with github actions (below),
https://github.com/thehajime/linux/blob/zpoline-nommu-v6.10/.github/workflows/ci.yml
using this dirty yaml file to build and execute part of testcases.
https://github.com/thehajime/linux/blob/zpoline-nommu-v6.10/.github/workflows/ci-docker-build.yml
-- Hajime
prev parent reply other threads:[~2026-07-14 0:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-13 11:57 [PATCH] ramfs: nommu: fix error rollback and reader races in ramfs_nommu_expand_for_mapping() Daniel Palmer
2026-07-13 19:49 ` Hajime Tazaki
2026-07-13 23:36 ` Daniel Palmer
2026-07-14 0:26 ` 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=m15x2ia01b.wl-thehajime@gmail.com \
--to=thehajime@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=daniel@thingy.jp \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=sashiko-bot@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 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.