On 2021/7/2 15:03, Arnd Bergmann wrote:
On Fri, Jul 2, 2021 at 3:02 AM Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> wrote:
On 2021/6/30 20:20, Arnd Bergmann wrote:
From: Arnd Bergmann <arnd@xxxxxxxx>
Jernej Skrabec reported a problem with the cw1200 driver failing on
arm64 systems with CONFIG_VMAP_STACK=y.
The driver in this case passes a pointer to a stack variable (in vmalloc
space) into the sdio layer, which gets translated into an invalid DMA
address.
Even without CONFIG_VMAP_STACK, the driver is still unreliable, as
cache invalidations on the DMA buffer may cause random data corruption
in adjacent stack slots.
This could be worked around in the SDIO core, but in the discussion we
decided that passing a stack variable into SDIO should always be considered
a bug, as it is for USB drivers.
Change the sdio core to produce a one-time warning for any on-stack
(both with and without CONFIG_VMAP_STACK) as well as any vmalloc
or module-local address that would have the same translation problem.
This was the previous comment about the same topic.
Should we check for mmc_io_rw_direct?
https://www.spinics.net/lists/linux-mmc/msg41794.html
Hi Shawn,
thank you for remembering that previous discussion, that is a
good question. Looking at the code though, I don't actually
see any part of mmc_io_rw_direct() doing DMA on a caller-provided
buffer. The only thing I see in the code is a 'u8 *out' argument, but
that is just a pointer to a single byte that is set by this function.
I didn't quite get the point we need check out for
mmc_io_rw_direct() either. As I thought what Ulf was suggesting was some
controllers might use data fifo to get cmd response and get DMA
involved? But I don't see a explicit one.
Do you see any other issue with that function, or does that mean
we don't have to change it?
Arnd
