Linux-NVME Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: logang@deltatee.com (Logan Gunthorpe)
Subject: [PATCH 4/4] nvmet-fc: Use new SGL alloc/free helper for requests
Date: Thu, 29 Mar 2018 11:02:10 -0600	[thread overview]
Message-ID: <bd62c2e6-558c-e314-177f-c95cf842c741@deltatee.com> (raw)
In-Reply-To: <15f4d135-7600-02b3-f50f-ed8deddd7b98@broadcom.com>



On 29/03/18 10:52 AM, James Smart wrote:
> overall - I'm a little concerned about the replacement.
> 
> I know the code depends on the null/zero checks in 
> nvmet_fc_free_tgt_pgs() as there are paths that can call them twice.? 
> Your replacement in that routine is fine, but you've fully removed any 
> initialization to zero or setting to zero on free. Given the structure 
> containing the req structure is reused, I'd rather that that code was 
> left in some way... or that nvmet_req_free_sgl() or 
> nvmet_fc_free_tgt_pgs() was updated to set req->sg to null and (not sure 
> necessary if req->sg is null) set req->sg_cnt to 0.

Ok, I can ensure we zero and NULL those in nvmet_req_free_sgl().

> also - sg_cnt isn't referenced as there is an assumption that: transfer 
> length meant there would be (transfer length / PAGESIZE + 1 if partial 
> page) pages allocated and sg_cnt would always equal that page cnt? thus 
> the fcpreq->sgXXX setting behavior in nvmet_fc_transfer_fcp_data().?? Is 
> that no longer valid ??? I may not have watched closely enough when the 
> sgl_alloc() common routine was introduced as it may have invalidated 
> these assumptions that were true before.

Per the bug in the previous patch, I don't think that was ever a valid
assumption. It doesn't have anything to do with the sgl_alloc change
either. The dma_map interface is allowed to merge SGLs and that's why it
can return fewer nents than it was passed. I'm not sure how many or
which DMA ops actually do this which is why it hasn't actually
manifested itself as a bug; but it is part of how the interface is
specified to work.

I think we need to store the sg_map_cnt separately and use it instead of
the calculation based on the transfer length. But this is really a fix
that should be rolled in with the previous patch. If you can point me to
where this needs to change I can update my patch, or if you want to fix
it yourself go ahead.

Thanks,

Logan

  reply	other threads:[~2018-03-29 17:02 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-29 16:07 [PATCH 0/4] SGL alloc and free helper functions for requests Logan Gunthorpe
2018-03-29 16:07 ` [PATCH 1/4] nvmet: Introduce helper functions to allocate and free request SGLs Logan Gunthorpe
2018-03-29 16:07 ` [PATCH 2/4] nvmet-rdma: Use new SGL alloc/free helper for requests Logan Gunthorpe
2018-04-04 12:43   ` Sagi Grimberg
2018-04-04 16:47     ` Logan Gunthorpe
2018-03-29 16:07 ` [PATCH 3/4] nvmet-fc: Don't use the count returned by the dma_map_sg call Logan Gunthorpe
2018-03-29 16:14   ` Bart Van Assche
2018-03-29 16:15     ` Logan Gunthorpe
2018-03-29 16:38     ` Logan Gunthorpe
2018-03-29 16:24   ` James Smart
2018-03-29 16:30     ` Logan Gunthorpe
2018-03-29 16:34       ` James Smart
2018-04-04 12:45   ` Sagi Grimberg
2018-03-29 16:07 ` [PATCH 4/4] nvmet-fc: Use new SGL alloc/free helper for requests Logan Gunthorpe
2018-03-29 16:52   ` James Smart
2018-03-29 17:02     ` Logan Gunthorpe [this message]
2018-03-29 17:39       ` James Smart
2018-03-29 18:15       ` Christoph Hellwig

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=bd62c2e6-558c-e314-177f-c95cf842c741@deltatee.com \
    --to=logang@deltatee.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