From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9AFC231CA4A for ; Mon, 4 May 2026 20:37:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777927070; cv=none; b=WYHA9q0o/4m+j6FaW/OJ6NFrnCm78ZJMkV8UoDWY64oEfz8sK1AOyXdd/WlEa0e69Y/sMugXkMufBJo0iRTtqxc73a6LdgoAWsBwh6agxGcfEWMQSgh/SrVQVJ4M17IMoZFTrqJkVrODh46sJsXvdxMsT6OJGRYy+FjFpGlPJo0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777927070; c=relaxed/simple; bh=1HOOLCCrrieuNT7pA7w7QnyHltTcbTCk3r2Vn9V54mk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=s1mstQy60f8QY0SKYlMb6Zpl34PiNxT93lymnY3Yp3vSeyUwBsvgbI01dilrvPf8CDvm2HZsW4sEjlRlPmVxmarEchltNVMbK423qMD8LlhkDwgZj7+Hpu960xoYbPHukQlRSZqADrl5iO7vViZAelnJRUGBpnAKSYQDA/80jww= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=rDz1JtKM; arc=none smtp.client-ip=209.85.128.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rDz1JtKM" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4852b81c73aso33066905e9.3 for ; Mon, 04 May 2026 13:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777927064; x=1778531864; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=lmBu9fDLE2OK+j8VOp99Tc/ddpcU6v5uiBfA0L7yFGU=; b=rDz1JtKMjYx/N8OTth0ayXsaliuMKdKWBtvLeycM4xamTG2dQNXrj2V7vBir9EGEnF 6egXpz2qNaGkiCXejbdOpSW67dCMyyVyaxmobVKLU//BjoRKaQSG7mh7aJ3zN4QQ9CWE qSZJpPhgfoKQKPJ6b6DUoIXP2EhmQmjrbFBgTIsH9adKuLwru9nNfsLdM9oZ33jQN6zz HyQXnp7hWKw2FTXx1cF9dVQrThCYwYf0nsOxndeJ4bKa4xwif9h3zfXxJd6Ciu1i7NNH Ic0+qzvkr4GtKQy0/qIF4WO0E7TIUmwBpBhPZSBLbEZOlNPUCHF3lWDsRso1dP2pxvNO CDdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777927064; x=1778531864; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lmBu9fDLE2OK+j8VOp99Tc/ddpcU6v5uiBfA0L7yFGU=; b=KaDmBLn/Vef5ayzrgp3esGla2PTxlDIE3WGjXtKkYWbX1XVPZQl9D+bHIXXQBBUBV2 62wZL3GGw59d/OSf5pWufx4ZDdNW3o8ckDx9QKpbhNj6Qn3N7+pNhGqzmV3jL6vNIwZl XDOO/KafUwx1UouWcg+psnzdBPMYEgpBL8Rp/mAF/FvSL6e4/NRsa81oi2ioohRtYuNY 8UblhYStcjE9rxORHkqKFgIsr05HtUcuHSALgp09Wp0eNLwDvLsNSsSBCsx8wH/zW37a b86SlzrQjJHufctx4egHwICHGjiP+ghBofRquiNxm4VRw9pHQ+3ya672ENOYc1sXaTpm MEEA== X-Forwarded-Encrypted: i=1; AFNElJ9JXR60+0LFhplSCHbWGsYaMg0QFX9h1OGZ7lkEaz3/FbjYKT1ZIj7CuINhIge/if3Qw9HLyOozeF0TW5k=@vger.kernel.org X-Gm-Message-State: AOJu0YwSbijdPghJCHva2fNjiScD8EP+CHGBuO25Iu7te48llCjAEsqB y0hL1C/vB+Qg/Tv4/10q5pm9ocA81aRxJHNO0BsdkCwZVASyBYmPo3lg X-Gm-Gg: AeBDievLogs2+5SSNV2sLTka4LaIWqiiTk4zGNUifPYU5gK/8SRUgAavdolHAYPFeVY fbfD/PRX9oMkcIFQDnL8vEeC/9TTlERzP3hWBlu1DTKfRH3vtJlHGAtcK0LJY/NJqWFL+RjBcfA m1okBjc147fArRx/TZBi42tXMSe7THlUw1w7eRsOdUQkJxiPVRXzvUnHTwmq33tCqEFVVLWtZDK dECf5puk+5BrEujrRBIqyPq/4i9LAV8422819JhDEZLu3oqnHtCozc442MhOeSzKnV1eSPBfc2C flKkvBdZ4v/T+ZEopVyIKfR+rWwIZ+tvLkMe2PX/YPm1bukdBdH7QN9Vtm0FtZim4+T/kRaNKYI roC1CZbHhUPYbkg7uHZp8mzZbKVI3xzhTqk6MH5qZSjAf5hEYOkqkE0abSIf61mxG0oVlOvs3U+ jY5KaYJL3B7uH1+5DzkUmtkAMU65SDWiGgsucIdjnDoxxyDVegJE7bYeSOc9GNDdSPv+OZ59rvf SPG3jPNjwr/UxsaDPRAodl1LcPdafrvGg+vwxDe9C+5/zr4+QTlVNediNlsuWHoQbQmN1CtVxa9 RQr43CqKM3k= X-Received: by 2002:a05:600c:46d0:b0:488:79a3:f04c with SMTP id 5b1f17b1804b1-48d18cee7a2mr1243075e9.27.1777927063757; Mon, 04 May 2026 13:37:43 -0700 (PDT) Received: from ?IPV6:2003:ea:8f06:f500:8479:dda0:bba8:c2d9? (p200300ea8f06f5008479dda0bba8c2d9.dip0.t-ipconnect.de. [2003:ea:8f06:f500:8479:dda0:bba8:c2d9]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48a8ebc4201sm476567895e9.15.2026.05.04.13.37.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 May 2026 13:37:43 -0700 (PDT) Message-ID: Date: Mon, 4 May 2026 22:37:42 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] lockdep: constify usage of struct lock_class_key where possible To: Peter Zijlstra Cc: Ingo Molnar , Will Deacon , Boqun Feng , Waiman Long , Linux Kernel Mailing List References: <20260504072826.GL3126523@noisy.programming.kicks-ass.net> Content-Language: en-US From: Heiner Kallweit In-Reply-To: <20260504072826.GL3126523@noisy.programming.kicks-ass.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 04.05.2026 09:28, Peter Zijlstra wrote: > On Tue, Apr 28, 2026 at 11:05:25PM +0200, Heiner Kallweit wrote: >> Constify usage of struct lock_class_key where possible. This requires >> to constify also usage of struct lockdep_subclass_key in two places. >> >> Especially relevant is constification of lockdep_map.key, as it makes >> clear that the key isn't changed during lifetime of struct lockdep_map. >> >> Signed-off-by: Heiner Kallweit >> --- >> include/linux/lockdep.h | 18 ++++++++++-------- >> include/linux/lockdep_types.h | 2 +- >> kernel/locking/lockdep.c | 12 ++++++------ >> 3 files changed, 17 insertions(+), 15 deletions(-) >> >> diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h >> index 621566345..3fa2b62f2 100644 >> --- a/include/linux/lockdep.h >> +++ b/include/linux/lockdep.h >> @@ -125,25 +125,27 @@ extern void lockdep_unregister_key(struct lock_class_key *key); >> * to lockdep: >> */ >> >> -extern void lockdep_init_map_type(struct lockdep_map *lock, const char *name, >> - struct lock_class_key *key, int subclass, u8 inner, u8 outer, u8 lock_type); >> +void lockdep_init_map_type(struct lockdep_map *lock, const char *name, >> + const struct lock_class_key *key, int subclass, >> + u8 inner, u8 outer, u8 lock_type); > >> @@ -252,9 +254,9 @@ static inline int lock_is_held(const struct lockdep_map *lock) >> #define lockdep_is_held(lock) lock_is_held(&(lock)->dep_map) >> #define lockdep_is_held_type(lock, r) lock_is_held_type(&(lock)->dep_map, (r)) >> >> -extern void lock_set_class(struct lockdep_map *lock, const char *name, >> - struct lock_class_key *key, unsigned int subclass, >> - unsigned long ip); >> +void lock_set_class(struct lockdep_map *lock, const char *name, >> + const struct lock_class_key *key, unsigned int subclass, >> + unsigned long ip); >> > > It is also silently removing extern, why? When touching this function prototype anyway, make it compliant with coding standard. See https://www.kernel.org/doc/html/v7.0/process/coding-style.html, section 6.1. "Do not use the extern keyword with function declarations as this makes lines longer and isn’t strictly necessary."