On Thu, Mar 29, 2018 at 11:02:10AM -0600, Logan Gunthorpe wrote:
> 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 fe
On 3/29/2018 10:02 AM, Logan Gunthorpe wrote:
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 pas
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
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 f
Use the new helpers introduced earlier to allocate the SGLs for
the request.
To do this, we drop the appearantly redundant data_sg and data_sg_cnt
members as they are identical to the existing req.sg and req.sg_cnt.
Signed-off-by: Logan Gunthorpe
Cc: James Smart
Cc: Christoph Hellwig
Cc: Sagi
5 matches
Mail list logo
