Skip to contentSkip to conversation

nvme: fix uninitialized prp2 value on small transfers

PATCH New Jan H. Schönherr 3 participants 4 messages Aug 27, 2017 – Aug 28, 2017 1 message not in the archive NVMe

lore
Share & tools
lore

Jan H. Schönherr

author
#0 lore raw

PATCH 1/1 nvme: fix uninitialized prp2 value on small transfers

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(-)
drivers/nvme/host/pci.c +3 -1
index 925467b..4a41a65 100644
@@ -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) {
Signature · 1 line
2.3.1.dirty
maintainer
#1 lore raw

PATCH 1/1 nvme: fix uninitialized prp2 value on small transfers

Quoted 5 lines · 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.

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?

author
#2 lore raw

PATCH 1/1 nvme: fix uninitialized prp2 value on small transfers

Quoted 5 lines · Christoph Hellwig
Quoted 4 lines · 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.

Quoted 8 lines
Quoted 1 line

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?.

Quoted 2 lines

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

A message that is not in the archive (sent off-list or not yet received): CADL4p-oxDfu0srX90+u9d0HfXLCNpFk2NdcoeaWEmMjRnwHX2w@mail.gmail.com

maintainer
#4 lore raw

PATCH 1/1 nvme: fix uninitialized prp2 value on small transfers

Quoted 7 lines

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,

Quoted 6 lines

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?