macvlan/macvtap patch in patchwork

macvlan/macvtap patch in patchwork

[David Miller]

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.

Re: macvlan/macvtap patch in patchwork

[Ward, David - 0663 - MITLL]

[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]

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


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.


-- 
David Ward, Associate Staff
Wideband Tactical Networking Group
MIT Lincoln Laboratory
Office: 781-981-4266
Mobile: 781-999-1925
Fax: 781-981-4583



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5650 bytes --]

Re: macvlan/macvtap patch in patchwork

[Ward, David - 0663 - MITLL]

[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]

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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5650 bytes --]

Re: macvlan/macvtap patch in patchwork

[David Miller]

From: "Ward, David - 0663 - MITLL" <david.ward@ll.mit.edu>
Date: Tue, 27 Sep 2011 19:11:00 -0400

> 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.

Thanks for explaining, patch applied.