- 13 Mar, 2017 7 commits
-
-
David Ahern authored
Multipath routes can be rendered usesless when a device in one of the paths is deleted. For example: $ ip -f mpls ro ls 100 nexthop as to 200 via inet 172.16.2.2 dev virt12 nexthop as to 300 via inet 172.16.3.2 dev br0 101 nexthop as to 201 via inet6 2000:2::2 dev virt12 nexthop as to 301 via inet6 2000:3::2 dev br0 $ ip li del br0 When br0 is deleted the other hop is not considered in mpls_select_multipath because of the alive check -- rt_nhn_alive is 0. rt_nhn_alive is decremented once in mpls_ifdown when the device is taken down (NETDEV_DOWN) and again when it is deleted (NETDEV_UNREGISTER). For a 2 hop route, deleting one device drops the alive count to 0. Since devices are taken down before unregistering, the decrement on NETDEV_UNREGISTER is redundant. Fixes: c89359a4 ("mpls: support for dead routes") Signed-off-by:
David Ahern <dsa@cumulusnetworks.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Igor Druzhinin authored
In some cases during XenBus disconnect event handling and subsequent queue resource release there may be some TX handlers active on other processors. Use RCU in order to synchronize with them. Signed-off-by:
Igor Druzhinin <igor.druzhinin@citrix.com> Signed-off-by:
-
David Ahern authored
When the mpls_router module is unloaded, mpls routes are deleted but notifications are not sent to userspace leaving userspace caches out of sync. Add the call to mpls_notify_route in mpls_net_exit as routes are freed. Fixes: 0189197f ("mpls: Basic routing support") Signed-off-by:
-
Etienne Noss authored
tcf_connmark_init does not check in its configuration if TCA_CONNMARK_PARMS is set, resulting in a null pointer dereference when trying to access it. [501099.043007] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 [501099.043039] IP: [<ffffffffc10c60fb>] tcf_connmark_init+0x8b/0x180 [act_connmark] ... [501099.044334] Call Trace: [501099.044345] [<ffffffffa47270e8>] ? tcf_action_init_1+0x198/0x1b0 [501099.044363] [<ffffffffa47271b0>] ? tcf_action_init+0xb0/0x120 [501099.044380] [<ffffffffa47250a4>] ? tcf_exts_validate+0xc4/0x110 [501099.044398] [<ffffffffc0f5fa97>] ? u32_set_parms+0xa7/0x270 [cls_u32] [501099.044417] [<ffffffffc0f60bf0>] ? u32_change+0x680/0x87b [cls_u32] [501099.044436] [<ffffffffa4725d1d>] ? tc_ctl_tfilter+0x4dd/0x8a0 [501099.044454] [<ffffffffa44a23a1>] ? security_capable+0x41/0x60 [501099.044471] [<ffffffffa470ca01>] ? rtnetlink_rcv_msg+0xe1/0x220 [501099.044490] [<ffffffffa470c920>] ? rtnl_newlink+0x870/0x870 [501099.044507] [<ffffffffa472cc61>] ? netlink_rcv_skb+0xa1/0xc0 [501099.044524] [<ffffffffa47073f4>] ? rtnetlink_rcv+0x24/0x30 [501099.044541] [<ffffffffa472c634>] ? netlink_unicast+0x184/0x230 [501099.044558] [<ffffffffa472c9d8>] ? netlink_sendmsg+0x2f8/0x3b0 [501099.044576] [<ffffffffa46d8880>] ? sock_sendmsg+0x30/0x40 [501099.044592] [<ffffffffa46d8e03>] ? SYSC_sendto+0xd3/0x150 [501099.044608] [<ffffffffa425fda1>] ? __do_page_fault+0x2d1/0x510 [501099.044626] [<ffffffffa47fbd7b>] ? system_call_fast_compare_end+0xc/0x9b Fixes: 22a5dc0e ("net: sched: Introduce connmark action") Signed-off-by:
Étienne Noss <etienne.noss@wifirst.fr> Signed-off-by:
Victorien Molle <victorien.molle@wifirst.fr> Acked-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
Neil Jerram authored
It wasn't clear if the 'forwarding' setting needs to be enabled on the interface that packets are received from, or on the interface that packets are forwarded to, or both. In fact (according to my code reading) the setting is relevant on the interface that packets are received from, so this change updates the doc to say that. Signed-off-by:
Neil Jerram <neil@tigera.io> Signed-off-by:
-
stephen hemminger authored
Move the send indirection table from the inner device (netvsc) to the network device context. It is possible that netvsc_device is not present (remove in progress). This solves potential use after free issues when packet is being created during MTU change, shutdown, or queue count changes. Fixes: d8e18ee0 ("netvsc: enhance transmit select_queue") Signed-off-by:
Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by:
-
David Arcari authored
When a network interface controlled by the aquantia ethernet driver is brought down a warning is output in dmesg (see below). The problem is that aq_pci_func_free_irqs() is calling free_irq() before it is calling irq_set_affinity_hint(). WARNING: CPU: 4 PID: 10068 at kernel/irq/manage.c:1503 __free_irq+0x24d/0x2b0 <snip> Call Trace: dump_stack+0x63/0x87 __warn+0xd1/0xf0 warn_slowpath_null+0x1d/0x20 __free_irq+0x24d/0x2b0 free_irq+0x39/0x90 aq_pci_func_free_irqs+0x52/0xa0 [atlantic] aq_nic_stop+0xca/0xd0 [atlantic] aq_ndev_close+0x1d/0x40 [atlantic] __dev_close_many+0x99/0x100 __dev_close+0x67/0xb0 <snip> Fixes: 36a4a50f ("net: ethernet: aquantia: switch to pci_alloc_irq_vectors") Cc: Christoph Hellwig <hch@lst.de> Cc: Pavel Belous <pavel.belous@aquantia.com> Signed-off-by:
David Arcari <darcari@redhat.com> Tested-by:
Pavel Belous <pavel.belous@aquantia.com> Signed-off-by:
-
- 10 Mar, 2017 28 commits
-
-
David S. Miller authored
Saeed Mahameed says: ==================== Mellanox mlx5 fixes 2017-03-09 This series contains some mlx5 core and ethernet driver fixes. For -stable: net/mlx5e: remove IEEE/CEE mode check when setting DCBX mode (for kernel >= 4.10) net/mlx5e: Avoid wrong identification of rules on deletion (for kernel >= 4.9) net/mlx5: Don't save PCI state when PCI error is detected (for kernel >= 4.9) net/mlx5: Fix create autogroup prev initializer (for kernel >=4.9) ==================== Signed-off-by: -
Eugenia Emantayev authored
Change packet type handler to ETH_P_IP instead of ETH_P_ALL since we are already expecting an IP packet. Also, using ETH_P_ALL will cause the loopback test packet type handler to be called on all outgoing packets, especially our own self loopback test SKB, which will be validated on xmit as well, and we don't want that. Tested with: ethtool -t ethX validated that the loopback test passes. Fixes: 0952da79 ('net/mlx5e: Add support for loopback selftest') Signed-off-by:
Eugenia Emantayev <eugenia@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
-
Or Gerlitz authored
When deleting offloaded TC flows, we must correctly identify E-switch rules. The current check could get us wrong w.r.t to rules set on the PF. Since it's possible to set NIC rules on the PF, switch to SRIOV offloads mode and then attempt to delete a NIC rule. To solve that, we add a flags field to offloaded rules, set it on creation time and use that over the code where currently needed. Fixes: 8b32580d ('net/mlx5e: Add TC vlan action for SRIOV offloads') Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Reviewed-by:
Roi Dayan <roid@mellanox.com> Signed-off-by:
-
Huy Nguyen authored
Currently, the function setdcbx fails if the request dcbx mode is either IEEE or CEE. We remove the IEEE/CEE mode check because we support both IEEE and CEE interfaces. Fixes: 3a6a931d ("net/mlx5e: Support DCBX CEE API") Signed-off-by:
Huy Nguyen <huyn@mellanox.com> Reviewed-by:
Daniel Jurgens <danielj@mellanox.com> Signed-off-by:
-
Daniel Jurgens authored
When a PCI error is detected the PCI state could be corrupt, don't save it in that flow. Save the state after initialization. After restoring the PCI state during slot reset save it again, restoring the state destroys the previously saved state info. Fixes: 05ac2c0b ('net/mlx5: Fix race between PCI error handlers and health work') Signed-off-by:
-
Paul Blakey authored
The autogroups list is a list of non overlapping group boundaries sorted by their start index. If the autogroups list wasn't empty and an empty group slot was found at the start of the list, the new group was added to the end of the list instead of the beginning, as the prev initializer was incorrect. When this was repeated, it caused multiple groups to have overlapping boundaries. Fixed that by correctly initializing the prev pointer to the start of the list. Fixes: eccec8da ('net/mlx5: Keep autogroups list ordered') Signed-off-by:
Paul Blakey <paulb@mellanox.com> Reviewed-by:
Mark Bloch <markb@mellanox.com> Signed-off-by:
-
David Howells authored
The RxRPC ACK packet may contain an extension that includes the peer's current Rx window size for this call. We adjust the local Tx window size to match. However, the transmitter can stall if the receive window is reduced to 0 by the peer and then reopened. This is because the normal way that the transmitter is re-energised is by dropping something out of our Tx queue and thus making space. When a single gap is made, the transmitter is woken up. However, because there's nothing in the Tx queue at this point, this doesn't happen. To fix this, perform a wake_up() any time we see the peer's Rx window size increasing. The observable symptom is that calls start failing on ETIMEDOUT and the following: kAFS: SERVER DEAD state=-62 appears in dmesg. Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Andrew Lunn authored
The hwmon temperature sensor devices is registered using a devm_hwmon API call. The marvell_release() would then manually free the device, not using a devm_hmon API, resulting in the device being removed twice, leading to a crash in kernfs_find_ns() during the second removal. Remove the manual removal, which makes marvell_release() empty, so remove it as well. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Fixes: 0b04680f ("phy: marvell: Add support for temperature sensor") Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
David S. Miller authored
Doug Berger says: ==================== net: bcmgenet: minor bug fixes v2: Accidentally sent the wrong set after rebasing. This collection contains a number of fixes for minor issues with the bcmgenet driver most of which were present in the initial submission of the driver. Some bugs were uncovered by inspection prior to the upcoming update for GENETv5 support: net: bcmgenet: correct the RBUF_OVFL_CNT and RBUF_ERR_CNT MIB values net: bcmgenet: correct MIB access of UniMAC RUNT counters net: bcmgenet: reserved phy revisions must be checked first net: bcmgenet: synchronize irq0 status between the isr and task Others bugs were found in power management testing: net: bcmgenet: power down internal phy if open or resume fails net: bcmgenet: Power up the internal PHY before probing the MII net: bcmgenet: decouple flow control from bcmgenet_tx_reclaim net: bcmgenet: add begin/complete ethtool ops Doug Berger (7): net: bcmgenet: correct the RBUF_OVFL_CNT and RBUF_ERR_CNT MIB values net: bcmgenet: correct MIB access of UniMAC RUNT counters net: bcmgenet: reserved phy revisions must be checked first net: bcmgenet: power down internal phy if open or resume fails net: bcmgenet: synchronize irq0 status between the isr and task net: bcmgenet: Power up the internal PHY before probing the MII net: bcmgenet: decouple flow control from bcmgenet_tx_reclaim Edwin Chan (1): net: bcmgenet: add begin/complete ethtool ops ==================== Signed-off-by: -
Doug Berger authored
The bcmgenet_tx_reclaim() function is used to reclaim transmit resources in different places within the driver. Most of them should not affect the state of the transmit flow control. This commit relocates the logic for waking tx queues based on freed resources to the napi polling function where it is more appropriate. Fixes: 1c1008c7 ("net: bcmgenet: add main driver file") Signed-off-by:
Doug Berger <opendmb@gmail.com> Reviewed-by:
-
Edwin Chan authored
Make sure clock is enabled for ethtool ops. Fixes: 1c1008c7 ("net: bcmgenet: add main driver file") Signed-off-by:
Edwin Chan <edwin.chan@broadcom.com> Signed-off-by:
-
Doug Berger authored
When using the internal PHY it must be powered up when the MII is probed or the PHY will not be detected. Since the PHY is powered up at reset this has not been a problem. However, when the kernel is restarted with kexec the PHY will likely be powered down when the kernel starts so it will not be detected and the Ethernet link will not be established. This commit explicitly powers up the internal PHY when the GENET driver is probed to correct this behavior. Fixes: 1c1008c7 ("net: bcmgenet: add main driver file") Signed-off-by:
-
Doug Berger authored
Add a spinlock to ensure that irq0_stat is not unintentionally altered as the result of preemption. Also removed unserviced irq0 interrupts and removed irq1_stat since there is no bottom half service for those interrupts. Fixes: 1c1008c7 ("net: bcmgenet: add main driver file") Signed-off-by:
-
Doug Berger authored
Since the internal PHY is powered up during the open and resume functions it should be powered back down if the functions fail. Fixes: 1c1008c7 ("net: bcmgenet: add main driver file") Signed-off-by:
-
Doug Berger authored
The reserved gphy_rev value of 0x01ff must be tested before the old or new scheme for GPHY major versioning are tested, otherwise it will be treated as 0xff00 according to the old scheme. Fixes: b04a2f5b ("net: bcmgenet: add support for new GENET PHY revision scheme") Signed-off-by:
-
Doug Berger authored
The gap between the Tx status counters and the Rx RUNT counters is now being added to allow correct reporting of the registers. Fixes: 1c1008c7 ("net: bcmgenet: add main driver file") Signed-off-by:
-
Doug Berger authored
The location of the RBUF overflow and error counters has moved between different version of the GENET MAC. This commit corrects the driver to read from the correct locations depending on the version of the GENET MAC. Fixes: 1c1008c7 ("net: bcmgenet: add main driver file") Signed-off-by:
-
Lendacky, Thomas authored
Depending on the hardware, the amd-xgbe driver may use disable_irq_nosync() and enable_irq() when an interrupt is received to process Rx packets. If the napi_complete_done() return value isn't checked an unbalanced enable for the IRQ could result, generating a warning stack trace. Update the driver to only enable interrupts if napi_complete_done() returns true. Reported-by:
Jeremy Linton <jeremy.linton@arm.com> Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
-
David Howells authored
If rxrpc_kernel_send_data() is asked to send data through a call that has already failed (due to a remote abort, received protocol error or network error), then return the associated error code saved in the call rather than ESHUTDOWN. This allows the caller to work out whether to ask for the abort code or not based on this. Signed-off-by:
-
Alexey Kodanev authored
commit c146066a ("ipv4: Don't use ufo handling on later transformed packets") and commit f89c56ce ("ipv6: Don't use ufo handling on later transformed packets") added a check that 'rt->dst.header_len' isn't zero in order to skip UFO, but it doesn't include IPcomp in transport mode where it equals zero. Packets, after payload compression, may not require further fragmentation, and if original length exceeds MTU, later compressed packets will be transmitted incorrectly. This can be reproduced with LTP udp_ipsec.sh test on veth device with enabled UFO, MTU is 1500 and UDP payload is 2000: * IPv4 case, offset is wrong + unnecessary fragmentation udp_ipsec.sh -p comp -m transport -s 2000 & tcpdump -ni ltp_ns_veth2 ... IP (tos 0x0, ttl 64, id 45203, offset 0, flags [+], proto Compressed IP (108), length 49) 10.0.0.2 > 10.0.0.1: IPComp(cpi=0x1000) IP (tos 0x0, ttl 64, id 45203, offset 1480, flags [none], proto UDP (17), length 21) 10.0.0.2 > 10.0.0.1: ip-proto-17 * IPv6 case, sending small fragments udp_ipsec.sh -6 -p comp -m transport -s 2000 & tcpdump -ni ltp_ns_veth2 ... IP6 (flowlabel 0x6b9ba, hlim 64, next-header Compressed IP (108) payload length: 37) fd00::2 > fd00::1: IPComp(cpi=0x1000) IP6 (flowlabel 0x6b9ba, hlim 64, next-header Compressed IP (108) payload length: 21) fd00::2 > fd00::1: IPComp(cpi=0x1000) Fix it by checking 'rt->dst.xfrm' pointer to 'xfrm_state' struct, skip UFO if xfrm is set. So the new check will include both cases: IPcomp and IPsec. Fixes: c146066a ("ipv4: Don't use ufo handling on later transformed packets") Fixes: f89c56ce ("ipv6: Don't use ufo handling on later transformed packets") Signed-off-by:
Alexey Kodanev <alexey.kodanev@oracle.com> Signed-off-by:
-
David Howells authored
Lockdep issues a circular dependency warning when AFS issues an operation through AF_RXRPC from a context in which the VFS/VM holds the mmap_sem. The theory lockdep comes up with is as follows: (1) If the pagefault handler decides it needs to read pages from AFS, it calls AFS with mmap_sem held and AFS begins an AF_RXRPC call, but creating a call requires the socket lock: mmap_sem must be taken before sk_lock-AF_RXRPC (2) afs_open_socket() opens an AF_RXRPC socket and binds it. rxrpc_bind() binds the underlying UDP socket whilst holding its socket lock. inet_bind() takes its own socket lock: sk_lock-AF_RXRPC must be taken before sk_lock-AF_INET (3) Reading from a TCP socket into a userspace buffer might cause a fault and thus cause the kernel to take the mmap_sem, but the TCP socket is locked whilst doing this: sk_lock-AF_INET must be taken before mmap_sem However, lockdep's theory is wrong in this instance because it deals only with lock classes and not individual locks. The AF_INET lock in (2) isn't really equivalent to the AF_INET lock in (3) as the former deals with a socket entirely internal to the kernel that never sees userspace. This is a limitation in the design of lockdep. Fix the general case by: (1) Double up all the locking keys used in sockets so that one set are used if the socket is created by userspace and the other set is used if the socket is created by the kernel. (2) Store the kern parameter passed to sk_alloc() in a variable in the sock struct (sk_kern_sock). This informs sock_lock_init(), sock_init_data() and sk_clone_lock() as to the lock keys to be used. Note that the child created by sk_clone_lock() inherits the parent's kern setting. (3) Add a 'kern' parameter to ->accept() that is analogous to the one passed in to ->create() that distinguishes whether kernel_accept() or sys_accept4() was the caller and can be passed to sk_alloc(). Note that a lot of accept functions merely dequeue an already allocated socket. I haven't touched these as the new socket already exists before we get the parameter. Note also that there are a couple of places where I've made the accepted socket unconditionally kernel-based: irda_accept() rds_rcp_accept_one() tcp_accept_from_sock() because they follow a sock_create_kern() and accept off of that. Whilst creating this, I noticed that lustre and ocfs don't create sockets through sock_create_kern() and thus they aren't marked as for-kernel, though they appear to be internal. I wonder if these should do that so that they use the new set of lock keys. Signed-off-by: -
David S. Miller authored
Michael Chan says: ==================== bnxt_en: Misc. small fixes. Fixes include moving the initial function reset, notifying the RDMA driver during tx timeout, setting dcbx_cap properly depending on whether the firmware agent is running or not, and an autoneg related improvement. ==================== Signed-off-by: -
Michael Chan authored
In some situations, the firmware will return 0 for autoneg supported speed. This may happen if the firmware detects no SFP module, for example. The driver should ignore this so that we don't end up with an invalid autoneg setting with nothing advertised. When SFP module is inserted, we'll get the updated settings from firmware at that time. Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Michael Chan authored
Set DCB_CAP_DCBX_HOST capability flag only if the firmware LLDP agent is not running. Signed-off-by:
-
Michael Chan authored
If we call bnxt_reset_task() due to tx timeout, we should call bnxt_ulp_stop() to inform the RDMA driver about the error and the impending reset. Signed-off-by:
-
Michael Chan authored
The firmware call to do function reset is done too late. It is causing the rings that have been reserved to be freed. In NPAR mode, this bug is causing us to run out of rings. Fixes: 391be5c2 ("bnxt_en: Implement new scheme to reserve tx rings.") Signed-off-by:
-
LABBE Corentin authored
Printing copyright does not give any useful information on the boot process. Furthermore, the email address printed is obsolete since commit ba57b6f2 ("MAINTAINERS: fix bouncing tun/tap entries") Signed-off-by:
Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by:
-
Alexander Potapenko authored
KMSAN reports a use of uninitialized memory in put_cmsg() because msg.msg_flags in recvfrom haven't been initialized properly. The flag values don't affect the result on this path, but it's still a good idea to initialize them explicitly. Signed-off-by:
Alexander Potapenko <glider@google.com> Signed-off-by:
-
- 09 Mar, 2017 5 commits
-
-
David S. Miller authored
Alexei Starovoitov says: ==================== bpf: htab fixes Two bpf hashtable fixes. See individual patches for details. ==================== Signed-off-by: -
Alexei Starovoitov authored
when all map elements are pre-allocated one cpu can delete and reuse htab_elem while another cpu is still walking the hlist. In such case the lookup may miss the element. Convert hlist to hlist_nulls to avoid such scenario. When bucket lock is taken there is no need to take such precautions, so only convert map_lookup and map_get_next to nulls. The race window is extremely small and only reproducible with explicit udelay() inside lookup_nulls_elem_raw() Similar to hlist add hlist_nulls_for_each_entry_safe() and hlist_nulls_entry_safe() helpers. Fixes: 6c905981 ("bpf: pre-allocate hash map elements") Reported-by:
Jonathan Perry <jonperry@fb.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Alexei Starovoitov authored
when htab_elem is removed from the bucket list the htab_elem.hash_node.next field should not be overridden too early otherwise we have a tiny race window between lookup and delete. The bug was discovered by manual code analysis and reproducible only with explicit udelay() in lookup_elem_raw(). Fixes: 6c905981 ("bpf: pre-allocate hash map elements") Reported-by:
-
Dmitry V. Levin authored
Replace MAX_ADDR_LEN with its numeric value to fix the following linux/packet_diag.h userspace compilation error: /usr/include/linux/packet_diag.h:67:17: error: 'MAX_ADDR_LEN' undeclared here (not in a function) __u8 pdmc_addr[MAX_ADDR_LEN]; This is not the first case in the UAPI where the numeric value of MAX_ADDR_LEN is used instead of symbolic one, uapi/linux/if_link.h already does the same: $ grep MAX_ADDR_LEN include/uapi/linux/if_link.h __u8 mac[32]; /* MAX_ADDR_LEN */ There are no UAPI headers besides these two that use MAX_ADDR_LEN. Signed-off-by:
Dmitry V. Levin <ldv@altlinux.org> Acked-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
-
Paolo Abeni authored
The gso code of several tunnels type (gre and udp tunnels) takes for granted that the skb->inner_protocol is properly initialized and drops the packet elsewhere. On the forwarding path no one is initializing such field, so gro encapsulated packets are dropped on forward. Since commit 38720352 ("gre: Use inner_proto to obtain inner header protocol"), this can be reproduced when the encapsulated packets use gre as the tunneling protocol. The issue happens also with vxlan and geneve tunnels since commit 8bce6d7d ("udp: Generalize skb_udp_segment"), if the forwarding host's ingress nic has h/w offload for such tunnel and a vxlan/geneve device is configured on top of it, regardless of the configured peer address and vni. To address the issue, this change initialize the inner_protocol field for encapsulated packets in both ipv4 and ipv6 gro complete callbacks. Fixes: 38720352 ("gre: Use inner_proto to obtain inner header protocol") Fixes: 8bce6d7d ("udp: Generalize skb_udp_segment") Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Acked-by:
Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
-
