linux-kernel - Re: [PATCH can v3 1/2] can: m_can: enable NAPI before enabling interrupts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20240912-ingenious-ruddy-deer-327fdb-mkl@pengutronix.de>
Date: Thu, 12 Sep 2024 09:45:05 +0200
From: Marc Kleine-Budde <mkl@...gutronix.de>
To: Jake Hamby <Jake.Hamby@...edyne.com>, 
	Chandrasekar Ramakrishnan <rcsekar@...sung.com>, Vincent Mailhol <mailhol.vincent@...adoo.fr>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Dong Aisheng <b29396@...escale.com>, Varka Bhadram <varkabhadram@...il.com>
Cc: linux-can@...r.kernel.org, netdev@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH can v3 1/2] can: m_can: enable NAPI before enabling
 interrupts

On 10.09.2024 19:15:28, Marc Kleine-Budde wrote:
> From: Jake Hamby <Jake.Hamby@...edyne.com>
> 
> If an interrupt (RX-complete or error flag) is set when bringing up
> the CAN device, e.g. due to CAN bus traffic before initializing the
> device, when m_can_start() is called and interrupts are enabled,
> m_can_isr() is called immediately, which disables all CAN interrupts
> and calls napi_schedule().
> 
> Because napi_enable() isn't called until later in m_can_open(), the
> call to napi_schedule() never schedules the m_can_poll() callback and
> the device is left with interrupts disabled and can't receive any CAN
> packets until rebooted.
> 
> This can be verified by running "cansend" from another device before
> setting the bitrate and calling "ip link set up can0" on the test
> device. Adding debug lines to m_can_isr() shows it's called with flags
> (IR_EP | IR_EW | IR_CRCE), which calls m_can_disable_all_interrupts()
> and napi_schedule(), and then m_can_poll() is never called.
> 
> Move the call to napi_enable() above the call to m_can_start() to
> enable any initial interrupt flags to be handled by m_can_poll() so
> that interrupts are reenabled. Add a call to napi_disable() in the
> error handling section of m_can_open(), to handle the case where later
> functions return errors.
> 
> Also, in m_can_close(), move the call to napi_disable() below the call
> to m_can_stop() to ensure all interrupts are handled when bringing
> down the device. This race condition is much less likely to occur.
> 
> Tested on a Microchip SAMA7G54 MPU. The fix should be applicable to
> any SoC with a Bosch M_CAN controller.
> 
> Signed-off-by: Jake Hamby <Jake.Hamby@...edyne.com>
> Fixes: e0d1f4816f2a ("can: m_can: add Bosch M_CAN controller support")
> Signed-off-by: Marc Kleine-Budde <mkl@...gutronix.de>

Tested successfully on a stm32mp1.

Tested-by: Marc Kleine-Budde <mkl@...gutronix.de>

regards,
Mar
c
-- 
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)