From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45]) (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 3FE733128AC for ; Thu, 11 Dec 2025 13:12:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765458780; cv=none; b=f5URNxir6mkSq1vvEJaUjShlRyOahHSJ062H1vpUX71PeWZW7JLz2j6KDFttEUfYULF7XODATkJx48oXqGCTnKa7XIg7ebXtFrdp/toyz63olXA7rZ4QwMOq0UwyGN3wLZ6dfp1SB177JjlSCntLIVAdMoJRcNJTABZgJIrR9qo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765458780; c=relaxed/simple; bh=v+ZQdnBsG3Jds4SOxdBrDPR7IaFiwIcDFZln0Uu2MNI=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ZTPbBl2Vk2be4GsmUuvC9Eg4TRGqtAfLQq9GmndPRX9IQDvO4/NKvvFop08hotHfSb9w17BK0ztYOH1jvyplLVyV8iX4TIH1eo0fTTX5t4NufDoRk5ihS9NuJpPgbqrSYXSs5C/mIf4nlgzv8XIf6L+8z5B+KMX7IClglKtCVe8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=OJ15YAaJ; arc=none smtp.client-ip=209.85.216.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="OJ15YAaJ" Received: by mail-pj1-f45.google.com with SMTP id 98e67ed59e1d1-34a2acb736eso41235a91.1 for ; Thu, 11 Dec 2025 05:12:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1765458777; x=1766063577; darn=lists.linux.dev; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aSAWeLhswH6DwjvXpmjx7xXAiszMCLjSPlHn40Ul7IQ=; b=OJ15YAaJNBVlEYm91LvmkrPE/6RM7e+KFi8EIjYTpVXDE9isWcBQPOassapH8zn9Ow +rChiSOagAlQteZATg2BfYtBUxjK55nLOjMyuHfb+wCYEycjMJ0YFLAOKVI1WRHMirD8 Qxj0ke9acYRXtO0lCaQHhp65XJ5l/t6C+7hDLBgeJTU4qmtWR75xAhXznrcJJHH3pJaq GBcvtCiBZdTRZj90O84foNHDA1SaWGzaRXruyxl658Yu7EBHNBfoChf34Tlxp8764aH/ gKhEhYCsuTZ3cvN35mtIaG40kNafZV4M0+5hn4pC7Qz6DL+vP6hXxPfhWbX1ETTCaZkh +Esg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765458777; x=1766063577; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=aSAWeLhswH6DwjvXpmjx7xXAiszMCLjSPlHn40Ul7IQ=; b=fQQelUmWNq4FzO8dYkgDQu+wBqosp9t73fjQgLK9Ja7LOVRBdW91KULBh1DQN/15lR cBKsFsceH9JVIzd/pYRwdM544PF5s7P/xiuXIbfZm9GBE1YehPHoV0oGOKEVBZGwX65w m7/4/6vkY79NCZZ8Nh3KAKO4OVGS/JG6DpTFl7BP6fWQ6w/wMNKSasAPK/ClB6lzJId2 WSUJ0fHws3gMMCBa3efTX2HFRAfdP79QJfNedMfTfqmBTb03frTo2uL91nge4JxZLL6Y Gw7YQYmlKz5uGluuyccEcc7pUa322XgeblGUiBiqtieqjPdoipmmWcrTSjVq/QKWMATe GGKg== X-Forwarded-Encrypted: i=1; AJvYcCW88RJA3JeGpx01Jfs8DDHrZDBiLQyfnF3/cKngSDfWAIJH1X9U64SJ1hAwf2THHzYuX+Wk@lists.linux.dev X-Gm-Message-State: AOJu0Yzd7dYNozm0IJUuctYR1C0P0FoJs6OTmCZjoviYZdQAufXnbtRu Pkl9tB9qKnWn6D+bkT2PEx8iwlFXOvFSQAl6g5zIxIavFCrPtNjHfEIVM1kWpCzemfH5UKvBXK1 0inDZSnkD0iFg7QckjDb7e9LPfF7PWApIoQjVHGe/ X-Gm-Gg: AY/fxX4bUMDCPM1cgfr/dmejxlAQw76f7Jm20h3303sbzAEEHBa2bCH0abNQz/OB6rW hBiqWYylgYopjqUop7uDLHjN8pZYmjk7fxH1DxFgtPLLoFcCxOUEBFYoPos2w5WyMpWI0EOOKRg a1HsFQ/tlZqmndtWfKHAuEANCklSZ6rX9xjyBqFQg4xdX/HYN/6fHWdVvmj0GccMy5l+B9/XEof LNANFrKvRQCw7eTr0vTkIwrhRTRCeAv3ZaJD0BgdOU87gzzcArDVWZ4VC66EZk2mVIMO0FhgTg4 aiBzwShXGOFKcUxp+djM7kGg X-Google-Smtp-Source: AGHT+IFKUTpUZDJYgmni8n60xNJbrbAVNuDkEgVCtA4vIsV0NrU5sPU9y26HNSVsbHocOOsMdXB5E5HCLF6JNhBBnMQ= X-Received: by 2002:a05:7022:685:b0:11a:5065:8763 with SMTP id a92af1059eb24-11f2966a3c7mr5044765c88.5.1765458776836; Thu, 11 Dec 2025 05:12:56 -0800 (PST) Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20251120145835.3833031-2-elver@google.com> <20251120145835.3833031-4-elver@google.com> <20251211120441.GG3911114@noisy.programming.kicks-ass.net> In-Reply-To: <20251211120441.GG3911114@noisy.programming.kicks-ass.net> From: Marco Elver Date: Thu, 11 Dec 2025 14:12:19 +0100 X-Gm-Features: AQt7F2ok29a5Gxu0w202jEvGPrWPxaH5LVi0EBv48F585MyX9KePj1tDpUehhNc Message-ID: Subject: Re: [PATCH v4 02/35] compiler-context-analysis: Add infrastructure for Context Analysis with Clang To: Peter Zijlstra Cc: Boqun Feng , Ingo Molnar , Will Deacon , "David S. Miller" , Luc Van Oostenryck , Chris Li , "Paul E. McKenney" , Alexander Potapenko , Arnd Bergmann , Bart Van Assche , Christoph Hellwig , Dmitry Vyukov , Eric Dumazet , Frederic Weisbecker , Greg Kroah-Hartman , Herbert Xu , Ian Rogers , Jann Horn , Joel Fernandes , Johannes Berg , Jonathan Corbet , Josh Triplett , Justin Stitt , Kees Cook , Kentaro Takeda , Lukas Bulwahn , Mark Rutland , Mathieu Desnoyers , Miguel Ojeda , Nathan Chancellor , Neeraj Upadhyay , Nick Desaulniers , Steven Rostedt , Tetsuo Handa , Thomas Gleixner , Thomas Graf , Uladzislau Rezki , Waiman Long , kasan-dev@googlegroups.com, linux-crypto@vger.kernel.org, linux-doc@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-security-module@vger.kernel.org, linux-sparse@vger.kernel.org, linux-wireless@vger.kernel.org, llvm@lists.linux.dev, rcu@vger.kernel.org Content-Type: text/plain; charset="UTF-8" On Thu, 11 Dec 2025 at 13:04, Peter Zijlstra wrote: > > On Thu, Nov 20, 2025 at 03:49:04PM +0100, Marco Elver wrote: > > > +/** > > + * context_guard_struct() - declare or define a context guard struct > > + * @name: struct name > > + * > > + * Helper to declare or define a struct type that is also a context guard. > > + * > > + * .. code-block:: c > > + * > > + * context_guard_struct(my_handle) { > > + * int foo; > > + * long bar; > > + * }; > > + * > > + * struct some_state { > > + * ... > > + * }; > > + * // ... declared elsewhere ... > > + * context_guard_struct(some_state); > > + * > > + * Note: The implementation defines several helper functions that can acquire > > + * and release the context guard. > > + */ > > +# define context_guard_struct(name, ...) \ > > + struct __ctx_guard_type(name) __VA_ARGS__ name; \ > > + static __always_inline void __acquire_ctx_guard(const struct name *var) \ > > + __attribute__((overloadable)) __no_context_analysis __acquires_ctx_guard(var) { } \ > > + static __always_inline void __acquire_shared_ctx_guard(const struct name *var) \ > > + __attribute__((overloadable)) __no_context_analysis __acquires_shared_ctx_guard(var) { } \ > > + static __always_inline bool __try_acquire_ctx_guard(const struct name *var, bool ret) \ > > + __attribute__((overloadable)) __no_context_analysis __try_acquires_ctx_guard(1, var) \ > > + { return ret; } \ > > + static __always_inline bool __try_acquire_shared_ctx_guard(const struct name *var, bool ret) \ > > + __attribute__((overloadable)) __no_context_analysis __try_acquires_shared_ctx_guard(1, var) \ > > + { return ret; } \ > > + static __always_inline void __release_ctx_guard(const struct name *var) \ > > + __attribute__((overloadable)) __no_context_analysis __releases_ctx_guard(var) { } \ > > + static __always_inline void __release_shared_ctx_guard(const struct name *var) \ > > + __attribute__((overloadable)) __no_context_analysis __releases_shared_ctx_guard(var) { } \ > > + static __always_inline void __assume_ctx_guard(const struct name *var) \ > > + __attribute__((overloadable)) __assumes_ctx_guard(var) { } \ > > + static __always_inline void __assume_shared_ctx_guard(const struct name *var) \ > > + __attribute__((overloadable)) __assumes_shared_ctx_guard(var) { } \ > > + struct name > > -typedef struct { > +context_guard_struct(rwlock) { > struct rwbase_rt rwbase; > atomic_t readers; > #ifdef CONFIG_DEBUG_LOCK_ALLOC > struct lockdep_map dep_map; > #endif > -} rwlock_t; > +}; > +typedef struct rwlock rwlock_t; > > > I must say I find the 'guard' naming here somewhat confusing. This is > not a guard, but an actual lock type. The switch to "context analysis" required us coming up with a name for the actual objects (previously: "capability") that "guard" those contexts. The reasoning was that these are guards for entering a particular context. The lock guards the given context, but the context itself != lock. Clang's naming of "capability" was a lot clearer in isolation, but the problem that Linus raised is that "capability" is already overloaded in the kernel. The fact it overlaps in naming with the other guard(..) infrastructure is not entirely coincidental, but I see the confusion. What's a better name? context_lock_struct -> and call it "context lock" rather than "context guard"; it might work also for things like RCU, PREEMPT, BH, etc. that aren't normal "locks", but could claim they are "context locks". context_handle_struct -> "context handle" ... ?