Re: [PATCH v5 19/25] arm64/mm: Wire up PTE_CONT for user mappings
From: David Hildenbrand <hidden>
Date: 2024-02-13 10:01:16
Also in:
linux-arm-kernel, linux-mm, lkml
From: David Hildenbrand <hidden>
Date: 2024-02-13 10:01:16
Also in:
linux-arm-kernel, linux-mm, lkml
On 12.02.24 21:38, Ryan Roberts wrote:
[...]quoted
quoted
quoted
quoted
+static inline bool mm_is_user(struct mm_struct *mm) +{ + /* + * Don't attempt to apply the contig bit to kernel mappings, because + * dynamically adding/removing the contig bit can cause page faults. + * These racing faults are ok for user space, since they get serialized + * on the PTL. But kernel mappings can't tolerate faults. + */ + return mm != &init_mm; +}We also have the efi_mm as a non-user mm, though I don't think we manipulate that while it is live, and I'm not sure if that needs any special handling.Well we never need this function in the hot (order-0 folio) path, so I think I could add a check for efi_mm here with performance implication. It's probably safest to explicitly exclude it? What do you think?Oops: This should have read "I think I could add a check for efi_mm here *without* performance implication"It turns out that efi_mm is only defined when CONFIG_EFI is enabled. I can do this: return mm != &init_mm && (!IS_ENABLED(CONFIG_EFI) || mm != &efi_mm);
Please use all the lines you need ;) if (IS_ENABLED(CONFIG_EFI) && unlikely(mm == &efi_mm)) return false; return mm != &init_mm;
Is that acceptable? This is my preference, but nothing else outside of efi references this symbol currently.
We could also mark MMs in some way to be special. return mm->is_user; Then it's easy to extend. -- Cheers, David / dhildenb