[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101220111141.GC7977@ff.dom.local>
Date: Mon, 20 Dec 2010 11:11:41 +0000
From: Jarek Poplawski <jarkao2@...il.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Changli Gao <xiaosuo@...il.com>,
Paweł Staszewski <pstaszewski@...are.pl>,
"David S. Miller" <davem@...emloft.net>,
Linux Network Development list <netdev@...r.kernel.org>
Subject: Re: Kernel panic eth2 mirred redirect to ifb0
On Mon, Dec 20, 2010 at 11:41:11AM +0100, Eric Dumazet wrote:
> Le lundi 20 décembre 2010 ?? 10:32 +0000, Jarek Poplawski a écrit :
> > On Mon, Dec 20, 2010 at 10:21:25AM +0100, Eric Dumazet wrote:
> > > Le lundi 20 décembre 2010 ?? 17:11 +0800, Changli Gao a écrit :
> > > > Yes, you are right. I just wonder where shared skbs are allowed. Is
> > > > there any rule?
> > > >
> > >
> > > Shared skbs are allowed for sure (pktgen is a provider of such skbs).
> >
> > But pktgen doesn't use common dev_queue_xmit() path. It looks like
> > some places checking segmentation call pskb_expand_head() assuming skb
> > isn't shared. Btw, it seems ifb should have GSO features similarly to
> > loopback. Anyway, until all this is verified, IMHO we should revert
> > Changli's mirred patch in stable.
> >
>
> I thought Changli question was : is a skb given to a device
> ndo_start_xmit() handler is allowed to be shared ;)
>
> I believe Changli patch should be reverted, because not doing a
> skb_clone() should be known by caller.
>
> To avoid the skb_clone(), we must tell caller what we did, so that
> caller dont even try to reuse skb (even freeing it)
To tell the truth, Changli could assume we don't need to tell anything,
because this mirred skb is almost not shared (except the refcount ;-).
Jarek P.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists