summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2017-04-27can: fix CAN BCM build with CONFIG_PROC_FS disabledOliver Hartkopp1-8/+13
The introduced namespace support moved the BCM variables for procfs into a per-net data structure. This leads to a build failure with disabled procfs: on x86_64: when CONFIG_PROC_FS is not enabled: ../net/can/bcm.c:1541:14: error: 'struct netns_can' has no member named 'bcmproc_dir' ../net/can/bcm.c:1601:14: error: 'struct netns_can' has no member named 'bcmproc_dir' ../net/can/bcm.c:1696:11: error: 'struct netns_can' has no member named 'bcmproc_dir' ../net/can/bcm.c:1707:15: error: 'struct netns_can' has no member named 'bcmproc_dir' http://marc.info/?l=linux-can&m=149321842526524&w=2 Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2017-04-26Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller84-249/+617
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparcLinus Torvalds6-2/+49
Pull sparc fixes from David Miller: "I didn't want the release to go out without the statx system call properly hooked up" * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc: sparc: Update syscall tables. sparc64: Fill in rest of HAVE_REGS_AND_STACK_ACCESS_API
2017-04-26statx: Kill fd-with-NULL-path support in favour of AT_EMPTY_PATHDavid Howells1-7/+6
With the new statx() syscall, the following both allow the attributes of the file attached to a file descriptor to be retrieved: statx(dfd, NULL, 0, ...); and: statx(dfd, "", AT_EMPTY_PATH, ...); Change the code to reject the first option, though this means copying the path and engaging pathwalk for the fstat() equivalent. dfd can be a non-directory provided path is "". [ The timing of this isn't wonderful, but applying this now before we have statx() in any released kernel, before anybody starts using the NULL special case. - Linus ] Fixes: a528d35e8bfc ("statx: Add a system call to make enhanced file info available") Reported-by: Michael Kerrisk <mtk.manpages@gmail.com> Signed-off-by: David Howells <dhowells@redhat.com> cc: Eric Sandeen <sandeen@sandeen.net> cc: fstests@vger.kernel.org cc: linux-api@vger.kernel.org cc: linux-man@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-04-26Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds44-141/+373
Pull networking fixes from David Miller: 1) MLX5 bug fixes from Saeed Mahameed et al: - released wrong resources when firmware timeout happens - fix wrong check for encapsulation size limits - UAR memory leak - ETHTOOL_GRXCLSRLALL failed to fill in info->data 2) Don't cache l3mdev on mis-matches local route, causes net devices to leak refs. From Robert Shearman. 3) Handle fragmented SKBs properly in macsec driver, the problem is that we were mis-sizing the sgvec table. From Jason A. Donenfeld. 4) We cannot have checksum offload enabled for inner UDP tunneled packet during IPSEC, from Ansis Atteka. 5) Fix double SKB free in ravb driver, from Dan Carpenter. 6) Fix CPU port handling in b53 DSA driver, from Florian Dainelli. 7) Don't use on-stack buffers for usb_control_msg() in CAN usb driver, from Maksim Salau. 8) Fix device leak in macvlan driver, from Herbert Xu. We have to purge the broadcast queue properly on port destroy. 9) Fix tx ring entry limit on EF10 devices in sfc driver. From Bert Kenward. 10) Fix memory leaks in team driver, from Pan Bian. 11) Don't setup ipv6_stub before it can be actually used, from Paolo Abeni. 12) Fix tipc socket flow control accounting, from Parthasarathy Bhuvaragan. 13) Fix crash on module unload in hso driver, from Andreas Kemnade. 14) Fix purging of bridge multicast entries, the problem is that if we don't defer it to ndo_uninit it's possible for new entries to get added after we purge. Fix from Xin Long. 15) Don't return garbage for PACKET_HDRLEN getsockopt, from Alexander Potapenko. 16) Fix autoneg stall properly in PHY layer, and revert micrel driver change that was papering over it. From Alexander Kochetkov. 17) Don't dereference an ipv4 route as an ipv6 one in the ip6_tunnnel code, from Cong Wang. 18) Clear out the congestion control private of the TCP socket in all of the right places, from Wei Wang. 19) rawv6_ioctl measures SKB length incorrectly, fix from Jamie Bainbridge. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (41 commits) ipv6: check raw payload size correctly in ioctl tcp: memset ca_priv data to 0 properly ipv6: check skb->protocol before lookup for nexthop net: core: Prevent from dereferencing null pointer when releasing SKB macsec: dynamically allocate space for sglist Revert "phy: micrel: Disable auto negotiation on startup" net: phy: fix auto-negotiation stall due to unavailable interrupt net/packet: check length in getsockopt() called with PACKET_HDRLEN net: ipv6: regenerate host route if moved to gc list bridge: move bridge multicast cleanup to ndo_uninit ipv6: fix source routing qed: Fix error in the dcbx app meta data initialization. netvsc: fix calculation of available send sections net: hso: fix module unloading tipc: fix socket flow control accounting error at tipc_recv_stream tipc: fix socket flow control accounting error at tipc_send_stream ipv6: move stub initialization after ipv6 setup completion team: fix memory leaks sfc: tx ring can only have 2048 entries for all EF10 NICs macvlan: Fix device ref leak when purging bc_queue ...
2017-04-26ipv6: check raw payload size correctly in ioctlJamie Bainbridge1-2/+1
In situations where an skb is paged, the transport header pointer and tail pointer can be the same because the skb contents are in frags. This results in ioctl(SIOCINQ/FIONREAD) incorrectly returning a length of 0 when the length to receive is actually greater than zero. skb->len is already correctly set in ip6_input_finish() with pskb_pull(), so use skb->len as it always returns the correct result for both linear and paged data. Signed-off-by: Jamie Bainbridge <jbainbri@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26tcp: memset ca_priv data to 0 properlyWei Wang1-8/+3
Always zero out ca_priv data in tcp_assign_congestion_control() so that ca_priv data is cleared out during socket creation. Also always zero out ca_priv data in tcp_reinit_congestion_control() so that when cc algorithm is changed, ca_priv data is cleared out as well. We should still zero out ca_priv data even in TCP_CLOSE state because user could call connect() on AF_UNSPEC to disconnect the socket and leave it in TCP_CLOSE state and later call setsockopt() to switch cc algorithm on this socket. Fixes: 2b0a8c9ee ("tcp: add CDG congestion control") Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Wei Wang <weiwan@google.com> Acked-by: Eric Dumazet <edumazet@google.com> Acked-by: Yuchung Cheng <ycheng@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26ipv6: check skb->protocol before lookup for nexthopWANG Cong1-16/+18
Andrey reported a out-of-bound access in ip6_tnl_xmit(), this is because we use an ipv4 dst in ip6_tnl_xmit() and cast an IPv4 neigh key as an IPv6 address: neigh = dst_neigh_lookup(skb_dst(skb), &ipv6_hdr(skb)->daddr); if (!neigh) goto tx_err_link_failure; addr6 = (struct in6_addr *)&neigh->primary_key; // <=== HERE addr_type = ipv6_addr_type(addr6); if (addr_type == IPV6_ADDR_ANY) addr6 = &ipv6_hdr(skb)->daddr; memcpy(&fl6->daddr, addr6, sizeof(fl6->daddr)); Also the network header of the skb at this point should be still IPv4 for 4in6 tunnels, we shold not just use it as IPv6 header. This patch fixes it by checking if skb->protocol is ETH_P_IPV6: if it is, we are safe to do the nexthop lookup using skb_dst() and ipv6_hdr(skb)->daddr; if not (aka IPv4), we have no clue about which dest address we can pick here, we have to rely on callers to fill it from tunnel config, so just fall to ip6_route_output() to make the decision. Fixes: ea3dc9601bda ("ip6_tunnel: Add support for wildcard tunnel endpoints.") Reported-by: Andrey Konovalov <andreyknvl@google.com> Tested-by: Andrey Konovalov <andreyknvl@google.com> Cc: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26virtio-net: on tx, only call napi_disable if tx napi is onWillem de Bruijn1-2/+8
As of tx napi, device down (`ip link set dev $dev down`) hangs unless tx napi is enabled. Else napi_enable is not called, so napi_disable will spin on test_and_set_bit NAPI_STATE_SCHED. Only call napi_disable if tx napi is enabled. Fixes: 5a719c2552ca ("virtio-net: transmit napi") Reported-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Willem de Bruijn <willemb@google.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26Merge branch 'ibmvnic-Move-sub-crq-init-out-of-interrupt-context'David S. Miller1-53/+61
Nathan Fontenot says: ==================== ibmvnic: Move sub crq init out of interrupt context The sub crqs are currently intialized in interrupt context when handling a crq response fromn the vios server. There is no reason they must be initialized there. Moving the initialization of the sub crqs to the ibmvnic_init routine allows us to do the initialization outside of interrupt context and make all of the allocations with GFP_KERNEL instead of GFP_ATOMIC. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26ibmvnic: Move initialization of sub crqs to ibmvnic_initNathan Fontenot1-11/+12
The sub crq structures are initialized in interrupt context while handling the response to crqs when negotiating capabilities for the driver. The sub crqs do not need to be initialized at this point and can be moved to being done from ibmvnic_init. Moving the init of the sub crqs to ibmvnic_init also allows use to allocate the memory with GFP_KERNEL instead of GFP_ATOMIC. Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26ibmvnic: Split initialization of scrqs to its own routineNathan Fontenot1-47/+54
Split the sending of capability request crqs and the initialization of sub crqs into their own routines. This is a first step to moving the allocation of sub-crqs out of interrupt context. Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26net: core: Prevent from dereferencing null pointer when releasing SKBMyungho Jung1-0/+3
Added NULL check to make __dev_kfree_skb_irq consistent with kfree family of functions. Link: https://bugzilla.kernel.org/show_bug.cgi?id=195289 Signed-off-by: Myungho Jung <mhjungk@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26dt-bindings: mdio: Clarify binding documentFlorian Fainelli1-4/+8
The described GPIO reset property is applicable to *all* child PHYs. If we have one reset line per PHY present on the MDIO bus, these automatically become properties of the child PHY nodes. Finally, indicate how the RESET pulse width must be defined, which is the maximum value of all individual PHYs RESET pulse widths determined by reading their datasheets. Fixes: 69226896ad63 ("mdio_bus: Issue GPIO RESET to PHYs.") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Roger Quadros <rogerq@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26Merge branch 'tcp-do-not-use-tcp_time_stamp-for-rcv-autotuning'David S. Miller6-61/+55
Eric Dumazet says: ==================== tcp: do not use tcp_time_stamp for rcv autotuning Some devices or linux distributions use HZ=100 or HZ=250 TCP receive buffer autotuning has poor behavior caused by this choice. Since autotuning happens after 4 ms or 10 ms, short distance flows get their receive buffer tuned to a very high value, but after an initial period where it was frozen to (too small) initial value. With BBR (or other CC allowing to increase BDP), we are willing to increase tcp_rmem[2], but this receive autotuning defect is a blocker for hosts dealing with gazillions of TCP flows in the data centers, since many of them have inflated RCVBUF. Risk of OOM is too high. Note that TSO autodefer, tcp cubic, and TCP TS options (RFC 7323) also suffer from our dependency to jiffies (via tcp_time_stamp). We have ongoing efforts to improve all that in the future. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26tcp: switch rcv_rtt_est and rcvq_space to high resolution timestampsEric Dumazet3-18/+24
Some devices or distributions use HZ=100 or HZ=250 TCP receive buffer autotuning has poor behavior caused by this choice. Since autotuning happens after 4 ms or 10 ms, short distance flows get their receive buffer tuned to a very high value, but after an initial period where it was frozen to (too small) initial value. With tp->tcp_mstamp introduction, we can switch to high resolution timestamps almost for free (at the expense of 8 additional bytes per TCP structure) Note that some TCP stacks use usec TCP timestamps where this patch makes even more sense : Many TCP flows have < 500 usec RTT. Hopefully this finer TS option can be standardized soon. Tested: HZ=100 kernel ./netperf -H lpaa24 -t TCP_RR -l 1000 -- -r 10000,10000 & Peer without patch : lpaa24:~# ss -tmi dst lpaa23 ... skmem:(r0,rb8388608,...) rcv_rtt:10 rcv_space:3210000 minrtt:0.017 Peer with the patch : lpaa23:~# ss -tmi dst lpaa24 ... skmem:(r0,rb428800,...) rcv_rtt:0.069 rcv_space:30000 minrtt:0.017 We can see saner RCVBUF, and more precise rcv_rtt information. Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Soheil Hassas Yeganeh <soheil@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26tcp: remove ack_time from struct tcp_sacktag_stateEric Dumazet1-4/+0
It is no longer needed, everything uses tp->tcp_mstamp instead. Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Soheil Hassas Yeganeh <soheil@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26tcp: use tp->tcp_mstamp in tcp_clean_rtx_queue()Eric Dumazet1-1/+1
Following patch will remove ack_time from struct tcp_sacktag_state Same info is now found in tp->tcp_mstamp Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Soheil Hassas Yeganeh <soheil@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26tcp: do not pass timestamp to tcp_rack_advance()Eric Dumazet3-9/+5
No longer needed, since tp->tcp_mstamp holds the information. This is needed to remove sack_state.ack_time in a following patch. Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Soheil Hassas Yeganeh <soheil@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26tcp: do not pass timestamp to tcp_rate_gen()Eric Dumazet3-6/+6
No longer needed, since tp->tcp_mstamp holds the information. This is needed to remove sack_state.ack_time in a following patch. Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Soheil Hassas Yeganeh <soheil@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26tcp: do not pass timestamp to tcp_fastretrans_alert()Eric Dumazet1-8/+4
Not used anymore now tp->tcp_mstamp holds the information. This is needed to remove sack_state.ack_time in a following patch. Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Soheil Hassas Yeganeh <soheil@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26tcp: do not pass timestamp to tcp_rack_identify_loss()Eric Dumazet1-5/+4
Not used anymore now tp->tcp_mstamp holds the information. Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Soheil Hassas Yeganeh <soheil@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26tcp: do not pass timestamp to tcp_rack_mark_lost()Eric Dumazet3-3/+3
This is no longer used, since tcp_rack_detect_loss() takes the timestamp from tp->tcp_mstamp Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Soheil Hassas Yeganeh <soheil@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26tcp: do not pass timestamp to tcp_rack_detect_loss()Eric Dumazet1-7/+4
We can use tp->tcp_mstamp as it contains a recent timestamp. This removes a call to skb_mstamp_get() from tcp_rack_reo_timeout() Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Soheil Hassas Yeganeh <soheil@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26tcp: add tp->tcp_mstamp fieldEric Dumazet2-0/+4
We want to use precise timestamps in TCP stack, but we do not want to call possibly expensive kernel time services too often. tp->tcp_mstamp is guaranteed to be updated once per incoming packet. We will use it in the following patches, removing specific skb_mstamp_get() calls, and removing ack_time from struct tcp_sacktag_state. Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Soheil Hassas Yeganeh <soheil@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26macsec: dynamically allocate space for sglistJason A. Donenfeld1-7/+22
We call skb_cow_data, which is good anyway to ensure we can actually modify the skb as such (another error from prior). Now that we have the number of fragments required, we can safely allocate exactly that amount of memory. Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver") Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Acked-by: Sabrina Dubroca <sd@queasysnail.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26rhashtable: remove insecure_max_entries paramFlorian Westphal2-10/+2
no users in the tree, insecure_max_entries is always set to ht->p.max_size * 2 in rhtashtable_init(). Replace only spot that uses it with a ht->p.max_size check. Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26Revert "phy: micrel: Disable auto negotiation on startup"David S. Miller1-11/+0
This reverts commit 99f81afc139c6edd14d77a91ee91685a414a1c66. It was papering over the real problem, which is fixed by commit f555f34fdc58 ("net: phy: fix auto-negotiation stall due to unavailable interrupt") Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26net: phy: fix auto-negotiation stall due to unavailable interruptAlexander Kochetkov2-4/+37
The Ethernet link on an interrupt driven PHY was not coming up if the Ethernet cable was plugged before the Ethernet interface was brought up. The patch trigger PHY state machine to update link state if PHY was requested to do auto-negotiation and auto-negotiation complete flag already set. During power-up cycle the PHY do auto-negotiation, generate interrupt and set auto-negotiation complete flag. Interrupt is handled by PHY state machine but doesn't update link state because PHY is in PHY_READY state. After some time MAC bring up, start and request PHY to do auto-negotiation. If there are no new settings to advertise genphy_config_aneg() doesn't start PHY auto-negotiation. PHY continue to stay in auto-negotiation complete state and doesn't fire interrupt. At the same time PHY state machine expect that PHY started auto-negotiation and is waiting for interrupt from PHY and it won't get it. Fixes: 321beec5047a ("net: phy: Use interrupts when available in NOLINK state") Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com> Cc: stable <stable@vger.kernel.org> # v4.9+ Tested-by: Roger Quadros <rogerq@ti.com> Tested-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-26Merge tag 'sound-4.11' of ↵Linus Torvalds9-28/+54
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "Since we got a bonus week, let me try to screw a few pending fixes. A slightly large fix is the locking fix in ASoC STI driver, but it's pretty board-specific, and the risk is fairly low. All the rest are small / trivial fixes, mostly marked as stable, for ALSA sequencer core, ASoC topology, ASoC Intel bytcr and Firewire drivers" * tag 'sound-4.11' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ASoC: intel: Fix PM and non-atomic crash in bytcr drivers ALSA: firewire-lib: fix inappropriate assignment between signed/unsigned type ALSA: seq: Don't break snd_use_lock_sync() loop by timeout ASoC: topology: Fix to store enum text values ASoC: STI: Fix null ptr deference in IRQ handler ALSA: oxfw: fix regression to handle Stanton SCS.1m/1d
2017-04-25Merge tag 'arc-4.11-final' of ↵Linus Torvalds5-10/+45
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc Pull ARC fix from Vineet Gupta: "Last minute fixes for ARC: - build error in Mellanox nps platform - addressing lack of saving FPU regs in releavnt configs" * tag 'arc-4.11-final' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc: ARCv2: entry: save Accumulator register pair (r58:59) if present ARC: [plat-eznps] Fix build error
2017-04-25net: move xdp_prog field in RX cache linesEric Dumazet1-1/+1
(struct net_device, xdp_prog) field should be moved in RX cache lines, reducing latencies when a single packet is received on idle host, since netif_elide_gro() needs it. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-25net/packet: check length in getsockopt() called with PACKET_HDRLENAlexander Potapenko1-0/+2
In the case getsockopt() is called with PACKET_HDRLEN and optlen < 4 |val| remains uninitialized and the syscall may behave differently depending on its value, and even copy garbage to userspace on certain architectures. To fix this we now return -EINVAL if optlen is too small. This bug has been detected with KMSAN. Signed-off-by: Alexander Potapenko <glider@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-25net: ipv6: regenerate host route if moved to gc listDavid Ahern1-2/+12
Taking down the loopback device wreaks havoc on IPv6 routing. By extension, taking down a VRF device wreaks havoc on its table. Dmitry and Andrey both reported heap out-of-bounds reports in the IPv6 FIB code while running syzkaller fuzzer. The root cause is a dead dst that is on the garbage list gets reinserted into the IPv6 FIB. While on the gc (or perhaps when it gets added to the gc list) the dst->next is set to an IPv4 dst. A subsequent walk of the ipv6 tables causes the out-of-bounds access. Andrey's reproducer was the key to getting to the bottom of this. With IPv6, host routes for an address have the dst->dev set to the loopback device. When the 'lo' device is taken down, rt6_ifdown initiates a walk of the fib evicting routes with the 'lo' device which means all host routes are removed. That process moves the dst which is attached to an inet6_ifaddr to the gc list and marks it as dead. The recent change to keep global IPv6 addresses added a new function, fixup_permanent_addr, that is called on admin up. That function restarts dad for an inet6_ifaddr and when it completes the host route attached to it is inserted into the fib. Since the route was marked dead and moved to the gc list, re-inserting the route causes the reported out-of-bounds accesses. If the device with the address is taken down or the address is removed, the WARN_ON in fib6_del is triggered. All of those faults are fixed by regenerating the host route if the existing one has been moved to the gc list, something that can be determined by checking if the rt6i_ref counter is 0. Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional") Reported-by: Dmitry Vyukov <dvyukov@google.com> Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: David Ahern <dsa@cumulusnetworks.com> Acked-by: Martin KaFai Lau <kafai@fb.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-25bridge: move bridge multicast cleanup to ndo_uninitXin Long2-1/+1
During removing a bridge device, if the bridge is still up, a new mdb entry still can be added in br_multicast_add_group() after all mdb entries are removed in br_multicast_dev_del(). Like the path: mld_ifc_timer_expire -> mld_sendpack -> ... br_multicast_rcv -> br_multicast_add_group The new mp's timer will be set up. If the timer expires after the bridge is freed, it may cause use-after-free panic in br_multicast_group_expired. BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 IP: [<ffffffffa07ed2c8>] br_multicast_group_expired+0x28/0xb0 [bridge] Call Trace: <IRQ> [<ffffffff81094536>] call_timer_fn+0x36/0x110 [<ffffffffa07ed2a0>] ? br_mdb_free+0x30/0x30 [bridge] [<ffffffff81096967>] run_timer_softirq+0x237/0x340 [<ffffffff8108dcbf>] __do_softirq+0xef/0x280 [<ffffffff8169889c>] call_softirq+0x1c/0x30 [<ffffffff8102c275>] do_softirq+0x65/0xa0 [<ffffffff8108e055>] irq_exit+0x115/0x120 [<ffffffff81699515>] smp_apic_timer_interrupt+0x45/0x60 [<ffffffff81697a5d>] apic_timer_interrupt+0x6d/0x80 Nikolay also found it would cause a memory leak - the mdb hash is reallocated and not freed due to the mdb rehash. unreferenced object 0xffff8800540ba800 (size 2048): backtrace: [<ffffffff816e2287>] kmemleak_alloc+0x67/0xc0 [<ffffffff81260bea>] __kmalloc+0x1ba/0x3e0 [<ffffffffa05c60ee>] br_mdb_rehash+0x5e/0x340 [bridge] [<ffffffffa05c74af>] br_multicast_new_group+0x43f/0x6e0 [bridge] [<ffffffffa05c7aa3>] br_multicast_add_group+0x203/0x260 [bridge] [<ffffffffa05ca4b5>] br_multicast_rcv+0x945/0x11d0 [bridge] [<ffffffffa05b6b10>] br_dev_xmit+0x180/0x470 [bridge] [<ffffffff815c781b>] dev_hard_start_xmit+0xbb/0x3d0 [<ffffffff815c8743>] __dev_queue_xmit+0xb13/0xc10 [<ffffffff815c8850>] dev_queue_xmit+0x10/0x20 [<ffffffffa02f8d7a>] ip6_finish_output2+0x5ca/0xac0 [ipv6] [<ffffffffa02fbfc6>] ip6_finish_output+0x126/0x2c0 [ipv6] [<ffffffffa02fc245>] ip6_output+0xe5/0x390 [ipv6] [<ffffffffa032b92c>] NF_HOOK.constprop.44+0x6c/0x240 [ipv6] [<ffffffffa032bd16>] mld_sendpack+0x216/0x3e0 [ipv6] [<ffffffffa032d5eb>] mld_ifc_timer_expire+0x18b/0x2b0 [ipv6] This could happen when ip link remove a bridge or destroy a netns with a bridge device inside. With Nikolay's suggestion, this patch is to clean up bridge multicast in ndo_uninit after bridge dev is shutdown, instead of br_dev_delete, so that netif_running check in br_multicast_add_group can avoid this issue. v1->v2: - fix this issue by moving br_multicast_dev_del to ndo_uninit, instead of calling dev_close in br_dev_delete. (NOTE: Depends upon b6fe0440c637 ("bridge: implement missing ndo_uninit()")) Fixes: e10177abf842 ("bridge: multicast: fix handling of temp and perm entries") Reported-by: Jianwen Ji <jiji@redhat.com> Signed-off-by: Xin Long <lucien.xin@gmail.com> Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-25ipv6: fix source routingSabrina Dubroca1-0/+4
Commit a149e7c7ce81 ("ipv6: sr: add support for SRH injection through setsockopt") introduced handling of IPV6_SRCRT_TYPE_4, but at the same time restricted it to only IPV6_SRCRT_TYPE_0 and IPV6_SRCRT_TYPE_4. Previously, ipv6_push_exthdr() and fl6_update_dst() would also handle other values (ie STRICT and TYPE_2). Restore previous source routing behavior, by handling IPV6_SRCRT_STRICT and IPV6_SRCRT_TYPE_2 the same way as IPV6_SRCRT_TYPE_0 in ipv6_push_exthdr() and fl6_update_dst(). Fixes: a149e7c7ce81 ("ipv6: sr: add support for SRH injection through setsockopt") Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Reviewed-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-25drivers: net: xgene-v2: Fix error return code in xge_mdio_config()Wei Yongjun1-0/+1
Fix to return error code -ENODEV from the no PHY found error handling case instead of 0, as done elsewhere in this function. Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-25net: Generic XDPDavid S. Miller5-22/+187
This provides a generic SKB based non-optimized XDP path which is used if either the driver lacks a specific XDP implementation, or the user requests it via a new IFLA_XDP_FLAGS value named XDP_FLAGS_SKB_MODE. It is arguable that perhaps I should have required something like this as part of the initial XDP feature merge. I believe this is critical for two reasons: 1) Accessibility. More people can play with XDP with less dependencies. Yes I know we have XDP support in virtio_net, but that just creates another depedency for learning how to use this facility. I wrote this to make life easier for the XDP newbies. 2) As a model for what the expected semantics are. If there is a pure generic core implementation, it serves as a semantic example for driver folks adding XDP support. One thing I have not tried to address here is the issue of XDP_PACKET_HEADROOM, thanks to Daniel for spotting that. It seems incredibly expensive to do a skb_cow(skb, XDP_PACKET_HEADROOM) or whatever even if the XDP program doesn't try to push headers at all. I think we really need the verifier to somehow propagate whether certain XDP helpers are used or not. v5: - Handle both negative and positive offset after running prog - Fix mac length in XDP_TX case (Alexei) - Use rcu_dereference_protected() in free_netdev (kbuild test robot) v4: - Fix MAC header adjustmnet before calling prog (David Ahern) - Disable LRO when generic XDP is installed (Michael Chan) - Bypass qdisc et al. on XDP_TX and record the event (Alexei) - Do not perform generic XDP on reinjected packets (DaveM) v3: - Make sure XDP program sees packet at MAC header, push back MAC header if we do XDP_TX. (Alexei) - Elide GRO when generic XDP is in use. (Alexei) - Add XDP_FLAG_SKB_MODE flag which the user can use to request generic XDP even if the driver has an XDP implementation. (Alexei) - Report whether SKB mode is in use in rtnl_xdp_fill() via XDP_FLAGS attribute. (Daniel) v2: - Add some "fall through" comments in switch statements based upon feedback from Andrew Lunn - Use RCU for generic xdp_prog, thanks to Johannes Berg. Tested-by: Andy Gospodarek <andy@greyhouse.net> Tested-by: Jesper Dangaard Brouer <brouer@redhat.com> Tested-by: David Ahern <dsa@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-25qed: fix invalid use of sizeof in qed_alloc_qm_data()Wei Yongjun1-1/+1
sizeof() when applied to a pointer typed expression gives the size of the pointer, not that of the pointed data. Fixes: b5a9ee7cf3be ("qed: Revise QM configuration") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Acked-by: Yuval Mintz <Yuval.Mintz@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-25qed: Fix error in the dcbx app meta data initialization.sudarsana.kalluru@cavium.com1-5/+5
DCBX app_data array is initialized with the incorrect values for personality field. This would prevent offloaded protocols from honoring the PFC. Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-25bpf: map_get_next_key to return first key on NULLTeng Qin5-20/+50
When iterating through a map, we need to find a key that does not exist in the map so map_get_next_key will give us the first key of the map. This often requires a lot of guessing in production systems. This patch makes map_get_next_key return the first key when the key pointer in the parameter is NULL. Signed-off-by: Teng Qin <qinteng@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-25netvsc: fix calculation of available send sectionsstephen hemminger2-6/+4
My change (introduced in 4.11) to use find_first_clear_bit incorrectly assumed that the size argument was words, not bits. The effect was only a small limited number of the available send sections were being actually used. This can cause performance loss with some workloads. Since map_words is now used only during initialization, it can be on stack instead of in per-device data. Fixes: b58a185801da ("netvsc: simplify get next send section") Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-25selftests/net: Fix broken test case in psock_fanoutMike Maloney1-1/+1
The error return falue form sock_fanout_open is -1, not zero. One test case was checking for 0 instead of -1. Tested: Built and tested in clean client. Signed-off-by: Mike Maloney <maloney@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-25net: ethernet: ti: netcp_core: remove unused compl queue mappingIvan Khoronzhuk1-4/+0
This code is unused and probably was unintentionally left while moving completion queue mapping in submit function. Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-25net: hso: fix module unloadingAndreas Kemnade1-1/+1
keep tty driver until usb driver is unregistered rmmod hso produces traces like this without that: [40261.645904] usb 2-2: new high-speed USB device number 2 using ehci-omap [40261.854644] usb 2-2: New USB device found, idVendor=0af0, idProduct=8800 [40261.862609] usb 2-2: New USB device strings: Mfr=3, Product=2, SerialNumber=0 [40261.872772] usb 2-2: Product: Globetrotter HSUPA Modem [40261.880279] usb 2-2: Manufacturer: Option N.V. [40262.021270] hso 2-2:1.5: Not our interface [40265.556945] hso: unloaded [40265.559875] usbcore: deregistering interface driver hso [40265.595947] Unable to handle kernel NULL pointer dereference at virtual address 00000033 [40265.604522] pgd = ecb14000 [40265.611877] [00000033] *pgd=00000000 [40265.617034] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [40265.622650] Modules linked in: hso(-) bnep bluetooth ipv6 arc4 twl4030_madc_hwmon wl18xx wlcore mac80211 cfg80211 snd_soc_simple_card snd_soc_simple_card_utils snd_soc_omap_twl4030 snd_soc_gtm601 generic_adc_battery extcon_gpio omap3_isp videobuf2_dma_contig videobuf2_memops wlcore_sdio videobuf2_v4l2 videobuf2_core ov9650 bmp280_i2c v4l2_common bmp280 bmg160_i2c bmg160_core at24 nvmem_core videodev bmc150_accel_i2c bmc150_magn_i2c media bmc150_accel_core tsc2007 bmc150_magn leds_tca6507 bno055 snd_soc_omap_mcbsp industrialio_triggered_buffer snd_soc_omap kfifo_buf snd_pcm_dmaengine gpio_twl4030 snd_soc_twl4030 twl4030_vibra twl4030_madc wwan_on_off ehci_omap pwm_bl pwm_omap_dmtimer panel_tpo_td028ttec1 encoder_opa362 connector_analog_tv omapdrm drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect [40265.698211] sysimgblt fb_sys_fops cfbcopyarea drm omapdss usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs omap2430 phy_twl4030_usb musb_hdrc twl4030_charger industrialio w2sg0004 twl4030_pwrbutton bq27xxx_battery w1_bq27000 omap_hdq [last unloaded: hso] [40265.723175] CPU: 0 PID: 2701 Comm: rmmod Not tainted 4.11.0-rc6-letux+ #6 [40265.730346] Hardware name: Generic OMAP36xx (Flattened Device Tree) [40265.736938] task: ecb81100 task.stack: ecb82000 [40265.741729] PC is at cdev_del+0xc/0x2c [40265.745666] LR is at tty_unregister_device+0x40/0x50 [40265.750915] pc : [<c027472c>] lr : [<c04b3ecc>] psr: 600b0113 sp : ecb83ea8 ip : eca4f898 fp : 00000000 [40265.763000] r10: 00000000 r9 : 00000000 r8 : 00000001 [40265.768493] r7 : eca4f800 r6 : 00000003 r5 : 00000000 r4 : ffffffff [40265.775360] r3 : c1458d54 r2 : 00000000 r1 : 00000004 r0 : ffffffff [40265.782257] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [40265.789764] Control: 10c5387d Table: acb14019 DAC: 00000051 [40265.795806] Process rmmod (pid: 2701, stack limit = 0xecb82218) [40265.802062] Stack: (0xecb83ea8 to 0xecb84000) [40265.806640] 3ea0: ec9e8100 c04b3ecc bf737378 ed5b7c00 00000003 bf7327ec [40265.815277] 3ec0: eca4f800 00000000 ec9fd800 eca4f800 bf737070 bf7328bc eca4f820 c05a9a04 [40265.823883] 3ee0: eca4f820 00000000 00000001 eca4f820 ec9fd870 bf737070 eca4f854 ec9fd8a4 [40265.832519] 3f00: ecb82000 00000000 00000000 c04e6960 eca4f820 bf737070 bf737048 00000081 [40265.841125] 3f20: c01071e4 c04e6a60 ecb81100 bf737070 bf737070 c04e5d94 bf737020 c05a8f88 [40265.849731] 3f40: bf737100 00000800 7f5fa254 00000081 c01071e4 c01c4afc 00000000 006f7368 [40265.858367] 3f60: ecb815f4 00000000 c0cac9c4 c01071e4 ecb82000 00000000 00000000 c01512f4 [40265.866973] 3f80: ed5b3200 c01071e4 7f5fa220 7f5fa220 bea78ec9 0010711c 7f5fa220 7f5fa220 [40265.875579] 3fa0: bea78ec9 c0107040 7f5fa220 7f5fa220 7f5fa254 00000800 dd35b800 dd35b800 [40265.884216] 3fc0: 7f5fa220 7f5fa220 bea78ec9 00000081 bea78dcc 00000000 bea78bd8 00000000 [40265.892822] 3fe0: b6f70521 bea78b6c 7f5dd613 b6f70526 80070030 7f5fa254 ffffffff ffffffff [40265.901458] [<c027472c>] (cdev_del) from [<c04b3ecc>] (tty_unregister_device+0x40/0x50) [40265.909942] [<c04b3ecc>] (tty_unregister_device) from [<bf7327ec>] (hso_free_interface+0x80/0x144 [hso]) [40265.919982] [<bf7327ec>] (hso_free_interface [hso]) from [<bf7328bc>] (hso_disconnect+0xc/0x18 [hso]) [40265.929718] [<bf7328bc>] (hso_disconnect [hso]) from [<c05a9a04>] (usb_unbind_interface+0x84/0x200) [40265.939239] [<c05a9a04>] (usb_unbind_interface) from [<c04e6960>] (device_release_driver_internal+0x138/0x1cc) [40265.949798] [<c04e6960>] (device_release_driver_internal) from [<c04e6a60>] (driver_detach+0x60/0x6c) [40265.959503] [<c04e6a60>] (driver_detach) from [<c04e5d94>] (bus_remove_driver+0x64/0x8c) [40265.968017] [<c04e5d94>] (bus_remove_driver) from [<c05a8f88>] (usb_deregister+0x5c/0xb8) [40265.976654] [<c05a8f88>] (usb_deregister) from [<c01c4afc>] (SyS_delete_module+0x160/0x1dc) [40265.985443] [<c01c4afc>] (SyS_delete_module) from [<c0107040>] (ret_fast_syscall+0x0/0x1c) [40265.994171] Code: c1458d54 e59f3020 e92d4010 e1a04000 (e5941034) [40266.016693] ---[ end trace 9d5ac43c7e41075c ]--- Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-25Merge branch 'qed-vf-tunnel'David S. Miller17-255/+857
Manish Chopra says: ==================== qed/qede: VF tunnelling support With this series VFs can run vxlan/geneve/gre tunnels over it. Please consider applying this series to "net-next" ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-25qed - VF tunnelling support [VXLAN/GENEVE/GRE]Chopra, Manish8-4/+446
This patch adds hardware channel APIs support between VF and PF for tunnelling configuration for the VFs. According to that configuration VFs can run VXLAN/GENEVE/GRE tunnels over it with tunnel features offloaded. Using these APIs VF can also request for UDP ports configuration to the PF, although PF and it's child VFs share the same port. Signed-off-by: Manish Chopra <manish.chopra@cavium.com> Signed-off-by: Yuval Mintz <yuval.mintz@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-25qed/qede: Add UDP ports in bulletin boardChopra, Manish9-1/+84
This patch adds support for UDP ports in bulletin board to notify UDP ports change to the VFs Signed-off-by: Manish Chopra <manish.chopra@cavium.com> Signed-off-by: Yuval Mintz <yuval.mintz@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-25qede: Configure UDP ports in local context.Chopra, Manish3-36/+52
This patch configures UDP ports locally instead of configuring them in deferred context which would be helpful in synchronizing UDP ports configuration for VFs which will be enabled in further patches. Signed-off-by: Manish Chopra <manish.chopra@cavium.com> Signed-off-by: Yuval Mintz <yuval.mintz@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-25qede: Disable tunnel offloads for non offloaded UDP portsChopra, Manish1-6/+17
This patch disables tunnel offloads via ndo_features_check() if given UDP port is not offloaded to hardware. This in turn allows to run multiple tunnel interfaces using different UDP ports. Signed-off-by: Manish Chopra <manish.chopra@cavium.com> Signed-off-by: Yuval Mintz <yuval.mintz@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-25 01:39:56 +0000