On Tue, Sep 27, 2011 at 09:44:02AM +0300, Sasha Levin wrote:
> On Mon, 2011-09-26 at 22:55 +0300, Michael S. Tsirkin wrote:
> > On Mon, Sep 26, 2011 at 10:37:22PM +0300, Sasha Levin wrote:
> > > On Mon, 2011-09-26 at 21:44 +0300, Michael S. Tsirkin wrote:
> > > > On Mon, Sep 26, 2011 at 08:41:08PM +0300, Sasha Levin wrote:
> > > > > This patch verifies that the length of a buffer stored in a linked
> > > > > list
> > > > > of pages is small enough to fit into a skb.
> > > > >
> > > > > If the size is larger than a max size of a skb, it means that we
> > > > > shouldn't
> > > > > go ahead building skbs anyway since we won't be able to send the
> > > > > buffer as
> > > > > the user requested.
> > > > >
> > > > > Cc: Rusty Russell <ru...@rustcorp.com.au>
> > > > > Cc: "Michael S. Tsirkin" <m...@redhat.com>
> > > > > Cc: virtualizat...@lists.linux-foundation.org
> > > > > Cc: net...@vger.kernel.org
> > > > > Cc: kvm@vger.kernel.org
> > > > > Signed-off-by: Sasha Levin <levinsasha...@gmail.com>
> > > >
> > > > Interesting. This is a theoretical issue, correct?
> > > > Not a crash you actually see.
> > >
> > > Actually it was an actual crash caused when our virtio-net driver in kvm
> > > tools did funny things and passed '(u32)-1' length as a buffer length to
> > > the guest kernel.
> > >
> > > > This crash would mean device is giving us packets
> > > > that are way too large. Avoiding crashes even in the face of
> > > > a misbehaved device is a good idea, but should
> > > > we print a diagnostic to a system log?
> > > > Maybe rate-limited or print once to avoid filling
> > > > up the disk. Other places in driver print with pr_debug
> > > > I'm not sure that's right but better than nothing.
> > >
> > > Yup, I'll add some debug info.
> > >
> > > > > ---
> > > > > drivers/net/virtio_net.c | 3 +++
> > > > > 1 files changed, 3 insertions(+), 0 deletions(-)
> > > > >
> > > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > > > index 0c7321c..64e0717 100644
> > > > > --- a/drivers/net/virtio_net.c
> > > > > +++ b/drivers/net/virtio_net.c
> > > > > @@ -165,6 +165,9 @@ static struct sk_buff *page_to_skb(struct
> > > > > virtnet_info *vi,
> > > > > unsigned int copy, hdr_len, offset;
> > > > > char *p;
> > > > >
> > > > > + if (len > MAX_SKB_FRAGS * PAGE_SIZE)
> > > >
> > > > unlikely()?
> > > >
> > > > Also, this seems too aggressive: at this point len includes the header
> > > > and the linear part. The right place for this
> > > > test is probably where we fill in the frags, just before
> > > > while (len)
> > > >
> > > > The whole can only happen when mergeable buffers
> > > > are disabled, right?
> > >
> > > >From what I understand it can happen whenever you're going to build a
> > > skb longer than PAGE_SIZE.
> >
> > Hmm how exactly? With mergeable buffers this only gets
> > the length of the 1st chunk which is up to 4K unless the driver
> > is buggy ...
>
> What about the case where TSO or ECN features are set? The code flow
> suggests that mergeable would get ignored in that case:
>
> /* If we can receive ANY GSO packets, we must allocate large ones. */
> if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO4) ||
> virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO6) ||
> virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_ECN))
> vi->big_packets = true;
>
> [...]
>
> if (!vi->mergeable_rx_bufs && !vi->big_packets) {
> skb = buf;
> len -= sizeof(struct virtio_net_hdr);
> skb_trim(skb, len);
> } else {
> page = buf;
> skb = page_to_skb(vi, page, len);
> ...
Sorry I don't get it yet. Where is mergeable ignored here?
> I haven't actually tested it with mergeable buffers enabled, but could
> do it later today.
Please do.
> --
>
> Sasha.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
