Re: [RFC PATCH] wifi: cfg80211: fix cqm_config access race

[Johannes Berg <johannes@sipsolutions.net>]

On Tue, 2023-08-15 at 12:56 +0200, Max Schulze wrote:
> Hello Johannes,
> 
> thanks for your patch.
> 
> While it works well in my lab setting, it crashes within minutes in the field. 
> 
> While the crashes look slightly different ("Unable to handle kernel pagign request"... descendant of is_swiotlb_active...) I think the notice beforehand is much more interesting: do you understand it?
> 
> : ------------[ cut here ]------------
> : Voluntary context switch within RCU read-side critical section!
[...]
> :  brcmf_sdio_bus_txctl+0xcc/0x1f4 [brcmfmac]
> :  brcmf_proto_bcdc_msg+0xd4/0xf0 [brcmfmac]
> :  brcmf_proto_bcdc_set_dcmd+0x88/0x124 [brcmfmac]
> :  brcmf_fil_cmd_data+0x84/0x180 [brcmfmac]
> :  brcmf_fil_iovar_data_set+0x11c/0x160 [brcmfmac]
> :  brcmf_cfg80211_set_cqm_rssi_range_config+0xe4/0x130 [brcmfmac]
> :  cfg80211_cqm_rssi_update+0x120/0x3f0 [cfg80211]
> :  cfg80211_cqm_rssi_notify+0x78/0x1b4 [cfg80211]
[...]

Oh, yeah, stupid me.

I did RCU protection around cfg80211_cqm_rssi_update() to have that
protected, but failed to realize that this will call back into the
driver too, which then promptly assumes it can sleep.

Well, OK, so this isn't how we can fix this.

That's really bad for multiple reasons though, because it also means we
call back into the driver from a driver call, which is generally not a
good idea since it can easily cause deadlocks.

Anyway, I guess I have to come up with something else. Thanks for
testing, and sorry I didn't realize that before.

johannes