[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20170320170944.3D26D609C6@smtp.codeaurora.org>
Date: Mon, 20 Mar 2017 17:09:44 +0000 (UTC)
From: Kalle Valo <kvalo@...eaurora.org>
To: Brian Norris <briannorris@...omium.org>
Cc: linux-wireless@...r.kernel.org, Cathy Luo <cluo@...vell.com>,
Nishant Sarmukadam <nishants@...vell.com>, rajatja@...gle.com,
dmitry.torokhov@...il.com, Amitkumar Karwar <akarwar@...vell.com>,
<linux-kernel@...r.kernel.org>,
Brian Norris <briannorris@...omium.org>
Subject: Re: [v3] mwifiex: fix kernel crash after shutdown command timeout
Brian Norris <briannorris@...omium.org> wrote:
> We observed a SHUTDOWN command timeout during reboot stress test due to
> a corner case firmware bug. It can lead to either a use-after-free +
> OOPS (on either the adapter structure, or the 'card' structure) or an
> abort (where, e.g., the PCI device is "disabled" before we're done
> dumping the FW).
>
> We can avoid this by canceling/flushing the FW dump work:
>
> (a) after we've terminated all other work queues (e.g., for processing
> commands which could time out)
> (b) after we've disabled all interrupts (which could also queue more
> work for us)
> (c) after we've unregistered the netdev and wiphy structures (and
> implicitly, and debugfs entries which could manually trigger FW dumps)
> (d) before we've actually disabled the device (e.g.,
> pci_device_disable())
>
> Altogether, this means no card->work will be scheduled if we sync at
> a point that satisfies the above. This can be done at the beginning of
> the .cleanup_if() callback.
>
> Signed-off-by: Brian Norris <briannorris@...omium.org>
Patch applied to wireless-drivers-next.git, thanks.
5caa7f384629 mwifiex: fix kernel crash after shutdown command timeout
--
https://patchwork.kernel.org/patch/9629349/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Powered by blists - more mailing lists