- 11 Apr, 2024 24 commits
-
-
Geliang Tang authored
This patch adds a new helper chk_msk_info() to show the counters in mptcp_info of the given info, and check that the timestamps move forward. Use it to show newly added last_data_sent, last_data_recv and last_ack_recv in mptcp_info in chk_last_time_info(). Signed-off-by:
Geliang Tang <tanggeliang@kylinos.cn> Reviewed-by:
Matthieu Baerts (NGI0) <matttbe@kernel.org> Reviewed-by:
Mat Martineau <martineau@kernel.org> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Geliang Tang authored
This patch adds "last time" fields last_data_sent, last_data_recv and last_ack_recv in struct mptcp_sock to record the last time data_sent, data_recv and ack_recv happened. They all are initialized as tcp_jiffies32 in __mptcp_init_sock(), and updated as tcp_jiffies32 too when data is sent in __subflow_push_pending(), data is received in __mptcp_move_skbs_from_subflow(), and ack is received in ack_update_msk(). Similar to tcpi_last_data_sent, tcpi_last_data_recv and tcpi_last_ack_recv exposed with TCP, this patch exposes the last time "an action happened" for MPTCP in mptcp_info, named mptcpi_last_data_sent, mptcpi_last_data_recv and mptcpi_last_ack_recv, calculated in mptcp_diag_fill_info() as the time deltas between now and the newly added last time fields in mptcp_sock. Since msk->last_ack_recv needs to be protected by mptcp_data_lock/unlock, and lock_sock_fast can sleep and be quite slow, move the entire mptcp_data_lock/unlock block after the lock/unlock_sock_fast block. Then mptcpi_last_data_sent and mptcpi_last_data_recv are set in lock/unlock_sock_fast block, while mptcpi_last_ack_recv is set in mptcp_data_lock/unlock block, which is protected by a spinlock and should not block for too long. Also add three reserved bytes in struct mptcp_info not to have holes in this structure exposed to userspace. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/446Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.gitJakub Kicinski authored
Erick Archer says: ==================== mana: Add flex array to struct mana_cfg_rx_steer_req_v2 (part) The "struct mana_cfg_rx_steer_req_v2" uses a dynamically sized set of trailing elements. Specifically, it uses a "mana_handle_t" array. So, use the preferred way in the kernel declaring a flexible array [1]. At the same time, prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). Also, avoid the open-coded arithmetic in the memory allocator functions [2] using the "struct_size" macro. Moreover, use the "offsetof" helper to get the indirect table offset instead of the "sizeof" operator and avoid the open-coded arithmetic in pointers using the new flex member. This new structure member also allow us to remove the "req_indir_tab" variable since it is no longer needed. Now, it is also possible to use the "flex_array_size" helper to compute the size of these trailing elements in the "memcpy" function. Specifically, the first commit adds the flex member and the patches 2 and 3 refactor the consumers of the "struct mana_cfg_rx_steer_req_v2". This code was detected with the help of Coccinelle, and audited and modified manually. The Coccinelle script used to detect this code pattern is the following: virtual report @rule1@ type t1; type t2; identifier i0; identifier i1; identifier i2; identifier ALLOC =~ "kmalloc|kzalloc|kmalloc_node|kzalloc_node|vmalloc|vzalloc|kvmalloc|kvzalloc"; position p1; @@ i0 = sizeof(t1) + sizeof(t2) * i1; ... i2 = ALLOC@p1(..., i0, ...); @script:python depends on report@ p1 << rule1.p1; @@ msg = "WARNING: verify allocation on line %s" % (p1[0].line) coccilib.report.print_report(p1[0],msg) Link: https://www.kernel.org/doc/html/next/process/deprecated.html#zero-length-and-one-element-arrays [1] Link: https://www.kernel.org/doc/html/next/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [2] v1: https://lore.kernel.org/linux-hardening/AS8PR02MB7237974EF1B9BAFA618166C38B382@AS8PR02MB7237.eurprd02.prod.outlook.com/ v2: https://lore.kernel.org/linux-hardening/AS8PR02MB723729C5A63F24C312FC9CD18B3F2@AS8PR02MB7237.eurprd02.prod.outlook.com/ ==================== Link: https://lore.kernel.org/r/AS8PR02MB72374BD1B23728F2E3C3B1A18B022@AS8PR02MB7237.eurprd02.prod.outlook.comSigned-off-by:
-
Erick Archer authored
This is an effort to get rid of all multiplications from allocation functions in order to prevent integer overflows [1][2]. As the "req" variable is a pointer to "struct mana_cfg_rx_steer_req_v2" and this structure ends in a flexible array: struct mana_cfg_rx_steer_req_v2 { [...] mana_handle_t indir_tab[] __counted_by(num_indir_entries); }; the preferred way in the kernel is to use the struct_size() helper to do the arithmetic instead of the calculation "size + size * count" in the kzalloc() function. Moreover, use the "offsetof" helper to get the indirect table offset instead of the "sizeof" operator and avoid the open-coded arithmetic in pointers using the new flex member. This new structure member also allow us to remove the "req_indir_tab" variable since it is no longer needed. Now, it is also possible to use the "flex_array_size" helper to compute the size of these trailing elements in the "memcpy" function. This way, the code is more readable and safer. This code was detected with the help of Coccinelle, and audited and modified manually. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [1] Link: https://github.com/KSPP/linux/issues/160 [2] Signed-off-by:Erick Archer <erick.archer@outlook.com> Link: https://lore.kernel.org/r/AS8PR02MB7237A21355C86EC0DCC0D83B8B022@AS8PR02MB7237.eurprd02.prod.outlook.comReviewed-by:
Justin Stitt <justinstitt@google.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org>
-
Erick Archer authored
This is an effort to get rid of all multiplications from allocation functions in order to prevent integer overflows [1][2]. As the "req" variable is a pointer to "struct mana_cfg_rx_steer_req_v2" and this structure ends in a flexible array: struct mana_cfg_rx_steer_req_v2 { [...] mana_handle_t indir_tab[] __counted_by(num_indir_entries); }; the preferred way in the kernel is to use the struct_size() helper to do the arithmetic instead of the calculation "size + size * count" in the kzalloc() function. Moreover, use the "offsetof" helper to get the indirect table offset instead of the "sizeof" operator and avoid the open-coded arithmetic in pointers using the new flex member. This new structure member also allow us to remove the "req_indir_tab" variable since it is no longer needed. This way, the code is more readable and safer. This code was detected with the help of Coccinelle, and audited and modified manually. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [1] Link: https://github.com/KSPP/linux/issues/160 [2] Signed-off-by:Long Li <longli@microsoft.com> Reviewed-by:
-
Erick Archer authored
The "struct mana_cfg_rx_steer_req_v2" uses a dynamically sized set of trailing elements. Specifically, it uses a "mana_handle_t" array. So, use the preferred way in the kernel declaring a flexible array [1]. At the same time, prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). This is a previous step to refactor the two consumers of this structure. drivers/infiniband/hw/mana/qp.c drivers/net/ethernet/microsoft/mana/mana_en.c The ultimate goal is to avoid the open-coded arithmetic in the memory allocator functions [2] using the "struct_size" macro. Link: https://www.kernel.org/doc/html/next/process/deprecated.html#zero-length-and-one-element-arrays [1] Link: https://www.kernel.org/doc/html/next/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [2] Signed-off-by:
-
Jakub Kicinski authored
Michael Chan says: ==================== bnxt_en: Updates for net-next The first patch prevents a driver crash when RSS contexts are configred in ifdown state. Patches 2 to 6 are improvements for managing MSIX for the aux device (for RoCE). The existing scheme statically carves out the MSIX vectors for RoCE even if the RoCE driver is not loaded. The new scheme adds flexibility and allows the L2 driver to use the RoCE MSIX vectors if needed when they are unused by the RoCE driver. The last patch updates the MODULE_DESCRIPTION(). ==================== Link: https://lore.kernel.org/r/20240409215431.41424-1-michael.chan@broadcom.comSigned-off-by:
-
Michael Chan authored
Update MODULE_DESCRIPTION to the more generic adapter family name. The old name only includes the first generation of supported adapters. Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Reviewed-by:
Jacob Keller <jacob.e.keller@intel.com> Link: https://lore.kernel.org/r/20240409215431.41424-8-michael.chan@broadcom.comSigned-off-by:
-
Vikas Gupta authored
If the RoCE driver is not registered for a RoCE capable device, add flexibility to use the RoCE resources (MSIX/NQs) for L2 purposes, such as additional rings configured by the user or for XDP. Reviewed-by:
Andy Gospodarek <andrew.gospodarek@broadcom.com> Signed-off-by:
Vikas Gupta <vikas.gupta@broadcom.com> Signed-off-by:
-
Vikas Gupta authored
The existing scheme sets aside a number of MSIX/NQs for the RoCE driver whether the RoCE driver is registered or not. This scheme is not flexible and limits the resources available for the L2 rings if RoCE is never used. Modify the scheme so that the RoCE MSIX/NQs can be used by the L2 driver if they are not used for RoCE. The MSIX/NQs are now represented by 3 fields. bp->ulp_num_msix_want contains the desired default value, edev->ulp_num_msix_vec contains the available value (but not necessarily in use), and ulp_tbl->msix_requested contains the actual value in use by RoCE. The L2 driver can dip into edev->ulp_num_msix_vec if necessary. We need to add rtnl_lock() back in bnxt_register_dev() and bnxt_unregister_dev() to synchronize the MSIX usage between L2 and RoCE. Reviewed-by:
-
Vikas Gupta authored
In its current form, bnxt_rdma_aux_device_init() not only initializes the necessary data structures of the newly created aux device but also adds the aux device into the aux bus subsytem. Refactor the logic into separate functions, first function to initialize the aux device along with the required resources and second, to actually add the device to the aux bus subsytem. This separation helps to create bnxt_en_dev much earlier and save its resources separately. Reviewed-by:
-
Vikas Gupta authored
Ever since commit: 30343221 ("bnxt_en: Remove runtime interrupt vector allocation") The MSIX base vector is effectively always 0. Remove all unneeded structure fields and code referencing the MSIX base. Reviewed-by:
Somnath Kotur <somnath.kotur@broadcom.com> Reviewed-by:
-
Kalesh AP authored
The memory for "edev->ulp_tbl" is allocated inside the bnxt_rdma_aux_device_init() function. If it fails, the driver will not create the auxiliary device for RoCE. Hence the NULL check inside bnxt_register_dev() is unnecessary. Reviewed-by:
Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by:
-
Pavan Chebbi authored
The current implementation requires the ifstate to be up when configuring the RSS contexts. It will try to fetch the RX ring IDs and will crash if it is in ifdown state. Return error if !netif_running() to prevent the crash. An improved implementation is in the works to allow RSS contexts to be changed while in ifdown state. Fixes: b3d0083c ("bnxt_en: Support RSS contexts in ethtool .{get|set}_rxfh()") Reviewed-by:
Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by:
-
Ido Schimmel authored
The Spectrum-4 ASIC supports 100Gb/s per lane link modes, but the only one currently supported by the driver is 800Gb/s over eight lanes. Add support for 100Gb/s over one lane, 200Gb/s over two lanes and 400Gb/s over four lanes. Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
-
Ido Schimmel authored
After commit 40867d74 ("net: Add l3mdev index to flow struct and avoid oif reset for port devices") it is possible to configure FIB rules that match on iif / oif being a l3mdev port. It was not possible before as these parameters were reset to the ifindex of the l3mdev device itself prior to the FIB rules lookup. Add tests that cover this functionality as it does not seem to be covered by existing ones and I am aware of at least one user that needs this functionality in addition to the one mentioned in [1]. Reuse the existing FIB rules tests by simply configuring a VRF prior to the test and removing it afterwards. Differentiate the output of the non-VRF tests from the VRF tests by appending "(VRF)" to the test name if a l3mdev FIB rule is present. Verified that these tests do fail on kernel 5.15.y which does not include the previously mentioned commit: # ./fib_rule_tests.sh -t fib_rule6_vrf [...] TEST: rule6 check: oif redirect to table (VRF) [FAIL] [...] TEST: rule6 check: iif redirect to table (VRF) [FAIL] # ./fib_rule_tests.sh -t fib_rule4_vrf [...] TEST: rule4 check: oif redirect to table (VRF) [FAIL] [...] TEST: rule4 check: iif redirect to table (VRF) [FAIL] [1] https://lore.kernel.org/netdev/20200922131122.GB1601@ICIPI.localdomain/Signed-off-by:
David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20240409110816.2508498-1-idosch@nvidia.comSigned-off-by:
-
Hangbin Liu authored
The maxattr should be the latest attr value, i.e. array size - 1, not total array size. Reported-by: syzbot+ecd7e07b4be038658c9f@syzkaller.appspotmail.com Fixes: 948dbafc ("net: team: use policy generated by YAML spec") Suggested-by:
Hangbin Liu <liuhangbin@gmail.com> Link: https://lore.kernel.org/r/20240409092812.3999785-1-liuhangbin@gmail.comSigned-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by:
Herve Codina <herve.codina@bootlin.com> Link: https://lore.kernel.org/r/20240409091203.39062-2-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Hangbin Liu authored
Add bond support to rt_link.yaml. Here is an example output: $ ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/rt_link.yaml \ --do getlink --json '{"ifname": "bond0"}' --output-json | jq '.linkinfo' { "kind": "bond", "data": { "mode": 4, "miimon": 100, ... "arp-interval": 0, "arp-ip-target": [ "192.168.1.1", "192.168.1.2" ], "arp-validate": 0, "arp-all-targets": 0, "ns-ip6-target": [ "2001::1", "2001::2" ], "primary-reselect": 0, ... "missed-max": 2, "ad-info": { "aggregator": 1, "num-ports": 1, "actor-key": 0, "partner-key": 1, "partner-mac": "00:00:00:00:00:00" } } } And here is the downlink info. $ ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/rt_link.yaml \ --do getlink --json '{"ifname": "dummy0"}' --output-json | jq '.linkinfo' { "kind": "dummy", "slave-kind": "bond", "slave-data": { "state": 0, "mii-status": 0, "link-failure-count": 0, "perm-hwaddr": "f2:82:f7:cc:47:13", "queue-id": 0, "prio": 0 } } Signed-off-by: -
Rahul Rameshbabu authored
nla_put_uint can either write a u32 or u64 netlink attribute value. The size depends on whether the value can be represented with a u32 or requires a u64. Use a uint annotation in various documentation to represent this. Signed-off-by:
Rahul Rameshbabu <rrameshbabu@nvidia.com> Link: https://lore.kernel.org/r/20240409232520.237613-2-rrameshbabu@nvidia.comSigned-off-by:
-
Jakub Kicinski authored
Pavel Begunkov says: ==================== optimise local CPU skb_attempt_defer_free Optimise the case when an skb comes to skb_attempt_defer_free() on the same CPU it was allocated on. The patch 1 enables skb caches and gives frags a chance to hit the page pool's fast path. CPU bound benchmarking with perfect skb_attempt_defer_free() gives around 1% of extra throughput. ==================== Link: https://lore.kernel.org/r/cover.1712711977.git.asml.silence@gmail.comSigned-off-by:
-
Pavel Begunkov authored
skb_attempt_defer_free() is used to free already processed skbs, so pass SKB_CONSUMED as the reason in kfree_skb_napi_cache(). Suggested-by:
Jason Xing <kerneljasonxing@gmail.com> Suggested-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Pavel Begunkov <asml.silence@gmail.com> Reviewed-by:
-
Pavel Begunkov authored
Optimise skb_attempt_defer_free() when run by the same CPU the skb was allocated on. Instead of __kfree_skb() -> kmem_cache_free() we can disable softirqs and put the buffer into cpu local caches. CPU bound TCP ping pong style benchmarking (i.e. netbench) showed a 1% throughput increase (392.2 -> 396.4 Krps). Cross checking with profiles, the total CPU share of skb_attempt_defer_free() dropped by 0.6%. Note, I'd expect the win doubled with rx only benchmarks, as the optimisation is for the receive path, but the test spends >55% of CPU doing writes. Signed-off-by:
-
Eric Dumazet authored
I forgot 32bit arches might have 64bit alignment for u64 fields. tcp_sock_write_txrx group does not contain pointers, but two u64 fields. It is possible that on 32bit kernel, a 32bit hole is before tp->tcp_clock_cache. I will try to remember a group can be bigger on 32bit kernels in the future. With help from Vladimir Oltean. Fixes: d2c3a7eb ("tcp: more struct tcp_sock adjustments") Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202404082207.HCEdQhUO-lkp@intel.com/Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20240409140914.4105429-1-edumazet@google.comSigned-off-by:
-
- 10 Apr, 2024 16 commits
-
-
Jakub Kicinski authored
Jakub Kicinski says: ==================== selftests: move bpf-offload test from bpf to net The test_offload.py test fits in networking and bpf equally well. We started adding more Python tests in networking and some of the code in test_offload.py can be reused, so move it to networking. Looks like it bit rotted over time and some fixes are needed. Admittedly more code could be extracted but I only had the time for a minor cleanup :( ==================== Link: https://lore.kernel.org/r/20240409031549.3531084-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
net/lib/py/nsim.py already contains the most useful parts of the netdevsim wrapper classes. Reuse them. Acked-by:
Stanislav Fomichev <sdf@google.com> Acked-by:
Martin KaFai Lau <martin.lau@kernel.org> Link: https://lore.kernel.org/r/20240409031549.3531084-5-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Non-ancient ip (iproute2-5.15.0, libbpf 0.7.0) refuses to load the sample with maps because we don't generate BTF: libbpf: BTF is required, but is missing or corrupted. ERROR: opening BPF object file failed Enable BTF by adding -g to clang flags. With that done neither of the programs load: libbpf: prog 'func': error relocating .BTF.ext function info: -22 libbpf: prog 'func': failed to relocate calls: -22 libbpf: failed to load object 'ksft-net-drv/net/sample_ret0.bpf.o' Andrii explains that this is because we don't specify section names for the code. Add the section names, too. Acked-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
-
Jakub Kicinski authored
Maps are removed asynchronously. Either there's a bigger delay now or the test has always been flaky. Retry waiting in the loop. Acked-by:
-
Jakub Kicinski authored
We're building more python tests on the netdev side, and some of the classes from the venerable BPF offload tests can be reused. Acked-by:
-
Jianbo Liu authored
The filter counter is updated under the protection of cb_lock in the cited commit. While waiting for the lock, it's possible the filter is being deleted by other thread, and thus causes UAF when dump it. Fix this issue by moving tcf_block_filter_cnt_update() after tfilter_put(). ================================================================== BUG: KASAN: slab-use-after-free in fl_dump_key+0x1d3e/0x20d0 [cls_flower] Read of size 4 at addr ffff88814f864000 by task tc/2973 CPU: 7 PID: 2973 Comm: tc Not tainted 6.9.0-rc2_for_upstream_debug_2024_04_02_12_41 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x7e/0xc0 print_report+0xc1/0x600 ? __virt_addr_valid+0x1cf/0x390 ? fl_dump_key+0x1d3e/0x20d0 [cls_flower] ? fl_dump_key+0x1d3e/0x20d0 [cls_flower] kasan_report+0xb9/0xf0 ? fl_dump_key+0x1d3e/0x20d0 [cls_flower] fl_dump_key+0x1d3e/0x20d0 [cls_flower] ? lock_acquire+0x1c2/0x530 ? fl_dump+0x172/0x5c0 [cls_flower] ? lockdep_hardirqs_on_prepare+0x400/0x400 ? fl_dump_key_options.part.0+0x10f0/0x10f0 [cls_flower] ? do_raw_spin_lock+0x12d/0x270 ? spin_bug+0x1d0/0x1d0 fl_dump+0x21d/0x5c0 [cls_flower] ? fl_tmplt_dump+0x1f0/0x1f0 [cls_flower] ? nla_put+0x15f/0x1c0 tcf_fill_node+0x51b/0x9a0 ? tc_skb_ext_tc_enable+0x150/0x150 ? __alloc_skb+0x17b/0x310 ? __build_skb_around+0x340/0x340 ? down_write+0x1b0/0x1e0 tfilter_notify+0x1a5/0x390 ? fl_terse_dump+0x400/0x400 [cls_flower] tc_new_tfilter+0x963/0x2170 ? tc_del_tfilter+0x1490/0x1490 ? print_usage_bug.part.0+0x670/0x670 ? lock_downgrade+0x680/0x680 ? security_capable+0x51/0x90 ? tc_del_tfilter+0x1490/0x1490 rtnetlink_rcv_msg+0x75e/0xac0 ? if_nlmsg_stats_size+0x4c0/0x4c0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? __netlink_lookup+0x35e/0x6e0 netlink_rcv_skb+0x12c/0x360 ? if_nlmsg_stats_size+0x4c0/0x4c0 ? netlink_ack+0x15e0/0x15e0 ? lockdep_hardirqs_on_prepare+0x400/0x400 ? netlink_deliver_tap+0xcd/0xa60 ? netlink_deliver_tap+0xcd/0xa60 ? netlink_deliver_tap+0x1c9/0xa60 netlink_unicast+0x43e/0x700 ? netlink_attachskb+0x750/0x750 ? lock_acquire+0x1c2/0x530 ? __might_fault+0xbb/0x170 netlink_sendmsg+0x749/0xc10 ? netlink_unicast+0x700/0x700 ? __might_fault+0xbb/0x170 ? netlink_unicast+0x700/0x700 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x534/0x6b0 ? import_iovec+0x7/0x10 ? kernel_sendmsg+0x30/0x30 ? __copy_msghdr+0x3c0/0x3c0 ? entry_SYSCALL_64_after_hwframe+0x46/0x4e ? lock_acquire+0x1c2/0x530 ? __virt_addr_valid+0x116/0x390 ___sys_sendmsg+0xeb/0x170 ? __virt_addr_valid+0x1ca/0x390 ? copy_msghdr_from_user+0x110/0x110 ? __delete_object+0xb8/0x100 ? __virt_addr_valid+0x1cf/0x390 ? do_sys_openat2+0x102/0x150 ? lockdep_hardirqs_on_prepare+0x284/0x400 ? do_sys_openat2+0x102/0x150 ? __fget_light+0x53/0x1d0 ? sockfd_lookup_light+0x1a/0x150 __sys_sendmsg+0xb5/0x140 ? __sys_sendmsg_sock+0x20/0x20 ? lock_downgrade+0x680/0x680 do_syscall_64+0x70/0x140 entry_SYSCALL_64_after_hwframe+0x46/0x4e RIP: 0033:0x7f98e3713367 Code: 0e 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 RSP: 002b:00007ffc74a64608 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000047eae0 RCX: 00007f98e3713367 RDX: 0000000000000000 RSI: 00007ffc74a64670 RDI: 0000000000000003 RBP: 0000000000000008 R08: 0000000000000000 R09: 0000000000000000 R10: 00007f98e360c5e8 R11: 0000000000000246 R12: 00007ffc74a6a508 R13: 00000000660d518d R14: 0000000000484a80 R15: 00007ffc74a6a50b </TASK> Allocated by task 2973: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x77/0x90 fl_change+0x27a6/0x4540 [cls_flower] tc_new_tfilter+0x879/0x2170 rtnetlink_rcv_msg+0x75e/0xac0 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x43e/0x700 netlink_sendmsg+0x749/0xc10 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x534/0x6b0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x70/0x140 entry_SYSCALL_64_after_hwframe+0x46/0x4e Freed by task 283: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 poison_slab_object+0x105/0x190 __kasan_slab_free+0x11/0x30 kfree+0x111/0x340 process_one_work+0x787/0x1490 worker_thread+0x586/0xd30 kthread+0x2df/0x3b0 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 Last potentially related work creation: kasan_save_stack+0x20/0x40 __kasan_record_aux_stack+0x9b/0xb0 insert_work+0x25/0x1b0 __queue_work+0x640/0xc90 rcu_work_rcufn+0x42/0x70 rcu_core+0x6a9/0x1850 __do_softirq+0x264/0x88f Second to last potentially related work creation: kasan_save_stack+0x20/0x40 __kasan_record_aux_stack+0x9b/0xb0 __call_rcu_common.constprop.0+0x6f/0xac0 queue_rcu_work+0x56/0x70 fl_mask_put+0x20d/0x270 [cls_flower] __fl_delete+0x352/0x6b0 [cls_flower] fl_delete+0x97/0x160 [cls_flower] tc_del_tfilter+0x7d1/0x1490 rtnetlink_rcv_msg+0x75e/0xac0 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x43e/0x700 netlink_sendmsg+0x749/0xc10 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x534/0x6b0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x70/0x140 entry_SYSCALL_64_after_hwframe+0x46/0x4e Fixes: 2081fd34 ("net: sched: cls_api: add filter counter") Signed-off-by:
Jianbo Liu <jianbol@nvidia.com> Reviewed-by:
Cosmin Ratiu <cratiu@nvidia.com> Tested-by:
Asbjørn Sloth Tønnesen <ast@fiberby.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Mina Almasry says: ==================== Minor cleanups to skb frag ref/unref (part) This series is largely motivated by a recent discussion where there was some confusion on how to properly ref/unref pp pages vs non pp pages: https://lore.kernel.org/netdev/CAHS8izOoO-EovwMwAm9tLYetwikNPxC0FKyVGu1TPJWSz4bGoA@mail.gmail.com/T/#t There is some subtely there because pp uses page->pp_ref_count for refcounting, while non-pp uses get_page()/put_page() for ref counting. Getting the refcounting pairs wrong can lead to kernel crash. [...] https://lore.kernel.org/lkml/CAHS8izN436pn3SndrzsCyhmqvJHLyxgCeDpWXA4r1ANt3RCDLQ@mail.gmail.com/T/ ==================== Link: https://lore.kernel.org/r/20240408153000.2152844-1-almasrymina@google.comSigned-off-by:
-
Mina Almasry authored
With the changes in the last patches, napi_frag_unref() is now reduandant. Remove it and use skb_page_unref directly. Signed-off-by:
Mina Almasry <almasrymina@google.com> Reviewed-by:
Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by:
-
Mina Almasry authored
The implementations of these 2 functions are almost identical. Remove the implementation of napi_frag_unref, and make it a call into skb_page_unref so we don't duplicate the implementation. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Tony Nguyen says: ==================== net/e1000e, igb, igc: Remove redundant runtime resume Bjorn Helgaas says: e1000e, igb, and igc all have code to runtime resume the device during ethtool operations. Since f32a2137 ("ethtool: runtime-resume netdev parent before ethtool ioctl ops"), dev_ethtool() does this for us, so remove it from the individual drivers. * '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: igc: Remove redundant runtime resume for ethtool ops igb: Remove redundant runtime resume for ethtool_ops e1000e: Remove redundant runtime resume for ethtool_ops ==================== Link: https://lore.kernel.org/r/20240408210849.3641172-1-anthony.l.nguyen@intel.comSigned-off-by:
-
Jakub Kicinski authored
Eric Dumazet says: ==================== bonding: remove RTNL from three sysfs files First patch might fix a potential deadlock. sysfs handlers should use rtnl_trylock() instead of rtnl_lock(). Following files can be read without acquiring RTNL : - /sys/class/net/bonding_masters - /sys/class/net/<name>/bonding/slaves - /sys/class/net/<name>/bonding/queue_id ==================== Link: https://lore.kernel.org/r/20240408190437.2214473-1-edumazet@google.comSigned-off-by:
-
Eric Dumazet authored
Annotate lockless reads of slave->queue_id. Annotate writes of slave->queue_id. Switch bonding_show_queue_id() to rcu_read_lock() and bond_for_each_slave_rcu(). Signed-off-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Link: https://lore.kernel.org/r/20240408190437.2214473-4-edumazet@google.comSigned-off-by:
-
Eric Dumazet authored
Slave devices are already RCU protected, simply switch to bond_for_each_slave_rcu(), Signed-off-by:
-
Eric Dumazet authored
netdev structures are already RCU protected. Change bond_init() and bond_uninit() to use RCU enabled list_add_tail_rcu() and list_del_rcu(). Then bonding_show_bonds() can use rcu_read_lock() while iterating through bn->dev_list. Signed-off-by:
-
Kuan-Wei Chiu authored
When constructing a heap, heapify operations are required on all non-leaf nodes. Thus, determining the index of the first non-leaf node is crucial. In a heap, the left child's index of node i is 2 * i + 1 and the right child's index is 2 * i + 2. Node CAKE_MAX_TINS * CAKE_QUEUES / 2 has its left and right children at indexes CAKE_MAX_TINS * CAKE_QUEUES + 1 and CAKE_MAX_TINS * CAKE_QUEUES + 2, respectively, which are beyond the heap's range, indicating it as a leaf node. Conversely, node CAKE_MAX_TINS * CAKE_QUEUES / 2 - 1 has a left child at index CAKE_MAX_TINS * CAKE_QUEUES - 1, confirming its non-leaf status. The loop should start from it since it's not a leaf node. By starting the loop from CAKE_MAX_TINS * CAKE_QUEUES / 2 - 1, we minimize function calls and branch condition evaluations. This adjustment theoretically reduces two function calls (one for cake_heapify() and another for cake_heap_get_backlog()) and five branch evaluations (one for iterating all non-leaf nodes, one within cake_heapify()'s while loop, and three more within the while loop with if conditions). Signed-off-by:
Kuan-Wei Chiu <visitorckw@gmail.com> Acked-by:
Toke Høiland-Jørgensen <toke@toke.dk> Link: https://lore.kernel.org/r/20240408174716.751069-1-visitorckw@gmail.comSigned-off-by:
-
Asbjørn Sloth Tønnesen authored
Replace netdev_{warn,err} with NL_SET_ERR_MSG_{FMT_,}MOD to better inform the user about the problem. Only compile-tested, no access to HW. Signed-off-by:
-
