[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20221203003211.4c6a63b9.max@enpas.org>
Date: Sat, 3 Dec 2022 00:32:11 +0900
From: Max Staudt <max@...as.org>
To: Marc Kleine-Budde <mkl@...gutronix.de>
Cc: "Jiri Slaby (SUSE)" <jirislaby@...nel.org>,
dario.binacchi@...rulasolutions.com, linux-serial@...r.kernel.org,
linux-kernel@...r.kernel.org,
Richard Palethorpe <richard.palethorpe@...e.com>,
Petr Vorel <petr.vorel@...e.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>, linux-can@...r.kernel.org,
netdev@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] can: slcan: fix freed work crash
This patch fixes the crash, but is IMHO incomplete: The flush_work() in
.ndo_stop() should also be removed, since its existence implies
unexpected behaviour.
In other words, my moving it there in can327 was a double mistake, and
slcan just happened to copy my mistake over.
I'm preparing a patch for can327, and it will remove the flush from
.ndo_stop(). What shall we do about slcan?
Max
Powered by blists - more mailing lists