Linux-NVME Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: keith.busch@intel.com (Keith Busch)
Subject: nvme_admin_passthru DMA failure
Date: Mon, 10 Oct 2016 11:29:10 -0400	[thread overview]
Message-ID: <20161010152910.GB8524@localhost.localdomain> (raw)
In-Reply-To: <CAEhN9jtpkEGOOo88hDADkhuL09OgGTUgSDsqsqxGOG7+XDfMCA@mail.gmail.com>

On Mon, Oct 10, 2016@08:58:36AM -0600, Patrick Sheridan wrote:
> Hi Keith,
> 
> It is a vendor specific command with opcode 0xC0 and is expected to
> copy data from the host to the drive.
> I think you hit the nail on the head:  nvme_is_write would indicate
> that it's a read.
> Out of curiosity, do you know why this worked in previous nvme drivers?

Before 4.1, the nvme driver mapped user pages and setup the prp
directly. It didn't care about the alignment.

Now we use blk_rq_map_user, and this uses a bounce buffer if your user
buffer is not aligned. If the data direction is wrong, the data will be
copied to/from the bounce buffer in the wrong direction.

I think you probably will want to adjust your vendor specific opcode.
The driver's ioctl doesn't have a data transfer field, so it always used
the opcode to determine which direction to DMA map a buffer. A C0 is a
command with no data transfer according to the spec. I know the spec
explicitly defines this direction only for defined commands rather
than vendor specific ones, but I don't think that was the intention
(potential for an ECN here).

If you have to stick with the current opcode, you should be able to
work-around the bounce buffer if you allocate your buffers on pages,
but that's conditional on your architecture not enforcing read/write
DMA direction.

      reply	other threads:[~2016-10-10 15:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-07 21:15 nvme_admin_passthru DMA failure Patrick Sheridan
2016-10-08 19:00 ` Busch, Keith
2016-10-10 14:58   ` Patrick Sheridan
2016-10-10 15:29     ` Keith Busch [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=20161010152910.GB8524@localhost.localdomain \
    --to=keith.busch@intel.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