Linux block layer
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Nathan Chancellor <nathan@kernel.org>, Marco Elver <elver@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v4 02/12] block/bdev: Annotate the blk_holder_ops callback functions
Date: Wed, 13 May 2026 15:13:57 -0700	[thread overview]
Message-ID: <e6dbe36b-7bd3-4848-91e1-9c84d421e1ee@acm.org> (raw)
In-Reply-To: <20260513133614.GA703152@ax162>

On 5/13/26 6:36 AM, Nathan Chancellor wrote:
> While doing a dynamic check is more expensive than a version check, I
> would not worry much about that overhead if the check is worthwhile or
> valuable. In this case, I tend to agree with you that it would just be
> better to bump the minimum version of Clang required for context
> analysis because of the improvements (other than the function pointer
> support) that you have landed in main since release/22.x. While I am
> always sad to see support for older compilers dropped, I don't think
> clang-22 is widespread enough for that to really matter. On the other
> hand, I do worry that if we do not have a wide enough window of
> supported compilers for developers / maintainers to use, we won't be
> able to uncover potential problems to address in the compiler (I feel
> like getting __counted_by deployed was particular painful for this
> reason), if that makes sense.

It seems to me that increasing the required Clang version is the least
controversial approach. If nobody objects I will start testing the patch
below.

Thanks,

Bart.

Subject: [PATCH] lib/Kconfig.debug: Require Clang 23 for context analysis

Context annotations for function pointers will be supported by Clang 23
but are not supported by Clang 22. Bump the minimum required Clang
version in preparation of annotating the blk_holder_ops function pointer
members.

Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
  lib/Kconfig.debug | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 8ff5adcfe1e0..5b5d1d183618 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -630,7 +630,7 @@ config DEBUG_FORCE_WEAK_PER_CPU

  config WARN_CONTEXT_ANALYSIS
  	bool "Compiler context-analysis warnings"
-	depends on CC_IS_CLANG && CLANG_VERSION >= 220100
+	depends on CC_IS_CLANG && CLANG_VERSION >= 230000
  	# Branch profiling re-defines "if", which messes with the compiler's
  	# ability to analyze __cond_acquires(..), resulting in false positives.
  	depends on !TRACE_BRANCH_PROFILING
@@ -641,7 +641,7 @@ config WARN_CONTEXT_ANALYSIS
  	  and releasing user-definable "context locks".

  	  Clang's name of the feature is "Thread Safety Analysis". Requires
-	  Clang 22.1.0 or later.
+	  Clang 23.0 or later.

  	  Produces warnings by default. Select CONFIG_WERROR if you wish to
  	  turn these warnings into errors.




  reply	other threads:[~2026-05-13 22:14 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-11 16:30 [PATCH v4 00/12] Enable lock context analysis Bart Van Assche
2026-05-11 16:30 ` [PATCH v4 01/12] block: Annotate the queue limits functions Bart Van Assche
2026-05-11 16:30 ` [PATCH v4 02/12] block/bdev: Annotate the blk_holder_ops callback functions Bart Van Assche
2026-05-11 22:19   ` Marco Elver
2026-05-12 19:28     ` Bart Van Assche
2026-05-13  6:54       ` Marco Elver
2026-05-13 13:36         ` Nathan Chancellor
2026-05-13 22:13           ` Bart Van Assche [this message]
2026-05-13 23:06             ` Marco Elver
2026-05-14  0:31               ` Bart Van Assche
2026-05-11 16:30 ` [PATCH v4 03/12] block/cgroup: Split blkg_conf_prep() Bart Van Assche
2026-05-11 16:30 ` [PATCH v4 04/12] block/cgroup: Split blkg_conf_exit() Bart Van Assche
2026-05-11 16:30 ` [PATCH v4 05/12] block/cgroup: Improve lock context annotations Bart Van Assche
2026-05-11 16:30 ` [PATCH v4 06/12] block/cgroup: Inline blkg_conf_{open,close}_bdev_frozen() Bart Van Assche
2026-05-11 16:30 ` [PATCH v4 07/12] block/crypto: Annotate the crypto functions Bart Van Assche
2026-05-11 16:30 ` [PATCH v4 08/12] block/blk-iocost: Add lock context annotations Bart Van Assche
2026-05-11 16:30 ` [PATCH v4 09/12] block/blk-mq-debugfs: Improve " Bart Van Assche
2026-05-11 16:30 ` [PATCH v4 10/12] block/kyber: Make the lock context annotations compatible with Clang Bart Van Assche
2026-05-11 16:30 ` [PATCH v4 11/12] block/mq-deadline: " Bart Van Assche
2026-05-11 16:30 ` [PATCH v4 12/12] block: Enable lock context analysis Bart Van Assche

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e6dbe36b-7bd3-4848-91e1-9c84d421e1ee@acm.org \
    --to=bvanassche@acm.org \
    --cc=axboe@kernel.dk \
    --cc=elver@google.com \
    --cc=hch@lst.de \
    --cc=linux-block@vger.kernel.org \
    --cc=nathan@kernel.org \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox