summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorShengming Hu <hu.shengming@zte.com.cn>2026-07-06 21:39:09 +0800
committerVlastimil Babka (SUSE) <vbabka@kernel.org>2026-07-08 18:14:56 +0200
commitaf9ea231c0b4530edc389a3126a69e0699b7699d (patch)
tree53dd79e44fe4f018d5f794d9cfc93f0d1da90631 /tools/perf/scripts/python
parentdc59e4fea9d83f03bad6bddf3fa2e52491777482 (diff)
mm/slub: fix lost local objects when bulk remote free batch fills
In free_to_pcs_bulk(), when remote_objects[] fills to PCS_BATCH_MAX, the code jumps to flush_remote to free the batch. If all remote entries have already been compacted out of p[] via tail swaps while local objects remain, the flush_remote path returns early since `i < size` no longer holds. The leftover local objects are then neither cached in the sheaf nor returned to the slab freelist, causing a memory leak. For illustration: size = 64, local objects at p[0..31], remote objects at p[32..63] After scanning all remotes: i = 32, size = 32 p[0..31] local objects are dropped. Harry pointed out that, although the logic contains a real leak, it does not appear to be triggerable with the current in-tree users. To hit this path, at least PCS_BATCH_MAX objects, currently hardcoded to 32, need to be collected in remote_objects[]. Looking at current kmem_cache_free_bulk() users: * maple_node has sheaf_capacity = 32 * skbuff_head_cache has sheaf_capacity = 28 * panthor and msm drivers have sheaf_capacity = 4 The sheaf capacity is, at least for now, derived purely from the object size, with the user-requested capacity used as a minimum. Therefore, among the current users, only maple_node has a sheaf_capacity large enough to reach PCS_BATCH_MAX. However, for the bug to trigger in maple_node, all objects in the sheaf would have to be from remote nodes. In that case, there would be no local objects left to leak. So this issue was found by code review rather than from a runtime report, and it does not seem to be triggerable by current users. Still, the bug could become reachable with future users, a different sheaf capacity, or a change to PCS_BATCH_MAX. Fix the logic by freeing a full remote batch in place during the scan and then continuing to process the compacted array. This keeps all local objects on the normal fast path, while the tail path only handles any leftover partial remote batch. The redundant next_remote_batch jump label is removed as well. Fixes: 989b09b73978 ("slab: skip percpu sheaves for remote object freeing") Signed-off-by: Shengming Hu <hu.shengming@zte.com.cn> Link: https://patch.msgid.link/202607062139095043SOsLi6TIf403tcjPf8fm@zte.com.cn Cc: stable@vger.kernel.org Reviewed-by: Harry Yoo (Oracle) <harry@kernel.org> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions