All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: Arnd Bergmann <arnd@kernel.org>, Shawn Lin <shawn.lin@rock-chips.com>
Cc: Jernej Skrabec <jernej.skrabec@gmail.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mmc: warn for invalid SDIO data buffers【请注意,邮件由linux-mmc-owner@vger.kernel.org代发】
Date: Fri, 2 Jul 2021 10:19:13 +0200	[thread overview]
Message-ID: <CAPDyKFrbQxyYUpFXfg2t071uN0JcCo74QsJ5Fx-VCkND-KKjPQ@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a3UjLfKpsg2M-RP3AO3CVCnZrbD71uaLf0+iiJ9RJsHCQ@mail.gmail.com>

On Fri, 2 Jul 2021 at 09:03, Arnd Bergmann <arnd@kernel.org> wrote:
>
> On Fri, Jul 2, 2021 at 3:02 AM Shawn Lin <shawn.lin@rock-chips.com> wrote:
> > On 2021/6/30 20:20, Arnd Bergmann wrote:
> > > From: Arnd Bergmann <arnd@arndb.de>
> > >
> > > 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.
>
> Do you see any other issue with that function, or does that mean
> we don't have to change it?

I was wrong when I earlier said that we needed to care about
mmc_io_rw_direct(). mmc_io_rw_direct() transfer "data" over the CMD
line. MMC host drivers can't do DMA on that.

I think the $subject patch looks reasonable to me.

Kind regards
Uffe

      parent reply	other threads:[~2021-07-02  8:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-30 12:20 [PATCH] mmc: warn for invalid SDIO data buffers Arnd Bergmann
2021-06-30 23:02 ` kernel test robot
2021-06-30 23:02   ` kernel test robot
2021-07-01  9:06   ` Arnd Bergmann
2021-07-01  9:06     ` Arnd Bergmann
2021-07-02  1:02 ` [PATCH] mmc: warn for invalid SDIO data buffers【请注意,邮件由linux-mmc-owner@vger.kernel.org代发】 Shawn Lin
2021-07-02  7:03   ` Arnd Bergmann
2021-07-02  8:15     ` Shawn Lin
2021-07-02  8:19     ` Ulf Hansson [this message]

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=CAPDyKFrbQxyYUpFXfg2t071uN0JcCo74QsJ5Fx-VCkND-KKjPQ@mail.gmail.com \
    --to=ulf.hansson@linaro.org \
    --cc=adrian.hunter@intel.com \
    --cc=arnd@kernel.org \
    --cc=jernej.skrabec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=shawn.lin@rock-chips.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.