<Ajay.Kathat@xxxxxxxxxxxxx> writes: > Fix for kernel crash observed with following test procedure [1]: > while true; > do ifconfig wlan0 up; > iw dev wlan0 scan & > ifconfig wlan0 down; > done > > During the above test procedure, the scan results are received from firmware > for 'iw scan' command gets queued even when the interface is going down. It > was causing the kernel oops when dereferencing the freed pointers. > > For synchronization, 'mac_close()' calls flush_workqueue() to block its > execution till all pending work is completed. Afterwards 'wilc->close' flag > which is set before the flush_workqueue() should avoid adding new work. > Added 'wilc->close' check in wilc_handle_isr() which is common for > SPI/SDIO bus to ignore the interrupts from firmware that inturns adds the > work since the interface is getting closed. > > 1. https://lore.kernel.org/linux-wireless/20221024135407.7udo3dwl3mqyv2yj@xxxxxxxxxxxx/ > > Reported-by: Michael Walle <mwalle@xxxxxxxxxx> > Signed-off-by: Ajay Singh <ajay.kathat@xxxxxxxxxxxxx> [...] > @@ -781,13 +776,15 @@ static int wilc_mac_close(struct net_device *ndev) > if (vif->ndev) { > netif_stop_queue(vif->ndev); > > + if (wl->open_ifcs == 0) > + wl->close = 1; > + wl-close is an int, I wonder if it's racy to int as a flag like this? In cases like this I usually use set_bit() & co because those guarantee atomicity, though don't know if that's overkill. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
