- 29 Aug, 2016 11 commits
-
-
Florian Fainelli authored
Since commit 83c0afae ("net: dsa: Add new binding implementation"), the shortcomings of the dsa platform device have been addressed, remove that TODO item. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Acked-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Saeed Mahameed says: ==================== Mellanox 100G mlx5 fixes 2016-08-29 This series contains some bug fixes for the mlx5 core and mlx5 ethernet driver. From Saeed, Fix UMR to consider hardware translation table field size limitation when calculating the maximum number of MTTs required by the driver. Three patches to speed-up netdevice close time by serializing channel (SQs & RQs) destruction rather than issuing and waiting for hardware interrupts to free them. From Eran, Fix ethtool ring parameter reporting for striding RQ layout. Add error prints on ETS validation failure. From Kamal, Fix memory leak on error flow. From Maor, Fix ethtool steering priorities number. ==================== Signed-off-by: -
Maor Gottlieb authored
Ethtool has 11 flow tables, each flow table has its own priority. Increase the number of priorities to be aligned with the number of flow tables. Fixes: 1174fce8 ('net/mlx5e: Support l3/l4 flow type specs in ethtool flow steering') Signed-off-by:
Maor Gottlieb <maorg@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
-
Eran Ben Elisha authored
Upon set ETS failure due to user invalid input, add error prints to specify the exact error to the user. Fixes: cdcf1121 ('net/mlx5e: Validate BW weight values of ETS') Signed-off-by:
Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by:
-
Kamal Heib authored
Free 'in' command object also when mlx5_core_modify_tir fails. Fixes: 724b2aa1 ("net/mlx5e: TIRs management refactoring") Signed-off-by:
Kamal Heib <kamalh@mellanox.com> Signed-off-by:
-
Tariq Toukan authored
Add a counter in ethtool for the number of times that TX xmit_more was used. Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
-
Eran Ben Elisha authored
The driver RQ has two possible configurations: striding RQ and non-striding RQ. Until this patch, the driver always reported the number of hardware WQEs (ring descriptors). For non striding RQ configuration, this was OK since we have one WQE per pending packet For striding RQ, multiple packets can fit into one WQE. For better user experience we normalize the rx_pending parameter (size of wqe/mtu) as the average ring size in case of striding RQ. Fixes: 461017cb ('net/mlx5e: Support RX multi-packet WQE ...') Signed-off-by:
-
Saeed Mahameed authored
Instead of asking the firmware to flush the SQ (Send Queue) via asynchronous completions when moved to error, we handle SQ flush manually (mlx5e_free_tx_descs) same as we did when SQ flush got timed out or on tx_timeout. This will reduce SQs flush time and speedup interface down procedure. Moved mlx5e_free_tx_descs to the end of en_tx.c for tx critical code locality. Fixes: 29429f33 ('net/mlx5e: Timeout if SQ doesn't flush during close') Signed-off-by:
-
Saeed Mahameed authored
ICO (Internal control operations) SQ (Send Queue) is closed/disabled after RQ (Receive Queue). After RQ is closed an ICO SQ completion might post a fragmented MPWQE (Multi Packet Work Queue Element) into that RQ. As on regular RQ post, check if we are allowed to post to that RQ (RQ is enabled). Cleanup in-progress UMR MPWQE on mlx5e_free_rx_descs if needed. Fixes: bc77b240 ('net/mlx5e: Add fragmented memory support for RX multi packet WQE') Signed-off-by:
-
Saeed Mahameed authored
This will significantly reduce receive queue flush time on interface down. Instead of asking the firmware to flush the RQ (Receive Queue) via asynchronous completions when moved to error, we handle RQ flush manually (mlx5e_free_rx_descs) same as we did when RQ flush got timed out. This will reduce RQs flush time and speedup interface down procedure (ifconfig down) from 6 sec to 0.3 sec on a 48 cores system. Moved mlx5e_free_rx_descs en_main.c where it is needed, to keep en_rx.c free form non critical data path code for better code locality. Fixes: 6cd392a0 ('net/mlx5e: Handle RQ flush in error cases') Signed-off-by:
-
Saeed Mahameed authored
ConnectX-4 UMR (User Memory Region) MTT translation table offset in WQE is limited to U16_MAX, before this patch we ignored that limitation and requested the maximum possible UMR translation length that the netdev might need (MAX channels * MAX pages per channel). In case of a system with #cores > 32 and when linear WQE allocation fails, falling back to using UMR WQEs will cause the RQ (Receive Queue) to get stuck. Here we limit UMR length to min(U16_MAX, max required pages) (while considering the required alignments) on driver load, by default U16_MAX is sufficient since the default RX rings value guarantees that we are in range, dynamically (on set_ringparam/set_channels) we will check if the new required UMR length (num mtts) is still in range, if not, fail the request. Fixes: bc77b240 ('net/mlx5e: Add fragmented memory support for RX multi packet WQE') Signed-off-by:
-
- 27 Aug, 2016 3 commits
-
-
Eric Dumazet authored
If vmalloc() was successful, do not attempt a kmalloc_array() Fixes: 4cf0b354 ("rhashtable: avoid large lock-array allocations") Reported-by:
CAI Qian <caiqian@redhat.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Florian Westphal <fw@strlen.de> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Tested-by:
-
Andrew Rybchenko authored
On 32-bit systems, mask is only an array of 3 longs, not 4, so don't try to write to mask[3]. Also include build-time checks in case the size of the bitmask changes. Fixes: 3c36a2ad ("sfc: display vadaptor statistics for all interfaces") Signed-off-by:
Edward Cree <ecree@solarflare.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetoothDavid S. Miller authored
Johan Hedberg says: ==================== pull request: bluetooth 2016-08-25 Here are a couple of important Bluetooth fixes for the 4.8 kernel: - Memory leak fix for HCI requests - Fix sk_filter handling with L2CAP - Fix sock_recvmsg behavior when MSG_TRUNC is not set Please let me know if there are any issues pulling. Thanks. ==================== Signed-off-by:
-
- 26 Aug, 2016 3 commits
-
-
Jiri Pirko authored
When team is in bridge and LACP is utilized, LACPDU packets are pushed to userspace using raw socket and there they are processed. However, since 8626c56c, LACPDU skbs are dropped by bridge rx_handler so they never reach packet handlers in rx path. Fix this by explicity treat LACPDUs to be pushed to exact delivery in team rx_handler. Reported-by:
Ido Schimmel <idosch@mellanox.com> Fixes: 8626c56c ("bridge: fix potential use-after-free when hook returns QUEUE or STOLEN verdict") Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Colin Ian King authored
ppe_cb->ppe_common_cb is being dereferenced before a null check is being made on it. If ppe_cb->ppe_common_cb is null then we end up with a null pointer dereference when assigning dsaf_dev. Fix this by moving the initialisation of dsaf_dev once we know ppe_cb->ppe_common_cb is OK to dereference. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Yisen Zhuang <yisen.zhuang@huawei.com> Signed-off-by:
-
Gao Feng authored
When cp_rx_poll does not get enough packet, it will check the rx interrupt status again. If so, it will jumpt to rx_status_loop again. But the goto jump resets the rx variable as zero too. As a result, it causes one possible deadloop. Assume this case, rx_status_loop only gets the packet count which is less than budget, and (cpr16(IntrStatus) & cp_rx_intr_mask) condition is always true. It causes the deadloop happens and system is blocked. Signed-off-by:
Gao Feng <fgao@ikuai8.com> Signed-off-by:
-
- 25 Aug, 2016 7 commits
-
-
Anjali Singhai Jain authored
This change makes a common flow for Client instance open during init and reset path. The Client subtask can handle both the cases instead of making a separate notify_client_of_open call. Also it may fix a bug during reset where the service task was leaking some memory and causing issues. Change-Id: I7232a32fd52b82e863abb54266fa83122f80a0cd Signed-off-by:
Anjali Singhai Jain <anjali.singhai@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Xander Huff authored
This reverts: commit 33c133cc ("phy: IRQ cannot be shared") On hardware with multiple PHY devices hooked up to the same IRQ line, allow them to share it. Sergei Shtylyov says: "I'm not sure now what was the reason I concluded that the IRQ sharing was impossible... most probably I thought that the kernel IRQ handling code exited the loop over the IRQ actions once IRQ_HANDLED was returned -- which is obviously not so in reality..." Signed-off-by:
Xander Huff <xander.huff@ni.com> Signed-off-by:
Nathan Sullivan <nathan.sullivan@ni.com> Signed-off-by:
-
Florian Fainelli authored
We kept shadow copies of which interrupt sources we have enabled and disabled, but due to an order bug in how intrl2_mask_clear was defined, we could run into the following scenario: CPU0 CPU1 intrl2_1_mask_clear(..) sets INTRL2_CPU_MASK_CLEAR bcm_sf2_switch_1_isr read INTRL2_CPU_STATUS and masks with stale irq1_mask value updates irq1_mask value Which would make us loop again and again trying to process and interrupt we are not clearing since our copy of whether it was enabled before still indicates it was not. Fix this by updating the shadow copy first, and then unasking at the HW level. Fixes: 246d7f77 ("net: dsa: add Broadcom SF2 switch driver") Signed-off-by:
-
Eric Dumazet authored
Should qdisc_alloc() fail, we must release the module refcount we got right before. Fixes: 6da7c8fc ("qdisc: allow setting default queuing discipline") Signed-off-by:
John Fastabend <john.r.fastabend@intel.com> Acked-by:
-
Wei Yongjun authored
Fix to return a negative error code in enable_mcast() error handling case, and release udp socket when necessary. Fixes: d0f91938 ("tipc: add ip/udp media type") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
Luiz Augusto von Dentz authored
Similar to bt_sock_recvmsg MSG_TRUNC shall be checked using the original flags not msg_flags. Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Luiz Augusto von Dentz authored
Commit b5f34f94 attempt to introduce proper handling for MSG_TRUNC but recv and variants should still work as read if no flag is passed, but because the code may set MSG_TRUNC to msg->msg_flags that shall not be used as it may cause it to be behave as if MSG_TRUNC is always, so instead of using it this changes the code to use the flags parameter which shall contain the original flags. Signed-off-by:
-
- 24 Aug, 2016 10 commits
-
-
Yotam Gigi authored
Make the function mlxsw_router_neigh_construct search the rif according to the neighbour dev other than the dev that was passed to the ndo, thus allowing creating neigbhours upon stacked devices. Fixes: 6cf3c971 ("mlxsw: spectrum_router: Add private neigh table") Signed-off-by:
Yotam Gigi <yotamg@mellanox.com> Reviewed-by:
-
Ido Schimmel authored
In case we have a layer 3 interface on top of a bridge (VLAN / FID RIF), then we should flood the following packet types to the router: * Broadcast: If DIP is the broadcast address of the interface, then we need to be able to get it to CPU by trapping it following route lookup. * Reserved IP multicast (224.0.0.X): Some control packets (e.g. OSPF) use this range and are trapped in the router block. Fixes: 99f44bb3 ("mlxsw: spectrum: Enable L3 interfaces on top of bridge devices") Signed-off-by:
-
Daniel Borkmann authored
During an audit for sk_filter(), we found that rx_busy_skb handling in l2cap_sock_recv_cb() and l2cap_sock_recvmsg() looks not quite as intended. The assumption from commit e328140f ("Bluetooth: Use event-driven approach for handling ERTM receive buffer") is that errors returned from sock_queue_rcv_skb() are due to receive buffer shortage. However, nothing should prevent doing a setsockopt() with SO_ATTACH_FILTER on the socket, that could drop some of the incoming skbs when handled in sock_queue_rcv_skb(). In that case sock_queue_rcv_skb() will return with -EPERM, propagated from sk_filter() and if in L2CAP_MODE_ERTM mode, wrong assumption was that we failed due to receive buffer being full. From that point onwards, due to the to-be-dropped skb being held in rx_busy_skb, we cannot make any forward progress as rx_busy_skb is never cleared from l2cap_sock_recvmsg(), due to the filter drop verdict over and over coming from sk_filter(). Meanwhile, in l2cap_sock_recv_cb() all new incoming skbs are being dropped due to rx_busy_skb being occupied. Instead, just use __sock_queue_rcv_skb() where an error really tells that there's a receive buffer issue. Split the sk_filter() and enable it for non-segmented modes at queuing time since at this point in time the skb has already been through the ERTM state machine and it has been acked, so dropping is not allowed. Instead, for ERTM and streaming mode, call sk_filter() in l2cap_data_rcv() so the packet can be dropped before the state machine sees it. Fixes: e328140f ("Bluetooth: Use event-driven approach for handling ERTM receive buffer") Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Acked-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Frederic Dalleau authored
In hci_req_sync_complete the event skb is referenced in hdev->req_skb. It is used (via hci_req_run_skb) from either __hci_cmd_sync_ev which will pass the skb to the caller, or __hci_req_sync which leaks. unreferenced object 0xffff880005339a00 (size 256): comm "kworker/u3:1", pid 1011, jiffies 4294671976 (age 107.389s) backtrace: [<ffffffff818d89d9>] kmemleak_alloc+0x49/0xa0 [<ffffffff8116bba8>] kmem_cache_alloc+0x128/0x180 [<ffffffff8167c1df>] skb_clone+0x4f/0xa0 [<ffffffff817aa351>] hci_event_packet+0xc1/0x3290 [<ffffffff8179a57b>] hci_rx_work+0x18b/0x360 [<ffffffff810692ea>] process_one_work+0x14a/0x440 [<ffffffff81069623>] worker_thread+0x43/0x4d0 [<ffffffff8106ead4>] kthread+0xc4/0xe0 [<ffffffff818dd38f>] ret_from_fork+0x1f/0x40 [<ffffffffffffffff>] 0xffffffffffffffff Signed-off-by:Frédéric Dalleau <frederic.dalleau@collabora.co.uk> Signed-off-by:
-
David Ahern authored
inet_diag_find_one_icsk takes a reference to a socket that is not released if sock_diag_destroy returns an error. Fix by changing tcp_diag_destroy to manage the refcnt for all cases and remove the sock_put calls from tcp_abort. Fixes: c1e64e29 ("net: diag: Support destroying TCP sockets") Reported-by:
Lorenzo Colitti <lorenzo@google.com> Signed-off-by:
David Ahern <dsa@cumulusnetworks.com> Signed-off-by:
-
Soheil Hassas Yeganeh authored
Instead of using sock_tx_timestamp, use skb_tx_timestamp to record software transmit timestamp of a packet. sock_tx_timestamp resets and overrides the tx_flags of the skb. The function is intended to be called from within the protocol layer when creating the skb, not from a device driver. This is inconsistent with other drivers and will cause issues for TCP. In TCP, we intend to sample the timestamps for the last byte for each sendmsg/sendpage. For that reason, tcp_sendmsg calls tcp_tx_timestamp only with the last skb that it generates. For example, if a 128KB message is split into two 64KB packets we want to sample the SND timestamp of the last packet. The current code in the tun driver, however, will result in sampling the SND timestamp for both packets. Also, when the last packet is split into smaller packets for retranmission (see tcp_fragment), the tun driver will record timestamps for all of the retransmitted packets and not only the last packet. Fixes: eda29772 (tun: Support software transmit time stamping.) Signed-off-by:
Soheil Hassas Yeganeh <soheil@google.com> Signed-off-by:
Francis Yan <francisyyan@google.com> Acked-by:
-
Eric Dumazet authored
After commit ca065d0c ("udp: no longer use SLAB_DESTROY_BY_RCU") we do not need this special allocation mode anymore, even if it is harmless. Signed-off-by:
-
Lance Richardson authored
The function sctp_diag_dump_one() currently performs a memcpy() of 64 bytes from a 16 byte field into another 16 byte field. Fix by using correct size, use sizeof to obtain correct size instead of using a hard-coded constant. Fixes: 8f840e47 ("sctp: add the sctp_diag.c file") Signed-off-by:
Lance Richardson <lrichard@redhat.com> Reviewed-by:
Xin Long <lucien.xin@gmail.com> Acked-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by:
-
Rabin Vincent authored
We currently enable interrupts before we enable NAPI. If an RX interrupt hits before we enabled NAPI then the NAPI callback is never called and we leave the hardware with RX interrupts disabled, which of course leads us to never handling received packets. Fix this by moving the interrupt enable to after we've enable NAPI and the reclaim tasklet. Fixes: cd5e4123 ("dwc_eth_qos: do phy_start before resetting hardware") Signed-off-by:
Rabin Vincent <rabinv@axis.com> Signed-off-by:
Lars Persson <larper@axis.com> Signed-off-by:
-
Fabio Estevam authored
clk_prepare_enable() may fail, so we should better check its return value and propagate it in the case of failure While at it, replace __lpc_eth_clock_enable() with a plain clk_prepare_enable/clk_disable_unprepare() call in order to simplify the code. Signed-off-by:
Fabio Estevam <fabio.estevam@nxp.com> Acked-by:
Vladimir Zapolskiy <vz@mleia.com> Signed-off-by:
-
- 23 Aug, 2016 6 commits
-
-
Jamie Lentin authored
The PORT_RATE_CONTROL register works differently on 88e6095/6095f/6131 in comparison to 6123/61/65, and 0x0 disables. The distinction was lost Linux 4.1 --> 4.2 Signed-off-by:
Jamie Lentin <jm@lentin.co.uk> Reviewed-by:
-
Xander Huff authored
Like the ksz8081, the ksz9031 has the behavior where it will clear the interrupt enable bits when leaving power down. This takes advantage of the solution provided by f5aba91d. Signed-off-by:
-
Eric Dumazet authored
When sending an ack in SYN_RECV state, we must scale the offered window if wscale option was negotiated and accepted. Tested: Following packetdrill test demonstrates the issue : 0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1) = 0 // Establish a connection. +0 < S 0:0(0) win 20000 <mss 1000,sackOK,wscale 7, nop, TS val 100 ecr 0> +0 > S. 0:0(0) ack 1 win 28960 <mss 1460,sackOK, TS val 100 ecr 100, nop, wscale 7> +0 < . 1:11(10) ack 1 win 156 <nop,nop,TS val 99 ecr 100> // check that window is properly scaled ! +0 > . 1:1(0) ack 1 win 226 <nop,nop,TS val 200 ecr 100> Signed-off-by:
Yuchung Cheng <ycheng@google.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
-
Zefir Kurtisi authored
The current scatter-gather logic in gianfar is flawed, since it does not consider the eTSEC's RxBD 'Data Length' field is context depening: for the last fragment it contains the full frame size, while fragments contain the fragment size, which equals the value written to register MRBLR. This causes data corruption as soon as the hardware starts to fragment receiving frames. As a result, the size of fragmented frames is increased by (nr_frags - 1) * MRBLR We first noticed this issue working with DSA, where an ICMP request sized 1472 bytes causes the scatter-gather logic to kick in. The full Ethernet frame (1518) gets increased by DSA (4), GMAC_FCB_LEN (8), and FSL_GIANFAR_DEV_HAS_TIMER (priv->padding=8) to a total of 1538 octets, which is fragmented by the hardware and reconstructed by the driver to a 3074 octet frame. This patch fixes the problem by adjusting the size of the last fragment. It was tested by setting MRBLR to different multiples of 64, proving correct scatter-gather operation on frames with up to 9000 octets in size. Signed-off-by:
Zefir Kurtisi <zefir.kurtisi@neratec.com> Signed-off-by:
-
Zefir Kurtisi authored
The eTSEC register MRBLR defines the maximum space in the RX buffers and is set to 1536 by gianfar. This reasonably covers the common use case where the MTU is kept at default 1500. In that case, the largest Ethernet frame size of 1518 plus an optional GMAC_FCB_LEN of 8, and an additional padding of 8 to handle FSL_GIANFAR_DEV_HAS_TIMER totals to 1534 and nicely fit within the chosen MRBLR. Alas, if the eTSEC is attached to a DSA enabled switch, the (E)DSA header extension (4 or 8 bytes) causes every maximum sized frame to be fragmented by the hardware. This patch increases the maximum RX buffer size by 8 and rounds up to the next multiple of 64, which the hardware's defines as RX buffer granularity. Signed-off-by:
-
Eric Dumazet authored
Laura tracked poll() [and friends] regression caused by commit e6afc8ac ("udp: remove headers from UDP packets before queueing") udp_poll() needs to know if there is a valid packet in receive queue, even if its payload length is 0. Change first_packet_length() to return an signed int, and use -1 as the indication of an empty queue. Fixes: e6afc8ac ("udp: remove headers from UDP packets before queueing") Reported-by:
Laura Abbott <labbott@redhat.com> Signed-off-by:
-
