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...] >>>