Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1615911

Re: [RFC 6/8] nvmet: Be careful about using iomem accesses when dealing with p2pmem

Show all headers | View raw

>  u16 nvmet_copy_to_sgl(struct nvmet_req *req, off_t off, const void *buf,
>  		size_t len)
>  {
> -	if (sg_pcopy_from_buffer(req->sg, req->sg_cnt, buf, len, off) != len)
> +	bool iomem = req->p2pmem;
> +	size_t ret;
> +
> +	ret = sg_copy_buffer(req->sg, req->sg_cnt, (void *)buf, len, off,
> +			     false, iomem);
> +
> +	if (ret != len)
>  		return NVME_SC_SGL_INVALID_DATA | NVME_SC_DNR;
> +
>  	return 0;
>  }

We can never ever get here from an IO command, and that is a good thing
because it would have been broken if we did, regardless of what copy
method we use...

Note that the nvme completion queues are still on the host memory, so
this means we have lost the ordering between data and completions as
they go to different pcie targets.

If at all, this is the place to *emphasize* we must never get here
with p2pmem, and immediately fail if we do.

I'm not sure what will happen with to copy_from_sgl, I guess we
have the same race because the nvme submission queues are also
on the host memory (which is on a different pci target). Maybe
more likely to happen with write-combine enabled?

Anyway I don't think we have a real issue here *currently*, because
we use copy_to_sgl only for admin/fabrics commands emulation and
copy_from_sgl to setup dsm ranges...

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[RFC 6/8] nvmet: Be careful about using iomem accesses when dealing with p2pmem Logan Gunthorpe <logang@deltatee.com> - 2017-03-31 00:20 +0200
  Re: [RFC 6/8] nvmet: Be careful about using iomem accesses when  dealing with p2pmem Sagi Grimberg <sagi@grimberg.me> - 2017-04-04 13:10 +0200
    Re: [RFC 6/8] nvmet: Be careful about using iomem accesses when  dealing with p2pmem Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-04-04 17:50 +0200
      Re: [RFC 6/8] nvmet: Be careful about using iomem accesses when  dealing with p2pmem Logan Gunthorpe <logang@deltatee.com> - 2017-04-04 19:30 +0200
      Re: [RFC 6/8] nvmet: Be careful about using iomem accesses when  dealing with p2pmem Sagi Grimberg <sagi@grimberg.me> - 2017-04-06 07:40 +0200
        Re: [RFC 6/8] nvmet: Be careful about using iomem accesses when  dealing with p2pmem Logan Gunthorpe <logang@deltatee.com> - 2017-04-06 18:10 +0200
        Re: [RFC 6/8] nvmet: Be careful about using iomem accesses when  dealing with p2pmem Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-04-06 18:40 +0200
        Re: [RFC 6/8] nvmet: Be careful about using iomem accesses when  dealing with p2pmem "Stephen  Bates" <sbates@raithlin.com> - 2017-04-07 13:30 +0200
          Re: [RFC 6/8] nvmet: Be careful about using iomem accesses when  dealing with p2pmem Sagi Grimberg <sagi@grimberg.me> - 2017-04-10 10:40 +0200

csiph-web