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 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.