Re: [PATCH v8 05/10] can: bcm: add missing rcu list annotations and operations

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The timer callback `bcm_tx_timeout_handler()` reads `op->kt_ival1`, `op->kt_ival2`, and `op->count` locklessly, risking torn reads and inconsistent state.
--

--- Patch [5]: [PATCH v8 05/10] can: bcm: add missing rcu list annotations and operations ---
commit 328ac2042a77c92625995c774ca6b37b5d654ec7
Author: Oliver Hartkopp <socketcan@hartkopp.net>

can: bcm: add missing rcu list annotations and operations

This commit fixes missing RCU list annotations for bcm_op additions and
removals to ensure procfs safely traverses the structures under
rcu_read_lock(). It also moves list additions to the end of the setup code
and fixes the removal path in bcm_release().

Closes: https://lore.kernel.org/linux-can/20260610094654.A1FFE1F00893@smtp.kernel.org/

> diff --git a/net/can/bcm.c b/net/can/bcm.c
> index 340b7fc89744e..fca7c714cc52f 100644
> --- a/net/can/bcm.c
> +++ b/net/can/bcm.c

[ ... ]

> @@ -1163,6 +1163,10 @@ static int bcm_tx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,
>  		op->flags |= TX_ANNOUNCE;
>  	}
>  
> +	/* add this bcm_op to the list of the tx_ops? */
> +	if (add_op_to_list)
> +		list_add_rcu(&op->list, &bo->tx_ops);
> +

[Severity: High]
This isn't a bug introduced by this patch, but while looking at the context
around bcm_tx_setup(), I noticed a potential problem with how the timer
variables are synchronized.

Although bcm_tx_setup() safely updates op->kt_ival1, op->kt_ival2, and
op->count under op->bcm_tx_lock, the timer callback bcm_tx_timeout_handler()
and bcm_tx_set_expiry() appear to read them locklessly:

net/can/bcm.c:bcm_tx_timeout_handler() {
        ...
        if (op->kt_ival1 && (op->count > 0)) {
                bcm_can_tx(op, NULL);
        ...
}

net/can/bcm.c:bcm_tx_set_expiry() {
        ...
        if (op->kt_ival1 && op->count)
                ival = op->kt_ival1;
        else if (op->kt_ival2)
                ival = op->kt_ival2;
        ...
}

Could this result in torn reads of the 64-bit ktime_t variables on 32-bit
platforms, or reading an inconsistent combination of count and interval
values?

If a user calls sendmsg() with SETTIMER (but without STARTTIMER) on an
active cyclic TX operation, could the already-running hrtimer execute
concurrently in softirq context and be rearmed with an incorrect
expiration time?

>  	if (op->flags & TX_ANNOUNCE)
>  		bcm_can_tx(op, NULL);
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260708-bcm_fixes-v8-0-8c2f5f3bc212@hartkopp.net?part=5