Message-ID: <20250919133124-ffdfc2386e03e9d646af8d93-pchelkin@ispras>
Date: Fri, 19 Sep 2025 14:00:06 +0300
From: Fedor Pchelkin <pchelkin@...ras.ru>
To: Ping-Ke Shih <pkshih@...ltek.com>
Cc: Zong-Zhe Yang <kevin_yang@...ltek.com>, 
	Bitterblue Smith <rtl8821cerfe2@...il.com>, Bernie Huang <phhuang@...ltek.com>, 
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"lvc-project@...uxtesting.org" <lvc-project@...uxtesting.org>
Subject: Re: [PATCH rtw v4 4/4] wifi: rtw89: avoid circular locking
 dependency in ser_state_run()

On Fri, 19. Sep 00:46, Ping-Ke Shih wrote:
> Fedor Pchelkin <pchelkin@...ras.ru> wrote:
> > On Thu, 18. Sep 05:52, Ping-Ke Shih wrote:
> > > Fedor Pchelkin <pchelkin@...ras.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/

Powered by blists - more mailing lists