- 10 Dec, 2020 40 commits
-
-
Oliver Hartkopp authored
When CAN_ISOTP_SF_BROADCAST is set in the CAN_ISOTP_OPTS flags the CAN_ISOTP socket is switched into functional addressing mode, where only single frame (SF) protocol data units can be send on the specified CAN interface and the given tp.tx_id after bind(). In opposite to normal and extended addressing this socket does not register a CAN-ID for reception which would be needed for a 1-to-1 ISOTP connection with a segmented bi-directional data transfer. Sending SFs on this socket is therefore a TX-only 'broadcast' operation. Signed-off-by:
Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by:
Thomas Wagner <thwa1@web.de> Link: https://lore.kernel.org/r/20201206144731.4609-1-socketcan@hartkopp.netSigned-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
David S. Miller authored
Huazhong Tan says: ==================== net: hns3: updates for -next This patchset adds support for tc mqprio offload, hw tc offload of tc flower, and adpation for max rss size changes. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Guojia Liao authored
For the max rss size of PF may be up to 512, the max queue number of single tc may be up to 512 too. For the total queue numbers may be up to 1280, so the queue offset of each tc may be more than 1024. So adjust the rss tc mode configuration command, including extend tc size field from 10 bits to 11 bits, and extend tc size field from 3 bits to 4 bits. Signed-off-by:
Guojia Liao <liaoguojia@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Guojia Liao authored
For the max rss size of PF may be up to 512, so adjust the command of configuring rss indirection table to support queue id larger than 255. The width of queue id is extended from 8 bits to 10 bits. The high 2 bits are stored in filed rss_qid_h when the queue id is larger than 255. Signed-off-by:
-
Guojia Liao authored
Currently, the driver gets the max rss size from configuration file when initialization. Both the PF and VF share the same max rss size, and no more than 128. For DEVICE_VERSION_V3, the max rss size for PF can be up to 512, so there is a new field in configuration file to store it, the old filed is used for VF. To be compatible with boards using old configure file, the PF will use the old filed if the one is zero. For the rss size may be larger than 256, so the type of rss_indirection_tbl of struct hclge_vport should be changed to u16 as well. Signed-off-by:
-
Jian Shen authored
Some new device supports forwarding packet to queues of specified TC when flow director rule hit. So add support to configure flow director rule by tc flower. To avoid rule conflict, add a new flow director mode HCLGE_FD_TC_FLOWER_ACTIVE, and only one mode can be active at the same time. Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
-
Jian Shen authored
For some new device, it supports forwarding packet to queues of specified TC when flow director rule hit. So extend the command handle to support it. Signed-off-by:
-
Jian Shen authored
Currently, the HNS3 driver only supports offload for tc number and prio_tc. This patch adds support for other qopts, including queues count and offset for each tc. When enable tc mqprio offload, it's not allowed to change queue numbers by ethtool. For hardware limitation, the queue number of each tc should be power of 2. For the queues is not assigned to each tc by average, so it's should return vport->alloc_tqps for hclge_get_max_channels(). Signed-off-by:
-
Jian Shen authored
Currently, there are multiple members related to tc information in struct hnae3_knic_private_info. Merge them into a new struct hnae3_tc_info. Signed-off-by:
-
Jakub Kicinski authored
Test robot reports: drivers/net/ethernet/netronome/nfp/crypto/tls.c: In function 'nfp_net_tls_rx_resync_req': drivers/net/ethernet/netronome/nfp/crypto/tls.c:477:18: warning: variable 'ipv6h' set but not used [-Wunused-but-set-variable] 477 | struct ipv6hdr *ipv6h; | ^~~~~ In file included from include/linux/compiler_types.h:65, from <command-line>: drivers/net/ethernet/netronome/nfp/crypto/tls.c: In function 'nfp_net_tls_add': include/linux/compiler_attributes.h:208:41: warning: statement will never be executed [-Wswitch-unreachable] 208 | # define fallthrough __attribute__((__fallthrough__)) | ^~~~~~~~~~~~~ drivers/net/ethernet/netronome/nfp/crypto/tls.c:299:3: note: in expansion of macro 'fallthrough' 299 | fallthrough; | ^~~~~~~~~~~ Use the IPv6 header in the switch, it doesn't matter which header we use to read the version field. Reported-by:kernel test robot <lkp@intel.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Reviewed-by:
Simon Horman <simon.horman@netronome.com> Signed-off-by:
-
Wong Vee Khee authored
Assign stmmac's mdio_bus probe capabilities to MDIOBUS_C22_C45. This extended the probing of C45 PHY devices on the MDIO bus. Signed-off-by:
Wong Vee Khee <vee.khee.wong@intel.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
David S. Miller authored
dule' Russell King says: ==================== Add support for VSOL V2801F/CarlitoxxPro CPGOS03 GPON module This patch set adds support for the V2801F / CarlitoxxPro module. This requires two changes: 1) the module only supports single byte reads to the ID EEPROM, while we need to still permit sequential reads to the diagnostics EEPROM for atomicity reasons. 2) we need to relax the encoding check when we have no reported capabilities to allow 1000base-X based on the module bitrate. Thanks to Pali Rohár for responsive testing over the last two days. (Resending, dropping the utf-8 characters in Pali's name so the patches get through vger. Added Andrew's r-b tags.) ==================== Signed-off-by: -
Russell King authored
Do not check the encoding when deriving 1000BASE-X from the bitrate when no other modes are discovered. Some GPON modules (VSOL V2801F and CarlitoxxPro CPGOS03-0490 v2.0) indicate NRZ encoding with a 1200Mbaud bitrate, but should be driven with 1000BASE-X on the host side. Tested-by:
Pali Rohár <pali@kernel.org> Reviewed-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Russell King authored
Add a workaround for the detection of VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 GPON module which CarlitoxxPro states needs single byte I2C reads to the EEPROM. Pali Rohár reports that he also has a CarlitoxxPro-based V2801F module, which reports a manufacturer of "OEM". This manufacturer can't be matched as it appears in many different modules, so also match the part number too. Reported-by:
Thomas Schreiber <tschreibe@gmail.com> Reported-by:
-
Xie He authored
1. When the x25 module gets loaded, layer 2 may already be running and connected. In this case, although we are in X25_LINK_STATE_0, we still need to handle the Restart Request received, rather than ignore it. 2. When we are in X25_LINK_STATE_2, we have already sent a Restart Request and is waiting for the Restart Confirmation with t20timer. t20timer will restart itself repeatedly forever so it will always be there, as long as we are in State 2. So we don't need to check x25_t20timer_pending again. Fixes: d023b2b9 ("net/x25: fix restart request/confirm handling") Cc: Martin Schiller <ms@dev.tdt.de> Signed-off-by:
Xie He <xie.he.0141@gmail.com> Acked-by:
Martin Schiller <ms@dev.tdt.de> Signed-off-by:
-
David S. Miller authored
Paolo Abeni says: ==================== mptcp: a bunch of fixes This series includes a few fixes following-up the recent code refactor for the MPTCP RX and TX paths. Boundling them together, since the fixes are somewhat related. ==================== Signed-off-by: -
Paolo Abeni authored
When the workqueue disposes of the msk, the subflows can still receive some data from the peer after __mptcp_close_ssk() completes. The above could trigger a race between the msk receive path and the msk destruction. Acquiring the mptcp_data_lock() in __mptcp_destroy_sock() will not save the day: the rx path could be reached even after msk destruction completes. Instead use the subflow 'disposable' flag to prevent entering the msk receive path after __mptcp_close_ssk(). Fixes: e16163b6 ("mptcp: refactor shutdown and close") Reviewed-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
Paolo Abeni authored
When a MPTCP listener socket is closed with unaccepted children pending, the ULP release callback will be invoked, but nobody will call into __mptcp_close_ssk() on the corresponding subflow. As a consequence, at ULP release time, the 'disposable' flag will be cleared and the subflow context memory will be leaked. This change addresses the issue always freeing the context if the subflow is still in the accept queue at ULP release time. Additionally, this fixes an incorrect code reference in the related comment. Note: this fix leverages the changes introduced by the previous commit. Fixes: e16163b6 ("mptcp: refactor shutdown and close") Reviewed-by:
-
Paolo Abeni authored
Christoph reported the following splat: WARNING: CPU: 0 PID: 4615 at net/ipv4/inet_connection_sock.c:1031 inet_csk_listen_stop+0x8e8/0xad0 net/ipv4/inet_connection_sock.c:1031 Modules linked in: CPU: 0 PID: 4615 Comm: syz-executor.4 Not tainted 5.9.0 #37 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:inet_csk_listen_stop+0x8e8/0xad0 net/ipv4/inet_connection_sock.c:1031 Code: 03 00 00 00 e8 79 b2 3d ff e9 ad f9 ff ff e8 1f 76 ba fe be 02 00 00 00 4c 89 f7 e8 62 b2 3d ff e9 14 f9 ff ff e8 08 76 ba fe <0f> 0b e9 97 f8 ff ff e8 fc 75 ba fe be 03 00 00 00 4c 89 f7 e8 3f RSP: 0018:ffffc900037f7948 EFLAGS: 00010293 RAX: ffff88810a349c80 RBX: ffff888114ee1b00 RCX: ffffffff827b14cd RDX: 0000000000000000 RSI: ffffffff827b1c38 RDI: 0000000000000005 RBP: ffff88810a2a8000 R08: ffff88810a349c80 R09: fffff520006fef1f R10: 0000000000000003 R11: fffff520006fef1e R12: ffff888114ee2d00 R13: dffffc0000000000 R14: 0000000000000001 R15: ffff888114ee1d68 FS: 00007f2ac1945700(0000) GS:ffff88811b400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffd44798bc0 CR3: 0000000109810002 CR4: 0000000000170ef0 Call Trace: __tcp_close+0xd86/0x1110 net/ipv4/tcp.c:2433 __mptcp_close_ssk+0x256/0x430 net/mptcp/protocol.c:1761 __mptcp_destroy_sock+0x49b/0x770 net/mptcp/protocol.c:2127 mptcp_close+0x62d/0x910 net/mptcp/protocol.c:2184 inet_release+0xe9/0x1f0 net/ipv4/af_inet.c:434 __sock_release+0xd2/0x280 net/socket.c:596 sock_close+0x15/0x20 net/socket.c:1277 __fput+0x276/0x960 fs/file_table.c:281 task_work_run+0x109/0x1d0 kernel/task_work.c:151 get_signal+0xe8f/0x1d40 kernel/signal.c:2561 arch_do_signal+0x88/0x1b60 arch/x86/kernel/signal.c:811 exit_to_user_mode_loop kernel/entry/common.c:161 [inline] exit_to_user_mode_prepare+0x9b/0xf0 kernel/entry/common.c:191 syscall_exit_to_user_mode+0x22/0x150 kernel/entry/common.c:266 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f2ac1254469 Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ff 49 2b 00 f7 d8 64 89 01 48 RSP: 002b:00007f2ac1944dc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffbf RBX: 000000000069bf00 RCX: 00007f2ac1254469 RDX: 0000000000000000 RSI: 0000000000008982 RDI: 0000000000000003 RBP: 000000000069bf00 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000069bf0c R13: 00007ffeb53f178f R14: 00000000004668b0 R15: 0000000000000003 After commit 0397c6d8 ("mptcp: keep unaccepted MPC subflow into join list"), the msk's workqueue and/or PM can touch the MPC subflow - and acquire its socket lock - even if it's still unaccepted. If the above event races with the relevant listener socket close, we can end-up with the above splat. This change addresses the issue delaying the MPC socket insertion in conn_list at accept time - that is, partially reverting the blamed commit. We must additionally ensure that mptcp_pm_fully_established() happens after accept() time, or the PM will not be able to handle properly such event - conn_list could be empty otherwise. In the receive path, we check the subflow list node to ensure it is out of the listener queue. Be sure client subflows do not match transiently such condition moving them into the join list earlier at creation time. Since we now have multiple mptcp_pm_fully_established() call sites from different code-paths, said helper can now race with itself. Use an additional PM status bit to avoid multiple notifications. Reported-by:
Christoph Paasch <cpaasch@apple.com> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/103 Fixes: 0397c6d8 ("mptcp: keep unaccepted MPC subflow into join list"), Reviewed-by:
-
Xie He authored
1. In x25_xmit, skb_reset_network_header is not necessary before we call lapb_data_request. The lapb module doesn't need skb->network_header. So there is no need to set skb->network_header before calling lapb_data_request. 2. In x25_data_indication (called by the lapb module after data have been received), skb_reset_network_header is not necessary before we call netif_rx. After we call netif_rx, the code in net/core/dev.c will call skb_reset_network_header before handing the skb to upper layers (in __netif_receive_skb_core, called by __netif_receive_skb_one_core, called by __netif_receive_skb, called by process_backlog). So we don't need to call skb_reset_network_header by ourselves. Cc: Martin Schiller <ms@dev.tdt.de> Signed-off-by:
-
Zheng Yongjun authored
Simplify the return expression. Signed-off-by:
Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by:
-
Dwip N. Banerjee authored
We observed that in the error case for batched send_subcrq_indirect() the driver does not account for the partial success case. This caused Linux to crash when free_map and pool index are inconsistent. Driver needs to update the rx pools "available" count when some batched sends worked but an error was encountered as part of the whole operation. Also track replenish_add_buff_failure for statistic purposes. Fixes: 4f0b6812 ("ibmvnic: Introduce batched RX buffer descriptor transmission") Signed-off-by:
Dwip N. Banerjee <dnbanerg@us.ibm.com> Reviewed-by:
Dany Madden <drt@linux.ibm.com> Signed-off-by:
-
David S. Miller authored
Mat Martineau says: ==================== mptcp: Add port parameter to ADD_ADDR option The ADD_ADDR MPTCP option is used to announce available IP addresses that a peer may connect to when adding more TCP subflows to an existing MPTCP connection. There is an optional port number field in that ADD_ADDR header, and this patch set adds capability for that port number to be sent and received. Patches 1, 2, and 4 refactor existing ADD_ADDR code to simplify implementation of port number support. Patches 3 and 5 are the main functional changes, for sending and receiving the port number in the MPTCP ADD_ADDR option. Patch 6 sends the ADD_ADDR option with port number on a bare TCP ACK, since the extra length of the option may run in to cases where sufficient TCP option space is not available on a data packet. Patch 7 plumbs in port number support for the in-kernel MPTCP path manager. Patches 8-11 add some optional debug output and a little more cleanup refactoring. ==================== Signed-off-by: -
Geliang Tang authored
Since the local variable sk has been defined, use it instead of open-coding. Reviewed-by:
Geliang Tang <geliangtang@gmail.com> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
-
Geliang Tang authored
Since the RM_ADDR signal had been reused with add_addr_signal, it's not suitable to call it add_addr_signal or mptcp_add_addr_status. So this patch renamed add_addr_signal to addr_signal, and renamed mptcp_add_addr_status to mptcp_addr_signal_status. Signed-off-by:
-
Geliang Tang authored
This patch reused add_addr_signal for the RM_ADDR announcing signal, by defining a new ADD_ADDR status named MPTCP_RM_ADDR_SIGNAL. Then the flag rm_addr_signal in PM could be dropped. Signed-off-by:
-
Geliang Tang authored
This patch printed out more debugging information for the ADD_ADDR suboption parsing on the incoming path. Signed-off-by:
-
Geliang Tang authored
This patch added a new parameter 'port' for mptcp_pm_announce_addr. If this parameter is true, we set the MPTCP_ADD_ADDR_PORT bit of the add_addr_signal. That means the announced address is added with a port number. Signed-off-by:
-
Geliang Tang authored
The process is similar to that of the ADD_ADDR IPv6, this patch also sent out a pure ack for the ADD_ADDR using port. Signed-off-by:
-
Geliang Tang authored
This patch added a new add_addr_signal type named MPTCP_ADD_ADDR_PORT, to identify it is an address with port to be added. It also added a new parameter 'port' for both mptcp_add_addr_len and mptcp_pm_add_addr_signal. In mptcp_established_options_add_addr, we check whether the announced address is added with port. If it is, we put this port number to mptcp_out_options's port field. Signed-off-by:
-
Geliang Tang authored
This patch uses adding up size to get the ADD_ADDR suboption length rather than returning the ADD_ADDR size constants. Signed-off-by:
-
Geliang Tang authored
In rfc8684, the length of ADD_ADDR suboption with IPv4 address and port is 18 octets, but mptcp_write_options is 32-bit aligned, so we need to pad it to 20 octets. All the other port related option lengths need to be added up 2 octets similarly. This patch added a new field 'port' in mptcp_out_options. When this field is set with a port number, we need to add up 4 octets for the ADD_ADDR suboption, and put the port number into the suboption. Signed-off-by:
-
Geliang Tang authored
The length of ADD_ADDR6 is 12 octets longer than ADD_ADDR. That's the only difference between them. This patch dropped the duplicate code between ADD_ADDR and ADD_ADDR6 suboptions writing, and unify them into one. Signed-off-by:
-
Geliang Tang authored
There are two differences between ADD_ADDR suboption and ADD_ADDR echo suboption: The length of the former is 8 octets longer than the length of the latter. The former's echo-flag is 0, and latter's echo-flag is 1. This patch added two local variables, len and echo, to unify ADD_ADDR and ADD_ADDR echo suboptions writing. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueDavid S. Miller authored
Tony Nguyen says: ==================== 100GbE Intel Wired LAN Driver Updates 2020-12-09 This series contains updates to ice driver only. Bruce changes the allocation of ice_flow_prof_params from stack to heap to avoid excessive stack usage. Corrects a misleading comment and silences a sparse warning that is not a problem. Paul allows for HW initialization to continue if PHY abilities cannot be obtained. Jeb removes bypassing FW link override and reading Option ROM and netlist information for non-E810 devices as this is now available on other devices. Nick removes vlan_ena field as this information can be gathered by checking num_vlan. Jake combines format strings and debug prints to the same line. Simon adds a space to fix string concatenation. v4: Drop ACL patches. Change PHY abilities failure message from debug to warning. v3: Fix email address for DaveM and fix character in cover letter v2: Expand on commit message for patch 3 to show example usage/commands. Reduce number of defensive checks being done. ==================== Signed-off-by: -
Zheng Yongjun authored
Simplify the return expression. Signed-off-by:
-
Zheng Yongjun authored
Simplify the return expression. Signed-off-by:
Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Zheng Yongjun authored
Simplify the return expression. Signed-off-by:
-
Zheng Yongjun authored
Simplify the return expression. Signed-off-by:
-
Zheng Yongjun authored
Simplify the return expression. Signed-off-by:
Madalin Bucur <madalin.bucur@oss.nxp.com> Signed-off-by:
-
