linux-kernel - Re: [PATCH rtw v3 3/5] wifi: rtw89: perform tx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250901194743-62fc282f96aeeb9804c34e2f-pchelkin@ispras>
Date: Mon, 1 Sep 2025 20:45:14 +0300
From: Fedor Pchelkin <pchelkin@...ras.ru>
To: Bitterblue Smith <rtl8821cerfe2@...il.com>
Cc: Ping-Ke Shih <pkshih@...ltek.com>, 
	Zong-Zhe Yang <kevin_yang@...ltek.com>, Po-Hao Huang <phhuang@...ltek.com>, 
	linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org, lvc-project@...uxtesting.org
Subject: Re: [PATCH rtw v3 3/5] wifi: rtw89: perform tx_wait completions for
 USB part

On Fri, 29. Aug 22:57, Bitterblue Smith wrote:
> On 29/08/2025 00:11, Fedor Pchelkin wrote:
> > There is no completion signaling for tx_wait skbs on USB part. This means
> > rtw89_core_tx_kick_off_and_wait() always returns with a timeout.
> > 
> > Moreover, recent rework of tx_wait objects lifecycle handling made the
> > driver be responsible for freeing the associated skbs, not the core
> > ieee80211 stack. Lack of completion signaling would cause those objects
> > being kept in driver internal tx_waits queue until rtw89_hci_reset()
> > occurs, and then a double free would happen.
> > 
> > Extract TX status handling into a separate function, like its
> > rtw89_pci_tx_status() counterpart. Signal completion from there.
> > 
> > Found by Linux Verification Center (linuxtesting.org).
> > 
> > Fixes: 2135c28be6a8 ("wifi: rtw89: Add usb.{c,h}")
> > Signed-off-by: Fedor Pchelkin <pchelkin@...ras.ru>
> > ---
> > 
> > New series iteration -> new nuances found.
> > 
> > It seems the two previous patches from the series would not be too great
> > in USB case because there is no completion signaling for tx_wait skbs
> > there.
> > 
> > I don't have this hardware so *the patch is compile tested only*. It'd
> > be nice if someone gave it a run on top of two previous patches of the
> > series, thanks!
> > 
> 
> I tested your first three patches with RTL8851BU for a few hours. It's
> looking good, no explosion yet.

Hello Bitterblue,

thank you!  Just in case, rtw89_core_send_nullfunc() has to be called in
order to trigger all the tx_wait activity touched with the patches, please
make sure it's called during the tests - it should be done after scan
complete, 47a498b84f01 ("wifi: rtw89: TX nulldata 0 after scan complete").

There is one more issue we'd also need to solve: perform tx_wait
completion signaling inside rtw89_usb_ops_reset() (driver shutdown stage
should probably also be handled with the case).  This'd require having an
ability to track TX URBs and kill them.  I'm just throwing these thoughts
now, maybe you have some ideas.  I'm still exploring the USB-part source
code and hopefully will have a chance to get hands on the USB chip soon.

> 
> The USB side doesn't have real TX ACK status reporting yet. I only
> learned recently how to do that. It looks like it will work about the
> same as in rtw88.

Do you mean similar pattern already exists in rtw88?  Could you give a
hint on how USB side TX ACK status reporting works there?  At a quick
glance, I don't see how those TX URB complete callbacks differ from what
rtw89 has.