Re: [PATCH v3 03/26] mm: introduce AS_NO_DIRECT_MAP

[Takahiro Itazuri <itazur@amazon.com>]

Some of you on the KVM side already know this, but for those on the MM
side who may not, I am taking over the guest_memfd direct-map removal
series.  I have finally caught up with this thread, and I sincerely
apologize for joining so late; other commitments kept me from catching
up sooner.

On Fri, 7 Aug 2026 15:48:24 -0700, Yosry Ahmed <yosry@kernel.org> wrote:
> > I'm not ok punting on that, i.e. whatever we come up with needs to land alongside
> > AS_NO_DIRECT_MAP, or at least before guest_memfd tries to use AS_NO_DIRECT_MAP.
>
> Yup, I meant the latter.
>
> > The only way KVM can use AS_NO_DIRECT_MAP without GUP is with a massive list of
> > caveats and addendums on things the VMM and guest can't do.  I'm not ok merging
> > guest_memfd support for AS_NO_DIRECT_MAP with such a list.
>
> This series is not adding the support in guest_memfd, just adding the
> generic AS_NO_DIRECT_MAP and using it for secretmem. Followup work is
> needed to plumb it for guest_memfd anyway, and I am proposing that we
> also punt the GUP story to that (when we have an actual user).

My reading of the discussion is that the generic AS_NO_DIRECT_MAP support
can land with GUP rejecting such mappings, provided that a generic GUP-like
access mechanism is in place before guest_memfd starts using
AS_NO_DIRECT_MAP.

As far as I know, Brendan is no longer at Google.  I do not know whether
he plans to continue the ALLOC_UNMAPPED / mermap work, or whether someone
else at Google has taken it over.  If that work is not already underway,
I would like to respin the AS_NO_DIRECT_MAP introduction and secretmem
adoption as a standalone MM series, separate from ALLOC_UNMAPPED and
mermap.  The AS_NO_DIRECT_MAP changes originated in the guest_memfd
direct-map removal series, and splitting the MM and KVM parts was already
requested during review.

The proposed MM series would include:

  - the folio direct-map helpers;
  - the AS_NO_DIRECT_MAP flag and filemap lifecycle;
  - the current GUP and build-ID rejections, while keeping the mlock
    check specific to secretmem; and
  - the secretmem conversion.

I would leave ALLOC_UNMAPPED, freetypes, mermap, the allocator fast path,
and the KVM / guest_memfd integration out of that series.  This would not
change the requirement discussed by Sean and Yosry above: the GUP-like
access problem would still need to be resolved before enabling
AS_NO_DIRECT_MAP for guest_memfd.

Please let me know if this work is already being continued; if not, does
the standalone MM series described above sound reasonable?

Thanks,
Takahiro