- 30 Nov, 2022 2 commits
-
-
Paolo Abeni authored
Currently in the receive path we don't need to discriminate between MPC SYN, MPC SYN-ACK and MPC ACK, but soon the fastopen code will need that info to properly track the fully established status. Track the exact MPC suboption type into the receive opt bitmap. No functional change intended. Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Reviewed-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Dmytro Shytyi authored
Since commit 54f1944e ("mptcp: factor out mptcp_connect()"), all the infrastructure is now in place to support the MSG_FASTOPEN flag, we just need to call into the fastopen path in mptcp_sendmsg(). Co-developed-by:
Benjamin Hesmans <benjamin.hesmans@tessares.net> Signed-off-by:
Dmytro Shytyi <dmytro@shytyi.net> Signed-off-by:
-
- 29 Nov, 2022 38 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski authored
tools/lib/bpf/ringbuf.c 927cbb47 ("libbpf: Handle size overflow for ringbuf mmap") b486d19a ("libbpf: checkpatch: Fixed code alignments in ringbuf.c") https://lore.kernel.org/all/20221121122707.44d1446a@canb.auug.org.au/Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netLinus Torvalds authored
Pull networking fixes from Jakub Kicinski: "Including fixes from bpf, can and wifi. Current release - new code bugs: - eth: mlx5e: - use kvfree() in mlx5e_accel_fs_tcp_create() - MACsec, fix RX data path 16 RX security channel limit - MACsec, fix memory leak when MACsec device is deleted - MACsec, fix update Rx secure channel active field - MACsec, fix add Rx security association (SA) rule memory leak Previous releases - regressions: - wifi: cfg80211: don't allow multi-BSSID in S1G - stmmac: set MAC's flow control register to reflect current settings - eth: mlx5: - E-switch, fix duplicate lag creation - fix use-after-free when reverting termination table Previous releases - always broken: - ipv4: fix route deletion when nexthop info is not specified - bpf: fix a local storage BPF map bug where the value's spin lock field can get initialized incorrectly - tipc: re-fetch skb cb after tipc_msg_validate - wifi: wilc1000: fix Information Element parsing - packet: do not set TP_STATUS_CSUM_VALID on CHECKSUM_COMPLETE - sctp: fix memory leak in sctp_stream_outq_migrate() - can: can327: fix potential skb leak when netdev is down - can: add number of missing netdev freeing on error paths - aquantia: do not purge addresses when setting the number of rings - wwan: iosm: - fix incorrect skb length leading to truncated packet - fix crash in peek throughput test due to skb UAF" * tag 'net-6.1-rc8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (79 commits) net: ethernet: renesas: ravb: Fix promiscuous mode after system resumed MAINTAINERS: Update maintainer list for chelsio drivers ionic: update MAINTAINERS entry sctp: fix memory leak in sctp_stream_outq_migrate() packet: do not set TP_STATUS_CSUM_VALID on CHECKSUM_COMPLETE net/mlx5: Lag, Fix for loop when checking lag Revert "net/mlx5e: MACsec, remove replay window size limitation in offload path" net: marvell: prestera: Fix a NULL vs IS_ERR() check in some functions net: tun: Fix use-after-free in tun_detach() net: mdiobus: fix unbalanced node reference count net: hsr: Fix potential use-after-free tipc: re-fetch skb cb after tipc_msg_validate mptcp: fix sleep in atomic at close time mptcp: don't orphan ssk in mptcp_close() dsa: lan9303: Correct stat name ipv4: Fix route deletion when nexthop info is not specified net: wwan: iosm: fix incorrect skb length net: wwan: iosm: fix crash in peek throughput test net: wwan: iosm: fix dma_alloc_coherent incompatible pointer type net: wwan: iosm: fix kernel test robot reported error ... -
Yuan Can authored
As the nla_nest_start() may fail with NULL returned, the return value should be checked. Note that this is not a real bug, nothing will break here. The next nla_put() will fail as well and we'll bail (and nla_nest_cancel() can handle NULL). But we keep getting those "fixes" so whatever. Signed-off-by:
Yuan Can <yuancan@huawei.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20221129013934.55184-1-yuancan@huawei.comSigned-off-by:
-
Yoshihiro Shimoda authored
After system resumed on some environment board, the promiscuous mode is disabled because the SoC turned off. So, call ravb_set_rx_mode() in the ravb_resume() to fix the issue. Reported-by:
Tho Vu <tho.vu.wh@renesas.com> Fixes: 0184165b ("ravb: add sleep PM suspend/resume support") Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by:
Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Link: https://lore.kernel.org/r/20221128065604.1864391-1-yoshihiro.shimoda.uh@renesas.comSigned-off-by:
-
Ayush Sawal authored
This updates the maintainers for chelsio inline crypto drivers and chelsio crypto drivers. Signed-off-by:
Ayush Sawal <ayush.sawal@chelsio.com> Link: https://lore.kernel.org/r/20221128231348.8225-1-ayush.sawal@chelsio.comSigned-off-by:
-
Shannon Nelson authored
Now that Pensando is a part of AMD we need to update a couple of addresses. We're keeping the mailing list address for the moment, but that will likely change in the near future. Signed-off-by:
Shannon Nelson <shannon.nelson@amd.com> Signed-off-by:
Brett Creeley <brett.creeley@amd.com> Link: https://lore.kernel.org/r/20221129011734.20849-1-shannon.nelson@amd.comSigned-off-by:
-
Zhengchao Shao authored
When sctp_stream_outq_migrate() is called to release stream out resources, the memory pointed to by prio_head in stream out is not released. The memory leak information is as follows: unreferenced object 0xffff88801fe79f80 (size 64): comm "sctp_repo", pid 7957, jiffies 4294951704 (age 36.480s) hex dump (first 32 bytes): 80 9f e7 1f 80 88 ff ff 80 9f e7 1f 80 88 ff ff ................ 90 9f e7 1f 80 88 ff ff 90 9f e7 1f 80 88 ff ff ................ backtrace: [<ffffffff81b215c6>] kmalloc_trace+0x26/0x60 [<ffffffff88ae517c>] sctp_sched_prio_set+0x4cc/0x770 [<ffffffff88ad64f2>] sctp_stream_init_ext+0xd2/0x1b0 [<ffffffff88aa2604>] sctp_sendmsg_to_asoc+0x1614/0x1a30 [<ffffffff88ab7ff1>] sctp_sendmsg+0xda1/0x1ef0 [<ffffffff87f765ed>] inet_sendmsg+0x9d/0xe0 [<ffffffff8754b5b3>] sock_sendmsg+0xd3/0x120 [<ffffffff8755446a>] __sys_sendto+0x23a/0x340 [<ffffffff87554651>] __x64_sys_sendto+0xe1/0x1b0 [<ffffffff89978b49>] do_syscall_64+0x39/0xb0 [<ffffffff89a0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcd Link: https://syzkaller.appspot.com/bug?exrid=29c402e56c4760763cc0 Fixes: 637784ad ("sctp: introduce priority based stream scheduler") Reported-by: syzbot+29c402e56c4760763cc0@syzkaller.appspotmail.com Signed-off-by:Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by:
Xin Long <lucien.xin@gmail.com> Link: https://lore.kernel.org/r/20221126031720.378562-1-shaozhengchao@huawei.comSigned-off-by:
-
Willem de Bruijn authored
CHECKSUM_COMPLETE signals that skb->csum stores the sum over the entire packet. It does not imply that an embedded l4 checksum field has been validated. Fixes: 682f048b ("af_packet: pass checksum validation status to the user") Signed-off-by:
Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/20221128161812.640098-1-willemdebruijn.kernel@gmail.comSigned-off-by:
-
Chris Mi authored
The cited commit adds a for loop to check if each port supports lag or not. But dev is not initialized correctly. Fix it by initializing dev for each iteration. Fixes: e87c6a83 ("net/mlx5: E-switch, Fix duplicate lag creation") Signed-off-by:
Chris Mi <cmi@nvidia.com> Reported-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com> Link: https://lore.kernel.org/r/20221129093006.378840-2-saeed@kernel.orgSigned-off-by:
-
Saeed Mahameed authored
This reverts commit c0071be0. The cited commit removed the validity checks which initialized the window_sz and never removed the use of the now uninitialized variable, so now we are left with wrong value in the window size and the following clang warning: [-Wuninitialized] drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec.c:232:45: warning: variable 'window_sz' is uninitialized when used here MLX5_SET(macsec_aso, aso_ctx, window_size, window_sz); Revet at this time to address the clang issue due to lack of time to test the proper solution. Fixes: c0071be0 ("net/mlx5e: MACsec, remove replay window size limitation in offload path") Signed-off-by:
-
Yu Xiao authored
Add support for reporting link modes, including `Supported link modes` and `Advertised link modes`, via ethtool $DEV. A new command `SPCODE_READ_MEDIA` is added to read info from management firmware. Also, the mapping table `nfp_eth_media_table` associates the link modes between NFP and kernel. Both of them help to support this ability. Signed-off-by:
Yu Xiao <yu.xiao@corigine.com> Reviewed-by:
Louis Peens <louis.peens@corigine.com> Signed-off-by:
Simon Horman <simon.horman@corigine.com> Reviewed-by:
Alexander Lobakin <alexandr.lobakin@intel.com> Link: https://lore.kernel.org/r/20221125113030.141642-1-simon.horman@corigine.comSigned-off-by:
-
Jiri Pirko authored
As the return value is not 0 only in case there is no such notifier block registered, add a WARN_ON_ONCE() to yell about it. Suggested-by:
Ido Schimmel <idosch@idosch.org> Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/20221125100255.1786741-1-jiri@resnulli.usSigned-off-by:
-
Paolo Abeni authored
Horatiu Vultur says: ==================== Add support for lan966x IS2 VCAP This provides initial support for lan966x for 'tc' traffic control userspace tool and its flower filter. For this is required to use the VCAP library. Currently supported flower filter keys and actions are: - source and destination MAC address keys - trap action ==================== Link: https://lore.kernel.org/r/20221125095010.124458-1-horatiu.vultur@microchip.comSigned-off-by:
-
Horatiu Vultur authored
On lan966x the layout of the vcap memory is different than on sparx5. Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
-
Horatiu Vultur authored
Implement vcap_operations and enable default port keyset configuration for each port. Now it is possible actually write/read/move entries in the VCAP. Signed-off-by:
-
Horatiu Vultur authored
Extend matchall with action goto. This is needed to enable the lookup in the VCAP. It is needed to connect chain 0 to a chain that is recognized by the HW. Signed-off-by:
-
Horatiu Vultur authored
Currently the only supported action is ACTION_TRAP and the only dissector is ETH_ADDRS. Others will be added in future patches. Signed-off-by:
-
Horatiu Vultur authored
Add registers used to access vcap controller. Signed-off-by:
-
Horatiu Vultur authored
This provides the lan966x is2 model and adds it to the vcap control instance that will be provided to the vcap API. Signed-off-by:
-
Horatiu Vultur authored
When lan966x driver is initialized, initialize also the VCAP module for lan966x. Signed-off-by:
-
Horatiu Vultur authored
Add the keysets, keys, actionsets and actions used by lan966x in IS2. Signed-off-by:
-
Horatiu Vultur authored
Currently there are 2 files that contain the keyfields, keys, actionfields and actions. First file is used by the kunit while the second one is used by VCAP api. The header file that is used by kunit is just a super set of the of the header file used by VCAP api. Therefore not to have duplicate information in different files which is also harder to maintain, create a single file that is used both by API and by kunit. Signed-off-by:
-
Shang XiaoJing authored
rhashtable_lookup_fast() returns NULL when failed instead of error pointer. Fixes: 396b80cb ("net: marvell: prestera: Add neighbour cache accounting") Fixes: 0a23ae23 ("net: marvell: prestera: Add router nexthops ABI") Signed-off-by:
Shang XiaoJing <shangxiaojing@huawei.com> Link: https://lore.kernel.org/r/20221125012751.23249-1-shangxiaojing@huawei.comSigned-off-by:
-
Shigeru Yoshida authored
syzbot reported use-after-free in tun_detach() [1]. This causes call trace like below: ================================================================== BUG: KASAN: use-after-free in notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75 Read of size 8 at addr ffff88807324e2a8 by task syz-executor.0/3673 CPU: 0 PID: 3673 Comm: syz-executor.0 Not tainted 6.1.0-rc5-syzkaller-00044-gcc675d22 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x15e/0x461 mm/kasan/report.c:395 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495 notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75 call_netdevice_notifiers_info+0x86/0x130 net/core/dev.c:1942 call_netdevice_notifiers_extack net/core/dev.c:1983 [inline] call_netdevice_notifiers net/core/dev.c:1997 [inline] netdev_wait_allrefs_any net/core/dev.c:10237 [inline] netdev_run_todo+0xbc6/0x1100 net/core/dev.c:10351 tun_detach drivers/net/tun.c:704 [inline] tun_chr_close+0xe4/0x190 drivers/net/tun.c:3467 __fput+0x27c/0xa90 fs/file_table.c:320 task_work_run+0x16f/0x270 kernel/task_work.c:179 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0xb3d/0x2a30 kernel/exit.c:820 do_group_exit+0xd4/0x2a0 kernel/exit.c:950 get_signal+0x21b1/0x2440 kernel/signal.c:2858 arch_do_signal_or_restart+0x86/0x2300 arch/x86/kernel/signal.c:869 exit_to_user_mode_loop kernel/entry/common.c:168 [inline] exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296 do_syscall_64+0x46/0xb0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcd The cause of the issue is that sock_put() from __tun_detach() drops last reference count for struct net, and then notifier_call_chain() from netdev_state_change() accesses that struct net. This patch fixes the issue by calling sock_put() from tun_detach() after all necessary accesses for the struct net has done. Fixes: 83c1f36f ("tun: send netlink notification when the device is modified") Reported-by: syzbot+106f9b687cd64ee70cd1@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=96eb7f1ce75ef933697f24eeab928c4a716edefe [1] Signed-off-by:
Shigeru Yoshida <syoshida@redhat.com> Link: https://lore.kernel.org/r/20221124175134.1589053-1-syoshida@redhat.comSigned-off-by:
-
Paolo Abeni authored
Lorenzo Bianconi says: ==================== refactor mtk_wed code to introduce SER support Refactor mtk_wed support in order to introduce proper integration for hw reset between mtk_eth_soc/mtk_wed and mt76 drivers. ==================== Link: https://lore.kernel.org/r/cover.1669303154.git.lorenzo@kernel.orgSigned-off-by:
-
Lorenzo Bianconi authored
Introduce reset parameter to mtk_wed_tx_ring_setup signature. This is a preliminary patch to add Wireless Ethernet Dispatcher reset support. Co-developed-by:
Sujuan Chen <sujuan.chen@mediatek.com> Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by:
-
Lorenzo Bianconi authored
Introduce mtk_wed_rx_reset routine in order to reset rx DMA for Wireless Ethernet Dispatcher available on MT7986 SoC. Co-developed-by:
-
Lorenzo Bianconi authored
Update mtk_wed_stop routine and rename old mtk_wed_stop() to mtk_wed_deinit(). This is a preliminary patch to add Wireless Ethernet Dispatcher reset support. Co-developed-by:
-
Lorenzo Bianconi authored
Remove duplicated code. Increase poll timeout to 10ms in order to be aligned with vendor sdk. This is a preliminary patch to add Wireless Ethernet Dispatcher reset support. Co-developed-by:
-
Lorenzo Bianconi authored
Move MTK_WDMA_RESET_IDX configuration in mtk_wdma_rx_reset routine. Increase poll timeout to 10ms in order to be aligned with vendor sdk. This is a preliminary patch to add Wireless Ethernet Dispatcher reset support. Co-developed-by:
-
Paolo Abeni authored
Miquel Raynal says: ==================== Marvell nvmem mac addresses support Now that we are aligned on how to make information available from static storage media to drivers like Ethernet controller drivers or switch drivers by using nvmem cells and going through the whole nvmem infrastructure, here are two driver updates to reflect these changes. Prior to the driver updates, I propose: * Reverting binding changes which should have never been accepted like that. * A conversion of the (old) Prestera and DFX server bindings (optional, can be dropped if not considered necessary). * A better description of the more recent Prestera PCI switch. Please mind that this series cannot break anything since retrieving the MAC address Prestera driver has never worked upstream, because the (ONIE tlv) driver supposed to export the MAC address has not been accepted in its original form and has been updated to the nvmem-layout infrastructure (bindings have been merged, the code remains to be applied). ==================== Link: https://lore.kernel.org/r/20221124111556.264647-1-miquel.raynal@bootlin.comSigned-off-by:
-
Miquel Raynal authored
The ONIE standard describes the organization of tlv (type-length-value) arrays commonly stored within NVMEM devices on common networking hardware. Several drivers already make use of NVMEM cells for purposes like retrieving a default MAC address provided by the manufacturer. What made ONIE tables unusable so far was the fact that the information where "dynamically" located within the table depending on the manufacturer wishes, while Linux NVMEM support only allowed statically defined NVMEM cells. Fortunately, this limitation was eventually tackled with the introduction of discoverable cells through the use of NVMEM layouts, making it possible to extract and consistently use the content of tables like ONIE's tlv arrays. Parsing this table at runtime in order to get various information is now possible. So, because many Marvell networking switches already follow this standard, let's consider using NVMEM cells as a new valid source of information when looking for a base MAC address, which is one of the primary uses of these new fields. Indeed, manufacturers following the ONIE standard are encouraged to provide a default MAC address there, so let's eventually use it if no other MAC address has been found using the existing methods. Link: https://opencomputeproject.github.io/onie/design-spec/hw_requirements.htmlSigned-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by:
-
Miquel Raynal authored
This driver fist makes an expensive DT lookup to retrieve its DT node (this is a PCI driver) in order to later search for the base-mac-provider property. This property has no reality upstream and this code should not have been accepted like this in the first place. Instead, there is a proper nvmem interface that should be used. Let's avoid these extra lookups and rely on the nvmem internal logic. Signed-off-by:
-
Miquel Raynal authored
Export of_get_mac_addr_nvmem() and rename it to of_get_mac_address_nvmem() in order to fit the convention followed by the existing exported helpers of the same kind. This way, OF compatible drivers using eg. fwnode_get_mac_address() can do a direct call to it instead of calling of_get_mac_address() just for the nvmem step, avoiding to repeat an expensive DT lookup which has already been done once. Eventually, fwnode_get_mac_address() should probably be updated to perform the nvmem lookup directly, but as of today, nvmem cells seem not to be supported by ACPI yet which would defeat this kind of extension. Suggested-by:
Marcin Wojtas <mw@semihalf.com> Signed-off-by:
-
Miquel Raynal authored
Even though the devices have very little in common beside the name and the main "switch" feature, Marvell Prestera switch family is also composed of PCI-only devices which can receive additional static properties, like nvmem cells to point at MAC addresses, for instance. Let's describe them. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Miquel Raynal authored
The currently described switch family is named AlleyCat3, it is a memory mapped switch found on Armada XP boards. Signed-off-by:
-
Miquel Raynal authored
Even though this description is not used anywhere upstream (no matching driver), while on this file I decided I would try a conversion to yaml in order to clarify the prestera family description. I cannot keep the nodename dfx-server@xxxx so I switched to dfx-bus@xxxx which matches simple-bus.yaml. Otherwise I took the example context from the only user of this compatible: armada-xp-98dx3236.dtsi, which is a rather old and not perfect DT. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Miquel Raynal authored
This reverts commit 40acc052. marvell,prestera.txt is an old file describing the old Alleycat3 standalone switches. The commit mentioned above actually hacked these bindings to add support for a device tree property for a more modern version of the IP connected over PCI, using only the generic compatible in order to retrieve the device node from the prestera driver to read one static property. The problematic property discussed here is "base-mac-provider". The original intent was to point to a nvmem device which could produce the relevant nvmem-cell. This property has never been acked by DT maintainers and fails all the layering that has been brought with the nvmem bindings by pointing at a nvmem producer, bypassing the existing nvmem bindings, rather than a nvmem cell directly. Furthermore, the property cannot even be used upstream because it expected the ONIE tlv driver to produce a specific cell, driver which used nacked bindings and thus was never merged, replaced by a more integrated concept: the nvmem-layout. So let's forget about this temporary addition, safely avoiding the need for any backward compatibility handling. A new (yaml) binding file will be brought with the prestera bindings, and there we will actually include a description of the modern IP over PCI, including the right way to point to a nvmem cell. Cc: Vadym Kochan <vadym.kochan@plvision.eu> Cc: Taras Chornyi <tchornyi@marvell.com> Signed-off-by:
-
