Alexis Lothoré <alexis.lothore@xxxxxxxxxxx> writes:
> 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 for the good summary.Maybe it's easier just to revert the commit
immediately so that you don't have to waste more time on this?
Especially if Ajay is missing.
But if would be nice if you could also include a separate patch which
documents in the code why SRCU is needed. Just to avoid duplicate work
later :)
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
