Hello,
On 5/9/24 15:24, Dan Carpenter wrote:
> Hello Alexis Lothoré,
>
> Commit f236464f1db7 ("wifi: wilc1000: convert list management to
> RCU") from Apr 10, 2024 (linux-next), leads to the following Smatch
> static checker warning:
>
> drivers/net/wireless/microchip/wilc1000/mon.c:236 wilc_wfi_init_mon_interface()
> warn: sleeping in atomic context
My bad for the extensive delay to fix this. I have been in fact scratching my
head quite a lot around it. Adding Kalle and Ajay to keep them updated, and
possibly to get opinions.
This issue is indeed due to my recent series converting back SRCU to RCU in wilc
driver (submitted because at this time, there was no obvious reason nor
documentation about why SRCU was needed). By checking further the consequence, I
find in fact three issues, and I suspect those to be the original reason for
SRCU usage in the driver instead of classical RCU. All of them are reproducible
with runtime checkers enabled regarding RCU and sleeps in atomic sections,
either by triggering some heavy traffic for the first one, or raising an access
points for the two others:
- one issue is in wilc_wfi_init_mon_interface (the initial warning raised by
Dan). This one:
- parses the vif list (under RCU) to perform some checks, possibly canceling
the interface registration
- then registers the monitoring interface (has sleeping calls, especially a
register_netdevice call)
- then if registration is successful, updates appropriate vif to flag it as
monitoring interface (then leave RCU section)
I have a hotfix for this, but not a very satisfying one, which consists in
splitting the RCU section into two (first and third points), but additionally
using the vif list lock to make sure vif list has not been altered in-between.
IMHO this kind of fix just make things worse in the driver, just to tame RCU.
- one issue is in wilc_wlan_txq_filter_dup_tcp_ack (the second warning raised
by Dan), which calls wait_for_completion_timeout while being in RCU critical
read. The issue can be properly fixed by just counting the number of packets to
be dropped inside the critical section, then effectively applying the multiple
wait_for_completion_timeout _after_ the RCU section.
- finally, there is an issue in set_channel ops (cfg80211.c), which fetches
the first vif (under RCU), and then uses this vif to send appropriate channel
configuration command (which sleeps at some point). Since used vif here comes
from the vif list, I don't think it is safe to leave earlier RCU section (vif
pointer needs to remain valid until command is sent to chip).
Because of the second point which would bring a not-so-clean fix, and the third
one for which I still don't have a proper fix, I am considering to submit a
revert for my RCU conversion series, to come back to SRCU. I don´t know if those
issues do or do not make SRCU usage more legitimate, but at least I feel like
really fixing it need slightly larger rework. I will still search for better
options, but if I do not find any, I will submit the revert.
Thanks,
Alexis
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
