netdev - Re: [PATCH vhost v10 03/10] virtio_ring: split: support add premapped buf

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: <CACGkMEsmxax+kOdQA=e4D_xT0WkTPRcooxRHNvsi6xpaV+8ahQ@mail.gmail.com>
Date:   Wed, 28 Jun 2023 12:07:10 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     Xuan Zhuo <xuanzhuo@...ux.alibaba.com>
Cc:     virtualization@...ts.linux-foundation.org,
        "Michael S. Tsirkin" <mst@...hat.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Jesper Dangaard Brouer <hawk@...nel.org>,
        John Fastabend <john.fastabend@...il.com>,
        netdev@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [PATCH vhost v10 03/10] virtio_ring: split: support add premapped buf

On Tue, Jun 27, 2023 at 5:05 PM Xuan Zhuo <xuanzhuo@...ux.alibaba.com> wrote:
>
> On Tue, 27 Jun 2023 16:03:26 +0800, Jason Wang <jasowang@...hat.com> wrote:
> > On Fri, Jun 2, 2023 at 5:22 PM Xuan Zhuo <xuanzhuo@...ux.alibaba.com> wrote:
> > >
> > > If the vq is the premapped mode, use the sg_dma_address() directly.
> > >
> > > Signed-off-by: Xuan Zhuo <xuanzhuo@...ux.alibaba.com>
> > > ---
> > >  drivers/virtio/virtio_ring.c | 46 ++++++++++++++++++++++--------------
> > >  1 file changed, 28 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > > index 2afdfb9e3e30..18212c3e056b 100644
> > > --- a/drivers/virtio/virtio_ring.c
> > > +++ b/drivers/virtio/virtio_ring.c
> > > @@ -598,8 +598,12 @@ static inline int virtqueue_add_split(struct virtqueue *_vq,
> > >                 for (sg = sgs[n]; sg; sg = sg_next(sg)) {
> > >                         dma_addr_t addr;
> > >
> > > -                       if (vring_map_one_sg(vq, sg, DMA_TO_DEVICE, &addr))
> > > -                               goto unmap_release;
> > > +                       if (vq->premapped) {
> > > +                               addr = sg_dma_address(sg);
> > > +                       } else {
> > > +                               if (vring_map_one_sg(vq, sg, DMA_TO_DEVICE, &addr))
> > > +                                       goto unmap_release;
> > > +                       }
> >
> > Btw, I wonder whether or not it would be simple to implement the
> > vq->premapped check inside vring_map_one_sg() assuming the
> > !use_dma_api is done there as well.
>
>
> YES,
>
> That will more simple for the caller.
>
> But we will have things like:
>
> int func(bool do)
> {
> if (!do)
>     return;
> }
>
> I like this way, but you don't like it in last version.

I see :)

So I think it depends on the error handling path, we should choose a
way that can let us easily deal with errors.

For example, it seems the current approach is better since it doesn't
need to change the unmap_release.

Thanks

>
> >
> > >
> > >                         prev = i;
> > >                         /* Note that we trust indirect descriptor
> > > @@ -614,8 +618,12 @@ static inline int virtqueue_add_split(struct virtqueue *_vq,
> > >                 for (sg = sgs[n]; sg; sg = sg_next(sg)) {
> > >                         dma_addr_t addr;
> > >
> > > -                       if (vring_map_one_sg(vq, sg, DMA_FROM_DEVICE, &addr))
> > > -                               goto unmap_release;
> > > +                       if (vq->premapped) {
> > > +                               addr = sg_dma_address(sg);
> > > +                       } else {
> > > +                               if (vring_map_one_sg(vq, sg, DMA_FROM_DEVICE, &addr))
> > > +                                       goto unmap_release;
> > > +                       }
> > >
> > >                         prev = i;
> > >                         /* Note that we trust indirect descriptor
> > > @@ -689,21 +697,23 @@ static inline int virtqueue_add_split(struct virtqueue *_vq,
> > >         return 0;
> > >
> > >  unmap_release:
> > > -       err_idx = i;
> > > +       if (!vq->premapped) {
> >
> > Can vq->premapped be true here? The label is named as "unmap_relase"
> > which implies "map" beforehand which seems not the case for
> > premapping.
>
> I see.
>
> Rethink about this, there is a better way.
> I will fix in next version.
>
>
> Thanks.
>
>
> >
> > Thanks
> >
> >
> > > +               err_idx = i;
> > >
> > > -       if (indirect)
> > > -               i = 0;
> > > -       else
> > > -               i = head;
> > > -
> > > -       for (n = 0; n < total_sg; n++) {
> > > -               if (i == err_idx)
> > > -                       break;
> > > -               if (indirect) {
> > > -                       vring_unmap_one_split_indirect(vq, &desc[i]);
> > > -                       i = virtio16_to_cpu(_vq->vdev, desc[i].next);
> > > -               } else
> > > -                       i = vring_unmap_one_split(vq, i);
> > > +               if (indirect)
> > > +                       i = 0;
> > > +               else
> > > +                       i = head;
> > > +
> > > +               for (n = 0; n < total_sg; n++) {
> > > +                       if (i == err_idx)
> > > +                               break;
> > > +                       if (indirect) {
> > > +                               vring_unmap_one_split_indirect(vq, &desc[i]);
> > > +                               i = virtio16_to_cpu(_vq->vdev, desc[i].next);
> > > +                       } else
> > > +                               i = vring_unmap_one_split(vq, i);
> > > +               }
> > >         }
> > >
> > >         if (indirect)
> > > --
> > > 2.32.0.3.g01195cf9f
> > >
> >
>