From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0BC64C83F1B for ; Thu, 17 Jul 2025 03:32:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9A7B26B009C; Wed, 16 Jul 2025 23:32:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 957D46B009D; Wed, 16 Jul 2025 23:32:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 846676B009F; Wed, 16 Jul 2025 23:32:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 710316B009C for ; Wed, 16 Jul 2025 23:32:22 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id EAB6159D06 for ; Thu, 17 Jul 2025 03:32:21 +0000 (UTC) X-FDA: 83672333682.06.519C8AB Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by imf10.hostedemail.com (Postfix) with ESMTP id 093D2C0006 for ; Thu, 17 Jul 2025 03:32:19 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LKE5B5An; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf10.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752723140; a=rsa-sha256; cv=none; b=EXVcCjhC4OvTSAGmkxaiyb8wnRoKS+zfR0jkzYveXx3juVrGfm0dObJYwUffd+Fylm0Le1 8uprHL+wun6jbhUTS/md8dvx/whraHZFqAzDYHaOhLICCFDcZYSgOs0PQoBBA9+rTy01bX GV6EWFkmaQAgc6FcqnDXNeCfQ1VPbRI= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LKE5B5An; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf10.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752723140; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ALXWQ2fb8wYyWYYm6SUMuBZcHfhUAJGMpunbcmlC6NE=; b=o/g6kfVHGyJ6kz/Prbc9whVPpH0RyRcuiTpssq1qFzxFHAtO3ndYDWImIG9uwXbXSQfE3L Hz1WRGAENcLb75lhzqBonlZTbyd9dixjvOIpOJfjGbBv5PzJNZAkscDcABw1sMDY8B+Zf5 wVxQZl72LUgxsXRB2nJW/j8QOg759OA= Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-455b00283a5so2669205e9.0 for ; Wed, 16 Jul 2025 20:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752723138; x=1753327938; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ALXWQ2fb8wYyWYYm6SUMuBZcHfhUAJGMpunbcmlC6NE=; b=LKE5B5Anm7WsmIljNi7BIxUTjWza4DmemkX7cmkTZ/E6Ft5gJPdS4VtqrK7wV4wJt9 8ooTXIv/+1y0dqEtNqLI/AsLlaOUW1DUh9hpxptFlGW4A4t/r48TzwHOgrIeJBzJbu7v II4RotbY/1Q3dM0dVsIlUtEkIHWt62DTQjvoss7dnnyqfeF0S7wT30QN4JEyIN/0AXZm 0TUKvnpcOyyX+bjQpHevba3TNTN0ibBP61Sj1v7633Ccs2M3OJHCvxKiPzVuMhPdE1Jw V6Ix8Pj66OiELTnryVONarab4P7FArJYpCPmd28bNfzKl+Z+OzDqg+1VxdscwkVAighH VnHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752723138; x=1753327938; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ALXWQ2fb8wYyWYYm6SUMuBZcHfhUAJGMpunbcmlC6NE=; b=GU7rkxMmw6Ml+HZtCJAS2/z70YHaXgj41/XgyclqGsdtTaKc70aiUEKqw54F1+5Muv V6nNRox9U5wRVrV/toqt3A3GEKWNEC6AggyWO5pYJX4hiFYjiDLPznVHPLn1lq7deEIo kOwzqaoTK8YLlewJ3lhLthv7nFRfRgpxImFFapwyBA/CWM12HoZRj5zOsOJhyHeXgelE oRlpD0jY5DsyzpbZI5JXYIVq2XKymTc6z/mg8QhKMUOSji6HO0I1fgwv17nZs2C9s+jV AOC6+W54SIFm5mrvm9AGnTlmYOaVfFoFtzv4KWfEoTBUAOkplbr82VVXudhjM7PwaUD6 Ldog== X-Forwarded-Encrypted: i=1; AJvYcCUDHmpVaWANkkRz4cu4t6YQM2h4pLOum/XZnwOoFl3WJ4XGnuqaefVtzYKtReucbaMtR9FxG9CuLA==@kvack.org X-Gm-Message-State: AOJu0YwD0EsykoMUii37q8XdL+W+ZH2XhUrCeXQJ/7zCCO0Mh+IsW+pA v0HTQK1qx3+QX9aQMODNR8rlOLaJp7QF9UgDOo9+l9bqMPYsLsqc1MtlKWFeZ2FBT2QOCcS1Nuh datJJVfzxl4tagzNuCNueiX+ovWRbeSk= X-Gm-Gg: ASbGncts3nMFESedDu0upJzP2CZHKkIlEs5GROdfBYWzAn7ux7NAel2semmYTWpDYhX xPGLpybL2mVNDkBup6unY0iamHkJQqEFyDUNd7M4UdfanAmY3PNAZAt3xafzf6sYG/3g2YFx0ed qOEWcCfXAoAbH9vOy4ru8bI/TO4gM7Npi7EZ+76LSI09uha1lExl7o9yL0hLAxQBEU20YDkWnBQ t6YBpv+2EfMXRp91uiPtgYH+8woPeYjEAuB X-Google-Smtp-Source: AGHT+IHHbwzegNRrMGleXtzaCJc5bmREIP4rsBChMliIwYO0/KXfSZvif+U/kAjHKVH66r3+hL/jJAmkkVvV1p0Y3xA= X-Received: by 2002:a05:600c:19d4:b0:456:237b:5e4e with SMTP id 5b1f17b1804b1-4562e2aa1eamr44363395e9.32.1752723138177; Wed, 16 Jul 2025 20:32:18 -0700 (PDT) MIME-Version: 1.0 References: <20250716022950.69330-1-alexei.starovoitov@gmail.com> <20250716022950.69330-7-alexei.starovoitov@gmail.com> <7173c09b-99fa-4e16-a764-b9ddfa7909ce@suse.cz> In-Reply-To: <7173c09b-99fa-4e16-a764-b9ddfa7909ce@suse.cz> From: Alexei Starovoitov Date: Wed, 16 Jul 2025 20:32:06 -0700 X-Gm-Features: Ac12FXy1n3F0bXBVzhjZco6DV9ntN-DghynUZhzi6NebtapC1Isi__SnkU5TEkg Message-ID: Subject: Re: [PATCH v3 6/6] slab: Make slub local_trylock_t more precise for LOCKDEP To: Vlastimil Babka Cc: bpf , linux-mm , Harry Yoo , Shakeel Butt , Michal Hocko , Sebastian Sewior , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Andrew Morton , Peter Zijlstra , Steven Rostedt , Johannes Weiner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 093D2C0006 X-Stat-Signature: cmm8br3hd35zd38r1dawx6oyoq4us8yu X-HE-Tag: 1752723139-747852 X-HE-Meta: U2FsdGVkX19KfMBNDdn9riwl6+crqRFhug2tfhz1eU4di6ZsJWkH1849pYT4caHev+m+uQSWgdfOSljUyVKAS6hBDO7GwabclBMQqW0VXKLEcU0+n72kmbJau1U+rq/di4+QYPR28IkD6c/Ube86kbkyL/f1WBTGGukcAkTLH46J27zhV098YZroONpKmWx2GLVRNyeqpd/n3UWtladURU6EoVvT1q2QuotuJs/im3RtA0sY7aFTc/i8dJ/idm0iTTTIudEie2yBKYm32+cRiPDlrJI2RprQhGAl1KjZCbIaGrWxUKBoBJrpEopDqASR+SNbThjBtskQ6bj6xnpQZfo9uoczooBuWE0+k+vWRxTDexWPhvDKhPBNx3zYB9HXvMfmcsqOwIILcGtWXOpK3krfiWYc6oPZgAfb88bx8YCXWB3jYVYskbzLH57CYm7bMrv0WwKWd6MPwZXwtRIvwG/tiuqBVUTr25XwR5c04xWdfgworUHuKw+wZlc4759RjrKfpCKp2yi1inoepP6Rcn2uHRce6jc7YaH3MOGOf6WpXGKdPRsWzlikkRlIu10OFnFHqlxhXF0g98amLdrZzBpPpw6JMe1925hGPlXvhzUX34qsnOrKe93m6FmupKJwymp9qMGlfylOYD+Ks/FuOZRaA1gzNmAV6thie8uQdOS5BBS2sCu5kMJIUil5HC2gAyXVNZaflHAfMcmWLm1YQu2wZbb/i8Bh87ItAapTxkeXTgd10mf9zL0UC6Vggbf1gsoz7r27que7p3rOf7JfzEYXHqQLpkt+UllB9SA/TQni1r3fZ+t3SPxomvCwMIkgE07EM1bdmbrRncslWy1UehtOn6S3eXWiIz3SGm5g2069jTaYYk+1UKUaNqEqKOReuru4rJZfFM5T8DEH8QRlR8DtGutapPY6WbZZ7h3HLS7e7jTER0hI20GVcSHwXFse7s1rk2bl4fvn8Ai06tx QuOQjKlj 8F8ib+Y/M6lEIyefRSu4U+D5r+LPoLYZLjTg9qXLxbMckYPsFNkO6aUMZ2GOt1D6q5ffLUigNZ/hKZiBe2xqy65ungMyqEvYYRlzjpONIa2g3DnnhvdfdAgWtVunLaDiDMjZVswJFp8uQvCDAmzoEZJs2auvzmBrzmqqj0BcKnk3+anXp5459oNRegrTRIvU9GuWdDiJ3FzjgKxVRhjXfMWeC4IwnU8geAlvn2YkZdZ7FFrxjuj+4jvoS/lB/sNw8ax8H3agxnfEYgSbLQdy0RTv8ZXTzmx4CRKjIVJVVQN8dSyZO3MIMvnwlTXJS/emoA9pbu60+iXc2JJcvHdwRabMV0xiP//v18P/ksxJ9I6uVs8uep19wlRZsrBcITWxqxqnINqQuPMVvsYsTN6uj5MJDa5p3/00JC79q X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Jul 16, 2025 at 6:35=E2=80=AFAM Vlastimil Babka wr= ote: > > On 7/16/25 04:29, Alexei Starovoitov wrote: > > From: Alexei Starovoitov > > > > Since kmalloc_nolock() can be called from any context > > the ___slab_alloc() can acquire local_trylock_t (which is rt_spin_lock > > in PREEMPT_RT) and attempt to acquire a different local_trylock_t > > while in the same task context. > > > > The calling sequence might look like: > > kmalloc() -> tracepoint -> bpf -> kmalloc_nolock() > > > > or more precisely: > > __lock_acquire+0x12ad/0x2590 > > lock_acquire+0x133/0x2d0 > > rt_spin_lock+0x6f/0x250 > > ___slab_alloc+0xb7/0xec0 > > kmalloc_nolock_noprof+0x15a/0x430 > > my_debug_callback+0x20e/0x390 [testmod] > > ___slab_alloc+0x256/0xec0 > > __kmalloc_cache_noprof+0xd6/0x3b0 > > > > Make LOCKDEP understand that local_trylock_t-s protect > > different kmem_caches. In order to do that add lock_class_key > > for each kmem_cache and use that key in local_trylock_t. > > > > This stack trace is possible on both PREEMPT_RT and !PREEMPT_RT, > > but teach lockdep about it only for PREEMP_RT, since > > in !PREEMPT_RT the code is using local_trylock_irqsave() only. > > > > Signed-off-by: Alexei Starovoitov > > Should we switch the order of patches 5 and 6 or is it sufficient there a= re > no callers of kmalloc_nolock() yet? I can switch the order. I don't think it makes much difference. > > --- > > mm/slab.h | 1 + > > mm/slub.c | 17 +++++++++++++++++ > > 2 files changed, 18 insertions(+) > > > > diff --git a/mm/slab.h b/mm/slab.h > > index 65f4616b41de..165737accb20 100644 > > --- a/mm/slab.h > > +++ b/mm/slab.h > > @@ -262,6 +262,7 @@ struct kmem_cache_order_objects { > > struct kmem_cache { > > #ifndef CONFIG_SLUB_TINY > > struct kmem_cache_cpu __percpu *cpu_slab; > > + struct lock_class_key lock_key; > > I see " * The class key takes no space if lockdep is disabled:", ok good. yes. I was considering guarding it with #ifdef CONFIG_PREEMPT_RT but then all accesses to ->lock_key would need to be wrapped with #ifdef as well. So init_kmem_cache_cpus() will have three #ifdef-s instead of one. Hence the above lock_key; is unconditional, though it's a bit odd that it's completely unused on !RT (only the compiler touches it). > > #endif > > /* Used for retrieving partial slabs, etc. */ > > slab_flags_t flags; > > diff --git a/mm/slub.c b/mm/slub.c > > index c92703d367d7..526296778247 100644 > > --- a/mm/slub.c > > +++ b/mm/slub.c > > @@ -3089,12 +3089,26 @@ static inline void note_cmpxchg_failure(const c= har *n, > > > > static void init_kmem_cache_cpus(struct kmem_cache *s) > > { > > +#ifdef CONFIG_PREEMPT_RT > > + /* Register lockdep key for non-boot kmem caches */ > > + bool finegrain_lockdep =3D !init_section_contains(s, 1); > > I guess it's to avoid the "if (WARN_ON_ONCE(static_obj(key)))" > if it means the two bootstrap caches get a different class just by being > static, then I guess it works. Yes. Not pretty. The alternative is to pass a flag through a bunch of functions all the way from kmem_cache_init. Another alternative is to bool finegrain_lockdep =3D s !=3D boot_kmem_cache_node && s !=3D boot_kmem_= cache. Both are imo uglier. init_section_contains() is more precise and matches static_obj(). Checking for SLAB_NO_OBJ_EXT isn't an option. Since it's conditional.