user/sven/linux.git/drivers/net/macvlan.c, branch v3.18.48

macvlan: fix a race on port dismantle and possible skb leaks

2014-10-25T20:24:02Z

We need to cancel the work queue after rcu grace period, otherwise it can be rescheduled by incoming packets. We need to purge queue if some skbs are still in it. We can use __skb_queue_head_init() variant in macvlan_process_broadcast() Signed-off-by: Eric Dumazet Fixes: 412ca1550cbec ("macvlan: Move broadcasts into a work queue") Cc: Herbert Xu Signed-off-by: David S. Miller

macvlan: optimize the receive path

2014-10-10T19:09:47Z

The netif_rx() call on the fast path of macvlan_handle_frame() appears to be there to ensure that we properly throttle incoming packets. However, it would appear as though the proper throttling is already in place for all possible ingress paths, and that the call is redundant. If packets are arriving from the physical NIC, we've already throttled them by this point. Otherwise, if they are coming via macvlan_queue_xmit(), it calls either 'dev_forward_skb()', which ends up calling netif_rx_internal(), or else in the broadcast case, we are throttling via macvlan_broadcast_enqueue(). The test results below are from off the box to an lxc instance running macvlan. Once the tranactions/sec stop increasing, the cpu idle time has gone to 0. Results are from a quad core Intel E3-1270 V2@3.50GHz box with bnx2x 10G card. for i in {10,100,200,300,400,500}; do super_netperf $i -H $ip -t TCP_RR; done Average of 5 runs. trans/sec trans/sec (3.17-rc7-net-next) (3.17-rc7-net-next + this patch) ---------- ---------- 208101 211534 (+1.6%) 839493 850162 (+1.3%) 845071 844053 (-.12%) 816330 819623 (+.4%) 778700 789938 (+1.4%) 735984 754408 (+2.5%) Signed-off-by: Jason Baron Signed-off-by: David S. Miller

macvlan: pass 'bool' type to macvlan_count_rx()

2014-10-10T19:09:47Z

Pass last argument to macvlan_count_rx() as the correct bool type. Signed-off-by: Jason Baron Signed-off-by: David S. Miller

net: better IFF_XMIT_DST_RELEASE support

2014-10-07T17:22:11Z

Testing xmit_more support with netperf and connected UDP sockets, I found strange dst refcount false sharing. Current handling of IFF_XMIT_DST_RELEASE is not optimal. Dropping dst in validate_xmit_skb() is certainly too late in case packet was queued by cpu X but dequeued by cpu Y The logical point to take care of drop/force is in __dev_queue_xmit() before even taking qdisc lock. As Julian Anastasov pointed out, need for skb_dst() might come from some packet schedulers or classifiers. This patch adds new helper to cleanly express needs of various drivers or qdiscs/classifiers. Drivers that need skb_dst() in their ndo_start_xmit() should call following helper in their setup instead of the prior : dev->priv_flags &= ~IFF_XMIT_DST_RELEASE; -> netif_keep_dst(dev); Instead of using a single bit, we use two bits, one being eventually rebuilt in bonding/team drivers. The other one, is permanent and blocks IFF_XMIT_DST_RELEASE being rebuilt in bonding/team. Eventually, we could add something smarter later. Signed-off-by: Eric Dumazet Cc: Julian Anastasov Signed-off-by: David S. Miller

macvlan: add source mode

2014-09-29T19:37:01Z

This patch adds a new mode of operation to macvlan, called "source". It allows one to set a list of allowed mac address, which is used to match against source mac address from received frames on underlying interface. This enables creating mac based VLAN associations, instead of standard port or tag based. The feature is useful to deploy 802.1x mac based behavior, where drivers of underlying interfaces doesn't allows that. Configuration is done through the netlink interface using e.g.: ip link add link eth0 name macvlan0 type macvlan mode source ip link add link eth0 name macvlan1 type macvlan mode source ip link set link dev macvlan0 type macvlan macaddr add 00:11:11:11:11:11 ip link set link dev macvlan0 type macvlan macaddr add 00:22:22:22:22:22 ip link set link dev macvlan0 type macvlan macaddr add 00:33:33:33:33:33 ip link set link dev macvlan1 type macvlan macaddr add 00:33:33:33:33:33 ip link set link dev macvlan1 type macvlan macaddr add 00:44:44:44:44:44 This allows clients with MAC addresses 00:11:11:11:11:11, 00:22:22:22:22:22 to be part of only VLAN associated with macvlan0 interface. Clients with MAC addresses 00:44:44:44:44:44 with only VLAN associated with macvlan1 interface. And client with MAC address 00:33:33:33:33:33 to be associated with both VLANs. Based on work of Stefan Gula v8: last version of Stefan Gula for Kernel 3.2.1 v9: rework onto linux-next 2014-03-12 by Michael Braun add MACADDR_SET command, enable to configure mac for source mode while creating interface v10: - reduce indention level - rename source_list to source_entry - use aligned 64bit ether address - use hash_64 instead of addr[5] v11: - rebase for 3.14 / linux-next 20.04.2014 v12 - rebase for linux-next 2014-09-25 Signed-off-by: Michael Braun Signed-off-by: David S. Miller

macvlan: allow to enqueue broadcast pkt on virtual device

2014-09-22T18:10:07Z

Since commit 412ca1550cbe ("macvlan: Move broadcasts into a work queue"), the driver uses tx_queue_len of the master device as the limit of packets enqueuing. Problem is that virtual drivers have this value set to 0, thus all broadcast packets were rejected. Because tx_queue_len was arbitrarily chosen, I replace it with a static limit of 1000 (also arbitrarily chosen). CC: Herbert Xu Reported-by: Thibaut Collet Suggested-by: Thibaut Collet Tested-by: Thibaut Collet Signed-off-by: Nicolas Dichtel Acked-by: Herbert Xu Signed-off-by: David S. Miller

net: allow macvlans to move to net namespace

2014-09-19T21:07:20Z

I cannot move a macvlan interface created on top of a bonding interface to a different namespace: % ip netns add dummy0 % ip link add link bond0 mac0 type macvlan % ip link set mac0 netns dummy0 RTNETLINK answers: Invalid argument % The problem seems to be that commit f9399814927a ("bonding: Don't allow bond devices to change network namespaces.") sets NETIF_F_NETNS_LOCAL on bonding interfaces, and commit 797f87f83b60 ("macvlan: fix netdev feature propagation from lower device") causes macvlan interfaces to inherit its features from the lower device. NETIF_F_NETNS_LOCAL should not be inherited from the lower device by a macvlan. Patch tested on 3.16. Signed-off-by: Francesco Ruggeri Acked-by: Cong Wang Signed-off-by: David S. Miller

macvlan: Allow setting multicast filter on all macvlan types

2014-08-21T23:54:25Z

Currently, macvlan code restricts multicast and unicast filter setting only to passthru devices. As a result, if a guest using macvtap wants to receive multicast traffic, it has to set IFF_ALLMULTI or IFF_PROMISC. This patch makes it possible to use the fdb interface to add multicast addresses to the filter thus allowing a guest to receive only targeted multicast traffic. CC: John Fastabend CC: Michael S. Tsirkin CC: Jason Wang Signed-off-by: Vladislav Yasevich Acked-by: John Fastabend Acked-by: Michael S. Tsirkin Signed-off-by: David S. Miller

Revert "macvlan: simplify the structure port"

2014-08-14T21:32:49Z

This reverts commit a188a54d11629bef2169052297e61f3767ca8ce5. It causes crashes ==================== [ 80.643286] BUG: unable to handle kernel NULL pointer dereference at 0000000000000878 [ 80.670103] IP: [] try_to_grab_pending+0x64/0x1f0 [ 80.691289] PGD 22c102067 PUD 235bf0067 PMD 0 [ 80.706611] Oops: 0002 [#1] SMP [ 80.717836] Modules linked in: macvlan nfsd lockd nfs_acl exportfs auth_rpcgss sunrpc oid_registry ioatdma ixgbe(-) mdio igb dca [ 80.757935] CPU: 37 PID: 6724 Comm: rmmod Not tainted 3.16.0-net-next-08-12-2014-FCoE+ #1 [ 80.785688] Hardware name: Intel Corporation S2600CO/S2600CO, BIOS SE5C600.86B.02.03.0003.041920141333 04/19/2014 [ 80.820310] task: ffff880235a9eae0 ti: ffff88022e844000 task.ti: ffff88022e844000 [ 80.845770] RIP: 0010:[] [] try_to_grab_pending+0x64/0x1f0 [ 80.875326] RSP: 0018:ffff88022e847b28 EFLAGS: 00010046 [ 80.893251] RAX: 0000000000037a6a RBX: 0000000000000878 RCX: 0000000000000000 [ 80.917187] RDX: ffff880235a9eae0 RSI: 0000000000000001 RDI: ffffffff810832db [ 80.941125] RBP: ffff88022e847b58 R08: 0000000000000000 R09: 0000000000000000 [ 80.965056] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88022e847b70 [ 80.988994] R13: 0000000000000000 R14: ffff88022e847be8 R15: ffffffff81ebe440 [ 81.012929] FS: 00007fab90b07700(0000) GS:ffff88043f7a0000(0000) knlGS:0000000000000000 [ 81.040400] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 81.059757] CR2: 0000000000000878 CR3: 0000000235a42000 CR4: 00000000001407e0 [ 81.083689] Stack: [ 81.090739] ffff880235a9eae0 0000000000000878 ffff88022e847b70 0000000000000000 [ 81.116253] ffff88022e847be8 ffffffff81ebe440 ffff88022e847b98 ffffffff810847f1 [ 81.141766] ffff88022e847b78 0000000000000286 ffff880234200000 0000000000000000 [ 81.167282] Call Trace: [ 81.175768] [] __cancel_work_timer+0x31/0x170 [ 81.195985] [] cancel_work_sync+0xb/0x10 [ 81.214769] [] macvlan_port_destroy+0x28/0x60 [macvlan] [ 81.237844] [] macvlan_uninit+0x40/0x50 [macvlan] [ 81.259209] [] rollback_registered_many+0x1a2/0x2c0 [ 81.281140] [] unregister_netdevice_many+0x1a/0xb0 [ 81.302786] [] macvlan_device_event+0x1ef/0x240 [macvlan] [ 81.326439] [] notifier_call_chain+0x4d/0x70 [ 81.346366] [] raw_notifier_call_chain+0x11/0x20 [ 81.367439] [] call_netdevice_notifiers_info+0x3b/0x70 [ 81.390228] [] call_netdevice_notifiers+0x11/0x20 [ 81.411587] [] rollback_registered_many+0x17d/0x2c0 [ 81.433518] [] unregister_netdevice_queue+0x75/0x110 [ 81.455735] [] unregister_netdev+0x1b/0x30 [ 81.475094] [] ixgbe_remove+0x170/0x1d0 [ixgbe] [ 81.495886] [] pci_device_remove+0x32/0x60 [ 81.515246] [] __device_release_driver+0x64/0xd0 [ 81.536321] [] driver_detach+0xc8/0xd0 [ 81.554530] [] bus_remove_driver+0x4e/0xa0 [ 81.573888] [] driver_unregister+0x2b/0x60 [ 81.593246] [] pci_unregister_driver+0x1e/0xa0 [ 81.613749] [] ixgbe_exit_module+0x1c/0x2e [ixgbe] [ 81.635401] [] SyS_delete_module+0x15b/0x1e0 [ 81.655334] [] ? sysret_check+0x22/0x5d [ 81.673833] [] ? trace_hardirqs_on_caller+0x11d/0x1e0 [ 81.696339] [] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 81.717985] [] system_call_fastpath+0x16/0x1b [ 81.738199] Code: 00 48 83 3d 6e bb da 00 00 48 89 c2 0f 84 67 01 00 00 fa 66 0f 1f 44 00 00 49 89 14 24 e8 b5 4b 02 00 45 84 ed 0f 85 ac 00 00 00 0f ba 2b 00 72 1d 31 c0 48 8b 5d d8 4c 8b 65 e0 4c 8b 6d e8 [ 81.807026] RIP [] try_to_grab_pending+0x64/0x1f0 [ 81.828468] RSP [ 81.840384] CR2: 0000000000000878 [ 81.851731] ---[ end trace 9f6c7232e3464e11 ]--- ==================== This bug could be triggered by these steps: modprobe ixgbe ; modprobe macvlan ip link add link p96p1 address 00:1B:21:6E:06:00 macvlan0 type macvlan ip link add link p96p1 address 00:1B:21:6E:06:01 macvlan1 type macvlan ip link add link p96p1 address 00:1B:21:6E:06:02 macvlan2 type macvlan ip link add link p96p1 address 00:1B:21:6E:06:03 macvlan3 type macvlan rmmod ixgbe Reported-by: "Keller, Jacob E" Signed-off-by: David S. Miller

macvlan: Initialize vlan_features to turn on offload support.

2014-08-01T05:10:01Z

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