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

Ackerley Tng <[email protected]>
Newsgroups gmane.linux.kernel,gmane.linux.kernel.mm
Message-ID <CAEvNRgHvbfiyLQ6za_DRmJcRBzNe2rg3Xf=wx0=4nMvkc=2neQ@mail.gmail.com>
"Brendan Jackman" <[email protected]> writes:

> Right, attempting this again now I've fixed my mail setup.
>
> I've no idea how that other "butt-dial" mail got sent, I was not able to
> sent mail _deliberately_ during that period but I guess somewhere in my
> setup I still had a copy of the password somewhere!
>
> On Fri Jul 31, 2026 at 8:28 PM BST, Yosry Ahmed wrote:
>>> > [..]
>
>>> >>  		return -EFAULT;
>>> >>
>>> >>  	if (write) {
>>> >> @@ -2731,7 +2730,7 @@ EXPORT_SYMBOL(get_user_pages_unlocked);
>>> >>   * This call assumes the caller has pinned the folio, that the lowest page table
>>> >>   * level still points to this folio, and that interrupts have been disabled.
>>> >>   *
>>> >> - * GUP-fast must reject all secretmem folios.
>>> >> + * GUP-fast must reject all folios without direct map entries (such as secretmem).
>>> >>   *
>>> >>   * Writing to pinned file-backed dirty tracked folios is inherently problematic
>>> >>   * (see comment describing the writable_file_mapping_allowed() function). We
>>> >> @@ -2769,7 +2768,7 @@ static bool gup_fast_folio_allowed(struct folio *folio, unsigned int flags)
>>> >>  	if (WARN_ON_ONCE(folio_test_slab(folio)))
>>> >>  		return false;
>>> >>
>>> >> -	/* hugetlb neither requires dirty-tracking nor can be secretmem. */
>>> >> +	/* hugetlb neither requires dirty-tracking nor can be without direct map. */
>>
>> Is this necessarily true? I know there were discussions/proposals about
>> using some of the hugetlb infrastructure for guest_memfd. I am not sure
>> if those folios would remain hugetlb folios though.
>>
>> Adding Ackerley here.
>
> I think Google might have a bunch of patches for this, afraid I know
> very little about it though.
>

We do have guest_memfd HugeTLB support (I'm gonna work on upstreaming!!)

When guest_memfd gets direct map removal support then at some point
guest_memfd HugeTLB is going to have to respect that. For now, I'd say
we should write this patch series assuming guest_memfd doesn't have
direct map removal support or HugeTLB pages.

>>> >>  	if (folio_test_hugetlb(folio))
>>> >>  		return true;
>>> >>
>>>
>>> [...snip...]
>>>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.