Re: [PATCH v3] can: m_can: initialize spin lock on device probe

["Markus Schneider-Pargmann" <msp@baylibre.com>]

[-- Attachment #1: Type: text/plain, Size: 3036 bytes --]

Hi,

On Fri Apr 25, 2025 at 1:17 PM CEST, Antonios Salios wrote:
> The spin lock tx_handling_spinlock in struct m_can_classdev is not being
> initialized. This leads the following spinlock bad magic complaint from the
> kernel, eg. when trying to send CAN frames with cansend from can-utils:
>
> [   10.631450] BUG: spinlock bad magic on CPU#0, cansend/95
> [   10.631462]  lock: 0xff60000002ec1010, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
> [   10.631479] CPU: 0 UID: 0 PID: 95 Comm: cansend Not tainted 6.15.0-rc3-00032-ga79be02bba5c #5 NONE
> [   10.631487] Hardware name: MachineWare SIM-V (DT)
> [   10.631490] Call Trace:
> [   10.631493] [<ffffffff800133e0>] dump_backtrace+0x1c/0x24
> [   10.631503] [<ffffffff800022f2>] show_stack+0x28/0x34
> [   10.631510] [<ffffffff8000de3e>] dump_stack_lvl+0x4a/0x68
> [   10.631518] [<ffffffff8000de70>] dump_stack+0x14/0x1c
> [   10.631526] [<ffffffff80003134>] spin_dump+0x62/0x6e
> [   10.631534] [<ffffffff800883ba>] do_raw_spin_lock+0xd0/0x142
> [   10.631542] [<ffffffff807a6fcc>] _raw_spin_lock_irqsave+0x20/0x2c
> [   10.631554] [<ffffffff80536dba>] m_can_start_xmit+0x90/0x34a
> [   10.631567] [<ffffffff806148b0>] dev_hard_start_xmit+0xa6/0xee
> [   10.631577] [<ffffffff8065b730>] sch_direct_xmit+0x114/0x292
> [   10.631586] [<ffffffff80614e2a>] __dev_queue_xmit+0x3b0/0xaa8
> [   10.631596] [<ffffffff8073b8fa>] can_send+0xc6/0x242
> [   10.631604] [<ffffffff8073d1c0>] raw_sendmsg+0x1a8/0x36c
> [   10.631612] [<ffffffff805ebf06>] sock_write_iter+0x9a/0xee
> [   10.631623] [<ffffffff801d06ea>] vfs_write+0x184/0x3a6
> [   10.631633] [<ffffffff801d0a88>] ksys_write+0xa0/0xc0
> [   10.631643] [<ffffffff801d0abc>] __riscv_sys_write+0x14/0x1c
> [   10.631654] [<ffffffff8079ebf8>] do_trap_ecall_u+0x168/0x212
> [   10.631662] [<ffffffff807a830a>] handle_exception+0x146/0x152
>
> Initializing the spin lock in m_can_class_allocate_dev solves that
> problem.
>
> Fixes: 1fa80e23c150 ("can: m_can: Introduce a tx_fifo_in_flight counter")
>
> Signed-off-by: Antonios Salios <antonios@mwa.re>
> Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>

Thanks for finding and fixing this.

Reviewed-by: Markus Schneider-Pargmann <msp@baylibre.com>

Best
Markus

> ---
> Changes since v2:
>  * Clarify bug in commit message
>
> Changes since v1:
>  * Move spin_lock_init from device probe functions to classdev alloc function
>  * Add a fixes tag
> ---
>  drivers/net/can/m_can/m_can.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index 884a6352c..12e313998 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c
> @@ -2379,6 +2379,8 @@ struct m_can_classdev *m_can_class_allocate_dev(struct device *dev,
>  	SET_NETDEV_DEV(net_dev, dev);
>  
>  	m_can_of_parse_mram(class_dev, mram_config_vals);
> +
> +	spin_lock_init(&class_dev->tx_handling_spinlock);
>  out:
>  	return class_dev;
>  }


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 252 bytes --]