Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sat, 3 Dec 2022 00:32:11 +0900
From:   Max Staudt <max@enpas.org>
To:     Marc Kleine-Budde <mkl@pengutronix.de>
Cc:     "Jiri Slaby (SUSE)" <jirislaby@kernel.org>,
        dario.binacchi@amarulasolutions.com, linux-serial@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        Richard Palethorpe <richard.palethorpe@suse.com>,
        Petr Vorel <petr.vorel@suse.com>,
        Wolfgang Grandegger <wg@grandegger.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>, linux-can@vger.kernel.org,
        netdev@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] can: slcan: fix freed work crash
Message-ID: <20221203003211.4c6a63b9.max@enpas.org>
In-Reply-To: <20221202152701.ewnillsqded7uby4@pengutronix.de>
References: <20221201073426.17328-1-jirislaby@kernel.org>
        <20221202152701.ewnillsqded7uby4@pengutronix.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

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