Subject: Re: [PATCH v3 1/2] vhost-net: fix handle_rx buffer size

From: "Michael S. Tsirkin" <[email-masked]>
Date: Thu, 3 May 2012 15:39:20 +0300

On Wed, Apr 25, 2012 at 10:30:10PM -0700, Eric W. Biederman wrote:
> Basil Gor <[email-masked]> writes:
> 
> > Take vlan header length into account, when vlan id is stored as
> > vlan_tci. Otherwise tagged packets comming from macvtap will be
> > truncated.
> 
> Better.
> 
> In recvmsg you are still missing handling of PACKET_AUXDATA
> that includes aux.tp_vlan_tci === vlan_id and
> aux.tp_status === TP_STATUS_VLAN_VALID.
> 
> That is the way pf_packet sockets report the vlan.  Not
> in the actual packet itself.
> 
> Eric

And vhost can't handle this without userspace changes,
because put_cmsg expects a userspace pointer.

So maybe, until someone says they care about this bug,
for now it's enough to check
	msg->msg_flags & MSG_CTRUNC
and error out in vhost.

Either this, or add a flag to put_cmsg that will
cause it to do memcpy instead of copy to user.

> > Signed-off-by: Basil Gor <[email-masked]>
> > ---
> >  drivers/vhost/net.c |    7 ++++++-
> >  1 files changed, 6 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> > index 1f21d2a..5c17010 100644
> > --- a/drivers/vhost/net.c
> > +++ b/drivers/vhost/net.c
> > @@ -24,6 +24,7 @@
> >  #include <linux/if_arp.h>
> >  #include <linux/if_tun.h>
> >  #include <linux/if_macvlan.h>
> > +#include <linux/if_vlan.h>
> >  
> >  #include <net/sock.h>
> >  
> > @@ -283,8 +284,12 @@ static int peek_head_len(struct sock *sk)
> >  
> >  	spin_lock_irqsave(&sk->sk_receive_queue.lock, flags);
> >  	head = skb_peek(&sk->sk_receive_queue);
> > -	if (likely(head))
> > +	if (likely(head)) {
> >  		len = head->len;
> > +		if (vlan_tx_tag_present(head))
> > +			len += VLAN_HLEN;
> > +	}
> > +
> >  	spin_unlock_irqrestore(&sk->sk_receive_queue.lock, flags);
> >  	return len;
> >  }
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [email-masked]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html