[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86ff131e-c1d2-ca1f-89a4-37cec62877f4@wanadoo.fr>
Date: Tue, 16 May 2023 18:47:17 +0200
From: Christophe JAILLET <christophe.jaillet@...adoo.fr>
To: Marc Kleine-Budde <mkl@...gutronix.de>
Cc: Pavel Pisa <pisa@....felk.cvut.cz>,
Ondrej Ille <ondrej.ille@...il.com>,
Wolfgang Grandegger <wg@...ndegger.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Martin Jerabek <martin.jerabek01@...il.com>,
linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org,
linux-can@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] can: ctucanfd: Fix an error handling path in
ctucan_probe_common()
Le 15/05/2023 à 22:51, Marc Kleine-Budde a écrit :
> On 15.05.2023 22:36:28, Christophe JAILLET wrote:
>> If register_candev() fails, a previous netif_napi_add() needs to be undone.
>> Add the missing netif_napi_del() in the error handling path.
>
> What about this path:
> free_candev(ndev) -> free_netdev() -> netif_napi_del()
>
> | https://elixir.bootlin.com/linux/v6.3.2/source/net/core/dev.c#L10714
>
> Marc
>
Ok, thanks for the review,
so in fact this is the netif_napi_del() call in ctucan_platform_remove()
that can be removed instead.
Harmless, but would be more consistent.
I'll send a patch for that.
CJ
Powered by blists - more mailing lists