[PATCH] nvme: fix uninitialized prp2 value on small transfers

[PATCH] nvme: fix uninitialized prp2 value on small transfers

[Jan H. Schönherr]

The value of iod->first_dma ends up as prp2 in NVMe commands. In case
there is not enough data to cross a page boundary, iod->first_dma is
never initialized and contains random data.

Comply with the NVMe specification and fill in 0 in that case.

Signed-off-by: Jan H. Sch?nherr <jschoenh at amazon.de>
---
 drivers/nvme/host/pci.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 925467b..4a41a65 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -555,8 +555,10 @@ static blk_status_t nvme_setup_prps(struct nvme_dev *dev, struct request *req)
 	int nprps, i;
 
 	length -= (page_size - offset);
-	if (length <= 0)
+	if (length <= 0) {
+		iod->first_dma = 0;
 		return BLK_STS_OK;
+	}
 
 	dma_len -= (page_size - offset);
 	if (dma_len) {
-- 
2.3.1.dirty

[PATCH] nvme: fix uninitialized prp2 value on small transfers

[Christoph Hellwig]

On Sun, Aug 27, 2017@03:56:37PM +0200, Jan H. Sch?nherr wrote:
> The value of iod->first_dma ends up as prp2 in NVMe commands. In case
> there is not enough data to cross a page boundary, iod->first_dma is
> never initialized and contains random data.
> 
> Comply with the NVMe specification and fill in 0 in that case.

Zeroing it out is fine with me, but NVMe 1.3 says:

   PRP Entry 2 (PRP2): This field:
	a) is reserved if the data transfer does not cross a memory page boundary.

so I don't think the specification requires it to be zeroed.
What kind of controller do you have that wants PRP2 zeroed for transfers
that don't cross a page boundary?

[PATCH] nvme: fix uninitialized prp2 value on small transfers

[Jan H. Schönherr]

On 08/27/2017 06:00 PM, Christoph Hellwig wrote:
> On Sun, Aug 27, 2017@03:56:37PM +0200, Jan H. Sch?nherr wrote:
>> The value of iod->first_dma ends up as prp2 in NVMe commands. In case
>> there is not enough data to cross a page boundary, iod->first_dma is
>> never initialized and contains random data.
>>
>> Comply with the NVMe specification and fill in 0 in that case.
>
> Zeroing it out is fine with me, but NVMe 1.3 says:
>
>    PRP Entry 2 (PRP2): This field:
> 	a) is reserved if the data transfer does not cross a memory page boundary.
>
> so I don't think the specification requires it to be zeroed.

And under "1.5 Conventions" it says:

    Hardware shall return ?0? for all bits and registers that are marked as reserved,
    and host software shall write all reserved bits and registers with the value of ?0?.

> What kind of controller do you have that wants PRP2 zeroed for transfers
> that don't cross a page boundary?

This came up while doing some tracing on NVMe commands, and the random values
were a bit odd...

Regards
Jan

[PATCH] nvme: fix uninitialized prp2 value on small transfers

[Sagi Grimberg]

> Dear All:
> 
>       I really need everyone's help, I use the nvme technology, through 
> two infiniband card,shared  the target side of a hard disk to the 
> client, I at the client through nvme connect, through two cards, can 
> identify two devices, respectively Is nvme0 and nvme1,
> 
> now I would like to nvme0n1 and nvme1n1 through multipath technology, 
> the client virtual into a /dev/nvme_share equipment, I want ask how to 
> achieve,
> 
>   because nvme no uuid, there is no scsi id, so I need everyone's Help, 
> thank you

I think that upstream libmultipath does support nvmf, which version are
you running?