From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8B0BA3ACA46 for ; Fri, 10 Jul 2026 06:03:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783663437; cv=none; b=RR8Wqm8haeMXsQB5aUjn8oeYKH4woDTtdf9gn5Zya25eg4znFG3Nkoe6gCiJ+CkG8Ocfx3F1Zj505U9qQEBcTsKp87EHCG1Eu0KNXmsSbcPhPC2ug04WC2Q0HNh8H6pdkcu4VLNU1eZpqBF60bn9eGGLYFRpwiehLnBnlnsDJno= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783663437; c=relaxed/simple; bh=90djEPSf6UNInB415ZgADE1JWeFYtSzN8n4NoEH5Rbc=; h=From:Subject:Date:Message-Id:MIME-Version:Content-Type:To:Cc; b=hD0w21fC/I8hLhxEqO71tNVvbGQrrnDJUx/Fp8TC+dSxVhZ9boqts6oxeEob4ryETfbux438ftdum+N8CXTs6CPvVlpujsB8r2w1nOxmNGjVy+EKwsaW2DnLSN9WKqV4oquf9iZSsgONkyUrhroFJb4BXtrm6c/yp4NhDrdyFXM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lk39EIrc; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lk39EIrc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 084881F000E9; Fri, 10 Jul 2026 06:03:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783663436; bh=ULBMQmnv8LLLVlD5lvSVdvDm5rfD5U8h0VCK9hrKVpw=; h=From:Subject:Date:To:Cc; b=lk39EIrc1OLJ45PR4qGIue0wtirqeIp1tg9bOwnuuSR3Y7aiIkoBul9vNk6v+ZvzT v530bKhAE+F+V1wC83Qdgcri53Ee8ZpaevpMbtx9OMGYhMucdH55s5hmGgJN3BCi4p gtrImcaiDC3FfsH6Cxd2bEHf5APXZqTML+Uzg+CSBre+ROQCAJm8crl9SiXdIlk+a4 S4i8pHUVhN8mIx7CGtgZM7EVUQxYCD0rpdr0rAtsiOr0aioNTnakV/fXc151izR4ec mdnLM6dfbHte2gsRjqZembbvY2axhKMBOlIPg9M8bmSzEYyb0okNAa8IDecsrBZath WkvinjFjZu3lQ== From: "Harry Yoo (Oracle)" Subject: [PATCH slab/for-next-fixes v2 0/3] mm/slab: fix unbounded recursion in free path with memalloc profiling Date: Fri, 10 Jul 2026 15:03:31 +0900 Message-Id: <20260710-kmalloc-no-objext-v2-0-2709afb6a030@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIAAAAAAAC/32NwQ6CMBBEf4Xs2dVtCQU9+R+GA+ACldqalhAM6 b9b8e7xTd7MbBDYaw5wyTbwvOignU0gDxl0Y2MHRn1PDJKkopIkTs/GGNehdejaB68zSiXOnWB SVOWQei/PvV73zRsE07Sn3nm0X/WX10kadZidf++/i9jVPxeLQEKhSlEWRFWRV9eJvWVzdH6AO sb4AVmp2ObIAAAA X-Change-ID: 20260702-kmalloc-no-objext-2619c1e06083 To: Vlastimil Babka , Andrew Morton , Hao Li , Christoph Lameter , David Rientjes , Roman Gushchin , Suren Baghdasaryan , Hao Ge , Kees Cook , Pedro Falcato , Shakeel Butt , Danielle Constantino , "Liam R. Howlett" Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Harry Yoo (Oracle)" X-Mailer: b4 0.14.3 This is a follow-up fix after the recent discussion [1]. See patch 2 for the detailed description on the bug. Based on slab/for-next-fixes (72bb229f916) and will be soon available at git.kernel.org [2]. Instead preventing cycles by bumping up the allocation size of obj_exts arrays, it introduces a new kmalloc type called KMALLOC_NO_OBJ_EXT and disallow formation of cycles between kmalloc types when allocating obj_exts arrays. obj_exts arrays of normal kmalloc caches are served from KMALLOC_NO_OBJ_EXT caches (that don't have obj_exts), and all other obj_exts arrays are served from normal kmalloc caches. I tried to reuse SLAB_ALLOC_NO_RECURSE to make kmalloc_slab() select KMALLOC_NO_OBJ_EXT, but it was not great because it does not allow sheaves for those caches. So I introduced a new slab alloc flag SLAB_ALLOC_NO_OBJ_EXT. To avoid huge confusion, I had to decouple "disallowing sheaves" semantics from SLAB_NO_OBJ_EXT and introduced SLAB_NO_SHEAVES. While this cannot be directly backported to v6.18 and v6.12 due to lack of SLAB_ALLOC_* flags and kmalloc_flags(), I don't this will be particularily challenging to backport it. Instead of a new slab alloc flag, we can use __GFP_NO_OBJ_EXT to select KMALLOC_NO_OBJ_EXT as kmalloc caches don't have sheaves in v6.18 anyway. [1] https://lore.kernel.org/linux-mm/9a139365-28e6-4f1e-b35b-7f6091e9aa14@kernel.org [2] https://git.kernel.org/pub/scm/linux/kernel/git/harry/linux.git/log/?h=kmalloc-no-objext-v2r2 [ "v2r2" because after exposing v2r1 I adjusted some of Vlastimil's feedback and fixed a memory leak due to bootstrapping twice when kmalloc caches are aliased ] Signed-off-by: Harry Yoo (Oracle) --- Changes in v2: - Fix a memory leak when kmalloc caches are aliased (patch 1). This is included as part of this series as patch 3 makes it easier to trigger the leak. - Fix a warning in MEM_ALLOC_PROFILING_DEBUG by dropping mark_obj_codetag_empty() for obj_exts. Sashiko raised this and I reproduced it and confirmed that the warnings are gone. https://sashiko.dev/#/patchset/20260702-kmalloc-no-objext-v1-0-167175008538%40kernel.org - Added R-b from Vlastimil on patch 2, thanks! - Adjusted Vlastimil's feedback on RFC v1 - Link to v1: https://lore.kernel.org/r/20260702-kmalloc-no-objext-v1-0-167175008538@kernel.org --- Harry Yoo (Oracle) (3): mm/slab: fix a memory leak due to bootstrapping sheaves twice mm/slab: decouple SLAB_NO_SHEAVES from SLAB_NO_OBJ_EXT mm/slab: prevent unbounded recursion in free path with new kmalloc type include/linux/slab.h | 16 +++++++- mm/slab.h | 15 +++++-- mm/slab_common.c | 18 ++++++++- mm/slub.c | 109 +++++++++++++++++++++------------------------------ 4 files changed, 88 insertions(+), 70 deletions(-) --- base-commit: 72bb229f9161a1efcd5df32141b69fcc6ae81a13 change-id: 20260702-kmalloc-no-objext-2619c1e06083 Best regards, -- Harry Yoo (Oracle)