From: Sagi Grimberg <sagi-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
To: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
Bart Van Assche
<bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>,
Yishai Hadas
<yishaih-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
Cc: Yishai Hadas <yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
linux-rdma <linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Or Gerlitz <ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
Joonsoo Kim <iamjoonsoo.kim-Hm3cg6mZ9cc@public.gmane.org>,
Haggai Eran <haggaie-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
Majd Dibbiny <majd-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Subject: Re: RDMA Read: Local protection error
Date: Thu, 26 May 2016 20:19:33 +0300 [thread overview]
Message-ID: <57473025.5020801@grimberg.me> (raw)
In-Reply-To: <574728EC.9040802-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
>>>>> When debugging is disabled, kzalloc returns page-aligned
>>>>> addresses:
>>>>
>>>> Is it defined some where that regular kzalloc/kmalloc guaranties to
>>>> return a page-aligned address as you see in your testing ? if so the
>>>> debug mode should behave the same. Otherwise we can consider using any
>>>> flag allocation that can force that if such exists.
>>>> Let's get other people's input here.
>>>
>>> My understanding is that the fact that k[mz]alloc() returns a
>>> page-aligned buffer if the allocation size is > PAGE_SIZE / 2 is a
>>> side effect of the implementation and not something callers of that
>>> function should rely on. I think the only assumption k[mz]alloc()
>>> callers should rely on is that the allocated memory respects
>>> ARCH_KMALLOC_MINALIGN.
>>
>> I agree. mlx4_alloc_priv_pages() is carefully designed to
>> correct the alignment of the buffer, so it already assumes
>> that it is not getting a page-aligned buffer.
>>
>> The alignment isn't the problem here, though. It's that
>> the buffer contains a page-boundary. That is guaranteed
>> to be the case for HCAs that support more than 512
>> sges, so that will have to be addressed (at least in
>> mlx5).
>
> rrr...
>
> I think we should make the pages allocations dma coherent
> in order to fix that...
>
> Nice catch Chunk.
Does this untested patch help (if so, mlx5 will need an identical patch)?
--
diff --git a/drivers/infiniband/hw/mlx4/mlx4_ib.h
b/drivers/infiniband/hw/mlx4/mlx4_ib.h
index ba328177eae9..78e9b3addfea 100644
--- a/drivers/infiniband/hw/mlx4/mlx4_ib.h
+++ b/drivers/infiniband/hw/mlx4/mlx4_ib.h
@@ -139,7 +139,6 @@ struct mlx4_ib_mr {
u32 max_pages;
struct mlx4_mr mmr;
struct ib_umem *umem;
- void *pages_alloc;
};
struct mlx4_ib_mw {
diff --git a/drivers/infiniband/hw/mlx4/mr.c
b/drivers/infiniband/hw/mlx4/mr.c
index b04f6238e7e2..becb4a65c755 100644
--- a/drivers/infiniband/hw/mlx4/mr.c
+++ b/drivers/infiniband/hw/mlx4/mr.c
@@ -278,30 +278,13 @@ mlx4_alloc_priv_pages(struct ib_device *device,
int max_pages)
{
int size = max_pages * sizeof(u64);
- int add_size;
- int ret;
-
- add_size = max_t(int, MLX4_MR_PAGES_ALIGN -
ARCH_KMALLOC_MINALIGN, 0);
- mr->pages_alloc = kzalloc(size + add_size, GFP_KERNEL);
- if (!mr->pages_alloc)
+ mr->pages = dma_alloc_coherent(device->dma_device, size,
+ &mr->page_map, GFP_KERNEL);
+ if (!mr->pages)
return -ENOMEM;
- mr->pages = PTR_ALIGN(mr->pages_alloc, MLX4_MR_PAGES_ALIGN);
-
- mr->page_map = dma_map_single(device->dma_device, mr->pages,
- size, DMA_TO_DEVICE);
-
- if (dma_mapping_error(device->dma_device, mr->page_map)) {
- ret = -ENOMEM;
- goto err;
- }
-
return 0;
-err:
- kfree(mr->pages_alloc);
-
- return ret;
}
static void
@@ -311,9 +294,8 @@ mlx4_free_priv_pages(struct mlx4_ib_mr *mr)
struct ib_device *device = mr->ibmr.device;
int size = mr->max_pages * sizeof(u64);
- dma_unmap_single(device->dma_device, mr->page_map,
- size, DMA_TO_DEVICE);
- kfree(mr->pages_alloc);
+ dma_free_coherent(device->dma_device, size,
+ mr->pages, mr->page_map);
mr->pages = NULL;
}
}
@@ -532,19 +514,8 @@ int mlx4_ib_map_mr_sg(struct ib_mr *ibmr, struct
scatterlist *sg, int sg_nents,
unsigned int sg_offset)
{
struct mlx4_ib_mr *mr = to_mmr(ibmr);
- int rc;
mr->npages = 0;
- ib_dma_sync_single_for_cpu(ibmr->device, mr->page_map,
- sizeof(u64) * mr->max_pages,
- DMA_TO_DEVICE);
-
- rc = ib_sg_to_pages(ibmr, sg, sg_nents, sg_offset, mlx4_set_page);
-
- ib_dma_sync_single_for_device(ibmr->device, mr->page_map,
- sizeof(u64) * mr->max_pages,
- DMA_TO_DEVICE);
-
- return rc;
+ return ib_sg_to_pages(ibmr, sg, sg_nents, sg_offset, mlx4_set_page);
}
--
--
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
next prev parent reply other threads:[~2016-05-26 17:19 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-29 16:24 RDMA Read: Local protection error Chuck Lever
[not found] ` <1A4F4C32-CE5A-44D9-9BFE-0E1F8D5DF44D-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2016-04-29 16:44 ` Santosh Shilimkar
[not found] ` <3fb4e75f-ff14-34e2-b6d3-6b6046812845-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2016-04-29 16:58 ` Chuck Lever
[not found] ` <72E8335B-282B-4DCC-AE4F-FE7E50ED5A08-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2016-04-29 19:07 ` Santosh Shilimkar
2016-04-29 16:45 ` Bart Van Assche
[not found] ` <57238F8C.70505-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2016-04-29 17:02 ` Chuck Lever
2016-04-29 17:34 ` Laurence Oberman
2016-05-02 15:10 ` Chuck Lever
[not found] ` <B72A389F-FFF1-498C-A946-8AA72B7769F8-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2016-05-02 16:08 ` Bart Van Assche
[not found] ` <57277B63.8030506-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2016-05-03 14:57 ` Chuck Lever
[not found] ` <6BBFD126-877C-4638-BB91-ABF715E29326-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2016-05-04 1:07 ` Joonsoo Kim
2016-05-04 19:59 ` Chuck Lever
[not found] ` <F6C79393-6174-49B3-ADBB-E40627DEE85D-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2016-05-09 1:03 ` Joonsoo Kim
[not found] ` <CAAmzW4NbY3Og0BgQyeA4LLXTnMuPTjxVUdFbH+HLahBw+MAhsw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-05-09 1:15 ` Chuck Lever
[not found] ` <1A79DEDE-A5C3-4581-A0AE-7C0AB056B4C7-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2016-05-09 2:11 ` Joonsoo Kim
2016-05-25 15:58 ` Chuck Lever
[not found] ` <1AFD636B-09FC-4736-B1C5-D1D9FA0B97B0-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2016-05-26 16:24 ` Yishai Hadas
[not found] ` <8a3276bf-f716-3dca-9d54-369fc3bdcc39-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2016-05-26 16:30 ` Bart Van Assche
[not found] ` <aaa67d51-663a-0aba-fc54-a5ab5d947a55-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2016-05-26 16:34 ` Chuck Lever
[not found] ` <C0AE237D-5E5A-4F94-B717-F3A3B4B4D4A8-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2016-05-26 16:48 ` Sagi Grimberg
[not found] ` <574728EC.9040802-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2016-05-26 17:19 ` Sagi Grimberg [this message]
[not found] ` <57473025.5020801-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2016-05-26 17:57 ` Chuck Lever
2016-05-26 19:23 ` Leon Romanovsky
[not found] ` <20160526192351.GV25500-2ukJVAZIZ/Y@public.gmane.org>
2016-05-26 20:12 ` Christoph Lameter
[not found] ` <alpine.DEB.2.20.1605261511230.8857-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
2016-05-29 7:02 ` Sagi Grimberg
[not found] ` <574A941D.9050404-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2016-05-29 7:17 ` Christoph Hellwig
[not found] ` <20160529071749.GB24347-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2016-05-29 8:13 ` Sagi Grimberg
[not found] ` <574AA4BE.2060207-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2016-05-29 8:15 ` Christoph Hellwig
[not found] ` <20160529081527.GA5839-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2016-05-29 8:37 ` Sagi Grimberg
2016-05-31 15:14 ` Christoph Lameter
2016-05-29 7:10 ` Christoph Hellwig
[not found] ` <20160529071040.GA24347-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2016-05-29 8:56 ` Leon Romanovsky
2016-05-26 20:10 ` Christoph Lameter
2016-05-26 16:39 ` 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=57473025.5020801@grimberg.me \
--to=sagi-nqwnxtmzq1alnmji0ikvqw@public.gmane.org \
--cc=bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org \
--cc=chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
--cc=haggaie-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org \
--cc=iamjoonsoo.kim-Hm3cg6mZ9cc@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=majd-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org \
--cc=ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org \
--cc=yishaih-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org \
--cc=yishaih-VPRAkNaXOzVWk0Htik3J/w@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox