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

On 11/08/2026 15:25, David Laight wrote:
> On Mon, 3 Aug 2026 15:59:35 +0200
> "Christophe Leroy (CS GROUP)" <[email protected]> wrote:
>
>> Le 14/07/2026 à 16:03, Kevin Brodsky a écrit :
>>> mm code often needs to know whether some mm represents a kernel or
>>> user address space. This is currently done by comparing the mm
>>> pointer with &init_mm; besides not being particularly elegant, this
>>> ignores the fact that other mm's (e.g. efi_mm) may also represent
>>> parts of the kernel address space.
>>>
>>> Introduce a new mm flag MMF_KERNEL and set it for init_mm.
>>> Subsequent patches will use this flag to replace comparisons with
>>> &init_mm. No functional change is introduced for now.  
>> Did you consider performance impact ? This test is usually done in quite 
>> critical memory handling functions.
>>
>> init_mm is known at link time. Before your patch 08/22 there is just a 
>> comparison of mm (r3) with a constant (loaded in r10):
>>
>> c0014048 <assert_pte_locked>:
>> c0014048:	3d 40 c1 09 	lis     r10,-16119
>> c001404c:	39 4a 03 98 	addi    r10,r10,920
>> c0014050:	7c 03 50 00 	cmpw    r3,r10
>> c0014054:	4d 82 00 20 	beqlr
>> ...
>>
>> After patch 08/22 we have, it first checks that mm is not 0, then it 
>> loads the word located at mm+528 then AND it with 0x1. This load might 
>> be costly.
>>
>> c0014048 <assert_pte_locked>:
>> c0014048:	2c 03 00 00 	cmpwi   r3,0
>> c001404c:	7c 85 23 78 	mr      r5,r4
>> c0014050:	41 82 00 10 	beq     c0014060 <assert_pte_locked+0x18>
>> c0014054:	81 23 02 10 	lwz     r9,528(r3)
>> c0014058:	71 29 00 01 	andi.   r9,r9,1
>> c001405c:	4c 82 00 20 	bnelr
>> ...
> Thought...
> Could the check be replaced by one that checks for kernel static data?
> That would require that other mm that represent part of the kernel
> address space be static (and probably not in modules).
> ISTR there is an address range check that can be used - and might be
> cheaper than the explicit test for init_mm on many 64bit archs.

That is actually an interesting idea. Finding those "kernel mms" boils
down to looking for global mm_struct, so checking if mm points to global
data would achieve essentially the same thing without a flag (and likely
faster). I'm not sure we want to bake in the assumption that "kernel mm"
is equivalent to "mm is global" though.

- Kevin