Re: [PATCH] mm/mm_slot: make sure slot is the first element of its wrapper structure

[<xu.xin16@zte.com.cn>]

> On 14/09/25 12:33 pm, Lance Yang wrote:
> >
> >
> > On 2025/9/14 14:21, Dev Jain wrote:
> >>
> >> On 14/09/25 5:30 am, Wei Yang wrote:
> >>> When using mm_slot in ksm/khugepaged, there is code snip like:
> >>>
> >>>       slot = mm_slot_lookup(mm_slots_hash, mm);
> >>>       mm_slot = mm_slot_entry(slot, struct ksm_mm_slot, slot);
> >>>       if (mm_slot && ..) {
> >>>       }
> >>>
> >>> This is only valid when mm_slot is the first element of its wrapper
> >>> structure, otherwise a NULL slot would converted to a mm_slot with
> >>> negative value. And current code thinks it is valid and continue.
> >>
> >> Shouldn't you fix the code for the case when you can't find the slot
> >> in the hashtable, i.e slot == NULL? Like, if (!slot) return.
> >
> > Right. For khugepaged specifically, the slot == NULL case in
> > __khugepaged_exit() (only user of mm_slot_lookup) should probably
> > be treated as a kernel BUG for new.
> >
> > But I'm not sure if the same logic applies to KSM ;)
> 
> I haven't seen the KSM analogue, but restricting the position of an element
> 
> in a struct to make the code work should imply that the code is wrong in
> 
> the first place :)

The same to KSM. The slot passed into mm_slot_entry() could not be NULL. Even if NULL,

kernel would panic due to NULL dereference in the subsequent procedure, but it has never

happened yet. 

So the patch seems little significant for KSM.