From: David Laight <David.Laight@ACULAB.COM>
To: 'Michael Walle' <michael@walle.cc>,
Ajay Singh <ajay.kathat@microchip.com>,
Claudiu Beznea <claudiu.beznea@microchip.com>
Cc: Kalle Valo <kvalo@kernel.org>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Michael Walle <mwalle@kernel.org>
Subject: RE: [PATCH] wilc1000: fix DMA on stack objects
Date: Fri, 29 Jul 2022 09:51:12 +0000 [thread overview]
Message-ID: <0ed9ec85a55941fd93773825fe9d374c@AcuMS.aculab.com> (raw)
In-Reply-To: <20220728152037.386543-1-michael@walle.cc>
From: Michael Walle
> Sent: 28 July 2022 16:21
>
> From: Michael Walle <mwalle@kernel.org>
>
> Sometimes wilc_sdio_cmd53() is called with addresses pointing to an
> object on the stack. E.g. wilc_sdio_write_reg() will call it with an
> address pointing to one of its arguments. Detect whether the buffer
> address is not DMA-able in which case a bounce buffer is used. The bounce
> buffer itself is protected from parallel accesses by sdio_claim_host().
>
> Fixes: 5625f965d764 ("wilc1000: move wilc driver out of staging")
> Signed-off-by: Michael Walle <mwalle@kernel.org>
> ---
> The bug itself probably goes back way more, but I don't know if it makes
> any sense to use an older commit for the Fixes tag. If so, please suggest
> one.
>
> The bug leads to an actual error on an imx8mn SoC with 1GiB of RAM. But the
> error will also be catched by CONFIG_DEBUG_VIRTUAL:
> [ 9.817512] virt_to_phys used for non-linear address: (____ptrval____) (0xffff80000a94bc9c)
>
> .../net/wireless/microchip/wilc1000/sdio.c | 28 ++++++++++++++++---
> 1 file changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/microchip/wilc1000/sdio.c
> b/drivers/net/wireless/microchip/wilc1000/sdio.c
> index 7962c11cfe84..e988bede880c 100644
> --- a/drivers/net/wireless/microchip/wilc1000/sdio.c
> +++ b/drivers/net/wireless/microchip/wilc1000/sdio.c
> @@ -27,6 +27,7 @@ struct wilc_sdio {
> bool irq_gpio;
> u32 block_size;
> int has_thrpt_enh3;
> + u8 *dma_buffer;
> };
>
> struct sdio_cmd52 {
> @@ -89,6 +90,9 @@ static int wilc_sdio_cmd52(struct wilc *wilc, struct sdio_cmd52 *cmd)
> static int wilc_sdio_cmd53(struct wilc *wilc, struct sdio_cmd53 *cmd)
> {
> struct sdio_func *func = container_of(wilc->dev, struct sdio_func, dev);
> + struct wilc_sdio *sdio_priv = wilc->bus_data;
> + bool need_bounce_buf = false;
> + u8 *buf = cmd->buffer;
> int size, ret;
>
> sdio_claim_host(func);
> @@ -100,12 +104,20 @@ static int wilc_sdio_cmd53(struct wilc *wilc, struct sdio_cmd53 *cmd)
> else
> size = cmd->count;
>
> + if ((!virt_addr_valid(buf) || object_is_on_stack(buf)) &&
How cheap are the above tests?
It might just be worth always doing the 'bounce'?
> + !WARN_ON_ONCE(size > WILC_SDIO_BLOCK_SIZE)) {
That WARN() ought to be an error return?
Or just assume that large buffers will dma-capable?
David
> + need_bounce_buf = true;
> + buf = sdio_priv->dma_buffer;
> + }
> +
> if (cmd->read_write) { /* write */
> - ret = sdio_memcpy_toio(func, cmd->address,
> - (void *)cmd->buffer, size);
> + if (need_bounce_buf)
> + memcpy(buf, cmd->buffer, size);
> + ret = sdio_memcpy_toio(func, cmd->address, buf, size);
> } else { /* read */
> - ret = sdio_memcpy_fromio(func, (void *)cmd->buffer,
> - cmd->address, size);
> + ret = sdio_memcpy_fromio(func, buf, cmd->address, size);
> + if (need_bounce_buf)
> + memcpy(cmd->buffer, buf, size);
> }
>
> sdio_release_host(func);
> @@ -127,6 +139,12 @@ static int wilc_sdio_probe(struct sdio_func *func,
> if (!sdio_priv)
> return -ENOMEM;
>
> + sdio_priv->dma_buffer = kzalloc(WILC_SDIO_BLOCK_SIZE, GFP_KERNEL);
> + if (!sdio_priv->dma_buffer) {
> + ret = -ENOMEM;
> + goto free;
> + }
> +
> ret = wilc_cfg80211_init(&wilc, &func->dev, WILC_HIF_SDIO,
> &wilc_hif_sdio);
> if (ret)
> @@ -160,6 +178,7 @@ static int wilc_sdio_probe(struct sdio_func *func,
> irq_dispose_mapping(wilc->dev_irq_num);
> wilc_netdev_cleanup(wilc);
> free:
> + kfree(sdio_priv->dma_buffer);
> kfree(sdio_priv);
> return ret;
> }
> @@ -171,6 +190,7 @@ static void wilc_sdio_remove(struct sdio_func *func)
>
> clk_disable_unprepare(wilc->rtc_clk);
> wilc_netdev_cleanup(wilc);
> + kfree(sdio_priv->dma_buffer);
> kfree(sdio_priv);
> }
>
> --
> 2.30.2
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2022-07-29 9:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-28 15:20 [PATCH] wilc1000: fix DMA on stack objects Michael Walle
2022-07-29 9:51 ` David Laight [this message]
2022-07-29 14:58 ` Michael Walle
2022-07-29 15:39 ` Ajay.Kathat
2022-08-04 7:22 ` Michael Walle
2022-08-04 12:43 ` Ajay.Kathat
2022-08-04 12:56 ` Michael Walle
2022-08-04 13:22 ` Ajay.Kathat
2022-07-31 11:46 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0ed9ec85a55941fd93773825fe9d374c@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=ajay.kathat@microchip.com \
--cc=claudiu.beznea@microchip.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=kvalo@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=michael@walle.cc \
--cc=mwalle@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox