Re: [PATCH v4 02/12] block/bdev: Annotate the blk_holder_ops callback functions

[Nathan Chancellor <nathan@kernel.org>]

On Wed, May 13, 2026 at 08:54:57AM +0200, Marco Elver wrote:
> On Tue, 12 May 2026 at 21:28, Bart Van Assche <bvanassche@acm.org> wrote:
> >
> > On 5/11/26 3:19 PM, Marco Elver wrote:
> > > On Mon, 11 May 2026 at 18:31, Bart Van Assche <bvanassche@acm.org> wrote:
> > >>
> > >> The four callback functions in blk_holder_ops all release the
> > >> bd_holder_lock. Annotate these functions accordingly.
> > >>
> > >> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> > >
> > > Because of this change we'll need clang 23, or you add:
> > >
> > > CONTEXT_ANALYSIS := $(call clang-min-version, 230000)
> > >
> > > .. although anything else that includes blkdev.h that has
> > > CONTEXT_ANALYSIS := y, but is compiled with clang 22 will break.
> > >
> > > Would have been good to wait for clang 23 to be released (August this
> > > year) - although if we consider the next merge window + final release
> > > of Linux 7.2, it might get reasonably close to August.
> >
> > Hi Marco,
> >
> > How about detecting whether or not Clang supports context annotations
> > for function pointers, e.g. as follows?
> >
> > diff --git a/init/Kconfig b/init/Kconfig
> > index 2937c4d308ae..61e592205179 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -32,6 +32,9 @@ config CLANG_VERSION
> >         default $(cc-version) if CC_IS_CLANG
> >         default 0
> >
> > +config CC_CONTEXT_ANNOTATIONS_ON_FUNCTION_POINTERS
> > +       def_bool $(success, echo 'struct __attribute__((capability("m"))) m {
> > }; struct a { void (*fp)(struct m* m)
> > __attribute__((release_capability(m))); };' | $(CC) -x c - -c -Wall
> > -Wextra -Werror -o /dev/null)
> > +
> >   config AS_IS_GNU
> >         def_bool $(success,test "$(as-name)" = GNU)
> 
> That works, but invokes the compiler every time to sync the config,
> adding a tiny bit of latency; I think we already have too many of
> those, and in this case a version check is sufficient. Clang 23 has
> not yet been released, and anyone using the current dev version ought
> to use the latest one.

Yeah, any time we do a prerelease check, we assume that people are
upgrading their prerelease compilers with regular cadence, otherwise
they are doing something wrong :)

> Maybe Nathan can keep me honest about the real overhead of this. :-)

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.

-- 
Cheers,
Nathan