Currently, the tx queue were selected implicitly in ndo_dfwd_start_xmit(). The will cause several issues: - NETIF_F_LLTX were removed for macvlan, so txq lock were done for macvlan instead of lower device which misses the necessary txq synchronization for lower device such as txq stopping or frozen required by dev watchdog or control path. - dev_hard_start_xmit() was called with NULL txq which bypasses the net device watchdog. - dev_hard_start_xmit() does not check txq everywhere which will lead a crash when tso is disabled for lower device. Fix this by explicitly introducing a new param for .ndo_select_queue() for just selecting queues in the case of l2 forwarding offload. netdev_pick_tx() was also extended to accept this parameter and dev_queue_xmit_accel() was used to do l2 forwarding transmission. With this fixes, NETIF_F_LLTX could be preserved for macvlan and there's no need to check txq against NULL in dev_hard_start_xmit(). Also there's no need to keep a dedicated ndo_dfwd_start_xmit() and we can just reuse the code of dev_queue_xmit() to do the transmission. In the future, it was also required for macvtap l2 forwarding support since it provides a necessary synchronization method. Cc: John Fastabend <john.r.fastabend@intel.com> Cc: Neil Horman <nhorman@tuxdriver.com> Cc: e1000-devel@lists.sourceforge.net Signed-off-by: Jason Wang <jasowang@redhat.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Acked-by: John Fastabend <john.r.fastabend@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
John W. Linville says: ==================== For the mac80211 bits, Johannes says: "I have a fix from Javier for mac80211_hwsim when used with wmediumd userspace, and a fix from Felix for buffering in AP mode." For the NFC bits, Samuel says: "This pull request only contains one fix for a regression introduced with commit e29a9e2ae165620d. Without this fix, we can not establish a p2p link in target mode. Only initiator mode works." For the iwlwifi bits, Emmanuel says: "It only includes new device IDs so it's not vital. If you have a pull request to net.git anyway, I'd happy to have this in." ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
In the past the IFA_PERMANENT flag indicated, that the valid and preferred
lifetime where ignored. Since change fad8da3e085ddf ("ipv6 addrconf: fix
preferred lifetime state-changing behavior while valid_lft is infinity")
we honour at least the preferred lifetime on those addresses. As such
the valid lifetime gets recalculated and updated to 0.
If loopback address is added manually this problem does not occur.
Also if NetworkManager manages IPv6, those addresses will get added via
inet6_rtm_newaddr and thus will have a correct lifetime, too.
Reported-by: François-Xavier Le Bail <fx.lebail@yahoo.com>
Reported-by: Damien Wyart <damien.wyart@gmail.com>
Fixes: fad8da3e085ddf ("ipv6 addrconf: fix preferred lifetime state-changing behavior while valid_lft is infinity")
Cc: Yasushi Asano <yasushi.asano@jp.fujitsu.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Samuel Ortiz <sameo@linux.intel.com> says: "This is the first NFC fixes pull request for 3.13. It only contains one fix for a regression introduced with commit e29a9e2ae165620d. Without this fix, we can not establish a p2p link in target mode. Only initiator mode works." Signed-off-by: John W. Linville <linville@tuxdriver.com>
Pablo Neira Ayuso says: ==================== The following patchset contains two patches: * fix the IRC NAT helper which was broken when adding (incomplete) IPv6 support, from Daniel Borkmann. * Refine the previous bugtrap that Jesper added to catch problems for the usage of the sequence adjustment extension in IPVs in Dec 16th, it may spam messages in case of finding a real bug. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
When we pull a received packet from a link's 'deferred packets' queue
for processing, its 'next' pointer is not cleared, and still refers to
the next packet in that queue, if any. This is incorrect, but caused
no harm before commit 40ba3cdf542a469aaa9083fa041656e59b109b90 ("tipc:
message reassembly using fragment chain") was introduced. After that
commit, it may sometimes lead to the following oops:
general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
Modules linked in: tipc
CPU: 4 PID: 0 Comm: swapper/4 Tainted: G W 3.13.0-rc2+ #6
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
task: ffff880017af4880 ti: ffff880017aee000 task.ti: ffff880017aee000
RIP: 0010:[<ffffffff81710694>] [<ffffffff81710694>] skb_try_coalesce+0x44/0x3d0
RSP: 0018:ffff880016603a78 EFLAGS: 00010212
RAX: 6b6b6b6bd6d6d6d6 RBX: ffff880013106ac0 RCX: ffff880016603ad0
RDX: ffff880016603ad7 RSI: ffff88001223ed00 RDI: ffff880013106ac0
RBP: ffff880016603ab8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: ffff88001223ed00
R13: ffff880016603ad0 R14: 000000000000058c R15: ffff880012297650
FS: 0000000000000000(0000) GS:ffff880016600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000805b000 CR3: 0000000011f5d000 CR4: 00000000000006e0
Stack:
ffff880016603a88 ffffffff810a38ed ffff880016603aa8 ffff88001223ed00
0000000000000001 ffff880012297648 ffff880016603b68 ffff880012297650
ffff880016603b08 ffffffffa0006c51 ffff880016603b08 00ffffffa00005fc
Call Trace:
<IRQ>
[<ffffffff810a38ed>] ? trace_hardirqs_on+0xd/0x10
[<ffffffffa0006c51>] tipc_link_recv_fragment+0xd1/0x1b0 [tipc]
[<ffffffffa0007214>] tipc_recv_msg+0x4e4/0x920 [tipc]
[<ffffffffa00016f0>] ? tipc_l2_rcv_msg+0x40/0x250 [tipc]
[<ffffffffa000177c>] tipc_l2_rcv_msg+0xcc/0x250 [tipc]
[<ffffffffa00016f0>] ? tipc_l2_rcv_msg+0x40/0x250 [tipc]
[<ffffffff8171e65b>] __netif_receive_skb_core+0x80b/0xd00
[<ffffffff8171df94>] ? __netif_receive_skb_core+0x144/0xd00
[<ffffffff8171eb76>] __netif_receive_skb+0x26/0x70
[<ffffffff8171ed6d>] netif_receive_skb+0x2d/0x200
[<ffffffff8171fe70>] napi_gro_receive+0xb0/0x130
[<ffffffff815647c2>] e1000_clean_rx_irq+0x2c2/0x530
[<ffffffff81565986>] e1000_clean+0x266/0x9c0
[<ffffffff81985f7b>] ? notifier_call_chain+0x2b/0x160
[<ffffffff8171f971>] net_rx_action+0x141/0x310
[<ffffffff81051c1b>] __do_softirq+0xeb/0x480
[<ffffffff819817bb>] ? _raw_spin_unlock+0x2b/0x40
[<ffffffff810b8c42>] ? handle_fasteoi_irq+0x72/0x100
[<ffffffff81052346>] irq_exit+0x96/0xc0
[<ffffffff8198cbc3>] do_IRQ+0x63/0xe0
[<ffffffff81981def>] common_interrupt+0x6f/0x6f
<EOI>
This happens when the last fragment of a message has passed through the
the receiving link's 'deferred packets' queue, and at least one other
packet was added to that queue while it was there. After the fragment
chain with the complete message has been successfully delivered to the
receiving socket, it is released. Since 'next' pointer of the last
fragment in the released chain now is non-NULL, we get the crash shown
above.
We fix this by clearing the 'next' pointer of all received packets,
including those being pulled from the 'deferred' queue, before they
undergo any further processing.
Fixes: 40ba3cdf542a4 ("tipc: message reassembly using fragment chain")
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Reported-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
initialise pcpu_tstats.syncp to kill the calltrace
[ 11.973950] Call Trace:
[ 11.973950] [<819bbaff>] dump_stack+0x48/0x60
[ 11.973950] [<819bbaff>] dump_stack+0x48/0x60
[ 11.973950] [<81078dcf>] __lock_acquire.isra.22+0x1bf/0xc10
[ 11.973950] [<81078dcf>] __lock_acquire.isra.22+0x1bf/0xc10
[ 11.973950] [<81079fa7>] lock_acquire+0x77/0xa0
[ 11.973950] [<81079fa7>] lock_acquire+0x77/0xa0
[ 11.973950] [<817ca7ab>] ? dev_get_stats+0xcb/0x130
[ 11.973950] [<817ca7ab>] ? dev_get_stats+0xcb/0x130
[ 11.973950] [<8183862d>] ip_tunnel_get_stats64+0x6d/0x230
[ 11.973950] [<8183862d>] ip_tunnel_get_stats64+0x6d/0x230
[ 11.973950] [<817ca7ab>] ? dev_get_stats+0xcb/0x130
[ 11.973950] [<817ca7ab>] ? dev_get_stats+0xcb/0x130
[ 11.973950] [<811cf8c1>] ? __nla_reserve+0x21/0xd0
[ 11.973950] [<811cf8c1>] ? __nla_reserve+0x21/0xd0
[ 11.973950] [<817ca7ab>] dev_get_stats+0xcb/0x130
[ 11.973950] [<817ca7ab>] dev_get_stats+0xcb/0x130
[ 11.973950] [<817d5409>] rtnl_fill_ifinfo+0x569/0xe20
[ 11.973950] [<817d5409>] rtnl_fill_ifinfo+0x569/0xe20
[ 11.973950] [<810352e0>] ? kvm_clock_read+0x20/0x30
[ 11.973950] [<810352e0>] ? kvm_clock_read+0x20/0x30
[ 11.973950] [<81008e38>] ? sched_clock+0x8/0x10
[ 11.973950] [<81008e38>] ? sched_clock+0x8/0x10
[ 11.973950] [<8106ba45>] ? sched_clock_local+0x25/0x170
[ 11.973950] [<8106ba45>] ? sched_clock_local+0x25/0x170
[ 11.973950] [<810da6bd>] ? __kmalloc+0x3d/0x90
[ 11.973950] [<810da6bd>] ? __kmalloc+0x3d/0x90
[ 11.973950] [<817b8c10>] ? __kmalloc_reserve.isra.41+0x20/0x70
[ 11.973950] [<817b8c10>] ? __kmalloc_reserve.isra.41+0x20/0x70
[ 11.973950] [<810da81a>] ? slob_alloc_node+0x2a/0x60
[ 11.973950] [<810da81a>] ? slob_alloc_node+0x2a/0x60
[ 11.973950] [<817b919a>] ? __alloc_skb+0x6a/0x2b0
[ 11.973950] [<817b919a>] ? __alloc_skb+0x6a/0x2b0
[ 11.973950] [<817d8795>] rtmsg_ifinfo+0x65/0xe0
[ 11.973950] [<817d8795>] rtmsg_ifinfo+0x65/0xe0
[ 11.973950] [<817cbd31>] register_netdevice+0x531/0x5a0
[ 11.973950] [<817cbd31>] register_netdevice+0x531/0x5a0
[ 11.973950] [<81892b87>] ? ip6_tnl_get_cap+0x27/0x90
[ 11.973950] [<81892b87>] ? ip6_tnl_get_cap+0x27/0x90
[ 11.973950] [<817cbdb6>] register_netdev+0x16/0x30
[ 11.973950] [<817cbdb6>] register_netdev+0x16/0x30
[ 11.973950] [<81f574a6>] vti6_init_net+0x1c4/0x1d4
[ 11.973950] [<81f574a6>] vti6_init_net+0x1c4/0x1d4
[ 11.973950] [<81f573af>] ? vti6_init_net+0xcd/0x1d4
[ 11.973950] [<81f573af>] ? vti6_init_net+0xcd/0x1d4
[ 11.973950] [<817c16df>] ops_init.constprop.11+0x17f/0x1c0
[ 11.973950] [<817c16df>] ops_init.constprop.11+0x17f/0x1c0
[ 11.973950] [<817c1779>] register_pernet_operations.isra.9+0x59/0x90
[ 11.973950] [<817c1779>] register_pernet_operations.isra.9+0x59/0x90
[ 11.973950] [<817c18d1>] register_pernet_device+0x21/0x60
[ 11.973950] [<817c18d1>] register_pernet_device+0x21/0x60
[ 11.973950] [<81f574b6>] ? vti6_init_net+0x1d4/0x1d4
[ 11.973950] [<81f574b6>] ? vti6_init_net+0x1d4/0x1d4
[ 11.973950] [<81f574c7>] vti6_tunnel_init+0x11/0x68
[ 11.973950] [<81f574c7>] vti6_tunnel_init+0x11/0x68
[ 11.973950] [<81f572a1>] ? mip6_init+0x73/0xb4
[ 11.973950] [<81f572a1>] ? mip6_init+0x73/0xb4
[ 11.973950] [<81f0cba4>] do_one_initcall+0xbb/0x15b
[ 11.973950] [<81f0cba4>] do_one_initcall+0xbb/0x15b
[ 11.973950] [<811a00d8>] ? sha_transform+0x528/0x1150
[ 11.973950] [<811a00d8>] ? sha_transform+0x528/0x1150
[ 11.973950] [<81f0c544>] ? repair_env_string+0x12/0x51
[ 11.973950] [<81f0c544>] ? repair_env_string+0x12/0x51
[ 11.973950] [<8105c30d>] ? parse_args+0x2ad/0x440
[ 11.973950] [<8105c30d>] ? parse_args+0x2ad/0x440
[ 11.973950] [<810546be>] ? __usermodehelper_set_disable_depth+0x3e/0x50
[ 11.973950] [<810546be>] ? __usermodehelper_set_disable_depth+0x3e/0x50
[ 11.973950] [<81f0cd27>] kernel_init_freeable+0xe3/0x182
[ 11.973950] [<81f0cd27>] kernel_init_freeable+0xe3/0x182
[ 11.973950] [<81f0c532>] ? do_early_param+0x7a/0x7a
[ 11.973950] [<81f0c532>] ? do_early_param+0x7a/0x7a
[ 11.973950] [<819b5b1b>] kernel_init+0xb/0x100
[ 11.973950] [<819b5b1b>] kernel_init+0xb/0x100
[ 11.973950] [<819cebf7>] ret_from_kernel_thread+0x1b/0x28
[ 11.973950] [<819cebf7>] ret_from_kernel_thread+0x1b/0x28
[ 11.973950] [<819b5b10>] ? rest_init+0xc0/0xc0
[ 11.973950] [<819b5b10>] ? rest_init+0xc0/0xc0
Before 469bdcefdc ("ipv6: fix the use of pcpu_tstats in ip6_vti.c"),
the pcpu_tstats.syncp is not used to pretect the 64bit elements of
pcpu_tstats, so not appear this calltrace.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
br_multicast_set_hash_max() is called from process context in net/bridge/br_sysfs_br.c by the sysfs store_hash_max() function. br_multicast_set_hash_max() calls spin_lock(&br->multicast_lock), which can deadlock the CPU if a softirq that also tries to take the same lock interrupts br_multicast_set_hash_max() while the lock is held . This can happen quite easily when any of the bridge multicast timers expire, which try to take the same lock. The fix here is to use spin_lock_bh(), preventing other softirqs from executing on this CPU. Steps to reproduce: 1. Create a bridge with several interfaces (I used 4). 2. Set the "multicast query interval" to a low number, like 2. 3. Enable the bridge as a multicast querier. 4. Repeatedly set the bridge hash_max parameter via sysfs. # brctl addbr br0 # brctl addif br0 eth1 eth2 eth3 eth4 # brctl setmcqi br0 2 # brctl setmcquerier br0 1 # while true ; do echo 4096 > /sys/class/net/br0/bridge/hash_max; done Signed-off-by: Curt Brune <curt@cumulusnetworks.com> Signed-off-by: Scott Feldman <sfeldma@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
It does not make sense to create an anycast address for an /128-prefix.
Suppress it.
As 32019e651c6fce ("ipv6: Do not leave router anycast address for /127
prefixes.") shows we also may not leave them, because we could accidentally
remove an anycast address the user has allocated or got added via another
prefix.
Cc: François-Xavier Le Bail <fx.lebail@yahoo.com>
Cc: Thomas Haller <thaller@redhat.com>
Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>