All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sagi Grimberg <sagig-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
To: Bart Van Assche
	<bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>,
	Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	Sebastian Parschauer
	<sebastian.riemer-EIkl63zCoXaH+58JC4qpiA@public.gmane.org>,
	"linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 5/6] IB core: Fix ib_sg_to_pages()
Date: Wed, 2 Dec 2015 11:31:36 +0200	[thread overview]
Message-ID: <565EBA78.3050201@dev.mellanox.co.il> (raw)
In-Reply-To: <565DF0A5.6040102-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>



On 01/12/2015 21:10, Bart Van Assche wrote:
> On 12/01/2015 10:32 AM, Sagi Grimberg wrote:
>>> Fix the code for detecting gaps and disable the code for chunking.
>>> A gap occurs not only if the second or later scatterlist element
>>> is not aligned but also if any scatterlist element other than the
>>> last does not end at a page boundary. Disable the code for chunking.
>>
>> So can you explain what went wrong with the code? If ib_sg_to_pages()
>> supports chunking, then sg elements are allowed not to end at a page
>> boundary if it is physically contig to the next sg and then the next
>> is chunked. Care to explain how did ib_sg_to_pages mess up?
>
> With the upstream implementation, if the previous element ends at a page
> boundary (last_end_dma_addr == dma_addr) but the current element does
> not start at a page boundary (page_addr != dma_addr) then the current
> element is mapped. I think this is wrong because this condition
> indicates a gap and hence that ib_sg_to_pages() should stop iterating in
> this case.

Why is (last_end_dma_addr == dma_addr) implying that the previous
element ends at a page boundary? it tests if the current is contig
to the prev (dma_addr is not necessarily the page address).

But I think I see whats wrong. If the prev sg didn't end aligned to
page we won't get into the above test at all and continue mapping.

Does this make the problem go away?
diff --git a/drivers/infiniband/core/verbs.c 
b/drivers/infiniband/core/verbs.c
index 043a60e..23457fe 100644
--- a/drivers/infiniband/core/verbs.c
+++ b/drivers/infiniband/core/verbs.c
@@ -1544,7 +1544,7 @@ int ib_sg_to_pages(struct ib_mr *mr,
                 u64 end_dma_addr = dma_addr + dma_len;
                 u64 page_addr = dma_addr & page_mask;

-               if (i && page_addr != dma_addr) {
+               if (i && (page_addr != dma_addr || last_page_off)) {
                         if (last_end_dma_addr != dma_addr) {
                                 /* gap */
                                 goto done;
--

Note that I don't mind making the chunking code go away if no one wants
it (I think Steve specifically asked for it). I'm just trying to
understand the exact mistake here.

> How ib_sg_to_pages() reports to its caller that mapping the first
> scatterlist element failed is not important to me. I included that
> change in this patch because I noticed that in the upstream SRP
> initiator does not consider ib_map_mr_sg() returning zero as an error. I
> think either ib_sg_to_pages() or ib_map_mr_sg() should be modified such
> that "no pages have been mapped" is handled as a mapping failure.

I don't either, but the patch introduces inconsistency in a case where
the caller passed sg_nents=0 (which will return 0 and not -errno).

Would it make better sense to have srp treat 0 return as error? note
that all other ULPs treat return_val != sg_nents as error.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2015-12-02  9:31 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-01 18:16 [PATCH 0/6] SRP initiator related bug fixes Bart Van Assche
     [not found] ` <565DE3EC.2070002-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2015-12-01 18:17   ` [PATCH 1/6] IB/srp: Fix a memory leak Bart Van Assche
2015-12-01 18:18   ` [PATCH 2/6] IB/srp: Fix possible send queue overflow Bart Van Assche
     [not found]     ` <565DE45B.7060100-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2015-12-02 12:34       ` Christoph Hellwig
2015-12-01 18:18   ` [PATCH 3/6] IB/srp: Initialize dma_length in srp_map_idb Bart Van Assche
     [not found]     ` <565DE476.3080308-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2015-12-01 18:35       ` Sagi Grimberg
2015-12-01 18:18   ` [PATCH 4/6] IB/srp: Fix indirect data buffer rkey endianness Bart Van Assche
     [not found]     ` <565DE487.2010803-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2015-12-01 18:37       ` Sagi Grimberg
     [not found]         ` <565DE8F7.5060100-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2015-12-01 18:46           ` Bart Van Assche
     [not found]             ` <565DEB13.6040508-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2015-12-02  9:32               ` Sagi Grimberg
2015-12-02 12:35       ` Christoph Hellwig
2015-12-01 18:19   ` [PATCH 5/6] IB core: Fix ib_sg_to_pages() Bart Van Assche
     [not found]     ` <565DE49D.4020102-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2015-12-01 18:32       ` Sagi Grimberg
     [not found]         ` <565DE7D0.4080408-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2015-12-01 19:10           ` Bart Van Assche
     [not found]             ` <565DF0A5.6040102-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2015-12-02  9:31               ` Sagi Grimberg [this message]
     [not found]                 ` <565EBA78.3050201-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2015-12-03  2:22                   ` Bart Van Assche
     [not found]                     ` <565FA75E.7010100-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2015-12-03  9:07                       ` Sagi Grimberg
2015-12-03  9:18                       ` Christoph Hellwig
     [not found]                         ` <20151203091806.GB21893-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2015-12-04  0:04                           ` Bart Van Assche
     [not found]                             ` <5660D881.7020801-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2015-12-06 10:37                               ` Sagi Grimberg
2015-12-06 14:02                               ` Christoph Hellwig
2015-12-01 18:19   ` [PATCH 6/6] IB/srp: Fix srp_map_sg_fr() Bart Van Assche
     [not found]     ` <565DE4BA.1040703-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2015-12-01 18:35       ` Sagi Grimberg
     [not found]         ` <565DE864.5050407-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2015-12-01 18:39           ` Bart Van Assche
     [not found]             ` <565DE977.2070606-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2015-12-02 11:59               ` Sagi Grimberg
     [not found]                 ` <565EDD2A.6050407-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2015-12-02 12:41                   ` Christoph Hellwig
     [not found]                     ` <20151202124154.GF28278-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2015-12-02 12:50                       ` Sagi Grimberg
     [not found]                         ` <565EE90D.8060303-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2015-12-03  8:46                           ` Sagi Grimberg
     [not found]                             ` <56600152.5050401-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2015-12-03  9:11                               ` Christoph Hellwig
2015-12-04 23:08   ` [PATCH 0/6] SRP initiator related bug fixes Bart Van Assche
     [not found]     ` <56621CDF.3070604-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2015-12-05 11:17       ` Christoph Hellwig
     [not found]         ` <20151205111715.GA31393-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2015-12-07 17:15           ` Bart Van Assche
2015-12-07 19:26   ` Bart Van Assche
     [not found]     ` <5665DD50.5090906-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2015-12-07 21:07       ` Doug Ledford
     [not found]         ` <5665F502.5020305-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-12-07 22:07           ` Bart Van Assche

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=565EBA78.3050201@dev.mellanox.co.il \
    --to=sagig-ldsdmyg8hgv8yrgs2mwiifqbs+8scbdb@public.gmane.org \
    --cc=bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org \
    --cc=dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=sebastian.riemer-EIkl63zCoXaH+58JC4qpiA@public.gmane.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.