summaryrefslogtreecommitdiff
path: root/scripts/const_structs.checkpatch
diff options
context:
space:
mode:
authorVlastimil Babka (SUSE) <vbabka@kernel.org>2026-06-10 18:40:04 +0300
committerVlastimil Babka (SUSE) <vbabka@kernel.org>2026-06-15 11:50:00 +0300
commitf09b59ae4414b0dc0929cf04cd8243157e0feab6 (patch)
treeeb7a41c466fc3e98b57ae3853022a0377a5de54f /scripts/const_structs.checkpatch
parentdfdfd58cce1c3f5df8733b64595448996c08e424 (diff)
downloadlinux-f09b59ae4414b0dc0929cf04cd8243157e0feab6.tar.xz
mm/slab: do not init any kfence objects on allocation
When init (zeroing) on allocation is requested, for kmalloc() we generally have to zero the full object size even if a smaller size is requested, in order to provide krealloc()'s __GFP_ZERO guarantees. When we end up allocating a kfence object, kfence performs the zeroing on its own because it has its own redzone beyond the requested size. Thus slab_post_alloc_hook() has an 'init' parameter which has to be evaluated in all callers (via slab_want_init_on_alloc()) and should be false for kfence allocations. For kfence allocations in slab_alloc_node() this is achieved by subtly skipping over the slab_want_init_on_alloc() call. Other callers (i.e. kmem_cache_alloc_bulk_noprof()) however evaluate it unconditionally even if they do end up with a kfence allocation. This is only subtly not a problem, as those are not kmalloc allocations and thus the "requested size" equals s->object_size and thus it cannot interfere with kfence's redzone. There's just a unnecessary double zeroing (in both kfence and slab_post_alloc_hook()), but it's all very fragile and contradicts the comment in kfence_guarded_alloc(). Remove this subtlety and simplify the code by eliminating the init parameter from slab_post_alloc_hook() and make it call slab_want_init_on_alloc() itself. Instead add a is_kfence_address() check before performing the memset, which will start doing the right thing for all callers of slab_post_alloc_hook(). This potentially adds overhead of the is_kfence_address() check to allocation hotpath, but that one is designed to be as small as possible, and it's only evaluated if zeroing is about to happen. This means (aside from init_on_alloc hardening) only for __GFP_ZERO allocations, and the zeroing itself comes with an overhead likely larger than the added check. While at it, refactor the handling of evaluating when KASAN does the init instead of SLUB, with no intended functional changes. A non-functional change is that we don't pass kasan_init as true to kasan_slab_alloc() if kasan has no integrated init, but then the value is ignored anyway, so it's theoretically more correct. Thanks to Harry Yoo for the initial refactoring attempt, and for updated comments that are used here. Link: https://patch.msgid.link/20260610-slab_alloc_flags-v2-2-7190909db118@kernel.org Reviewed-by: Harry Yoo (Oracle) <harry@kernel.org> Reviewed-by: Suren Baghdasaryan <surenb@google.com> Reviewed-by: Hao Li <hao.li@linux.dev> Reviewed-by: Marco Elver <elver@google.com> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
Diffstat (limited to 'scripts/const_structs.checkpatch')
0 files changed, 0 insertions, 0 deletions