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 57A26C83F2D for ; Tue, 15 Jul 2025 21:00:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ED8CA6B0093; Tue, 15 Jul 2025 17:00:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EB04F6B0095; Tue, 15 Jul 2025 17:00:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D9F4C6B0096; Tue, 15 Jul 2025 17:00:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C99006B0093 for ; Tue, 15 Jul 2025 17:00:15 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 990121401BD for ; Tue, 15 Jul 2025 21:00:15 +0000 (UTC) X-FDA: 83667716790.11.0E19090 Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) by imf11.hostedemail.com (Postfix) with ESMTP id AB2B340012 for ; Tue, 15 Jul 2025 21:00:13 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=FsnszXnk; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.216.43 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752613213; a=rsa-sha256; cv=none; b=t400YV1JBH9BE492j2d9OsKkZj6txvuCGP6wMNe26H1CXcjvidVuwguJOlZYm9idq1Jtc3 W5oGkFFLz5UI9/DEw8zYox0tSWKvicr1yOHOHKZsuTi4e4EKrmBd6nSrNSG93HU/aJiR/W KpYBw+5bF+Dk4dgX7MvCWHCsB9cy8uE= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=FsnszXnk; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.216.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=1752613213; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xqbmHHNSEa4JpvA3O2cZtNvMFvd8/F8HQFJvzgbhv/Q=; b=FnXQs7BUIhjIszNw6ipib+5/0DISXkQ/EgfamibW8iuKMn/x+hRrPDYmzPFL2tZNwhQc4K PmN+Jaj5bZtAYV/iMQmwsJb8vC9gmeAASODudOrEo+9R6dwzuc7WXG+0M83RzdMU+Gofvx 1LX2873CdSqSRKhIyBmrd+YCIm/I2SU= Received: by mail-pj1-f43.google.com with SMTP id 98e67ed59e1d1-3137c20213cso5668920a91.3 for ; Tue, 15 Jul 2025 14:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752613212; x=1753218012; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=xqbmHHNSEa4JpvA3O2cZtNvMFvd8/F8HQFJvzgbhv/Q=; b=FsnszXnkodlC4rEbLkz2YJmVws1hWWkWdC0aVBIaeK36kWyZFWADf4z/5033MaFiTF LXGZkNBSq0rVDH/QbUWl1gFHRPqN1RmX7zlhLTWGLn/RHH1+G8bUc9uz9CHUwR+hlwYy MfknRG5UWlLMdGI2UEyoG6fJVOOjt+bZwGl3bmu/CwEL+pALGWQGLwW3HTa/e+7ZIn3G z918EBDz3B+Frx6+ftKfw3thQHYY3LyFFZngX51A6ileI8Eg8ZeO1qBRLANvSghU/Uwn V1gfGm/YCU/2i56CElT/dvFkppayWNdVaCTrwT2o8cCnuFyCW5oV8n+9tkS385pPwvTC 1+qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752613212; x=1753218012; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=xqbmHHNSEa4JpvA3O2cZtNvMFvd8/F8HQFJvzgbhv/Q=; b=hUfW2qgk67EFgo1c28d5yQVojYEMa7uRqbpKX9bkYHcel666k35FxSaAnSEyb6Xjyj 7b7VMlDdLDaU+QdAN8tWUDe6eZvSm5hel0rQEPVTwdwr3IBYWbtY7RjFcomR/IGJTpLK 79l4lPCij/VSiA3uQbpGTMr7N6V3sKw6nszkbEJ1QfbWxV1lA5dnxislo7lDEybcuM4F hXsQ9V2LrMBcania8LQP7f5TMqouoeGERi7FNUAaBbXXUH8XiApjK0joiqbt9S40BCX/ btyGCYqFTJEaBo/wxrsfC6qbhoRlN/EvfoPULfNxwzJAbUvOLrAh+IEOgadF0d21M53y 2TKQ== X-Forwarded-Encrypted: i=1; AJvYcCXqrZvVGUmZtOw4fJIgfejYWs3dcacubqK0FC4BY4L/h9RiYV1ex5AU5iGF6UvS48UU1KphUR7hnA==@kvack.org X-Gm-Message-State: AOJu0YzrW2T+eF3AS3Uo67a8AcG4sgsCGHOlGFwVaMlqfm5/em7U9rNs dZUqbpUxbQzATwCTFQk1DEIP+w3i6WbtXXu8cWp0kbFTRl3W6f99ai/l X-Gm-Gg: ASbGncvBi+xskzqcYfV/6g36YCE/CD6snvZ4gXx4UNknMLmqxK+KIDpkyy3DeMOt0mx OgutTDN3+6FSxpATjMAzDXoDtpFPEvjyWVAJviqry2mAmxdQFAdJWTpoD4kCte/uPKmMwIyN8EP ZDqwLkqnAYKkyN9Pf/BK1JwImgr6WgBwRZwZ0J9rCLvs337K7C1anoGrQYovUw2jTTZ+rQvtJwJ p3/nAhTdj9txgq27aviCob3i8sdlsPaowYythkKOUJOuIgd6VzO059V3DV5eShbwBkHyrINzbfc dlTs6xczdKtaLj31nzdfdAE71WshwmTQN0pEiQOdirqaXAGMy5FdC7UGsZwIGBcXD3XPpuQg7NM un0nD8nXw1NjN9OaACN41AsMWdjg7PQc= X-Google-Smtp-Source: AGHT+IFQ9fKQ1sqqST03sgxe97fgQIm400AotSUeIJgcrQWBKs4Dyb5+kWPd8crbeHNMNaVSrKe1Yw== X-Received: by 2002:a17:90b:2252:b0:312:1508:fb4e with SMTP id 98e67ed59e1d1-31c9f45e1bamr150315a91.17.1752613212067; Tue, 15 Jul 2025 14:00:12 -0700 (PDT) Received: from ast-mac ([2620:10d:c090:500::6:249f]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-b3bbe6bd903sm12587927a12.49.2025.07.15.14.00.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Jul 2025 14:00:11 -0700 (PDT) Date: Tue, 15 Jul 2025 14:00:05 -0700 From: Alexei Starovoitov To: Vlastimil Babka Cc: Sebastian Andrzej Siewior , bpf , linux-mm , Harry Yoo , Shakeel Butt , Michal Hocko , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Andrew Morton , Peter Zijlstra , Steven Rostedt , Johannes Weiner Subject: Re: [PATCH v2 3/6] locking/local_lock: Introduce local_lock_lockdep_start/end() Message-ID: References: <1adbee35-6131-49de-835b-2c93aacfdd1e@suse.cz> <20250711151730.rz_TY1Qq@linutronix.de> <20250714110639.uOaKJEfL@linutronix.de> <6835614d-c316-4ecf-ae2b-52687a66ae7c@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: AB2B340012 X-Stat-Signature: ugitzcopsdrp7wphzcexo97cmwuffwdw X-HE-Tag: 1752613213-860286 X-HE-Meta: U2FsdGVkX18w5kpOUhSiI3zHXUzlO7aFMxkDLr2ztZM/ukRcJtaODWyiHf1livKzH+RdsHjZdm6cRaTAwVKOXygtfUJU6uCFqHZ0gsSMM0ejY3iPapLMNAUp7NoKCuHqfHBwC3NIxCGDOxnEIYl9LtsN2TJwXgeyJpCvLx9ccU6a0Qr1aDbJkHm5baR17NQ0+t05YygFIZF+9O/9Jak6i4oYsDPeqLsKmcs1GRC2/LPMKcAEvfUGnrxPWwp2lw80QVgBayEH4isyueQht16ilCMoxWKwdGcCtxgNJDd+ixhXmIG9M3GmMURHaLGDAME9dUZNeTYE++BDQ46u8mag5O+Uclp0HDy1rgYXFuh7rJbi/XnZgkJyebRhtt1pQkbb9EETIzEszmSQJESqWiL/WsJUz/WPycjvHO3MEIOBuN1waJR2nHd1xXpJYDJY5nMKjxiVbcbCyYN1DfPsbgx6knQoX/QN1YOusaMA2rgzkHAk/lgHUVIJdmXpaWdhfzRyLENlQqL0fVR+q3XoTrFKNKiRQJWyDBlQC0g47NRd1vXWC2h4eCpT2PbTELzaxyMeHYrp+cG5rhjlOUtw1V1EeRMrB4/BQM63SIVlrSnaucQu6Qq5A0PrIfZjH/2fKAryRFUKkEL0cahKuUEmUaoR5I9EBRTK4ekbZCuIUzyKt1bPtrLsGPdPxgt1oP+YYRhcsDEEbFxpXl1cN1CqHvbZ89Hui5o0FXmdx7BpDSQ7AEUT3roK9fJin0WFPBmMSSpeJkQhH3EYAm2aAIN374Ra8sWI5IpDdGjZluccjsprhBAxNO1aCEN/ZyCM0ozRpGPz9EwIdsVN47YskpXkqjfG1Rq+UYv9cfXuduEllyAqbOc0Wql0kZGvYjVrmxvoRXEvmpFH8l5PFoOjG/XqFCxCgyiZYYGOvlDRABdUo///LTHbvP0PD2L0Aowx97ZGwA9mstM5kuzZBd7nxuO5JQJ W+F70Hx/ konWjvRhVPNG0DZ1h0rhaabOSrz+Oo3jTQWoYX1pNrGYRxA4vCzf9nIflxe2it/iiAvOzDc0dm+jHNnTul9NIPIlOxDCZ10C+xGeh0wJjNaUrXHs/LAcjaDiAoXH8HZD2FEz8qkkyZcvSRBD3iT/F8uVegJMuJ3oyQYEXs/0WO17VaDtTp3R0FrUJgOiP+DDe/fYATHDMP7EeUWd5K2LDDxd3Cu8Oh3iEBKOZgKjk8EfNIVjO1+E38bx9A+hBl2hq/m4n8VQsCUfyRwMnSN0km1gP3iNkrgTGcnkrXVuMqlIpoODIn6VdANCvAILrSDQdWDzmORjZiaDAJ9G1Ubd/9v41Mcn01jLhGFbjaKyH1iSRoHj722qfYizdSELeJeYVQ4s873L7xZNhNVbIAGcPwyPZVDylL/gO0e26dV1HK/AwCRo7O9j03TQXbgraIoMJkEC7j8Mno2CJpDR+W8tnrlYFDAUEIgXAMcI1Rrd/PyCq3gq2/YUmVfXhjuFqXvz3rIXJsbEI5QMfBegKjKVLmKUcDNyl8agQpR/7IZyUE5yK39N/O5hBCVzjeG8wCC13UxJ5 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 Tue, Jul 15, 2025 at 07:48:39PM +0200, Vlastimil Babka wrote: > On 7/15/25 19:29, Alexei Starovoitov wrote: > > On Tue, Jul 15, 2025 at 08:56:21AM +0200, Vlastimil Babka wrote: > >> > the addresses of the locks are different and they're different > >> > kmalloc buckets, but lockdep cannot understand this without > >> > explicit local_lock_lockdep_start(). > >> > The same thing I'm trying to explain in the commit log. > >> > >> Thanks for the explanation and sorry for being so dense. > >> Maybe lockdep's lock classes can be used here somehow instead of having to > >> teach lockdep completely new tricks, but I don't know enough about those to > >> know for sure. > > > > I tried that with a separate lock_key for each local_trylock_t > > and it's sort-of kinda works for 16 cpus, but doesn't scale > > when number of cpus is large. > > There is no good way to pick LOCKDEP_BITS. > > > > It can be made optional on PREEMP_RT only > > and used for kmalloc buckets only that kmalloc_nolock() is using, > > but still feels less clean than > > local_lock_lockdep_start/end() > > since it makes lockdep work harder. > > > > Better ideas? > > I was thinking something like a class for normal context and a different > class for kmalloc_nolock() context (determined by allow_spinning) but it's > quite vague as I don't understand lockdep enough. lockdep is not context sensitive. Any lock can either 'lock' or 'trylock'. One cannot tell lockdep to use different class when lock is 'lock'ed from a different context (like special gfpflags), but good news... Turned out lockdep understand LD_LOCK_PERCPU which was added specifically for local_lock. So no need to register lock_key for each cpu. The following diff addresses false positive on PREEMPT_RT. This is definitely cleaner than local_lock_lockdep_start/end() trickery. I'm thinking to wrap it with ifdef CONFIG_PREEMPT_RT and add to respin. As long as we stick to local_trylock_irqsave() for !PREEMPT_RT and local_lock_irqsave() for PREEMPT_RT all cases should be covered. For !PREEMP_RT there will be no issue with "inconsistent {INITIAL USE} -> {IN-NMI} usage." case, since we will be doing local_trylock_irqsave(). And for PREEMPT_RT there is no NMI or hardirq in this path. Meaning that what you were suggesting earlier: > if (unlikely(!local_trylock_irqsave(&s->cpu_slab->lock, *flags)) > local_lock_irqsave(&s->cpu_slab->lock, *flags); isn't an option. For !RT we can only use local_trylock_irqsave() without fallback otherwise we will be back to square one re: lockdep falsepositives. So I'll be going with Sebastian's approach: + if (!IS_ENABLED(CONFIG_PREEMPT_RT) && !allow_spin) + BUG_ON(!local_trylock_irqsave(&s->cpu_slab->lock, *flags)); + else + local_lock_irqsave(&s->cpu_slab->lock, *flags); >From a51dd40cadc5fbe0a2dfa9d8fb493cdc14ab2e9f Mon Sep 17 00:00:00 2001 From: Alexei Starovoitov Date: Tue, 15 Jul 2025 10:16:42 -0700 Subject: [PATCH v2] lockdep Signed-off-by: Alexei Starovoitov --- mm/slab.h | 1 + mm/slub.c | 5 +++++ 2 files changed, 6 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; #endif /* Used for retrieving partial slabs, etc. */ slab_flags_t flags; diff --git a/mm/slub.c b/mm/slub.c index 2f30b85fbf68..ca7f6a3d5db4 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -3080,9 +3080,13 @@ static void init_kmem_cache_cpus(struct kmem_cache *s) int cpu; struct kmem_cache_cpu *c; + if (!init_section_contains(s, 1)) + /* register lockdep key for non-boot kmem caches */ + lockdep_register_key(&s->lock_key); for_each_possible_cpu(cpu) { c = per_cpu_ptr(s->cpu_slab, cpu); local_trylock_init(&c->lock); + lockdep_set_class(&c->lock, &s->lock_key); c->tid = init_tid(cpu); } } @@ -5953,6 +5957,7 @@ void __kmem_cache_release(struct kmem_cache *s) { cache_random_seq_destroy(s); #ifndef CONFIG_SLUB_TINY + lockdep_unregister_key(&s->lock_key); free_percpu(s->cpu_slab); #endif free_kmem_cache_nodes(s); -- 2.47.1