[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E825804.2010603@ll.mit.edu>
Date: Tue, 27 Sep 2011 19:11:00 -0400
From: "Ward, David - 0663 - MITLL" <david.ward@...mit.edu>
To: David Miller <davem@...emloft.net>
CC: "kaber@...sh.net" <kaber@...sh.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"herbert@...dor.hengli.com.au" <herbert@...dor.hengli.com.au>,
"krkumar2@...ibm.com" <krkumar2@...ibm.com>
Subject: Re: macvlan/macvtap patch in patchwork
On 27/09/11 15:14, David Miller wrote:
> Could you guys please review:
>
> http://patchwork.ozlabs.org/patch/115273/
>
> My gut instinct is that the current behavior is intentional, but since
> the patch submitter didn't describe exactly what the undesirable
> behavior is it's hard to tell what the patch is actually fixing.
>
> Thanks.
Sorry if my commit message was not descriptive enough -- I can revise it
if you would like.
The macvlan and macvtap drivers both call macvlan_queue_xmit when
sending outgoing frames. In the case of unicast frames between
macvlan/macvtap devices, we first forward the frame to the lowerdev, so
that its network taps can see it.
The problem is that I was forwarding the frame to the lowerdev the wrong
way, by calling vlan->forward which serves a different purpose.
vlan->forward points to dev_forward_skb for macvlan (so the forwarding
works fine), but it points to macvtap_forward for macvtap (which causes
an oops when called here). We need to always use dev_forward_skb to
forward to a lowerdev.
David
Download attachment "smime.p7s" of type "application/pkcs7-signature" (5650 bytes)
Powered by blists - more mailing lists