25 Oct, 2019
1 commit
-
This patch removes variables and callback these are related to the nested
device structure.
devices that can be nested have their own nest_level variable that
represents the depth of nested devices.
In the previous patch, new {lower/upper}_level variables are added and
they replace old private nest_level variable.
So, this patch removes all 'nest_level' variables.In order to avoid lockdep warning, ->ndo_get_lock_subclass() was added
to get lockdep subclass value, which is actually lower nested depth value.
But now, they use the dynamic lockdep key to avoid lockdep warning instead
of the subclass.
So, this patch removes ->ndo_get_lock_subclass() callback.Signed-off-by: Taehee Yoo
Signed-off-by: David S. Miller
25 Apr, 2018
4 commits
-
This patch provides a basic function to allow a lower device to disable
macvlan offload if it was previously enabled on a given macvlan. The idea
here is to allow for recovery from failure should the lowerdev run out of
resources.Signed-off-by: Alexander Duyck
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher -
This patch adds a function indicating if a given macvlan can fully supports
destination filtering, especially as it relates to unicast traffic. For
those macvlan interfaces that do not support destination filtering such
passthru or source mode filtering we should not be enabling offload
support.Signed-off-by: Alexander Duyck
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher -
It doesn't make sense to define macvlan_count_rx as a static inline and
then add a forward declaration after that as an extern. I am dropping the
extern declaration since it seems like it is something that likely got
missed when the function was made an inline.Signed-off-by: Alexander Duyck
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher -
This change renames the fwd_priv member to accel_priv as this more
accurately reflects the actual purpose of this value. In addition I am
adding an accessor which will allow us to further abstract this in the
future if needed.Signed-off-by: Alexander Duyck
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
09 Dec, 2017
1 commit
-
Move 'macaddr_count' from after 'netpoll' to after 'nest_level' to pack
and reduce a memory hole.Fixes: 88ca59d1aaf28c25 (macvlan: remove unused fields in struct macvlan_dev)
Signed-off-by: Girish Moodalbail
Signed-off-by: David S. Miller
04 Nov, 2017
1 commit
-
Files removed in 'net-next' had their license header updated
in 'net'. We take the remove from 'net-next'.Signed-off-by: David S. Miller
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
26 Oct, 2017
1 commit
-
commit 635b8c8ecdd2 ("tap: Renaming tap related APIs, data structures,
macros") captured all the tap related fields into a new struct tap_dev.
However, it failed to remove those fields from struct macvlan_dev.
Those fields are currently unused and must be removed. While there
I moved the comment for MAX_TAP_QUEUES to the right place.Fixes: 635b8c8ecdd27142 (tap: Renaming tap related APIs, data structures, macros)
Signed-off-by: Girish Moodalbail
Signed-off-by: David S. Miller
05 Oct, 2017
1 commit
-
Add extack arg to netdev_upper_dev_link and netdev_master_upper_dev_link
Signed-off-by: David Ahern
Signed-off-by: David S. Miller
12 Feb, 2017
1 commit
-
Renaming tap related APIs, data structures and macros in tap.c from macvtap_.* to tap_.*
Signed-off-by: Sainath Grandhi
Signed-off-by: David S. Miller
23 Jun, 2015
1 commit
-
Macvtap should be compatible with tuntap for
maximum number of queues.commit 'baf71c5c1f80d82e92924050a60b5baaf97e3094 (tuntap:
Increase the number of queues in tun.)' removes
the limitations and increases number of queues in tuntap.
Now, Its safe to increase number of queues in Macvtap as well.This patch also modifies 'macvtap_del_queues' function
to avoid extra memory allocation in stack.Changes from v1->v2 :
Michael S. Tsirkin, Jason Wang :
Better way to use linked list to
avoid use of extra memory in stack.
Sergei Shtylyov : Specify dependent commit's summary.Signed-off-by: Pankaj Gupta
Signed-off-by: David S. Miller
30 Sep, 2014
1 commit
-
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:44This 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-25Signed-off-by: Michael Braun
Signed-off-by: David S. Miller
03 Jun, 2014
1 commit
-
Add netpoll support to macvlan devices. Based on the netpoll support in the 802.1q vlan code.
Tested and macvlan could work well with netconsole.
Signed-off-by: Ding Tianhong
Signed-off-by: David S. Miller
17 May, 2014
1 commit
-
Macvlan devices try to avoid stacking, but that's not always
successfull or even desired. As an example, the following
configuration is perefectly legal and valid:eth0 ] dev_uc_sync+0x3c/0x80
[ 115.620686]
but task is already holding lock:
[ 115.620723] (&macvlan_netdev_addr_lock_key){+.....}, at: [] dev_set_rx_mode+0x1e/0x40
[ 115.620795]
which lock already depends on the new lock.[ 115.620853]
the existing dependency chain (in reverse order) is:
[ 115.620894]
-> #1 (&macvlan_netdev_addr_lock_key){+.....}:
[ 115.620935] [] lock_acquire+0xa2/0x130
[ 115.620974] [] _raw_spin_lock_nested+0x37/0x50
[ 115.621019] [] vlan_dev_set_rx_mode+0x53/0x110 [8021q]
[ 115.621066] [] __dev_set_rx_mode+0x57/0xa0
[ 115.621105] [] dev_set_rx_mode+0x26/0x40
[ 115.621143] [] __dev_open+0xde/0x140
[ 115.621174] [] __dev_change_flags+0x9d/0x170
[ 115.621174] [] dev_change_flags+0x29/0x60
[ 115.621174] [] do_setlink+0x321/0x9a0
[ 115.621174] [] rtnl_newlink+0x51f/0x730
[ 115.621174] [] rtnetlink_rcv_msg+0x95/0x250
[ 115.621174] [] netlink_rcv_skb+0xa9/0xc0
[ 115.621174] [] rtnetlink_rcv+0x2a/0x40
[ 115.621174] [] netlink_unicast+0xf0/0x1c0
[ 115.621174] [] netlink_sendmsg+0x2ff/0x740
[ 115.621174] [] sock_sendmsg+0x8b/0xc0
[ 115.621174] [] ___sys_sendmsg+0x369/0x380
[ 115.621174] [] __sys_sendmsg+0x42/0x80
[ 115.621174] [] SyS_sendmsg+0x12/0x20
[ 115.621174] [] system_call_fastpath+0x16/0x1b
[ 115.621174]
-> #0 (&vlan_netdev_addr_lock_key/1){+.....}:
[ 115.621174] [] __lock_acquire+0x1773/0x1a60
[ 115.621174] [] lock_acquire+0xa2/0x130
[ 115.621174] [] _raw_spin_lock_nested+0x37/0x50
[ 115.621174] [] dev_uc_sync+0x3c/0x80
[ 115.621174] [] macvlan_set_mac_lists+0xca/0x110 [macvlan]
[ 115.621174] [] __dev_set_rx_mode+0x57/0xa0
[ 115.621174] [] dev_set_rx_mode+0x26/0x40
[ 115.621174] [] __dev_open+0xde/0x140
[ 115.621174] [] __dev_change_flags+0x9d/0x170
[ 115.621174] [] dev_change_flags+0x29/0x60
[ 115.621174] [] do_setlink+0x321/0x9a0
[ 115.621174] [] rtnl_newlink+0x51f/0x730
[ 115.621174] [] rtnetlink_rcv_msg+0x95/0x250
[ 115.621174] [] netlink_rcv_skb+0xa9/0xc0
[ 115.621174] [] rtnetlink_rcv+0x2a/0x40
[ 115.621174] [] netlink_unicast+0xf0/0x1c0
[ 115.621174] [] netlink_sendmsg+0x2ff/0x740
[ 115.621174] [] sock_sendmsg+0x8b/0xc0
[ 115.621174] [] ___sys_sendmsg+0x369/0x380
[ 115.621174] [] __sys_sendmsg+0x42/0x80
[ 115.621174] [] SyS_sendmsg+0x12/0x20
[ 115.621174] [] system_call_fastpath+0x16/0x1b
[ 115.621174]
other info that might help us debug this:[ 115.621174] Possible unsafe locking scenario:
[ 115.621174] CPU0 CPU1
[ 115.621174] ---- ----
[ 115.621174] lock(&macvlan_netdev_addr_lock_key);
[ 115.621174] lock(&vlan_netdev_addr_lock_key/1);
[ 115.621174] lock(&macvlan_netdev_addr_lock_key);
[ 115.621174] lock(&vlan_netdev_addr_lock_key/1);
[ 115.621174]
*** DEADLOCK ***[ 115.621174] 2 locks held by ip/1704:
[ 115.621174] #0: (rtnl_mutex){+.+.+.}, at: [] rtnetlink_rcv+0x1b/0x40
[ 115.621174] #1: (&macvlan_netdev_addr_lock_key){+.....}, at: [] dev_set_rx_mode+0x1e/0x40
[ 115.621174]
stack backtrace:
[ 115.621174] CPU: 3 PID: 1704 Comm: ip Not tainted 3.15.0-rc1+ #24
[ 115.621174] Hardware name: Hewlett-Packard HP xw8400 Workstation/0A08h, BIOS 786D5 v02.38 10/25/2010
[ 115.621174] ffffffff82339ae0 ffff880465f79568 ffffffff816ee20c ffffffff82339ae0
[ 115.621174] ffff880465f795a8 ffffffff816e9e1b ffff880465f79600 ffff880465b019c8
[ 115.621174] 0000000000000001 0000000000000002 ffff880465b019c8 ffff880465b01230
[ 115.621174] Call Trace:
[ 115.621174] [] dump_stack+0x4d/0x66
[ 115.621174] [] print_circular_bug+0x200/0x20e
[ 115.621174] [] __lock_acquire+0x1773/0x1a60
[ 115.621174] [] ? trace_hardirqs_on_caller+0xb2/0x1d0
[ 115.621174] [] lock_acquire+0xa2/0x130
[ 115.621174] [] ? dev_uc_sync+0x3c/0x80
[ 115.621174] [] _raw_spin_lock_nested+0x37/0x50
[ 115.621174] [] ? dev_uc_sync+0x3c/0x80
[ 115.621174] [] dev_uc_sync+0x3c/0x80
[ 115.621174] [] macvlan_set_mac_lists+0xca/0x110 [macvlan]
[ 115.621174] [] __dev_set_rx_mode+0x57/0xa0
[ 115.621174] [] dev_set_rx_mode+0x26/0x40
[ 115.621174] [] __dev_open+0xde/0x140
[ 115.621174] [] __dev_change_flags+0x9d/0x170
[ 115.621174] [] dev_change_flags+0x29/0x60
[ 115.621174] [] ? mem_cgroup_bad_page_check+0x21/0x30
[ 115.621174] [] do_setlink+0x321/0x9a0
[ 115.621174] [] ? __lock_acquire+0x37c/0x1a60
[ 115.621174] [] rtnl_newlink+0x51f/0x730
[ 115.621174] [] ? rtnl_newlink+0xe9/0x730
[ 115.621174] [] rtnetlink_rcv_msg+0x95/0x250
[ 115.621174] [] ? trace_hardirqs_on+0xd/0x10
[ 115.621174] [] ? rtnetlink_rcv+0x1b/0x40
[ 115.621174] [] ? rtnetlink_rcv+0x40/0x40
[ 115.621174] [] netlink_rcv_skb+0xa9/0xc0
[ 115.621174] [] rtnetlink_rcv+0x2a/0x40
[ 115.621174] [] netlink_unicast+0xf0/0x1c0
[ 115.621174] [] netlink_sendmsg+0x2ff/0x740
[ 115.621174] [] sock_sendmsg+0x8b/0xc0
[ 115.621174] [] ? might_fault+0x5f/0xb0
[ 115.621174] [] ? might_fault+0xa8/0xb0
[ 115.621174] [] ? might_fault+0x5f/0xb0
[ 115.621174] [] ? verify_iovec+0x5e/0xe0
[ 115.621174] [] ___sys_sendmsg+0x369/0x380
[ 115.621174] [] ? __do_page_fault+0x11d/0x570
[ 115.621174] [] ? up_read+0x1f/0x40
[ 115.621174] [] ? __do_page_fault+0x214/0x570
[ 115.621174] [] ? mntput_no_expire+0x6b/0x1c0
[ 115.621174] [] ? mntput_no_expire+0x17/0x1c0
[ 115.621174] [] ? mntput+0x24/0x40
[ 115.621174] [] __sys_sendmsg+0x42/0x80
[ 115.621174] [] SyS_sendmsg+0x12/0x20
[ 115.621174] [] system_call_fastpath+0x16/0x1bFix this by correctly providing macvlan lockdep class.
Signed-off-by: Vlad Yasevich
Signed-off-by: David S. Miller
05 Jan, 2014
1 commit
-
They are same, so unify them as one; since macvlan is a kind of vlan,
vlan_pcpu_stats should be a proper name for vlan and macvlan.Signed-off-by: Li RongQing
Signed-off-by: David S. Miller
28 Dec, 2013
1 commit
-
Only used in one file, no need to expose
Signed-off-by: Stephen Hemminger
Signed-off-by: David S. Miller
13 Dec, 2013
1 commit
-
Since now macvlan and macvtap use the same receive and
forward handlers, we can remove them completely and use
netif_rx and dev_forward_skb() directly.Signed-off-by: Vlad Yasevich
Signed-off-by: David S. Miller
16 Nov, 2013
1 commit
-
Introduce helper function macvlan_dev_real_dev which returns the
underlying device of a macvlan device, similar to vlan_dev_real_dev()
for 802.1q VLAN devices.v2: IFF_MACVLAN flag and equivalent of is_macvlan_dev() were
introduced in the meantimev3: do BUG() if compiled without macvlan support
Signed-off-by: Michal Kubecek
Signed-off-by: David S. Miller
08 Nov, 2013
1 commit
-
Add a operations structure that allows a network interface to export
the fact that it supports package forwarding in hardware between
physical interfaces and other mac layer devices assigned to it (such
as macvlans). This operaions structure can be used by virtual mac
devices to bypass software switching so that forwarding can be done
in hardware more efficiently.Signed-off-by: John Fastabend
Signed-off-by: Neil Horman
CC: Andy Gospodarek
CC: "David S. Miller"
Signed-off-by: David S. Miller
26 Jun, 2013
1 commit
-
When the user issues TUNSETOFFLOAD ioctl, macvtap does not do
anything other then to verify arguments. This patch adds
functionality to allow users to actually control offload features.
NETIF_F_GSO and NETIF_F_GRO are always on, but the rest of the
features can be controlled.Signed-off-by: Vlad Yasevich
Signed-off-by: David S. Miller
13 Jun, 2013
1 commit
-
This patch silents the following sparse warnings:
drivers/net/macvtap.c:98:9: warning: incorrect type in assignment (different
address spaces)
drivers/net/macvtap.c:98:9: expected struct macvtap_queue *
drivers/net/macvtap.c:98:9: got struct macvtap_queue [noderef]
*
drivers/net/macvtap.c:120:9: warning: incorrect type in assignment (different
address spaces)
drivers/net/macvtap.c:120:9: expected struct macvtap_queue *
drivers/net/macvtap.c:120:9: got struct macvtap_queue [noderef]
*
drivers/net/macvtap.c:151:22: error: incompatible types in comparison expression
(different address spaces)
drivers/net/macvtap.c:233:23: error: incompatible types in comparison expression
(different address spaces)
drivers/net/macvtap.c:243:23: error: incompatible types in comparison expression
(different address spaces)
drivers/net/macvtap.c:247:15: error: incompatible types in comparison expression
(different address spaces)
CC [M] drivers/net/macvtap.o
drivers/net/macvlan.c:232:24: error: incompatible types in comparison expression
(different address spaces)Signed-off-by: Jason Wang
Signed-off-by: David S. Miller
08 Jun, 2013
3 commits
-
This patch adds TUNSETQUEUE ioctl to let userspace can temporarily disable or
enable a queue of macvtap. This is used to be compatible at API layer of tuntap
to simplify the userspace to manage the queues. This is done through introducing
a linked list to track all taps while using vlan->taps array to only track
active taps.Signed-off-by: Jason Wang
Acked-by: Michael S. Tsirkin
Signed-off-by: David S. Miller -
Macvtap should be at least compatible with tap, so change the max number to 16.
Signed-off-by: Jason Wang
Acked-by: Michael S. Tsirkin
Signed-off-by: David S. Miller -
Acked-by: Michael S. Tsirkin
Signed-off-by: Jason Wang
Signed-off-by: David S. Miller
07 Feb, 2013
1 commit
-
Setting up IPv6 addresses on configurations with many macvlans
is not really working, as many multicast messages are dropped.Add a multicast filter to macvlan to reduce the amount of cloned
skbs and overhead.Successfully tested with 1024 macvlans on one ethernet device.
Signed-off-by: Eric Dumazet
Cc: Ben Greear
Signed-off-by: David S. Miller
16 Apr, 2012
1 commit
-
This adds FDB bridge ops to the macvlan device passthru mode.
Additionally a flags field was added and a NOPROMISC bit to
allow users to use passthru mode without the driver calling
dev_set_promiscuity(). The flags field is a u16 placed in a
4 byte hole (consuming 2 bytes) of the macvlan_dev struct.We want to do this so that the macvlan driver or stack
above the macvlan driver does not have to process every
packet. For the use case where we know all the MAC addresses
of the endstations above us this works well.This patch is a result of Roopa Prabhu's work. Follow up
patches are needed for VEPA and VEB macvlan modes.v2: Change from distinct nopromisc mode to a flags field to
configure this. This avoids the tendency to add a new
mode every time we need some slightly different behavior.
v3: fix error in dev_set_promiscuity and add change and get
link attributes for flags.CC: Roopa Prabhu
CC: Michael S. Tsirkin
Signed-off-by: John Fastabend
Signed-off-by: David S. Miller
21 Oct, 2011
1 commit
-
On systems that create and delete lots of dynamic devices the
31bit linux ifindex fails to fit in the 16bit macvtap minor,
resulting in unusable macvtap devices. I have systems running
automated tests that that hit this condition in just a few days.Use a linux idr allocator to track which mavtap minor numbers
are available and and to track the association between macvtap
minor numbers and macvtap network devices.Remove the unnecessary unneccessary check to see if the network
device we have found is indeed a macvtap device. With macvtap
specific data structures it is impossible to find any other
kind of networking device.Increase the macvtap minor range from 65536 to the full 20 bits
that is supported by linux device numbers. It doesn't solve the
original problem but there is no penalty for a larger minor
device range.Signed-off-by: Eric W. Biederman
Signed-off-by: David S. Miller
17 Nov, 2010
1 commit
-
macvlan is a stacked device, like tunnels. We should use the lockless
mechanism we are using in tunnels and loopback.This patch completely removes locking in TX path.
tx stat counters are added into existing percpu stat structure, renamed
from rx_stats to pcpu_stats.Note : this reverts commit 2c11455321f37 (macvlan: add multiqueue
capability)Note : rx_errors converted to a 32bit counter, like tx_dropped, since
they dont need 64bit range.Signed-off-by: Eric Dumazet
Cc: Patrick McHardy
Cc: Ben Greear
Cc: Ben Hutchings
Acked-by: Patrick McHardy
Signed-off-by: David S. Miller
16 Nov, 2010
1 commit
-
Signed-off-by: Joe Perches
Signed-off-by: David S. Miller
17 Aug, 2010
1 commit
-
Implement multiqueue facility for macvtap driver. The idea is that
a macvtap device can be opened multiple times and the fd's can be
used to register eg, as backend for vhost.Signed-off-by: Krishna Kumar
Signed-off-by: David S. Miller
28 Jul, 2010
1 commit
-
Conflicts:
drivers/net/bnx2x_main.cMerge bnx2x bug fixes in by hand... :-/
Signed-off-by: David S. Miller
23 Jul, 2010
1 commit
-
Mark Wagner reported OOM symptoms when sending UDP traffic over
a macvtap link to a kvm receiver.This appears to be caused by the fact that macvtap packet queues
are unlimited in length. This means that if the receiver can't
keep up with the rate of flow, then we will hit OOM. Of course
it gets worse if the OOM killer then decides to kill the receiver.This patch imposes a cap on the packet queue length, in the same
way as the tuntap driver, using the device TX queue length.Please note that macvtap currently has no way of giving congestion
notification, that means the software device TX queue cannot be
used and packets will always be dropped once the macvtap driver
queue fills up.This shouldn't be a great problem for the scenario where macvtap
is used to feed a kvm receiver, as the traffic is most likely
external in origin so congestion notification can't be applied
anyway.Of course, if anybody decides to complain about guest-to-guest
UDP packet loss down the track, then we may have to revisit this.Incidentally, this patch also fixes a real memory leak when
macvtap_get_queue fails.Chris Wright noticed that for this patch to work, we need a
non-zero TX queue length. This patch includes his work to change
the default macvtap TX queue length to 500.Reported-by: Mark Wagner
Signed-off-by: Herbert Xu
Acked-by: Chris Wright
Acked-by: Arnd Bergmann
Signed-off-by: David S. Miller
29 Jun, 2010
1 commit
-
Use u64_stats_sync infrastructure to implement 64bit stats.
Signed-off-by: Eric Dumazet
Acked-by: Patrick McHardy
Signed-off-by: David S. Miller
02 Jun, 2010
1 commit
-
What this patch does is it removes two receive frame hooks (for bridge and for
macvlan) from __netif_receive_skb. These are replaced them with a single
hook for both. It only supports one hook per device because it makes no
sense to do bridging and macvlan on the same device.Then a network driver (of virtual netdev like macvlan or bridge) can register
an rx_handler for needed net device.Signed-off-by: Jiri Pirko
Signed-off-by: Stephen Hemminger
Signed-off-by: David S. Miller
16 May, 2010
1 commit
-
Now there's null check here and also again in the hook. Looking at bridge bits
which are simmilar, port structure is rcu_dereferenced right away in
handle_bridge and passed to hook. Looks nicer.Signed-off-by: Jiri Pirko
Acked-by: Patrick McHardy
Signed-off-by: David S. Miller
19 Feb, 2010
1 commit
-
This adds support for passing a macvtap file descriptor into
vhost-net, much like we already do for tun/tap.Most of the new code is taken from the respective patch
in the tun driver and may get consolidated in the future.Signed-off-by: Arnd Bergmann
Acked-by: Sridhar Samudrala
Signed-off-by: David S. Miller
17 Feb, 2010
1 commit
-
Add __percpu sparse annotations to net drivers.
These annotations are to make sparse consider percpu variables to be
in a different address space and warn if accessed without going
through percpu accessors. This patch doesn't affect normal builds.Signed-off-by: Tejun Heo
Acked-by: David S. Miller
Cc: Eric Dumazet
Cc: Arnd Bergmann
Signed-off-by: David S. Miller
04 Feb, 2010
2 commits
-
In order to use macvlan with qemu and other tools that require
a tap file descriptor, the macvtap driver adds a small backend
with a character device with the same interface as the tun
driver, with a minimum set of features.Macvtap interfaces are created in the same way as macvlan
interfaces using ip link, but the netif is just used as a
handle for configuration and accounting, while the data
goes through the chardev. Each macvtap interface has its
own character device, simplifying permission management
significantly over the generic tun/tap driver.Cc: Patrick McHardy
Cc: Stephen Hemminger
Cc: David S. Miller"
Cc: "Michael S. Tsirkin"
Cc: Herbert Xu
Cc: Or Gerlitz
Cc: netdev@vger.kernel.org
Cc: bridge@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Arnd Bergmann
Signed-off-by: David S. Miller -
This makes it possible to hook into the macvlan driver
from another kernel module. In particular, the goal is
to extend it with the macvtap backend that provides
a tun/tap compatible interface directly on the macvlan
device.Signed-off-by: Arnd Bergmann
Signed-off-by: David S. Miller