linux-toradex.git/drivers/net/ipvlan/ipvlan.h, branch v4.10

ipvlan: fix multicast processing

2016-12-23T22:53:47+00:00

In an IPvlan setup when master is set in loopback mode e.g.

  ethtool -K eth0 set loopback on

  where eth0 is master device for IPvlan setup.

The failure is caused by the faulty logic that determines if the
packet is from TX-path vs. RX-path by just looking at the mac-
addresses on the packet while processing multicast packets.

In the loopback-mode where this crash was happening, the packets
that are sent out are reflected by the NIC and are processed on
the RX path, but mac-address check tricks into thinking this
packet is from TX path and falsely uses dev_forward_skb() to pass
packets to the slave (virtual) devices.

This patch records the path while queueing packets and eliminates
logic of looking at mac-addresses for the same decision.

------------[ cut here ]------------
kernel BUG at include/linux/skbuff.h:1737!
Call Trace:
 [] dev_forward_skb+0x92/0xd0
 [] ipvlan_process_multicast+0x395/0x4c0 [ipvlan]
 [] ? ipvlan_process_multicast+0xd7/0x4c0 [ipvlan]
 [] ? process_one_work+0x147/0x660
 [] process_one_work+0x1a9/0x660
 [] ? process_one_work+0x147/0x660
 [] worker_thread+0x11d/0x360
 [] ? rescuer_thread+0x350/0x350
 [] kthread+0xdb/0xe0
 [] ? _raw_spin_unlock_irq+0x30/0x50
 [] ? flush_kthread_worker+0xc0/0xc0
 [] ret_from_fork+0x9a/0xd0
 [] ? flush_kthread_worker+0xc0/0xc0

Fixes: ba35f8588f47 ("ipvlan: Defer multicast / broadcast processing to a work-queue")
Signed-off-by: Mahesh Bandewar 
CC: Eric Dumazet 
Signed-off-by: David S. Miller

driver: ipvlan: Free ipvl_port directly with kfree instead of kfree_rcu

2016-12-07T18:21:21+00:00

There are two functions which would free the ipvl_port now. The first
is ipvlan_port_create. It frees the ipvl_port in the error handler,
so it could kfree it directly. The second is ipvlan_port_destroy. It
invokes netdev_rx_handler_unregister which enforces one grace period
by synchronize_net firstly, so it also could kfree the ipvl_port
directly and safely.

So it is unnecessary to use kfree_rcu to free ipvl_port.

Signed-off-by: Gao Feng 
Signed-off-by: David S. Miller

driver: ipvlan: Remove useless member mtu_adj of struct ipvl_dev

2016-11-30T20:01:32+00:00

The mtu_adj is initialized to zero when alloc mem, there is no any
assignment to mtu_adj. It is only used in ipvlan_adjust_mtu as one
right value.
So it is useless member of struct ipvl_dev, then remove it.

Signed-off-by: Gao Feng 
Signed-off-by: David S. Miller

ipvlan: Introduce l3s mode

2016-09-19T05:25:22+00:00

In a typical IPvlan L3 setup where master is in default-ns and
each slave is into different (slave) ns. In this setup egress
packet processing for traffic originating from slave-ns will
hit all NF_HOOKs in slave-ns as well as default-ns. However same
is not true for ingress processing. All these NF_HOOKs are
hit only in the slave-ns skipping them in the default-ns.
IPvlan in L3 mode is restrictive and if admins want to deploy
iptables rules in default-ns, this asymmetric data path makes it
impossible to do so.

This patch makes use of the l3_rcv() (added as part of l3mdev
enhancements) to perform input route lookup on RX packets without
changing the skb->dev and then uses nf_hook at NF_INET_LOCAL_IN
to change the skb->dev just before handing over skb to L4.

Signed-off-by: Mahesh Bandewar 
CC: David Ahern 
Reviewed-by: David Ahern 
Signed-off-by: David S. Miller

ipvlan: misc changes

2016-02-22T03:43:24+00:00

1. scope correction for few functions that are used in single file.
2. Adjust variables that are used in fast-path to fit into single cacheline
3. Update rcv_frame() to skip shared check for frames coming over wire

Signed-off-by: Mahesh Bandewar 
Signed-off-by: David S. Miller

ipvlan: mode is u16

2016-02-22T03:43:24+00:00

The mode argument was erronusly defined as u32 but it has always
been u16. Also use ipvlan_set_mode() helper to set the mode instead
of assigning directly. This should avoid future erronus assignments /
updates.

Signed-off-by: Mahesh Bandewar 
Signed-off-by: David S. Miller

ipvlan: use rcu_deference_bh() in ipvlan_queue_xmit()

2015-07-16T04:33:40+00:00

In tx path rcu_read_lock_bh() is held, so we need rcu_deference_bh().
This fixes the following warning:

 ===============================
 [ INFO: suspicious RCU usage. ]
 4.1.0-rc1+ #1007 Not tainted
 -------------------------------
 drivers/net/ipvlan/ipvlan.h:106 suspicious rcu_dereference_check() usage!

 other info that might help us debug this:

 rcu_scheduler_active = 1, debug_locks = 0
 1 lock held by dhclient/1076:
  #0:  (rcu_read_lock_bh){......}, at: [] rcu_lock_acquire+0x0/0x26

 stack backtrace:
 CPU: 2 PID: 1076 Comm: dhclient Not tainted 4.1.0-rc1+ #1007
 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  0000000000000001 ffff8800d381bac8 ffffffff81a4154f 000000003c1a3c19
  ffff8800d4d0a690 ffff8800d381baf8 ffffffff810b849f ffff880117d41148
  ffff880117d40000 ffff880117d40068 0000000000000156 ffff8800d381bb18
 Call Trace:
  [] dump_stack+0x4c/0x65
  [] lockdep_rcu_suspicious+0x107/0x110
  [] ipvlan_port_get_rcu+0x47/0x4e
  [] ipvlan_queue_xmit+0x35/0x450
  [] ? rcu_read_unlock+0x3e/0x5f
  [] ? local_clock+0x19/0x22
  [] ? __lock_is_held+0x39/0x52
  [] ipvlan_start_xmit+0x1b/0x44
  [] dev_hard_start_xmit+0x2ae/0x467
  [] __dev_queue_xmit+0x50a/0x60c
  [] dev_queue_xmit_sk+0x13/0x15
  [] dev_queue_xmit+0x10/0x12
  [] packet_sendmsg+0xb6b/0xbdf
  [] ? mark_lock+0x2e/0x226
  [] ? sched_clock_cpu+0x9e/0xb7
  [] sock_sendmsg_nosec+0x12/0x1d
  [] sock_sendmsg+0x29/0x2e
  [] sock_write_iter+0x70/0x91
  [] __vfs_write+0x7e/0xa7
  [] vfs_write+0x92/0xe8
  [] SyS_write+0x47/0x7e
  [] system_call_fastpath+0x12/0x6f

Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.")
Cc: Mahesh Bandewar 
Signed-off-by: Cong Wang 
Acked-by: Mahesh Bandewar 
Acked-by: Konstantin Khlebnikov 
Signed-off-by: David S. Miller

ipvlan: unhash addresses without synchronize_rcu

2015-07-16T04:33:39+00:00

All structures used in traffic forwarding are rcu-protected:
ipvl_addr, ipvl_dev and ipvl_port. Thus we can unhash addresses
without synchronization. We'll anyway hash it back into the same
bucket: in worst case lockless lookup will scan hash once again.

Signed-off-by: Konstantin Khlebnikov 
Signed-off-by: David S. Miller

ipvlan: remove counters of ipv4 and ipv6 addresses

2015-07-16T04:33:39+00:00

They are unused after commit f631c44bbe15 ("ipvlan: Always set broadcast bit in
multicast filter").

Signed-off-by: Konstantin Khlebnikov 
Signed-off-by: David S. Miller

ipvlan: Defer multicast / broadcast processing to a work-queue

2015-05-05T23:29:49+00:00

Processing multicast / broadcast in fast path is performance draining
and having more links means more cloning and bringing performance
down further.

Broadcast; in particular, need to be given to all the virtual links.
Earlier tricks of enabling broadcast bit for IPv4 only interfaces are not
really working since it fails autoconf. Which means enabling broadcast
for all the links if protocol specific hacks do not have to be added into
the driver.

This patch defers all (incoming as well as outgoing) multicast traffic to
a work-queue leaving only the unicast traffic in the fast-path. Now if we
need to apply any additional tricks to further reduce the impact of this
(multicast / broadcast) type of traffic, it can be implemented while
processing this work without affecting the fast-path.

Signed-off-by: Mahesh Bandewar 
Signed-off-by: David S. Miller