Linux RDMA and InfiniBand development
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Michael Margolin <mrgolin@amazon.com>
Cc: jgg@nvidia.com, linux-rdma@vger.kernel.org, sleybo@amazon.com,
	matua@amazon.com, gal.pressman@linux.dev,
	Firas Jahjah <firasj@amazon.com>,
	Yonatan Nachum <ynachum@amazon.com>
Subject: Re: [PATCH for-next] RDMA/core: Fix best page size finding when it can cross SG entries
Date: Thu, 13 Feb 2025 14:51:26 +0200	[thread overview]
Message-ID: <20250213125126.GK17863@unreal> (raw)
In-Reply-To: <20250209142608.21230-1-mrgolin@amazon.com>

On Sun, Feb 09, 2025 at 02:26:08PM +0000, Michael Margolin wrote:
> A single scatter-gather entry is limited by a 32 bits "length" field
> that is practically 4GB - PAGE_SIZE. This means that even when the
> memory is physically contiguous, we might need more than one entry to
> represent it. Additionally when using dmabuf, the sg_table might be
> originated outside the subsystem and optimized for other needs.
> 
> For instance an SGT of 16GB GPU continuous memory might look like this:
> (a real life example)
> 
> dma_address 34401400000, length fffff000
> dma_address 345013ff000, length fffff000
> dma_address 346013fe000, length fffff000
> dma_address 347013fd000, length fffff000
> dma_address 348013fc000, length 4000
> 
> Since ib_umem_find_best_pgsz works within SG entries, in the above case
> we will result with the worst possible 4KB page size.
> 
> Fix this by taking into consideration only the alignment of addresses of
> real discontinuity points rather than treating SG entries as such, and
> adjust the page iterator to correctly handle cross SG entry pages.
> 
> There is currently an assumption that drivers do not ask for pages
> bigger than maximal DMA size supported by their devices.
> 
> Reviewed-by: Firas Jahjah <firasj@amazon.com>
> Reviewed-by: Yonatan Nachum <ynachum@amazon.com>
> Signed-off-by: Michael Margolin <mrgolin@amazon.com>
> ---
>  drivers/infiniband/core/umem.c  | 34 +++++++++++++++++++++++----------
>  drivers/infiniband/core/verbs.c | 11 ++++++-----
>  2 files changed, 30 insertions(+), 15 deletions(-)

Applied with the following change to prevent arithmetic overflow.

diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index e7e428369159..63a92d6cfbc2 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -112,8 +112,7 @@ unsigned long ib_umem_find_best_pgsz(struct ib_umem *umem,
                /* If the current entry is physically contiguous with the previous
                 * one, no need to take its start addresses into consideration.
                 */
-               if (curr_base + curr_len != sg_dma_address(sg)) {
-
+               if (curr_base != sg_dma_address(sg) - curr_len) {
                        curr_base = sg_dma_address(sg);
                        curr_len = 0;
 

  reply	other threads:[~2025-02-13 12:51 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-09 14:26 [PATCH for-next] RDMA/core: Fix best page size finding when it can cross SG entries Michael Margolin
2025-02-13 12:51 ` Leon Romanovsky [this message]
2025-02-13 14:04   ` Jason Gunthorpe
2025-02-13 14:30     ` Margolin, Michael
2025-02-13 14:42       ` Jason Gunthorpe
2025-02-13 17:25         ` Margolin, Michael
2025-02-13 17:35         ` Leon Romanovsky
2025-02-13 17:40           ` Jason Gunthorpe
2025-02-13 17:55             ` Leon Romanovsky
2025-02-13 18:12               ` Jason Gunthorpe
2025-02-14  5:55                 ` Leon Romanovsky
2025-02-14 15:33                   ` Jason Gunthorpe
2025-02-16  8:07                 ` Leon Romanovsky
2025-02-17  8:40                   ` Margolin, Michael
2025-02-13 12:53 ` Leon Romanovsky
2025-02-14  6:57   ` Leon Romanovsky

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=20250213125126.GK17863@unreal \
    --to=leon@kernel.org \
    --cc=firasj@amazon.com \
    --cc=gal.pressman@linux.dev \
    --cc=jgg@nvidia.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=matua@amazon.com \
    --cc=mrgolin@amazon.com \
    --cc=sleybo@amazon.com \
    --cc=ynachum@amazon.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