Re: [PATCH 03/22] mm: introduce MMF_KERNEL flag and set it for init_mm

On 21/07/2026 17:04, David Hildenbrand (Arm) wrote:
> 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).

That was my rationale as well - anything that isn't a user mm is a
kernel mm, in the sense that it owns kernel-space page tables.

However if we reduce the scope of the flag as per Dave Hansen's
feedback, maybe MMF_KERNEL_PGTABLES is more appropriate. I think it's a
question of whether we want to keep this flag with a narrow scope
(strictly about page table handling), or possibly widen it later.

- Kevin