[lvc-project] [PATCH rtw v4 4/4] wifi: rtw89: avoid circular locking dependency in ser_state_run()

Fedor Pchelkin pchelkin at ispras.ru
Fri Sep 19 14:00:06 MSK 2025


On Fri, 19. Sep 00:46, Ping-Ke Shih wrote:
> Fedor Pchelkin <pchelkin at ispras.ru> wrote:
> > On Thu, 18. Sep 05:52, Ping-Ke Shih wrote:
> > > Fedor Pchelkin <pchelkin at ispras.ru> wrote:
> > > By the way, you mark this patchset as 'rtw'. Does it mean this patchset is
> > > urgent to you? If not, it will be more smooth (avoid possible merge conflict)
> > > if it goes via 'rtw-next'. Let me know your preference.
> > 
> > The first patch of the series is rather urgent compared to the others
> > because it addresses the issue occasionally banging on a working system.
> > The other ones are less urgent.
> > 
> > TBH I'm not aware of your development process in details.  It's v6.17-rc6
> > at the moment.  If I target all patches at rtw-next, are they to land in
> > upcoming merge window for v6.18 release (a couple of weeks from now)?
> > If yes then no hurries from me, rtw-next is ok.
> 
> It's v6.17-rc6 (-rc eve), so I don't plan to send a pull-request.
> 
> Originally I plan to send the last pull-request to v6.18 today, so I did
> review this patchset yesterday to see if I can merge it before sending. 
> Since only two or three minor changes are needed, I can wait a while and
> send the pull-request next Monday if you can re-spin the patchset this
> weekend. 
> 
> If not, I can still merge this patchset in v6.18-rc cycle to rtw tree.
> However, this might cause merge conflict with -next, so I don't prefer
> this. Upper maintainers need to spend extra time to resolve conflicts.

One thing that I forgot to mention is about rtw89 USB part.

"BUG: KFENCE: use-after-free write in rtw89_core_tx_kick_off_and_wait"
which is fixed by the first patch of the current series is reproduced
reliably with USB HCI because there is no TX completion there yet, i.e.
rtw89_core_tx_kick_off_and_wait() always exits with a timeout and touches
skb parts which are most probably already freed by the call to
ieee80211_tx_status_irqsafe() from URB completion callback.  I've got
a dongle now and confirm the bug.  Turns out it was reported here [1] by
Bitterblue Smith as well.

[1]: https://lore.kernel.org/linux-wireless/1e5e97d4-8267-4f77-a4bf-1fe23ea40f77@gmail.com/

The first patch does avoid use-after-free bug for USB, too.  But, as
there is no TX ACK completion implemented for USB yet, tx_wait_list will
be piled up with wasted items which can't be freed due to the lack of
completion.  It's better than crash but still a problem.

Bitterblue suggested [2] implementing the missing TX completion parts for
USB to fix this entirely.  I've got a bunch of patches for it which will
send as a separate USB-series today or tomorrow.  I expect it'll require
time for review and it probably should have to be improved/reworked in
several places.  Anyway I'll send it soon so you've got a more complete
picture and some time until Monday to decide how to handle it.

[2]: https://lore.kernel.org/linux-wireless/0cb4d19b-94c7-450e-ac56-8b0d4a1d889f@gmail.com/



More information about the lvc-project mailing list