Re: [PATCH 2/2] mm/memfd: handle GUP references reliably when write-sealing

["David Rheinsberg" <david@readahead.eu>]

Hi David

On Tue, Nov 3, 2026, at 7:31 PM, David Hildenbrand (Arm) wrote:
> We made a big mistake when introducing write-sealing: we should have
> disallowed *any* file mappings while we are write-sealing. Write-sealing is
> usually done by a producer that wants to hand-off some data to a consumer.
> Having the producer have a read-only mapping (private or read-only shared)
> of the memfd while sealing is rather odd: it couldn't have been used to
> fill the memfd in the first place.
>
> Most identified public users don't do anything like that: they either never
> map the memfd before write-sealing (using write() instead), or munmap()
> before write-sealing:
>
>  - systemd's journal writes, fwupd, Flatpak, runc, crun and
>    containers/storage write to the memfd without mmap'ing it, before
>    sealing it [1,2,3,4,5,6]. The FD consumer will not access the memfd
>    before sealing.
>
>  - dbus-broker, Mutter, Chromium's Android linker, KWin, Weston and glycin
>    map the memfd file, but unmap it before sealing [7,8,9,10,11,12].
>    glycin retries sealing while waiting for the loader to unmap.
>
>  - go-memfd exposes a shared writable mapping before F_SEAL_WRITE and a
>    private read-only mapping afterwards. Its API explicitly requires
>    unmapping the writable mapping before sealing [13].

When I wrote memfd-sealing, we had this use-case where an application writes a buffer and then shares it both with in-process and out-of-process tasks. Only if out-of-process tasks are actually involved, the buffer is sealed. Otherwise, it is kept unsealed and can be recycled. Hand-off to other processes was optional, rare and asynchronous, so sealing could happen at any time. Yet, we wanted to keep the buffers mapped to avoid costly TLB flushes. Mappings were readonly, but writes were done through syscalls.

We still do this, but I don't think any of the open-source users picked this up. I did not follow the folio changes, so I am quite unsure whether the implementation was racy from the beginning, or whether new infrastructure introduced the races.

Can you elaborate why folio ref-counts are unreliable / unstable?

Thanks
David