summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2025-05-06selftests: iou-zcrx: Clean up build warnings for error formatHaiyue Wang1-2/+2
Clean up two build warnings: [1] iou-zcrx.c: In function ‘process_recvzc’: iou-zcrx.c:263:37: warning: too many arguments for format [-Wformat-extra-args] 263 | error(1, 0, "payload mismatch at ", i); | ^~~~~~~~~~~~~~~~~~~~~~ [2] Use "%zd" for ssize_t type as better iou-zcrx.c: In function ‘run_client’: iou-zcrx.c:357:47: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘ssize_t’ {aka ‘long int’} [-Wformat=] 357 | error(1, 0, "send(): %d", sent); | ~^ ~~~~ | | | | int ssize_t {aka long int} | %ld Signed-off-by: Haiyue Wang <haiyuewa@163.com> Reviewed-by: David Wei <dw@davidwei.uk> Link: https://patch.msgid.link/20250502175136.1122-1-haiyuewa@163.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-06Merge branch 'selftests-mptcp-increase-code-coverage'Jakub Kicinski5-42/+257
Matthieu Baerts says: ==================== selftests: mptcp: increase code coverage Here are various patches slightly improving MPTCP code coverage: - Patch 1: avoid a harmless 'grep: write error' warning. - Patch 2: use getaddrinfo() with IPPROTO_MPTCP in more places. - Patch 3-6: prepare and add support to get info for a specific subflow when giving the 5-tuple. - Patch 7: validate the previous patch and cover "subflow_get_info_size" in the kernel code (mptcp_diag.c). ==================== Link: https://patch.msgid.link/20250502-net-next-mptcp-sft-inc-cover-v1-0-68eec95898fb@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-06selftests: mptcp: add chk_sublfow in diag.shGang Yan1-0/+32
This patch aims to add chk_dump_subflow in diag.sh. The subflow's info can be obtained through "ss -tin", then use the 'mptcp_diag' to verify the token in subflow_info. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/524 Co-developed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Gang Yan <yangang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250502-net-next-mptcp-sft-inc-cover-v1-7-68eec95898fb@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-06selftests: mptcp: add helpers to get subflow_infoGang Yan1-2/+157
This patch adds 'get_subflow_info' in 'mptcp_diag', which can check whether a TCP connection is an MPTCP subflow based on the "INET_ULP_INFO_MPTCP" with tcp_diag method. The helper 'print_subflow_info' in 'mptcp_diag' can print the subflow_filed of an MPTCP subflow for further checking the 'subflow_info' through inet_diag method. The example of the whole output should be: $ ./mptcp_diag -s "127.0.0.1:10000 127.0.0.1:38984" 127.0.0.1:10000 -> 127.0.0.1:38984 It's a mptcp subflow, the subflow info: flags:Mec token:0000(id:0)/4278e77e(id:0) seq:9288466187236176036 \ sfseq:1 ssnoff:2317083055 maplen:215 Co-developed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Gang Yan <yangang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250502-net-next-mptcp-sft-inc-cover-v1-6-68eec95898fb@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-06selftests: mptcp: refactor NLMSG handling with 'proto'Gang Yan1-18/+20
This patch introduces the '__u32 proto' variable to the 'send_query' and 'recv_nlmsg' functions for further extending function. In the 'send_query' function, the inclusion of this variable makes the structure clearer and more readable. In the 'recv_nlmsg' function, the '__u32 proto' variable ensures that the 'diag_info' field remains unmodified when processing IPPROTO_TCP data, thereby preventing unintended transformation into 'mptcp_info' format. While at it, increment iovlen directly when an item is added to simplify this portion of the code and improve its readaility. Co-developed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Gang Yan <yangang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250502-net-next-mptcp-sft-inc-cover-v1-5-68eec95898fb@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-06selftests: mptcp: refactor send_query parameters for code clarityGang Yan1-9/+10
This patch use 'inet_diag_req_v2' instead of 'token' as parameters of send_query, and construct the req in 'get_mptcpinfo'. This modification enhances the clarity of the code, and prepare for the dump_subflow_info. Co-developed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Gang Yan <yangang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250502-net-next-mptcp-sft-inc-cover-v1-4-68eec95898fb@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-06selftests: mptcp: add struct params in mptcp_diagGang Yan1-5/+11
This patch adds a struct named 'params' to save 'target_token' and other future parameters. This structure facilitates future function expansions. Co-developed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Gang Yan <yangang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250502-net-next-mptcp-sft-inc-cover-v1-3-68eec95898fb@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-06selftests: mptcp: sockopt: use IPPROTO_MPTCP for getaddrinfoGeliang Tang2-8/+24
getaddrinfo MPTCP is recently supported in glibc and IPPROTO_MPTCP for getaddrinfo is used in mptcp_connect.c. But in mptcp_sockopt.c and mptcp_inq.c, IPPROTO_TCP are still used for getaddrinfo, So this patch updates them. Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250502-net-next-mptcp-sft-inc-cover-v1-2-68eec95898fb@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-06selftests: mptcp: info: hide 'grep: write error' warningsMatthieu Baerts (NGI0)1-2/+5
mptcp_lib_get_info_value() will only print the first entry that match the filter because of the ';q' at the end. As a consequence, the 'sed' command could finish before the previous 'grep' one and print a 'write error' warning because it is trying to write data to the closed pipe. Such warnings are not interesting, they can be hidden by muting stderr here for grep. While at it, clearly indicate that mptcp_lib_get_info_value() will only print the first matched entry to avoid confusions later on. Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250502-net-next-mptcp-sft-inc-cover-v1-1-68eec95898fb@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-06sctp: Remove unused sctp_assoc_del_peer and sctp_chunk_iifDr. David Alan Gilbert4-29/+0
sctp_assoc_del_peer() last use was removed in 2015 by commit 73e6742027f5 ("sctp: Do not try to search for the transport twice") which now uses rm_peer instead of del_peer. sctp_chunk_iif() last use was removed in 2016 by commit 1f45f78f8e51 ("sctp: allow GSO frags to access the chunk too") Remove them. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Acked-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/20250501233815.99832-1-linux@treblig.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-06net: phy: Refactor fwnode_get_phy_node()Andy Shevchenko1-4/+4
Refactor to check if the fwnode we got is correct and return if so, otherwise do additional checks. Using same pattern in all conditionals makes it slightly easier to read and understand. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20250430143802.3714405-1-andriy.shevchenko@linux.intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-06dt-bindings: net: ethernet-controller: Add informative text about RGMII delaysAndrew Lunn1-7/+90
Device Tree and Ethernet MAC driver writers often misunderstand RGMII delays. Rewrite the Normative section in terms of the PCB, is the PCB adding the 2ns delay. This meaning was previous implied by the definition, but often wrongly interpreted due to the ambiguous wording and looking at the definition from the wrong perspective. The new definition concentrates clearly on the hardware, and should be less ambiguous. Add an Informative section to the end of the binding describing in detail what the four RGMII delays mean. This expands on just the PCB meaning, adding in the implications for the MAC and PHY. Additionally, when the MAC or PHY needs to add a delay, which is software configuration, describe how Linux does this, in the hope of reducing errors. Make it clear other users of device tree binding may implement the software configuration in other ways while still conforming to the binding. Fixes: 9d3de3c58347 ("dt-bindings: net: Add YAML schemas for the generic Ethernet options") Signed-off-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20250430-v6-15-rc3-net-rgmii-delays-v2-1-099ae651d5e5@lunn.ch Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-06strparser: Remove unused __strp_unpauseDr. David Alan Gilbert2-15/+0
The last use of __strp_unpause() was removed in 2022 by commit 84c61fe1a75b ("tls: rx: do not use the standard strparser") Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250501002402.308843-1-linux@treblig.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-05virtio-net: free xsk_buffs on error in virtnet_xsk_pool_enable()Jakub Kicinski1-2/+6
The selftests added to our CI by Bui Quang Minh recently reveals that there is a mem leak on the error path of virtnet_xsk_pool_enable(): unreferenced object 0xffff88800a68a000 (size 2048): comm "xdp_helper", pid 318, jiffies 4294692778 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): __kvmalloc_node_noprof+0x402/0x570 virtnet_xsk_pool_enable+0x293/0x6a0 (drivers/net/virtio_net.c:5882) xp_assign_dev+0x369/0x670 (net/xdp/xsk_buff_pool.c:226) xsk_bind+0x6a5/0x1ae0 __sys_bind+0x15e/0x230 __x64_sys_bind+0x72/0xb0 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Acked-by: Jason Wang <jasowang@redhat.com> Fixes: e9f3962441c0 ("virtio_net: xsk: rx: support fill with xsk buffer") Link: https://patch.msgid.link/20250430163836.3029761-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-05virtio-net: don't re-enable refill work too early when NAPI is disabledJakub Kicinski1-3/+8
Commit 4bc12818b363 ("virtio-net: disable delayed refill when pausing rx") fixed a deadlock between reconfig paths and refill work trying to disable the same NAPI instance. The refill work can't run in parallel with reconfig because trying to double-disable a NAPI instance causes a stall under the instance lock, which the reconfig path needs to re-enable the NAPI and therefore unblock the stalled thread. There are two cases where we re-enable refill too early. One is in the virtnet_set_queues() handler. We call it when installing XDP: virtnet_rx_pause_all(vi); ... virtnet_napi_tx_disable(..); ... virtnet_set_queues(..); ... virtnet_rx_resume_all(..); We want the work to be disabled until we call virtnet_rx_resume_all(), but virtnet_set_queues() kicks it before NAPIs were re-enabled. The other case is a more trivial case of mis-ordering in __virtnet_rx_resume() found by code inspection. Taking the spin lock in virtnet_set_queues() (requested during review) may be unnecessary as we are under rtnl_lock and so are all paths writing to ->refill_enabled. Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Bui Quang Minh <minhquangbui99@gmail.com> Fixes: 4bc12818b363 ("virtio-net: disable delayed refill when pausing rx") Fixes: 413f0271f396 ("net: protect NAPI enablement with netdev_lock()") Link: https://patch.msgid.link/20250430163758.3029367-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-05Merge branch 'net_sched-fix-a-regression-in-sch_htb'Jakub Kicinski2-9/+41
Cong Wang says: ==================== net_sched: fix a regression in sch_htb This patchset contains a fix for the regression reported by Alan and a selftest to cover that case. Please see each patch description for more details. ==================== Link: https://patch.msgid.link/20250428232955.1740419-1-xiyou.wangcong@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-05selftests/tc-testing: Add a test case to cover basic HTB+FQ_CODEL caseCong Wang1-0/+35
Integrate the reproducer from Alan into TC selftests and use scapy to generate TCP traffic instead of relying on ping command. Cc: Alan J. Wylie <alan@wylie.me.uk> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Link: https://patch.msgid.link/20250428232955.1740419-3-xiyou.wangcong@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-05sch_htb: make htb_deactivate() idempotentCong Wang1-9/+6
Alan reported a NULL pointer dereference in htb_next_rb_node() after we made htb_qlen_notify() idempotent. It turns out in the following case it introduced some regression: htb_dequeue_tree(): |-> fq_codel_dequeue() |-> qdisc_tree_reduce_backlog() |-> htb_qlen_notify() |-> htb_deactivate() |-> htb_next_rb_node() |-> htb_deactivate() For htb_next_rb_node(), after calling the 1st htb_deactivate(), the clprio[prio]->ptr could be already set to NULL, which means htb_next_rb_node() is vulnerable here. For htb_deactivate(), although we checked qlen before calling it, in case of qlen==0 after qdisc_tree_reduce_backlog(), we may call it again which triggers the warning inside. To fix the issues here, we need to: 1) Make htb_deactivate() idempotent, that is, simply return if we already call it before. 2) Make htb_next_rb_node() safe against ptr==NULL. Many thanks to Alan for testing and for the reproducer. Fixes: 5ba8b837b522 ("sch_htb: make htb_qlen_notify() idempotent") Reported-by: Alan J. Wylie <alan@wylie.me.uk> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Link: https://patch.msgid.link/20250428232955.1740419-2-xiyou.wangcong@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-05Merge tag 'for-netdev' of ↵Jakub Kicinski13-121/+740
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Martin KaFai Lau says: ==================== pull-request: bpf-next 2025-05-02 We've added 14 non-merge commits during the last 10 day(s) which contain a total of 13 files changed, 740 insertions(+), 121 deletions(-). The main changes are: 1) Avoid skipping or repeating a sk when using a UDP bpf_iter, from Jordan Rife. 2) Fixed a crash when a bpf qdisc is set in the net.core.default_qdisc, from Amery Hung. 3) A few other fixes in the bpf qdisc, from Amery Hung. - Always call qdisc_watchdog_init() in the .init prologue such that the .reset/.destroy epilogue can always call qdisc_watchdog_cancel() without issue. - bpf_qdisc_init_prologue() was incorrectly returning an error when the bpf qdisc is set as the default_qdisc and the mq is creating the default_qdisc. It is now fixed. * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: selftests/bpf: Cleanup bpf qdisc selftests selftests/bpf: Test attaching a bpf qdisc with incomplete operators bpf: net_sched: Make some Qdisc_ops ops mandatory selftests/bpf: Test setting and creating bpf qdisc as default qdisc bpf: net_sched: Fix bpf qdisc init prologue when set as default qdisc selftests/bpf: Add tests for bucket resume logic in UDP socket iterators selftests/bpf: Return socket cookies from sock_iter_batch progs bpf: udp: Avoid socket skips and repeats during iteration bpf: udp: Use bpf_udp_iter_batch_item for bpf_udp_iter_state batch items bpf: udp: Get rid of st_bucket_done bpf: udp: Make sure iter->batch always contains a full bucket snapshot bpf: udp: Make mem flags configurable through bpf_iter_udp_realloc_batch bpf: net_sched: Fix using bpf qdisc as default qdisc selftests/bpf: Fix compilation errors ==================== Link: https://patch.msgid.link/20250503010755.4030524-1-martin.lau@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-05Merge tag 'uml-for-linux-6.15-rc6' of ↵Linus Torvalds4-15/+17
git://git.kernel.org/pub/scm/linux/kernel/git/uml/linux Pull uml fix from Johannes Berg: "There's just a single fix here for the _nofault changes that were causing issues with clang, and then when we looked at it some other issues seemed to exist" * tag 'uml-for-linux-6.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/uml/linux: um: fix _nofault accesses
2025-05-05Merge tag 'soc-fixes-6.15' of ↵Linus Torvalds12-40/+90
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC fixes from Arnd Bergmann: "The main changes are once more for the NXP i.MX platform, addressing multiple regressions in recent devicetree updates for the i.MX8MM and i.MX6ULL SoCs, a PCIe fix for i.MX9 and a MAINTAINERS file update to disambiguate NXP i.MX SoCs from Sony IMX image sensors. The stm32 platform devicetree files get some compatibility fixes for the interrupt controller node. Another compatibility fix is done for the Arm Morello platform's cache controller node. The code changes are all for firmware drivers, fixing kernel-side bugs on the Arm FF-A and SCMI drivers" * tag 'soc-fixes-6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: arm64: dts: st: Use 128kB size for aliased GIC400 register access on stm32mp23 SoCs arm64: dts: st: Adjust interrupt-controller for stm32mp23 SoCs arm64: dts: st: Use 128kB size for aliased GIC400 register access on stm32mp21 SoCs arm64: dts: st: Adjust interrupt-controller for stm32mp21 SoCs arm64: dts: st: Use 128kB size for aliased GIC400 register access on stm32mp25 SoCs arm64: dts: st: Adjust interrupt-controller for stm32mp25 SoCs arm64: dts: imx8mm-verdin: Link reg_usdhc2_vqmmc to usdhc2 MAINTAINERS: add exclude for dt-bindings to imx entry ARM: dts: opos6ul: add ksz8081 phy properties arm64: dts: imx95: Correct the range of PCIe app-reg region arm64: dts: imx8mp: configure GPU and NPU clocks in nominal DTSI arm64: dts: morello: Fix-up cache nodes firmware: arm_ffa: Skip Rx buffer ownership release if not acquired firmware: arm_scmi: Fix timeout checks on polling path firmware: arm_scmi: Balance device refcount when destroying devices
2025-05-05s390: Update defconfigsHeiko Carstens3-17/+8
Just the regular update of all defconfigs. Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-05-05s390/dcssblk: Fix build error with CONFIG_DAX=m and CONFIG_DCSSBLK=yGerald Schaefer1-2/+1
After commit 653d7825c149 ("dcssblk: mark DAX broken, remove FS_DAX_LIMITED support") moved the "select DAX" from config DCSSBLK to the new config DCSSBLK_DAX, randconfig tests could result in build errors like this: s390-linux-ld: drivers/s390/block/dcssblk.o: in function `dcssblk_shared_store': drivers/s390/block/dcssblk.c:417: undefined reference to `kill_dax' s390-linux-ld: drivers/s390/block/dcssblk.c:418: undefined reference to `put_dax' This is because it's now possible to have CONFIG_DCSSBLK=y, but CONFIG_DAX=m. Fix this by adding "depends on DAX || DAX=n" to config DCSSBLK, to make it explicit that we want either no DAX, or the same "y/m" for both config DAX and DCSSBLK, similar to config BLK_DEV_DM. This also requires removing the "select DAX" from config DCSSBLK_DAX, or else there would be a recursive dependency detected. DCSSBLK_DAX is marked as BROKEN at the moment, and won't work well with DAX anyway, so it doesn't really matter if it is selected. Fixes: 653d7825c149 ("dcssblk: mark DAX broken, remove FS_DAX_LIMITED support") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202504291604.pvjonhWX-lkp@intel.com/ Signed-off-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-05-05s390/entry: Fix last breaking event handling in case of stack corruptionHeiko Carstens1-1/+2
In case of stack corruption stack_invalid() is called and the expectation is that register r10 contains the last breaking event address. This dependency is quite subtle and broke a couple of years ago without that anybody noticed. Fix this by getting rid of the dependency and read the last breaking event address from lowcore. Fixes: 56e62a737028 ("s390: convert to generic entry") Acked-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-05-05s390/configs: Enable options required for TC flow offloadKonstantin Shkolnyy2-0/+12
While testing Open vSwitch with Nvidia ConnectX-6 NIC, it was noticed that it didn't offload TC flows into the NIC, and its log contained many messages such as: "failed to offload flow: No such file or directory: <network device name>" and, upon enabling more versose logging, additionally: "received NAK error=2 - TC classifier not found" The options enabled here are listed as requirements in Nvidia online documentation, among other options that were already enabled. Now all options listed by Nvidia are enabled.. This option is also added because Fedora has it: CONFIG_NET_EMATCH Signed-off-by: Konstantin Shkolnyy <kshk@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-05-05s390/configs: Enable VDPA on Nvidia ConnectX-6 network cardKonstantin Shkolnyy2-0/+16
ConnectX-6 is the first VDPA-capable NIC. For earlier NICs, Nvidia implements a VDPA emulation in s/w, which hasn't been validated on s390. Add options necessary for VDPA to work. These options are also added because Fedora has them: CONFIG_VDPA_SIM CONFIG_VDPA_SIM_NET CONFIG_VDPA_SIM_BLOCK CONFIG_VDPA_USER CONFIG_VP_VDPA Signed-off-by: Konstantin Shkolnyy <kshk@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-05-05selftests: netfilter: nft_fib.sh: check lo packets bypass fib lookupFlorian Westphal1-0/+23
With reverted fix: PASS: fib expression did not cause unwanted packet drops [ 37.285169] ns1-KK76Kt nft_rpfilter: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=32287 DF PROTO=ICMP TYPE=8 CODE=0 ID=1818 SEQ=1 FAIL: rpfilter did drop packets FAIL: ns1-KK76Kt cannot reach 127.0.0.1, ret 0 Check for this. Link: https://lore.kernel.org/netfilter/20250422114352.GA2092@breakpoint.cc/ Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2025-05-05netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAXPablo Neira Ayuso1-0/+6
Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when resizing hashtable because __GFP_NOWARN is unset. Similar to: b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX") Reviewed-by: Stefano Brivio <sbrivio@redhat.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2025-05-05netfilter: nft_set_pipapo: prevent overflow in lookup table allocationPablo Neira Ayuso1-14/+44
When calculating the lookup table size, ensure the following multiplication does not overflow: - desc->field_len[] maximum value is U8_MAX multiplied by NFT_PIPAPO_GROUPS_PER_BYTE(f) that can be 2, worst case. - NFT_PIPAPO_BUCKETS(f->bb) is 2^8, worst case. - sizeof(unsigned long), from sizeof(*f->lt), lt in struct nft_pipapo_field. Then, use check_mul_overflow() to multiply by bucket size and then use check_add_overflow() to the alignment for avx2 (if needed). Finally, add lt_size_check_overflow() helper and use it to consolidate this. While at it, replace leftover allocation using the GFP_KERNEL to GFP_KERNEL_ACCOUNT for consistency, in pipapo_resize(). Fixes: 3c4287f62044 ("nf_tables: Add set type for arbitrary concatenation of ranges") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Reviewed-by: Stefano Brivio <sbrivio@redhat.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2025-05-05netfilter: nf_conntrack: speed up reads from nf_conntrack proc fileFlorian Westphal1-35/+53
Dumping all conntrack entries via proc interface can take hours due to linear search to skip entries dumped so far in each cycle. Apply same strategy used to speed up ipvs proc reading done in commit 178883fd039d ("ipvs: speed up reads from ip_vs_conn proc file") to nf_conntrack. Note that the ctnetlink interface doesn't suffer from this problem, but many scripts depend on the nf_conntrack proc interface. Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2025-05-05netfilter: nft_quota: match correctly when the quota just depletedZhongqiu Duan1-7/+13
The xt_quota compares skb length with remaining quota, but the nft_quota compares it with consumed bytes. The xt_quota can match consumed bytes up to quota at maximum. But the nft_quota break match when consumed bytes equal to quota. i.e., nft_quota match consumed bytes in [0, quota - 1], not [0, quota]. Fixes: 795595f68d6c ("netfilter: nft_quota: dump consumed quota") Signed-off-by: Zhongqiu Duan <dzq.aishenghu0@gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2025-05-05selftests: netfilter: add conntrack stress testFlorian Westphal3-0/+408
Add a new test case to check: - conntrack_max limit is effective - conntrack_max limit cannot be exceeded from within a netns - resizing the hash table while packets are inflight works - removal of all conntrack rules disables conntrack in netns - conntrack tool dump (conntrack -L) returns expected number of (unique) entries - procfs interface - if available - has same number of entries as conntrack -L dump Expected output with selftest framework: selftests: net/netfilter: conntrack_resize.sh PASS: got 1 connections: netns conntrack_max is pernet bound PASS: got 100 connections: netns conntrack_max is init_net bound PASS: dump in netns had same entry count (-C 1778, -L 1778, -p 1778, /proc 0) PASS: dump in netns had same entry count (-C 2000, -L 2000, -p 2000, /proc 0) PASS: test parallel conntrack dumps PASS: resize+flood PASS: got 0 connections: conntrack disabled PASS: got 1 connections: conntrack enabled ok 1 selftests: net/netfilter: conntrack_resize.sh Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2025-05-05netfilter: bridge: Move specific fragmented packet to slow_path instead of ↵Huajian Yang2-12/+12
dropping it The config NF_CONNTRACK_BRIDGE will change the bridge forwarding for fragmented packets. The original bridge does not know that it is a fragmented packet and forwards it directly, after NF_CONNTRACK_BRIDGE is enabled, function nf_br_ip_fragment and br_ip6_fragment will check the headroom. In original br_forward, insufficient headroom of skb may indeed exist, but there's still a way to save the skb in the device driver after dev_queue_xmit.So droping the skb will change the original bridge forwarding in some cases. Fixes: 3c171f496ef5 ("netfilter: bridge: add connection tracking system") Signed-off-by: Huajian Yang <huajianyang@asrmicro.com> Reviewed-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2025-05-05um: fix _nofault accessesJohannes Berg4-15/+17
Nathan reported [1] that when built with clang, the um kernel crashes pretty much immediately. This turned out to be an issue with the inline assembly I had added, when clang used %rax/%eax for both operands. Reorder it so current->thread.segv_continue is written first, and then the lifetime of _faulted won't have overlap with the lifetime of segv_continue. In the email thread Benjamin also pointed out that current->mm is only NULL for true kernel tasks, but we could do this for a userspace task, so the current->thread.segv_continue logic must be lifted out of the mm==NULL check. Finally, while looking at this, put a barrier() so the NULL assignment to thread.segv_continue cannot be reorder before the possibly faulting operation. Reported-by: Nathan Chancellor <nathan@kernel.org> Closes: https://lore.kernel.org/r/20250402221254.GA384@ax162 [1] Fixes: d1d7f01f7cd3 ("um: mark rodata read-only and implement _nofault accesses") Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-05-05wifi: rtw89: constrain TX power according to dynamic antenna power tableKuan-Chung Chen4-26/+150
Dynamic Antenna Gain (DAG) adjusts TX power based on antenna gain. To prevent signal distortion from excessive power increases, a dynamic antenna power table limits the maximum adjustable TX power. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250430055157.13623-3-pkshih@realtek.com
2025-05-05wifi: rtw89: phy: add C2H event handler for report of FW scanKuan-Chung Chen3-3/+46
Newer firmware will notify driver of the Packet Detection (PD) value on the channel after switch channels during FW scan. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250430055157.13623-2-pkshih@realtek.com
2025-05-05wifi: rtw89: Fix inadverent sharing of struct ieee80211_supported_band dataOndrej Jirman1-5/+28
Internally wiphy writes to individual channels in this structure, so we must not share one static definition of channel list between multiple device instances, because that causes hard to debug breakage. For example, with two rtw89 driven devices in the system, channel information may get incoherent, preventing channel use. Signed-off-by: Ondrej Jirman <megi@xff.cz> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250429122916.1734879-3-megi@xff.cz
2025-05-05wifi: rtw89: Convert rtw89_core_set_supported_band to use devm_*Ondrej Jirman1-63/+36
The code can be simplified by using device managed memory allocations. Simplify it. Signed-off-by: Ondrej Jirman <megi@xff.cz> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250429122916.1734879-2-megi@xff.cz
2025-05-05wifi: rtw89: introduce helper to get designated link for MLOZong-Zhe Yang5-38/+43
A link bound to HW band 0 was previously always assumed to exist, because it's true on non-MLD connection, and MLO connection is not supported yet. Now, start to consider MLO cases and prepare to enable MLO support in the following. Add skeleton of designated link. For single-link cases, helper returns the one. For multi-link cases, priorities can be scheduled. Then, drop assumption of link bound to HW band 0. One exception is that MCC doesn't work with MLD yet, so it still expects link on HW band 0 somewhere. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-11-pkshih@realtek.com
2025-05-05wifi: rtw89: roc: dynamically handle link id and link instance indexZong-Zhe Yang4-11/+16
Originally, a macro, RTW89_ROC_BY_LINK_INDEX, is used to decide the link which deals with the ROC process. Before enabling MLO support, it's fine to hard-code RTW89_ROC_BY_LINK_INDEX as 0 since the link instance-0 (on HW-0) is always active. But, for the impending enablement of MLO support, tweak the leaf functions to dynamically handle ROC link instance index. Besides, in the follow-up, ROC caller will get a designated link and will then drop RTW89_ROC_BY_LINK_INDEX. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-10-pkshih@realtek.com
2025-05-05wifi: rtw89: Fill in correct Rx link ID for MLOPo-Hao Huang2-13/+14
For MLO connections, RX link ID is required to do address conversion. Fill it in by the hardware info. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-9-pkshih@realtek.com
2025-05-05wifi: rtw89: add MLD capabilities declarationPo-Hao Huang1-1/+21
Add MLD capabilities so association requests can carry multi-link element with correct content. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-8-pkshih@realtek.com
2025-05-05wifi: rtw89: extend join_info H2C command for MLO fieldsPo-Hao Huang2-2/+26
The join_info H2C command is used to indicate a station is connected and tell FW to create/maintain an instance for it. Extend to fill MLO fields. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-7-pkshih@realtek.com
2025-05-05wifi: rtw89: Configure scan band when mlo_dbcc_mode changesPo-Hao Huang3-1/+4
Previously only the first band is used for scanning. With MLO, update scan parameters accordingly by so we can choose to scan from either band. C2H event return value reflects current scanning band, mask it out so we don't treat correct return value as fail. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-6-pkshih@realtek.com
2025-05-05wifi: rtw89: extend mapping from Qsel to DMA ch for MLOZong-Zhe Yang1-0/+12
After impending MLO support, TX Qsel would come from other HW band rather than HW-0. For example, when working on HW-1, TX release report may fill QSEL_XX_1 and cause warning "Cannot map qsel to dma: ...". So, extend the mapping to recognize multiple HW bands. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-5-pkshih@realtek.com
2025-05-05wifi: rtw89: Adjust management queue mapping for [MLO, HW-1]Po-Hao Huang2-1/+20
Adjust mapping of management packets accordingly to send it on the second hardware band. Previously only single band is used and we plan to enable MLO, so the second band will be needed. Data packets will be steered by hardware so no related changes are required. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-4-pkshih@realtek.com
2025-05-05wifi: rtw89: 8922a: use SW CRYPTO when broadcast in MLO modePo-Hao Huang8-0/+11
8922A doesn't support broadcast/multicast traffic under MLO mode. So let mac80211 do the encryption/decryption for us when the connection is in MLO mode. Future BE ICs fixes this issue. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-3-pkshih@realtek.com
2025-05-05wifi: rtw89: 8922a: rfk: adjust timeout time of RX DCKPing-Ke Shih1-1/+2
The RX DCK in firmware could retry 3 times if calibration value is not stable. Roughly each calibration can be done within 16 ms, so expect 16 * 4 (with additional 16 ms) will be enough. More, in coming MLO, it will do calibration on two path, so multiply 2. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-2-pkshih@realtek.com
2025-05-05wifi: rtw89: fw: Remove "const" on allocation typeKees Cook1-1/+1
In preparation for making the kmalloc family of allocators type aware, we need to make sure that the returned type from the allocation matches the type of the variable being assigned. (Before, the allocator would always return "void *", which can be implicitly cast to any pointer type.) The assigned type is "struct rtw89_reg2_def *" but the returned type, while technically matching, will be const qualified. As there isn't a general way to discard "const" qualifiers, adjust the returned type to match the assigned type. No change in allocation size results. Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250426060935.work.049-kees@kernel.org
2025-05-05wifi: rtlwifi: Remove unused rtl_bb_delay()Dr. David Alan Gilbert2-12/+0
The last use of rtl_bb_delay() was removed in 2014's commit 5c99f04fec93 ("rtlwifi: rtl8723be: Update driver to match Realtek release of 06/28/14") Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250425235340.288340-4-linux@treblig.org
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-02 11:36:20 +0300