From: Rusty Russell <rusty@rustcorp.com.au>
To: Dave Airlie <airlied@gmail.com>, LKML <linux-kernel@vger.kernel.org>
Cc: virtualization@lists.linux-foundation.org
Subject: Re: BUG_ON in virtio-ring.c
Date: Mon, 27 May 2013 11:12:24 +0930 [thread overview]
Message-ID: <87vc65p5a7.fsf@rustcorp.com.au> (raw)
In-Reply-To: <CAPM=9tyLrJ8VAdGCw_1guRS-ogCPE1Qp7faE_nrx_dAm2gvHLQ@mail.gmail.com>
Dave Airlie <airlied@gmail.com> writes:
> Hi Rusty,
>
> current virtio-ring.c has a BUG_ON in virtqueue_add that checks
> total_sg > vg->vring.num, however I'm not sure it really is 100%
> correct.
>
> If I have an indirect ring and I'm adding sgs to it and the host is
> delayed (say I've got a thread consuming things from the vring and its
> off doing something interesting),
> I'd really like to get ENOSPC back from virtqueue_add. However if the
> indirect addition fails due to free_sg being 0, we hit the BUG_ON
> before we ever get to the ENOSPC check.
It is correct for the moment: drivers can't assume indirect buffer
support in the transport.
BUT for a new device, we could say "this depends on indirect descriptor
support", put the appropriate check in the device init, and then remove
the BUG_ON().
> the BUG_ON is quite valid in the no indirect case, but when we have
> indirect buffers it doesn't seem like it always makes sense.
>
> Not sure best way to fix it, I'm just a virtio newbie :)
Mailing me and the list was the right thing, since this raises question
of the spec as well as the Linux implementation.
Good luck!
Rusty.
WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Dave Airlie <airlied@gmail.com>, LKML <linux-kernel@vger.kernel.org>
Cc: <virtualization@lists.linux-foundation.org>
Subject: Re: BUG_ON in virtio-ring.c
Date: Mon, 27 May 2013 11:12:24 +0930 [thread overview]
Message-ID: <87vc65p5a7.fsf@rustcorp.com.au> (raw)
In-Reply-To: <CAPM=9tyLrJ8VAdGCw_1guRS-ogCPE1Qp7faE_nrx_dAm2gvHLQ@mail.gmail.com>
Dave Airlie <airlied@gmail.com> writes:
> Hi Rusty,
>
> current virtio-ring.c has a BUG_ON in virtqueue_add that checks
> total_sg > vg->vring.num, however I'm not sure it really is 100%
> correct.
>
> If I have an indirect ring and I'm adding sgs to it and the host is
> delayed (say I've got a thread consuming things from the vring and its
> off doing something interesting),
> I'd really like to get ENOSPC back from virtqueue_add. However if the
> indirect addition fails due to free_sg being 0, we hit the BUG_ON
> before we ever get to the ENOSPC check.
It is correct for the moment: drivers can't assume indirect buffer
support in the transport.
BUT for a new device, we could say "this depends on indirect descriptor
support", put the appropriate check in the device init, and then remove
the BUG_ON().
> the BUG_ON is quite valid in the no indirect case, but when we have
> indirect buffers it doesn't seem like it always makes sense.
>
> Not sure best way to fix it, I'm just a virtio newbie :)
Mailing me and the list was the right thing, since this raises question
of the spec as well as the Linux implementation.
Good luck!
Rusty.
next prev parent reply other threads:[~2013-05-27 1:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-24 3:40 BUG_ON in virtio-ring.c Dave Airlie
2013-05-27 1:42 ` Rusty Russell [this message]
2013-05-27 1:42 ` Rusty Russell
2013-05-27 3:29 ` Dave Airlie
2013-05-27 3:29 ` Dave Airlie
2013-05-27 5:38 ` Rusty Russell
2014-10-07 15:46 ` Alexey Lapitsky
2014-10-13 5:39 ` Rusty Russell
2014-11-04 14:44 ` Alexey Lapitsky
2014-12-18 3:13 ` Rusty Russell
2014-12-18 3:13 ` Rusty Russell
2014-10-07 15:46 ` Alexey Lapitsky
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=87vc65p5a7.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=airlied@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=virtualization@lists.linux-foundation.org \
/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.