On 2/16/25 06:08, Huacai Chen wrote: > On Sat, Feb 15, 2025 at 10:05 PM Harry (Hyeonggon) Yoo > <42.hyeyoo@xxxxxxxxx> wrote: >> >> >> You mean when SLAB_FREELIST_RANDOM enabled? >> Assuming that... > Yes. > >> >> > the CPU1's idle task stack from >> > the booting kernel may be the CPU2's idle task stack from the target >> > kernel, and CPU2's idle task stack from the booting kernel may be the >> > CPU1's idle task stack from the target kernel >> The freelist can have more objects than the number of cpus and then it's not just exchanging stacks between cpus but also with whatever else allocates from the same slab. >> What happens if it's not the case? > SLAB means "objects with the same type", right? So it is probably the kmalloc() is not objects of the same type, just size > case. Yes, there is a very very low possibility that not the case, > but... > > In theory x86_64 also has a low possibility that the idle task's stack > or other metadata be overwritten, then should we also disable random > kmalloc for x86_64? Does x86 really have such possibility? Can you explain in more detail? > On the other hand, if we really need to handle this theoretic > possibility about SLAB_FREELIST_RANDOM now, we can simply move > init_freelist_randomization() after all initcalls, too. I think a more robust approach would be to make sure any allocations critical for hibernation/resume are static? Are there really multiple CPU's idle task stacks involved? Aren't the critical paths single cpu only? I'd assume when multiple cpus might be running at that phase, all bets about determinism are off? So there could be a statically allocated stack for the single cpu? Note I don't know much about how hibernation works. But it seems fragile to rely on rather complex allocators (slab over page allocators) to give me exactly the same addresses accross boots, and hack around their randomization features to help with that, if there's an alternative to use static allocations for the critical pieces of the hibernation/resume code. > Huacai > >> >> > but idle task's stack >> > from the booting kernel won't be other things from the target kernel >> > (and won't be overwritten by switching kernel). >> >> What guarantees that it won't be overwritten? >> To me it seems to be a fragile assumption that could be broken. >> >> Am I missing something? >> >> -- >> Harry >
