Dave Airlie <airl...@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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/