On 7/16/26 11:33, Kevin Brodsky wrote:
> On 14/07/2026 17:04, Lorenzo Stoakes (ARM) wrote:
>> On Tue, Jul 14, 2026 at 07:47:43AM -0700, Dave Hansen wrote:
>>> Could we give this some nice comments explaining what a kernel mm is,
>>> please? Part of the problem with the init_mm checks is that they're
>>> magic and it's not always clear what's special about init_mm.
>
> Agreed, we need to define what this property means exactly, and your
> comments on patch 14 show that extending it to efi_mm isn't necessarily
> as benign as it appeared to me at first.
>
> My motivation really is about how page tables are handled (in particular
> whether ptlocks are used), so as you suggested on patch 19 maybe this
> flag should be narrower in scope, and the naming should reflect it.
> Possibly MMF_KERNEL_PGTABLES? That's at least one thing that should be
> true of all of init_mm, efi_mm and tboot_mm: their page tables use
> kernel permissions, not user, and should follow the same rules including
> not using ptlocks.
>
>>> Maybe start with this list?
>>>
>>> 1. There's only one of them.
>>> 2. All kernel threads share it. tsk->mm is the same for all kernel
>>> threads.
>>> 3. It holds the reference copy of the kernel page tables
>>> 4. Userspace can't be entered when it is the current mm
>>> 5. It has different TLB flushing rules than userspace mms
>>>
>>> I _think_ those are universal across all architectures.
>> Well point 1 isn't true of efimm or tboot_mm so we possibly need a better
>> name :)
>>
>> "Special" is overloaded too much already. I quite like "eternal" so:
>>
>> static inline bool mm_is_eternal(const struct mm_struct *mm)
>> {
>> return mm && mm_flags_test(MMF_ETERNAL, mm);
>> }
>
> Cheeky but why not! I do wonder whether this conveys the right idea
> though. The main point of this flag is that page tables are
> allocated/initialised/locked differently; in principle you could have a
> temporary non-user mm.
I mean, we talk about MMs that are not used for actual user space processes?
IOW, the following:
arch/x86/kernel/tboot.c:static struct mm_struct tboot_mm = {
drivers/firmware/efi/efi.c:struct mm_struct efi_mm = {
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-test.c:static struct mm_struct sva_mm
= {
mm/init-mm.c:struct mm_struct init_mm = {
So "user" vs. "kernel" is quite intuitive. Sure, there can be multiple
"kernel" ones, but each with a distinct purpose (IOW, we don't have multiple
init_mm MMs).
--
Cheers,
David
