On Wed, Mar 23, 2022 at 12:19 AM Oleksandr Natalenko
<oleksandr@xxxxxxxxxxxxxx> wrote:
The following upstream commits:
aa6f8dcbab47 swiotlb: rework "fix info leak with DMA_FROM_DEVICE"
ddbd89deb7d3 swiotlb: fix info leak with DMA_FROM_DEVICE
break ath9k-based Wi-Fi access point for me. The AP emits beacons, but
no client can connect to it, either from the very beginning, or
shortly after start. These are the only symptoms I've noticed (i.e.,
no BUG/WARNING messages in `dmesg` etc).
Funky, but clearly true:
These commits appeared in v5.17 and v5.16.15, and both kernels are
broken for me. I'm pretty confident these commits make the difference
since I've built both v5.17 and v5.16.15 without them, and it fixed
the issue.
Can you double-check (or just explicitly confirm if you already did
that test) that you need to revert *both* of those commits, and it's
the later "rework" fix that triggers it?
So, I do understand this might be an issue with regard to SG I/O
handling in ath9k, hence relevant people in Cc.
Yeah, almost certainly an ath9k bug, but a regression is a regression,
so if people can't find the issue in ath9k, we'll have to revert those
commits.
Honestly, I personally think they were a bit draconian to begin with,
and didn't limit their effects sufficiently.
I'm assuming that the ath9k issue is that it gives DMA mapping a big
enough area to handle any possible packet size, and just expects -
quite reasonably - smaller packets to only fill the part they need.
Which that "info leak" patch obviously breaks entirely.