netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zoltan Kiss <zoltan.kiss@citrix.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: <netdev@vger.kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	<kvm@vger.kernel.org>, David Miller <davem@davemloft.net>
Subject: Re: Moving frags and SKBTX_DEV_ZEROCOPY skbs
Date: Wed, 14 May 2014 20:41:53 +0100	[thread overview]
Message-ID: <5373C701.1080301@citrix.com> (raw)
In-Reply-To: <1400077432.7973.85.camel@edumazet-glaptop2.roam.corp.google.com>

On 14/05/14 15:23, Eric Dumazet wrote:
> On Wed, 2014-05-14 at 14:40 +0100, Zoltan Kiss wrote:
>> Hi,
>>
>> Recently I've investigated issues around SKBTX_DEV_ZEROCOPY skbs where
>> the frags list were modified. I came across this function skb_shift(),
>> which moves frags between skbs. And there are a lot more of such kind,
>> skb_split or skb_try_coalesce, for example.
>> It could be a dangerous thing if a frag is referenced from an skb which
>> doesn't have the original destructor_arg, and to avoid that
>> skb_orphan_frags should be called. Although probably these functions are
>> not normally touched in usual usecases, I think it would be useful to
>> review core skb functions proactively and add an skb_orphan_frags
>> everywhere where the frags could be referenced from other places.
>> Any opinion about this?
>
>
> For skb_shift(), it is currently used from tcp stack only, where
> this SKBTX_DEV_ZEROCOPY thing is not used, so I do not think there is a
> bug for the moment.
It is called from tcp_input.c, which suggests it can be called on 
incoming TCP packets. If the backend domain communicates with the 
frontend through sockets, zerocopy packets can turn up here.
But here is the thing: deliver_skb calls orphan_frags for every packet 
delivered to the local stack, so we are safe IF these functions are 
called before the IP stack. So we are safe now, but things can go wrong, if:
- such a frag-mangling function is called before deliver_skb, now or in 
the future
- if someone wants to take advantage of zerocopy in the guest<->backend path

>
> I already gave a patch for skb_try_coalesce() : For this one we do not
> wan skb_orphan_frags() overhead. Its simply better in this case to
> abort.
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 1b62343f5837..85995a14aafc 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -3838,7 +3839,10 @@ bool skb_try_coalesce(struct sk_buff *to, struct sk_buff *from,
>   		return true;
>   	}
>
> -	if (skb_has_frag_list(to) || skb_has_frag_list(from))
> +	if (skb_has_frag_list(to) ||
> +	    skb_has_frag_list(from) ||
> +	    (skb_shinfo(to)->tx_flags & SKBTX_DEV_ZEROCOPY) ||
> +	    (skb_shinfo(from)->tx_flags & SKBTX_DEV_ZEROCOPY))
>   		return false;
>
>   	if (skb_headlen(from) != 0) {
>
>
>

  parent reply	other threads:[~2014-05-14 19:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-14 13:40 Moving frags and SKBTX_DEV_ZEROCOPY skbs Zoltan Kiss
2014-05-14 14:23 ` Eric Dumazet
2014-05-14 17:42   ` David Miller
2014-05-14 17:52     ` Eric Dumazet
2014-05-14 19:41   ` Zoltan Kiss [this message]
2014-05-14 19:52     ` Eric Dumazet
2014-05-15 17:14     ` Zoltan Kiss

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=5373C701.1080301@citrix.com \
    --to=zoltan.kiss@citrix.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=xen-devel@lists.xenproject.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).