nvme_admin_passthru DMA failure

[Patrick Sheridan]

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?

- Patrick

On Sat, Oct 8, 2016 at 1:00 PM, Busch, Keith <keith.busch at intel.com> wrote:
> Is this a vendor specific opcode? If so, what is the opcode value and what direction are you expecting the data transfer to go?
>
>
>> -----Original Message-----
>> From: Linux-nvme [mailto:linux-nvme-bounces at lists.infradead.org] On Behalf Of Patrick Sheridan
>> Sent: Friday, October 7, 2016 3:15 PM
>> To: linux-nvme at lists.infradead.org
>> Subject: nvme_admin_passthru DMA failure
>>
>> There is a problem when using an NVME_IOCTL_ADMIN_CMD to submit an
>> nvme_admin_passthru struct such that user data
>> (nvme_passthru_cmd.addr) does not get DMA'd to the drive correctly.
>>
>> The problem first appeared in kernel tags/v4.5.1 and was absent in
>> tags/v4.5.  The only relevant difference between those was in
>> block/blk-core.c, so this is likely a block layer problem:
>>
>> diff --git a/block/blk-core.c b/block/blk-core.c
>> index b83d297..45f4d7e 100644
>> --- a/block/blk-core.c
>> +++ b/block/blk-core.c
>> @@ -2198,7 +2198,7 @@ int blk_insert_cloned_request(struct
>> request_queue *q, struct request *rq)
>>         if (q->mq_ops) {
>>                 if (blk_queue_io_stat(q))
>>                         blk_account_io_start(rq, true);
>> -               blk_mq_insert_request(rq, false, true, true);
>> +               blk_mq_insert_request(rq, false, true, false);
>>                 return 0;
>>         }