From: Sven Eckelmann <sven@narfation.org>
To: sashiko-reviews@lists.linux.dev
Cc: marek.lindner@mailbox.org, sw@simonwunderlich.de,
antonio@mandelbit.com, b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [PATCH batadv] batman-adv: mark functions inheriting critical sections
Date: Thu, 15 Oct 2026 09:26:21 +0200 [thread overview]
Message-ID: <2860295.mvXUDI8C0e@sven-desktop> (raw)
In-Reply-To: <sashiko-outbox-172395@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1829 bytes --]
On Thursday, 15 October 2026 09:22:30 CEST sashiko-bot@kernel.org wrote:
[...]
> [Severity: Low]
> Does adding this capability annotation break the type signature when passed
> as a function pointer?
>
> In net/batman-adv/originator.c, batadv_frag_check_entry() is passed as the
> check_cb argument to batadv_frag_purge_orig():
>
> batadv_frag_purge_orig(orig_node,
> batadv_frag_check_entry);
>
> Because the check_cb function pointer definition lacks the corresponding
> capability annotation, this creates a capability type mismatch that leads to
> a static analysis warning or error during context analysis.
No, it doesn't in my tests.
>
> [ ... ]
>
> > diff --git a/net/batman-adv/multicast.c b/net/batman-adv/multicast.c
> > index 22dd28d5e1abc..6ebab4eb1382e 100644
> > --- a/net/batman-adv/multicast.c
> > +++ b/net/batman-adv/multicast.c
> > @@ -683,6 +685,7 @@ static void batadv_mcast_mla_list_free(struct hlist_head *mcast_list)
> > */
> > static void batadv_mcast_mla_tt_retract(struct batadv_priv *bat_priv,
> > struct hlist_head *mcast_list)
> > + __must_hold(&bat_priv->mcast.mla_lock)
> > {
>
> [Severity: Low]
> Is it possible this annotation is violated during teardown?
>
> In batadv_mcast_free(), the code intentionally skips acquiring mla_lock
> because it relies on implicit serialization after the worker is canceled:
>
> /* safely calling outside of worker, as worker was canceled above */
> batadv_mcast_mla_tt_retract(bat_priv, NULL);
>
> However, batadv_mcast_mla_tt_retract() is now strictly annotated to require
> the lock, which will cause a build warning or error when compiled with
> CONFIG_WARN_CONTEXT_ANALYSIS=y. Is this one of the corner cases preventing
> the enablement of CONTEXT_ANALYSIS := y?
Yes, it is one one of the corner cases.
Regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
prev parent reply other threads:[~2026-10-15 7:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 7:08 [PATCH batadv] batman-adv: mark functions inheriting critical sections Sven Eckelmann
[not found] ` <sashiko-outbox-172395@kernel.org>
2026-10-15 7:26 ` Sven Eckelmann [this message]
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=2860295.mvXUDI8C0e@sven-desktop \
--to=sven@narfation.org \
--cc=antonio@mandelbit.com \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=marek.lindner@mailbox.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sw@simonwunderlich.de \
/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