On 18/01/2022 20:35, Jason Gunthorpe wrote:
> On Tue, Jan 18, 2022 at 08:01:59AM +0000, yangx.jy@xxxxxxxxxxx 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].
Currently RDMA WRITE, RDMA ATOMIC and etc use the same scheme to reference to iova.
Feel free to correct me if i missed something :)
Do you mean we should retrieve iova's page first, and the reference the kernel address by
kmap(), sorry for my stupid question ?
Thanks
Zhijian
