lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=hENdzYGNp14fm9y9+A71D2BJSjV5GewHMkSJKUzNOs0hqWg@mail.gmail.com>
Date:   Thu, 30 Sep 2021 14:37:14 +0800
From:   Zhu Yanjun <zyjzyj2000@...il.com>
To:     Shunsuke Mie <mie@...l.co.jp>
Cc:     Christian König <christian.koenig@....com>,
        Alex Deucher <alexander.deucher@....com>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Doug Ledford <dledford@...hat.com>,
        Jason Gunthorpe <jgg@...pe.ca>,
        Jianxin Xiong <jianxin.xiong@...el.com>,
        Leon Romanovsky <leon@...nel.org>,
        Maor Gottlieb <maorg@...dia.com>,
        Sean Hefty <sean.hefty@...el.com>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org,
        linux-media@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        RDMA mailing list <linux-rdma@...r.kernel.org>,
        dhobsong@...l.co.jp, taki@...l.co.jp, etom@...l.co.jp
Subject: Re: [RFC PATCH v2 1/1] Providers/rxe: Add dma-buf support

On Thu, Sep 30, 2021 at 2:20 PM Shunsuke Mie <mie@...l.co.jp> wrote:
>
> Implement a new provider method for dma-buf base memory registration.
>
> Signed-off-by: Shunsuke Mie <mie@...l.co.jp>
> ---
>  providers/rxe/rxe.c | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
>
> diff --git a/providers/rxe/rxe.c b/providers/rxe/rxe.c
> index 3c3ea8bb..84e00e60 100644
> --- a/providers/rxe/rxe.c
> +++ b/providers/rxe/rxe.c
> @@ -239,6 +239,26 @@ static struct ibv_mr *rxe_reg_mr(struct ibv_pd *pd, void *addr, size_t length,
>         return &vmr->ibv_mr;
>  }
>
> +static struct ibv_mr *rxe_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t offset,
> +                                       size_t length, uint64_t iova, int fd,
> +                                       int access)
> +{
> +       struct verbs_mr *vmr;
> +       int ret;
> +
> +       vmr = malloc(sizeof(*vmr));
> +       if (!vmr)
> +               return NULL;
> +

Do we need to set vmr to zero like the following?

memset(vmr, 0, sizeof(*vmr));

Zhu Yanjun

> +       ret = ibv_cmd_reg_dmabuf_mr(pd, offset, length, iova, fd, access, vmr);
> +       if (ret) {
> +               free(vmr);
> +               return NULL;
> +       }
> +
> +       return &vmr->ibv_mr;
> +}
> +
>  static int rxe_dereg_mr(struct verbs_mr *vmr)
>  {
>         int ret;
> @@ -1706,6 +1726,7 @@ static const struct verbs_context_ops rxe_ctx_ops = {
>         .alloc_pd = rxe_alloc_pd,
>         .dealloc_pd = rxe_dealloc_pd,
>         .reg_mr = rxe_reg_mr,
> +       .reg_dmabuf_mr = rxe_reg_dmabuf_mr,
>         .dereg_mr = rxe_dereg_mr,
>         .alloc_mw = rxe_alloc_mw,
>         .dealloc_mw = rxe_dealloc_mw,
> --
> 2.17.1
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ