linux-stable.git/drivers/net/macvlan.c, branch linux-3.10.y

macvlan: Initialize vlan_features to turn on offload support.

2014-08-14T01:24:15+00:00

[ Upstream commit 081e83a78db9b0ae1f5eabc2dedecc865f509b98 ]

Macvlan devices do not initialize vlan_features.  As a result,
any vlan devices configured on top of macvlans perform very poorly.
Initialize vlan_features based on the vlan features of the lower-level
device.

Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: force a list_del() in unregister_netdevice_many()

2014-06-26T19:12:38+00:00

[ Upstream commit 87757a917b0b3c0787e0563c679762152be81312 ]

unregister_netdevice_many() API is error prone and we had too
many bugs because of dangling LIST_HEAD on stacks.

See commit f87e6f47933e3e ("net: dont leave active on stack LIST_HEAD")

In fact, instead of making sure no caller leaves an active list_head,
just force a list_del() in the callee. No one seems to need to access
the list after unregister_netdevice_many()

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

macvlan: Don't propagate IFF_ALLMULTI changes on down interfaces.

2014-05-31T04:52:16+00:00

[ Upstream commit bbeb0eadcf9fe74fb2b9b1a6fea82cd538b1e556 ]

Clearing the IFF_ALLMULTI flag on a down interface could cause an allmulti
overflow on the underlying interface.

Attempting the set IFF_ALLMULTI on the underlying interface would cause an
error and the log message:

"allmulti touches root, set allmulti failed."

Signed-off-by: Peter Christensen 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Revert "macvlan : fix checksums error when we are in bridge mode"

2014-05-31T04:52:16+00:00

[ Upstream commit f114890cdf84d753f6b41cd0cc44ba51d16313da ]

This reverts commit 12a2856b604476c27d85a5f9a57ae1661fc46019.
The commit above doesn't appear to be necessary any more as the
checksums appear to be correctly computed/validated.

Additionally the above commit breaks kvm configurations where
one VM is using a device that support checksum offload (virtio) and
the other VM does not.
In this case, packets leaving virtio device will have CHECKSUM_PARTIAL
set.  The packets is forwarded to a macvtap that has offload features
turned off.  Since we use CHECKSUM_UNNECESSARY, the host does does not
update the checksum and thus a bad checksum is passed up to
the guest.

CC: Daniel Lezcano 
CC: Patrick McHardy 
CC: Andrian Nord 
CC: Eric Dumazet 
CC: Michael S. Tsirkin 
CC: Jason Wang 
Signed-off-by: Vlad Yasevich 
Acked-by: Michael S. Tsirkin 
Acked-by: Jason Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

macvlan: validate flags

2013-09-14T13:54:54+00:00

[ Upstream commit 1512747820367c8b3b8b72035f0f78c62f2bf1e9 ]

commit df8ef8f3aaa6692970a436204c4429210addb23a
    macvlan: add FDB bridge ops and macvlan flags
added a flags field to macvlan, which can be
controlled from userspace.
The idea is to make the interface future-proof
so we can add flags and not new fields.

However, flags value isn't validated, as a result,
userspace can't detect which flags are supported.

Signed-off-by: Michael S. Tsirkin 
Cc: "David S. Miller" 
Cc: John Fastabend 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

macvlan: don't touch promisc without passthrough

2013-06-13T08:20:33+00:00

commit df8ef8f3aaa6692970a436204c4429210addb23a
"macvlan: add FDB bridge ops and macvlan flags"
added a way to control NOPROMISC macvlan flag through netlink.

However, with a non passthrough device we never set promisc on open,
even if NOPROMISC is off.  As a result:

If userspace clears NOPROMISC on open, then does not clear it on a
netlink command, promisc counter is not decremented on stop and there
will be no way to clear it once macvlan is detached.

If userspace does not clear NOPROMISC on open, then sets NOPROMISC on a
netlink command, promisc counter will be decremented from 0 and overflow
to fffffffff with no way to clear promisc.

To fix, simply ignore NOPROMISC flag in a netlink command for
non-passthrough devices, same as we do at open/close.

Since we touch this code anyway - check dev_set_promiscuity return code
and pass it to users (though an error here is unlikely).

Cc: "David S. Miller" 
Reviewed-by: John Fastabend 
Signed-off-by: Michael S. Tsirkin 
Signed-off-by: David S. Miller

macvlan: fix passthru mode race between dev removal and rx path

2013-05-11T23:25:00+00:00

Currently, if macvlan in passthru mode is created and data are rxed and
you remove this device, following panic happens:

NULL pointer dereference at 0000000000000198
IP: [] macvlan_handle_frame+0x153/0x1f7 [macvlan]

I'm using following script to trigger this:


I run this script while "ping -f" is running on another machine to send
packets to e1 rx.

Reason of the panic is that list_first_entry() is blindly called in
macvlan_handle_frame() even if the list was empty. vlan is set to
incorrect pointer which leads to the crash.

I'm fixing this by protecting port->vlans list by rcu and by preventing
from getting incorrect pointer in case the list is empty.

Introduced by: commit eb06acdc85585f2 "macvlan: Introduce 'passthru' mode to takeover the underlying device"

Signed-off-by: Jiri Pirko 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller

net: vlan: announce STAG offload capability in some drivers

2013-04-19T18:46:06+00:00

- macvlan: propagate STAG filtering capabilities from underlying device
- ifb: announce STAG tagging support in addition to CTAG tagging support
- veth: announce STAG tagging/stripping support in addition to CTAG support

Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller

net: vlan: prepare for 802.1ad VLAN filtering offload

2013-04-19T18:45:27+00:00

Change the rx_{add,kill}_vid callbacks to take a protocol argument in
preparation of 802.1ad support. The protocol argument used so far is
always htons(ETH_P_8021Q).

Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller

net: vlan: rename NETIF_F_HW_VLAN_* feature flags to NETIF_F_HW_VLAN_CTAG_*

2013-04-19T18:45:26+00:00

Rename the hardware VLAN acceleration features to include "CTAG" to indicate
that they only support CTAGs. Follow up patches will introduce 802.1ad
server provider tagging (STAGs) and require the distinction for hardware not
supporting acclerating both.

Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller