search for: virtqueue_add_inbuf

...t; + return err; > Should we also roll back the frag offset added above to avoid leaking frags? I believe the put_page here is sufficient for correctness. When we allocate a buffer using skb_page_frag_refill, we use get_page/put_page to allocate/free respectively. For example, if the virtqueue_add_inbuf succeeded, we would eventually call put_page either in virtio-net (e.g., page_to_skb for packets <= GOOD_COPY_LEN bytes) or later in __skb_frag_unref and other functions called during dev_kfree_skb. However, an offset rollback does allow the space to be reused by the next allocation, which coul...

...current buffer. This extra space is not included in > + * ctx->truesize. > + */ What's the reason that this extra space is not accounted for truesize? > len += hole; > alloc_frag->offset += hole; > } > > - sg_init_one(rq->sg, buf, len); > - err = virtqueue_add_inbuf(rq->vq, rq->sg, 1, buf, gfp); > - if (err < 0) > - put_page(virt_to_head_page(buf)); > - > - return err; > + sg_init_one(rq->sg, ctx->buf, len); > + err = virtqueue_add_inbuf(rq->vq, rq->sg, 1, ctx, gfp); > + if (err < 0) { > + put_page(virt_to_head...

...current buffer. This extra space is not included in > + * ctx->truesize. > + */ What's the reason that this extra space is not accounted for truesize? > len += hole; > alloc_frag->offset += hole; > } > > - sg_init_one(rq->sg, buf, len); > - err = virtqueue_add_inbuf(rq->vq, rq->sg, 1, buf, gfp); > - if (err < 0) > - put_page(virt_to_head_page(buf)); > - > - return err; > + sg_init_one(rq->sg, ctx->buf, len); > + err = virtqueue_add_inbuf(rq->vq, rq->sg, 1, ctx, gfp); > + if (err < 0) { > + put_page(virt_to_head...

...urn err; > > Should we also roll back the frag offset added above to avoid leaking frags? > I believe the put_page here is sufficient for correctness. When we > allocate a buffer using skb_page_frag_refill, we use get_page/put_page > to allocate/free respectively. For example, if the virtqueue_add_inbuf > succeeded, we would eventually call put_page either in virtio-net > (e.g., page_to_skb for packets <= GOOD_COPY_LEN bytes) or later in > __skb_frag_unref and other functions called during dev_kfree_skb. > > However, an offset rollback does allow the space to be reused by the ne...

...urn err; > > Should we also roll back the frag offset added above to avoid leaking frags? > I believe the put_page here is sufficient for correctness. When we > allocate a buffer using skb_page_frag_refill, we use get_page/put_page > to allocate/free respectively. For example, if the virtqueue_add_inbuf > succeeded, we would eventually call put_page either in virtio-net > (e.g., page_to_skb for packets <= GOOD_COPY_LEN bytes) or later in > __skb_frag_unref and other functions called during dev_kfree_skb. > > However, an offset rollback does allow the space to be reused by the ne...

From: "Edgar E. Iglesias" <edgar.iglesias at xilinx.com> I'm trying to run rpmsg and remoteproc on the ZynqMP (arm64) but I'm hitting a DMA/mm error. The issue was discussed here: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333050.html Russel King pointed out that the arm64 is not doing anything wrong by returning vmapped memory (which is incompatible

From: "Edgar E. Iglesias" <edgar.iglesias at xilinx.com> I'm trying to run rpmsg and remoteproc on the ZynqMP (arm64) but I'm hitting a DMA/mm error. The issue was discussed here: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333050.html Russel King pointed out that the arm64 is not doing anything wrong by returning vmapped memory (which is incompatible

...9,7 @@ int virtqueue_add_outbuf(struct virtqueue *vq, void *data, gfp_t gfp) { - return virtqueue_add(vq, &sg, num, 1, 0, data, NULL, gfp); + return virtqueue_add(vq, &sg, num, 1, 0, data, NULL, false, gfp); } EXPORT_SYMBOL_GPL(virtqueue_add_outbuf); @@ -2220,7 +2221,7 @@ int virtqueue_add_inbuf(struct virtqueue *vq, void *data, gfp_t gfp) { - return virtqueue_add(vq, &sg, num, 0, 1, data, NULL, gfp); + return virtqueue_add(vq, &sg, num, 0, 1, data, NULL, false, gfp); } EXPORT_SYMBOL_GPL(virtqueue_add_inbuf); @@ -2244,7 +2245,7 @@ int virtqueue_add_inbuf_ctx(struct vir...

Wei Wang wrote: > @@ -164,6 +284,8 @@ static unsigned fill_balloon(struct virtio_balloon *vb, size_t num) > break; > } > > + if (use_sg && xb_set_page(vb, page, &pfn_min, &pfn_max) < 0) Isn't this leaking "page" ? > + break; > balloon_page_push(&pages, page); > } > > @@ -184,8 +307,12 @@ static unsigned

Wei Wang wrote: > @@ -164,6 +284,8 @@ static unsigned fill_balloon(struct virtio_balloon *vb, size_t num) > break; > } > > + if (use_sg && xb_set_page(vb, page, &pfn_min, &pfn_max) < 0) Isn't this leaking "page" ? > + break; > balloon_page_push(&pages, page); > } > > @@ -184,8 +307,12 @@ static unsigned

Add virtqueue_add_sgs which is more general than virtqueue_add_buf, which makes virtio-scsi and virtio-blk nicer, then add virtqueue_add_inbuf and virtqueue_add_outbuf which handle the more general case, and finally delete virtqueue_add_buf(). I'm hoping this will be the final post of the whole series, and it can move from my pending-rebases tree into virtio-next. Thanks! Rusty. Paolo Bonzini (4): scatterlist: introduce sg_unmark...

Add virtqueue_add_sgs which is more general than virtqueue_add_buf, which makes virtio-scsi and virtio-blk nicer, then add virtqueue_add_inbuf and virtqueue_add_outbuf which handle the more general case, and finally delete virtqueue_add_buf(). I'm hoping this will be the final post of the whole series, and it can move from my pending-rebases tree into virtio-next. Thanks! Rusty. Paolo Bonzini (4): scatterlist: introduce sg_unmark...

...ger question as to how much difference that makes in Real Life, of course. I'll measure that today. Here are my two patches, back-to-back (it cam out of of an earlier concern about reducing stack usage, hence the stack measurements). Cheers, Rusty. Subject: virtio_net: pass well-formed sg to virtqueue_add_inbuf() This is the only place which doesn't hand virtqueue_add_inbuf or virtqueue_add_outbuf a well-formed, well-terminated sg. Fix it, so we can make virtio_add_* simpler. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_ne...

...ger question as to how much difference that makes in Real Life, of course. I'll measure that today. Here are my two patches, back-to-back (it cam out of of an earlier concern about reducing stack usage, hence the stack measurements). Cheers, Rusty. Subject: virtio_net: pass well-formed sg to virtqueue_add_inbuf() This is the only place which doesn't hand virtqueue_add_inbuf or virtqueue_add_outbuf a well-formed, well-terminated sg. Fix it, so we can make virtio_add_* simpler. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_ne...

...struct virtqueue *vq, > + struct scatterlist sg[], unsigned int num, > + void *data, > + gfp_t gfp) > +{ > + return virtqueue_add(vq, true, &sg, sg_next_arr, num, 0, 1, 0, data, gfp); > +} > +EXPORT_SYMBOL_GPL(virtqueue_add_outbuf_urgent); > + > +/** > * virtqueue_add_inbuf - expose input buffers to other end > * @vq: the struct virtqueue we're talking about. > * @sgs: array of scatterlists (need not be terminated!) > @@ -382,7 +420,7 @@ int virtqueue_add_inbuf(struct virtqueue *vq, > void *data, > gfp_t gfp) > { > - return virtqu...

...sg received with no recipient\n"); > > /* publish the real size of the buffer */ > - sg_init_one(&sg, msg, RPMSG_BUF_SIZE); > + rpmsg_msg_sg_init(vrp, &sg, msg, RPMSG_BUF_SIZE); > > /* add the buffer back to the remote processor's virtqueue */ > - err = virtqueue_add_inbuf(vrp->rvq, &sg, 1, msg, GFP_KERNEL); > + err = dma_virtqueue_add_inbuf(vrp->rvq, &sg, 1, msg, GFP_KERNEL); > if (err < 0) { > dev_err(dev, "failed to add a virtqueue buffer: %d\n", err); > return err; > @@ -1007,9 +1023,9 @@ static int rpmsg_probe(st...

...sg received with no recipient\n"); > > /* publish the real size of the buffer */ > - sg_init_one(&sg, msg, RPMSG_BUF_SIZE); > + rpmsg_msg_sg_init(vrp, &sg, msg, RPMSG_BUF_SIZE); > > /* add the buffer back to the remote processor's virtqueue */ > - err = virtqueue_add_inbuf(vrp->rvq, &sg, 1, msg, GFP_KERNEL); > + err = dma_virtqueue_add_inbuf(vrp->rvq, &sg, 1, msg, GFP_KERNEL); > if (err < 0) { > dev_err(dev, "failed to add a virtqueue buffer: %d\n", err); > return err; > @@ -1007,9 +1023,9 @@ static int rpmsg_probe(st...

...zeof(*evt)); > + } else if (!(evt->head & VIOMMU_FAULT_RESV_MASK)) { > + viommu_fault_handler(viommu, &evt->fault); > + } > + > + sg_init_one(sg, evt, sizeof(*evt)); in case of above error case, ie. len > sizeof(*evt), is it safe to push evt again? > + ret = virtqueue_add_inbuf(vq, sg, 1, evt, GFP_ATOMIC); > + if (ret) > + dev_err(viommu->dev, "could not add event buffer\n"); > + } > + > + if (!virtqueue_kick(vq)) > + dev_err(viommu->dev, "kick failed\n"); > +} > + > /* IOMMU API */ > > static bool viommu_...

...ed int num, > + void *data, > + gfp_t gfp) > +{ > + return virtqueue_add_premapped(vq, &sg, num, 1, 0, data, NULL, gfp); > +} > +EXPORT_SYMBOL_GPL(virtqueue_add_outbuf_premapped); > + > /** > * virtqueue_add_inbuf - expose input buffers to other end > * @vq: the struct virtqueue we're talking about. > diff --git a/include/linux/virtio.h b/include/linux/virtio.h > index dcab9c7e8784..d8b472a7dcae 100644 > --- a/include/linux/virtio.h > +++ b/include/linux/virtio.h > @@ -43,6 +43,11 @@...

...buffer we give it with sweet, sweet randomness. */ -static void register_buffer(u8 *buf, size_t size) +static void register_buffer(struct virtrng_info *vi, u8 *buf, size_t size) { struct scatterlist sg; sg_init_one(&sg, buf, size); /* There should always be room for one buffer. */ - virtqueue_add_inbuf(vq, &sg, 1, buf, GFP_KERNEL); + virtqueue_add_inbuf(vi->vq, &sg, 1, buf, GFP_KERNEL); - virtqueue_kick(vq); + virtqueue_kick(vi->vq); } static int virtio_read(struct hwrng *rng, void *buf, size_t size, bool wait) { int ret; + struct virtrng_info *vi = (struct virtrng_info *)r...