All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Li, Zhijian" <lizhijian@cn.fujitsu.com>
To: Jason Gunthorpe <jgg@nvidia.com>,
	"lizhijian@fujitsu.com" <lizhijian@fujitsu.com>
Cc: "yangx.jy@fujitsu.com" <yangx.jy@fujitsu.com>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"tom@talpey.com" <tom@talpey.com>,
	"yanjun.zhu@linux.dev" <yanjun.zhu@linux.dev>,
	"rpearsonhpe@gmail.com" <rpearsonhpe@gmail.com>,
	"y-goto@fujitsu.com" <y-goto@fujitsu.com>,
	"tomasz.gromadzki@intel.com" <tomasz.gromadzki@intel.com>
Subject: Re: [RFC PATCH v2 2/2] RDMA/rxe: Support RDMA Atomic Write operation
Date: Thu, 20 Jan 2022 20:07:36 +0800	[thread overview]
Message-ID: <022be340-a49a-1e94-5fb8-1c77f06fecc2@cn.fujitsu.com> (raw)
In-Reply-To: <20220119123635.GH84788@nvidia.com>

Hi Jason


on 2022/1/19 20:36, Jason Gunthorpe wrote:
> On Wed, Jan 19, 2022 at 01:54:32AM +0000, lizhijian@fujitsu.com wrote:
>>
>> On 18/01/2022 20:35, Jason Gunthorpe wrote:
>>> On Tue, Jan 18, 2022 at 08:01:59AM +0000, yangx.jy@fujitsu.com wrote:
>>>> On 2022/1/17 21:16, Jason Gunthorpe wrote:
>>>>> On Thu, Jan 13, 2022 at 11:03:50AM +0800, Xiao Yang wrote:
>>>>>> +static enum resp_states process_atomic_write(struct rxe_qp *qp,
>>>>>> +					     struct rxe_pkt_info *pkt)
>>>>>> +{
>>>>>> +	struct rxe_mr *mr = qp->resp.mr;
>>>>>> +
>>>>>> +	u64 *src = payload_addr(pkt);
>>>>>> +
>>>>>> +	u64 *dst = iova_to_vaddr(mr, qp->resp.va + qp->resp.offset, sizeof(u64));
>>>>>> +	if (!dst || (uintptr_t)dst&  7)
>>>>>> +		return RESPST_ERR_MISALIGNED_ATOMIC;
>>>>> It looks to me like iova_to_vaddr is completely broken, where is the
>>>>> kmap on that flow?
>>>> Hi Jason,
>>>>
>>>> I think rxe_mr_init_user() maps the user addr space to the kernel addr
>>>> space during memory region registration, the mapping records are saved
>>>> into mr->cur_map_set->map[x].
>>> There is no way to touch user memory from the CPU in the kernel
>> That's absolutely right, but I don't think it references that user memory directly.
>>
>>> without calling one of the kmap's, so I don't know what this thinks it
>>> is doing.
>>>
>>> Jason
>> IMHO, for the rxe, rxe_mr_init_user() will call get_user_page() to pin iova first, and then
>> the page address will be recorded into mr->cur_map_set->map[x]. So that when we want
>> to reference iova's kernel address, we can call iova_to_vaddr() where it will retrieve its kernel
>> address by travel the mr->cur_map_set->map[x].
> That flow needs a kmap

IIUC, this was a existing issue in iova_to_vaddr() right ?
Alternatively, can we have below changes to fix it simply?

diff --git a/drivers/infiniband/sw/rxe/rxe_mr.c 
b/drivers/infiniband/sw/rxe/rxe_mr.c
index 0621d387ccba..978fdd23665c 100644
--- a/drivers/infiniband/sw/rxe/rxe_mr.c
+++ b/drivers/infiniband/sw/rxe/rxe_mr.c
@@ -260,7 +260,8 @@ int rxe_mr_init_user(struct rxe_pd *pd, u64 start, 
u64 length, u64 iova,
                                 num_buf = 0;
                         }

-                       vaddr = page_address(sg_page_iter_page(&sg_iter));
+                       // FIXME: don't forget to kunmap_local(vaddr)
+                       vaddr = 
kmap_local_page(sg_page_iter_page(&sg_iter));
                         if (!vaddr) {
                                 pr_warn("%s: Unable to get virtual 
address\n",
                                                 __func__);



>
>> Do you mean we should retrieve iova's page first, and the reference the kernel address by
>> kmap(), sorry for my stupid question ?
> Going from struct page to something the kernel can can touch requires
> kmap

Got it

Thanks

Zhijian


>
> Jason



  parent reply	other threads:[~2022-01-20 12:07 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-13  3:03 [RFC PATCH v2 0/2] RDMA/rxe: Add RDMA Atomic Write operation Xiao Yang
2022-01-13  3:03 ` [RFC PATCH v2 1/2] RDMA/rxe: Rename send_atomic_ack() and atomic member of struct resp_res Xiao Yang
2022-01-13  3:03 ` [RFC PATCH v2 2/2] RDMA/rxe: Support RDMA Atomic Write operation Xiao Yang
2022-01-13 11:35   ` kernel test robot
2022-01-13 12:16   ` kernel test robot
2022-01-13 12:16     ` kernel test robot
2022-01-17 13:16   ` Jason Gunthorpe
2022-01-18  8:01     ` yangx.jy
2022-01-18 12:35       ` Jason Gunthorpe
2022-01-19  1:54         ` lizhijian
2022-01-19 12:36           ` Jason Gunthorpe
2022-01-19 16:47             ` Ira Weiny
2022-01-20 12:07             ` Li, Zhijian [this message]
2022-01-21 12:58               ` Jason Gunthorpe
2022-01-21 16:06                 ` Ira Weiny
2022-01-21 16:08                   ` Ira Weiny
2022-01-24  3:47                     ` lizhijian
2022-01-27  9:37                   ` yangx.jy
2022-01-27  9:57                     ` hch
2022-01-27 18:08                       ` Ira Weiny
2022-01-28  6:16                         ` hch
2022-01-28 19:15                           ` Ira Weiny
2022-02-10 11:06                             ` yangx.jy
2022-02-11 18:30                               ` Ira Weiny
2022-01-18  8:02     ` yangx.jy
2022-01-18  8:04     ` yangx.jy
2022-01-18  9:03       ` yangx.jy

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=022be340-a49a-1e94-5fb8-1c77f06fecc2@cn.fujitsu.com \
    --to=lizhijian@cn.fujitsu.com \
    --cc=jgg@nvidia.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=lizhijian@fujitsu.com \
    --cc=rpearsonhpe@gmail.com \
    --cc=tom@talpey.com \
    --cc=tomasz.gromadzki@intel.com \
    --cc=y-goto@fujitsu.com \
    --cc=yangx.jy@fujitsu.com \
    --cc=yanjun.zhu@linux.dev \
    /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.