RE: [PATCH rtw-next] wifi: rtl8xxxu: Allocate the USB control buffer separately

[Ping-Ke Shih <pkshih@realtek.com>]

Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> On 08/11/2026 11:42, Tapparit Rukthawornwong via B4 Relay wrote:
> > From: Tapparit Rukthawornwong <lnwgorou@gmail.com>
> >
> > priv->usb_buf receives the data of every control-IN transfer used for
> > register reads, but it is embedded in struct rtl8xxxu_priv directly
> > after usb_buf_mutex. On CPUs with DMA-incoherent caches the two share a
> > cache line, which Documentation/core-api/dma-api-howto.rst says can
> > corrupt data.
> >
> > This happens in practice. When another task contends for usb_buf_mutex
> > while a read is in flight, the CPU writes to that cache line, and the
> > device's data can be lost when the buffer is unmapped. usb_control_msg()
> > still returns the full length, but the read returns stale buffer
> > contents, typically the value of the previous register write. The driver
> > then writes that value back in a read-modify-write.
> >
> > On an RTL8192EU, a stale read of REG_FPGA0_XA_HSSI_PARM2 (0x824) during a
> > scan is written back, after which the chip stops receiving and does not
> > recover on its own. REG_FPGA0_POWER_SAVE (0x818) also drifts away from
> > its init value without obvious symptoms.
> >
> > Aligning the field inside the struct is not enough: the struct lives in
> > the mac80211 private area, which is only NETDEV_ALIGN (32 byte) aligned.
> > devm_kzalloc() returns ARCH_DMA_MINALIGN aligned memory, so allocate the
> > buffer separately.
> >
> > Tested on a Raspberry Pi 2 (BCM2836, dwc_otg, 32-bit, 6.18.50 with this
> > change backported) with a TP-Link TL-WN823N v2 (RTL8192EU), triggering a
> > scan every 15 seconds:
> >
> >   unpatched:  599 scans, 9 receive hangs with 0x824 corrupted, plus
> >               2 other connection failures with 0x824 intact
> >   patched:   1200 scans, no failures, 0x818 and 0x824 correct at
> >               every check
> >
> > To look at the reads directly, a test build put a sentinel in the buffer
> > before each read and re-read when it came back unchanged. 300 scans per
> > layout:
> >
> >   buffer next to the mutex (current):  72 of 193 contended reads stale,
> >                                        0 of ~260000 uncontended reads
> >   buffer in its own cache line:        0 of 214 contended reads stale
> >   buffer from devm_kzalloc():          0 of 270 contended reads stale
> >
> > The re-read always returned the expected value, so the device answered
> > correctly and only the host-side buffer was stale.
> >
> > Signed-off-by: Tapparit Rukthawornwong <lnwgorou@gmail.com>
> 
> A similar patch was applied just five days ago.

For the record:

https://patch.msgid.link/20261010-rtl8xxxu-usb-dma-v1-1-e670d9c08fdf@khu.ac.kr