summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
8 daysipv6: change inet6_sk_rebuild_header() to use inet->cork.fl.u.ip6Eric Dumazet
TCP v6 spends a good amount of time rebuilding a fresh fl6 at each transmit in inet6_csk_xmit()/inet6_csk_route_socket(). TCP v4 caches the information in inet->cork.fl.u.ip4 instead. This patch is a first step converting IPv6 to the same strategy: Before this patch inet6_sk_rebuild_header() only validated/rebuilt a dst. Automatic variable @fl6 content was lost. After this patch inet6_sk_rebuild_header() also initializes inet->cork.fl.u.ip6, which can be reused in the future. This makes inet6_sk_rebuild_header() very similar to inet_sk_rebuild_header(). Also remove the EXPORT_SYMBOL_GPL(), inet6_sk_rebuild_header() is not called from any module. Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260204163035.4123817-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
8 daysMerge branch ↵Jakub Kicinski
'tcp-remove-net-core-request_sock-c-and-no-longer-inline-__reqsk_free' Eric Dumazet says: ==================== tcp: remove net/core/request_sock.c and no longer inline __reqsk_free() After DCCP removal, net/core/request_sock.c makes no more sense. Move reqsk_queue_alloc() and reqsk_fastopen_remove() to TCP files. Then put __reqsk_free() out of line to save ~2 Kbytes of text. ==================== Link: https://patch.msgid.link/20260204055147.1682705-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
8 daystcp: move __reqsk_free() out of lineEric Dumazet
Inlining __reqsk_free() is overkill, let's reclaim 2 Kbytes of text. $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new add/remove: 2/4 grow/shrink: 2/14 up/down: 225/-2338 (-2113) Function old new delta __reqsk_free - 114 +114 sock_edemux 18 82 +64 inet_csk_listen_start 233 264 +31 __pfx___reqsk_free - 16 +16 __pfx_reqsk_queue_alloc 16 - -16 __pfx_reqsk_free 16 - -16 reqsk_queue_alloc 46 - -46 tcp_req_err 272 177 -95 reqsk_fastopen_remove 348 253 -95 cookie_bpf_check 157 62 -95 cookie_tcp_reqsk_alloc 387 290 -97 cookie_v4_check 1568 1465 -103 reqsk_free 105 - -105 cookie_v6_check 1519 1412 -107 sock_gen_put 187 78 -109 sock_pfree 212 82 -130 tcp_try_fastopen 1818 1683 -135 tcp_v4_rcv 3478 3294 -184 reqsk_put 306 90 -216 tcp_get_cookie_sock 551 318 -233 tcp_v6_rcv 3404 3141 -263 tcp_conn_request 2677 2384 -293 Total: Before=24887415, After=24885302, chg -0.01% Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260204055147.1682705-5-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
8 daysnet: get rid of net/core/request_sock.cEric Dumazet
After DCCP removal, this file was not needed any more. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260204055147.1682705-4-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
8 daystcp: move reqsk_fastopen_remove to net/ipv4/tcp_fastopen.cEric Dumazet
This function belongs to TCP stack, not to net/core/request_sock.c We get rid of the now empty request_sock.c n the following patch. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260204055147.1682705-3-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
8 daysinet: move reqsk_queue_alloc() to net/ipv4/inet_connection_sock.cEric Dumazet
Only called once from inet_csk_listen_start(), it can be static. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260204055147.1682705-2-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
8 daysMerge branch 'net-stmmac-rk-final-cleanups-part'Jakub Kicinski
Russell King says: ==================== net: stmmac: rk: final cleanups part This is the last part of my current dwmac-rk cleanups. ==================== Link: https://patch.msgid.link/aYMN2gZMfLPKuukG@shell.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
8 daysnet: stmmac: rk: rk3506, rk3528 and rk3588 have rmii_mode in clock registerRussell King (Oracle)
rk3506, rk3528 and rk3588 have the rmii_mode bit in the clock GRF register rather than the gmac GRF register. Provide a mask for this field in the clock register, and convert these SoCs to use this. Add the necessary code in rk_gmac_powerup() to write this field. This allows us to get rid of these SoCs set_to_rmii() function. As such, we need to mark these SoCs as supporting RMII mode. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> #px30,rk3328,rk3568,rk3588 Link: https://patch.msgid.link/E1vnYyB-00000007hpF-1dwK@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
8 daysnet: stmmac: rk: use rk_encode_wm16() for clock selectionRussell King (Oracle)
Use rk_encode_wm16() for RMII clock gating control, and also for the io_clksel bit used to select the transmit clock between CRU-derived and IO-derived clock sources. Both of these were configured via the "set_clock_selection" method in the SoC specific operations, but there is no requirement to change the io_clksel except when enabling clocks. It is also possible that we don't need to ungate the RMII clock if we are operating in RGMII mode, but this commit makes no change there. Split up the configuration of these as separate functions, and remove the set_clock_selection() method. Since these clocking bits are in the same register that we call the "speed" register, move the logic for writing that register into rk_write_speed_grf_reg(). Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> #px30,rk3328,rk3568,rk3588 Link: https://patch.msgid.link/E1vnYy6-00000007hp9-1AJM@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
8 daysnet: stmmac: rk: rk3528: gmac0 only supports RMIIRussell King (Oracle)
RK3528 gmac0 dtsi contains: gmac0: ethernet@ffbd0000 { phy-handle = <&rmii0_phy>; phy-mode = "rmii"; mdio0: mdio { rmii0_phy: ethernet-phy@2 { phy-is-integrated; }; }; }; This follows the same pattern as rk3328, where this gmac instance only supports RMII. Disable RGMII in phylink's supported_interfaces mask for this gmac instance. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/E1vnYy1-00000007hp3-0hKm@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
8 daysnet: stmmac: rk: rk3328: gmac2phy only supports RMIIRussell King (Oracle)
As detailed in a previous commit ("net: stmmac: rk: convert rk3328 to use bsp_priv->id") rk3328 gmac2phy only supports RMII, whereas gmac2io supports both RMII and RGMII. Clear supports_rgmii for gmac2phy. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> #px30,rk3328 gmac2io,rk3568,rk3588 Link: https://patch.msgid.link/E1vnYxw-00000007hox-0DqH@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
8 daysnet: stmmac: rk: replace empty set_to_rmii() with supports_rmiiRussell King (Oracle)
Rather than providing a now-empty set_to_rmii() method to indicate that RMII is supported, switch to setting ops->supports_rmii instead. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> #px30,rk3328,rk3568,rk3588 Link: https://patch.msgid.link/E1vnYxq-00000007hor-3yXt@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
8 daysnet: stmmac: rk: introduce flags indicating support for RGMII/RMIIRussell King (Oracle)
Introduce two boolean flags into struct rk_priv_data indicating whether RGMII and/or RMII is supported for this instance. Use these to configure the supported_interfaces mask for phylink, validate the interface mode. Initialise these from equivalent flags in the rk_gmac_ops or depending on the presence of the ops->set_to_rgmii and ops->set_to_mii methods. Finally, make ops->set_to_* optional. This will allow us to get rid of empty set_to_rmii() methods. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> #px30,rk3328,rk3568,rk3588 Link: https://patch.msgid.link/E1vnYxl-00000007hol-3XiH@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
8 daysgfs2: fiemap page fault fixAndreas Gruenbacher
In gfs2_fiemap(), we are calling iomap_fiemap() while holding the inode glock. This can lead to recursive glock taking if the fiemap buffer is memory mapped to the same inode and accessing it triggers a page fault. Fix by disabling page faults for iomap_fiemap() and faulting in the buffer by hand if necessary. Fixes xfstest generic/742. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
8 daysgpio: loongson-64bit: Fix incorrect NULL check after devm_kcalloc()Chen Ni
Fix incorrect NULL check in loongson_gpio_init_irqchip(). The function checks chip->parent instead of chip->irq.parents. Fixes: 03c146cb6cd1 ("gpio: loongson-64bit: Add support for Loongson-2K0300 SoC") Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Link: https://patch.msgid.link/20260205072649.3271158-1-nichen@iscas.ac.cn Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
8 daysASoC: cs35l56: KUnit tests for parsing and using onchip GPIOsRichard Fitzgerald
Add KUnit test cases for: - cs35l56_process_xu_properties() which reads the onchip GPIO definitions. - cs35l56_set_fw_name() calls functions to configure and set the GPIOs. - cs35l56_set_fw_name() saves the ID value in cs35l56_priv.speaker_id. - cs35l56_set_fw_name() does not overwrite a speaker ID that was already found some other way. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260205164838.1611295-4-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
8 daysASoC: cs35l56-shared: KUnit tests for onchip speaker ID gpiosRichard Fitzgerald
Add KUnit testing of: cs35l56_check_and_save_onchip_spkid_gpios() cs35l56_configure_onchip_spkid_pads() cs35l56_read_onchip_spkid() The test consists of: - A mock regmap that simulates the pad and pin config registers. - Parameterization of the pin list, pulls list, a simulated value for each pin and the speaker ID value that this should produce. - A self-test of the simulated pin and GPIO registers. - A test that the value returned by cs35l56_read_onchip_spkid() is correct. - A test that the pin pull-up/down are set correctly by cs35l56_configure_onchip_spkid_pads() - A test that cs35l56_configure_onchip_spkid_pads() and cs35l56_read_onchip_spkid(0 return the expected values if cs35l56_base->num_onchip_spkid_gpios == 0. - A test that cs35l56_check_and_save_onchip_spkid_gpios() saves the configuration. - A test that cs35l56_check_and_save_onchip_spkid_gpios() rejects illegal GPIO numbers. - A test that cs35l56_check_and_save_onchip_spkid_gpios() rejects illegal pull types. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260205164838.1611295-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
8 daysASoC: cs35l56: Support for reading speaker ID from on-chip GPIOsRichard Fitzgerald
Add support for using the state of pins on the amplifier to indicate the type of speaker fitted. Previously, where there were alternate speaker vendors, this was indicated using host CPU GPIOs. Some new Dell models use spare pins on the CS35L63 as GPIOs for the speaker ID detection. Cirrus-specific SDCA Disco properties provide a list of the pins to be used, and pull-up/down settings for the pads. This list is ordered, MSbit to LSbit. The code to set the firmware filename has been modified to check for using chip pins for speaker ID. The entire block of code to set firmware name has been moved out of cs35l56_component_probe() into its own function to make it easier to KUnit test. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260205164838.1611295-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
8 daysbpf: Require frozen map for calculating map hashKP Singh
Currently, bpf_map_get_info_by_fd calculates and caches the hash of the map regardless of the map's frozen state. This leads to a TOCTOU bug where userspace can call BPF_OBJ_GET_INFO_BY_FD to cache the hash and then modify the map contents before freezing. Therefore, a trusted loader can be tricked into verifying the stale hash while loading the modified contents. Fix this by returning -EPERM if the map is not frozen when the hash is requested. This ensures the hash is only generated for the final, immutable state of the map. Fixes: ea2e6467ac36 ("bpf: Return hashes of maps in BPF_OBJ_GET_INFO_BY_FD") Reported-by: Toshi Piazza <toshi.piazza@microsoft.com> Signed-off-by: KP Singh <kpsingh@kernel.org> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/r/20260205070755.695776-1-kpsingh@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
8 daysipv6: Fix ECMP sibling count mismatch when clearing RTF_ADDRCONFShigeru Yoshida
syzbot reported a kernel BUG in fib6_add_rt2node() when adding an IPv6 route. [0] Commit f72514b3c569 ("ipv6: clear RA flags when adding a static route") introduced logic to clear RTF_ADDRCONF from existing routes when a static route with the same nexthop is added. However, this causes a problem when the existing route has a gateway. When RTF_ADDRCONF is cleared from a route that has a gateway, that route becomes eligible for ECMP, i.e. rt6_qualify_for_ecmp() returns true. The issue is that this route was never added to the fib6_siblings list. This leads to a mismatch between the following counts: - The sibling count computed by iterating fib6_next chain, which includes the newly ECMP-eligible route - The actual siblings in fib6_siblings list, which does not include that route When a subsequent ECMP route is added, fib6_add_rt2node() hits BUG_ON(sibling->fib6_nsiblings != rt->fib6_nsiblings) because the counts don't match. Fix this by only clearing RTF_ADDRCONF when the existing route does not have a gateway. Routes without a gateway cannot qualify for ECMP anyway (rt6_qualify_for_ecmp() requires fib_nh_gw_family), so clearing RTF_ADDRCONF on them is safe and matches the original intent of the commit. [0]: kernel BUG at net/ipv6/ip6_fib.c:1217! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 6010 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 RIP: 0010:fib6_add_rt2node+0x3433/0x3470 net/ipv6/ip6_fib.c:1217 [...] Call Trace: <TASK> fib6_add+0x8da/0x18a0 net/ipv6/ip6_fib.c:1532 __ip6_ins_rt net/ipv6/route.c:1351 [inline] ip6_route_add+0xde/0x1b0 net/ipv6/route.c:3946 ipv6_route_ioctl+0x35c/0x480 net/ipv6/route.c:4571 inet6_ioctl+0x219/0x280 net/ipv6/af_inet6.c:577 sock_do_ioctl+0xdc/0x300 net/socket.c:1245 sock_ioctl+0x576/0x790 net/socket.c:1366 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: f72514b3c569 ("ipv6: clear RA flags when adding a static route") Reported-by: syzbot+cb809def1baaac68ab92@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=cb809def1baaac68ab92 Tested-by: syzbot+cb809def1baaac68ab92@syzkaller.appspotmail.com Signed-off-by: Shigeru Yoshida <syoshida@redhat.com> Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de> Link: https://patch.msgid.link/20260204095837.1285552-1-syoshida@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
8 daysMerge tag 'nf-26-02-05' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf Florian Westphal says: ==================== netfilter: update for net This is one last-minute crash fix for nf_tables, from Andrew Fasano: Logical check is inverted, this makes kernel fail to correctly undo the transaction, leading to a use-after-free. * tag 'nf-26-02-05' of https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf: netfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate() ==================== Link: https://patch.msgid.link/20260205074450.3187-1-fw@strlen.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
8 daysbpf: Limit bpf program signature sizeKP Singh
Practical BPF signatures are significantly smaller than KMALLOC_MAX_CACHE_SIZE Allowing larger sizes opens the door for abuse by passing excessive size values and forcing the kernel into expensive allocation paths (via kmalloc_large or vmalloc). Fixes: 349271568303 ("bpf: Implement signature verification for BPF programs") Reported-by: Chris Mason <clm@meta.com> Signed-off-by: KP Singh <kpsingh@kernel.org> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/r/20260205063807.690823-1-kpsingh@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
8 daysloop: revert exclusive opener loop status changeJens Axboe
This commit effectively reverts the following two commits: 2704024d83fa ("loop: add missing bd_abort_claiming in loop_set_status") 08e136ebd193 ("loop: don't change loop device under exclusive opener in loop_set_status") as there are reports of them causing issues with unmounting. As we're close to the 6.19 kernel release and the original author hasn't taken a closer look at this yet, revert them for release. Reported-by: nokangaroo <nokangaroo@aon.at> Link: https://lore.kernel.org/all/62de4453-17e8-47f6-a10b-39bf5a49fdee@leemhuis.info/ Signed-off-by: Jens Axboe <axboe@kernel.dk>
8 daysobjtool/klp: Fix unexported static call key access for manually built ↵Josh Poimboeuf
livepatch modules Enabling CONFIG_MEM_ALLOC_PROFILING_DEBUG with CONFIG_SAMPLE_LIVEPATCH results in the following error: samples/livepatch/livepatch-shadow-fix1.o: error: objtool: static_call: can't find static_call_key symbol: __SCK__WARN_trap This is caused an extra file->klp sanity check which was added by commit 164c9201e1da ("objtool: Add base objtool support for livepatch modules"). That check was intended to ensure that livepatch modules built with klp-build always have full access to their static call keys. However, it failed to account for the fact that manually built livepatch modules (i.e., not built with klp-build) might need access to unexported static call keys, for which read-only access is typically allowed for modules. While the livepatch-shadow-fix1 module doesn't explicitly use any static calls, it does have a memory allocation, which can cause CONFIG_MEM_ALLOC_PROFILING_DEBUG to insert a WARN() call. And WARN() is now an unexported static call as of commit 860238af7a33 ("x86_64/bug: Inline the UD1"). Fix it by removing the overzealous file->klp check, restoring the original behavior for manually built livepatch modules. Fixes: 164c9201e1da ("objtool: Add base objtool support for livepatch modules") Reported-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Song Liu <song@kernel.org> Tested-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/0bd3ae9a53c3d743417fe842b740a7720e2bcd1c.1770058775.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
8 daysobjtool/klp: Fix symbol correlation for orphaned local symbolsJosh Poimboeuf
When compiling with CONFIG_LTO_CLANG_THIN, vmlinux.o has __irf_[start|end] before the first FILE entry: $ readelf -sW vmlinux.o Symbol table '.symtab' contains 597706 entries: Num: Value Size Type Bind Vis Ndx Name 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND 1: 0000000000000000 0 NOTYPE LOCAL DEFAULT 18 __irf_start 2: 0000000000000200 0 NOTYPE LOCAL DEFAULT 18 __irf_end 3: 0000000000000000 0 SECTION LOCAL DEFAULT 17 .text 4: 0000000000000000 0 SECTION LOCAL DEFAULT 18 .init.ramfs This causes klp-build warnings like: vmlinux.o: warning: objtool: no correlation: __irf_start vmlinux.o: warning: objtool: no correlation: __irf_end The problem is that Clang LTO is stripping the initramfs_data.o FILE symbol, causing those two symbols to be orphaned and not noticed by klp-diff's correlation logic. Add a loop to correlate any symbols found before the first FILE symbol. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Reported-by: Song Liu <song@kernel.org> Acked-by: Song Liu <song@kernel.org> Link: https://patch.msgid.link/e21ec1141fc749b5f538d7329b531c1ab63a6d1a.1770055235.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
8 dayslivepatch: Free klp_{object,func}_ext data after initializationPetr Pavlu
The klp_object_ext and klp_func_ext data, which are stored in the __klp_objects and __klp_funcs sections, respectively, are not needed after they are used to create the actual klp_object and klp_func instances. This operation is implemented by the init function in scripts/livepatch/init.c. Prefix the two sections with ".init" so they are freed after the module is initializated. Signed-off-by: Petr Pavlu <petr.pavlu@suse.com> Acked-by: Joe Lawrence <joe.lawrence@redhat.com> Acked-by: Miroslav Benes <mbenes@suse.cz> Reviewed-by: Aaron Tomlin <atomlin@atomlin.com> Link: https://patch.msgid.link/20260123102825.3521961-3-petr.pavlu@suse.com Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
8 dayslivepatch: Fix having __klp_objects relics in non-livepatch modulesPetr Pavlu
The linker script scripts/module.lds.S specifies that all input __klp_objects sections should be consolidated into an output section of the same name, and start/stop symbols should be created to enable scripts/livepatch/init.c to locate this data. This start/stop pattern is not ideal for modules because the symbols are created even if no __klp_objects input sections are present. Consequently, a dummy __klp_objects section also appears in the resulting module. This unnecessarily pollutes non-livepatch modules. Instead, since modules are relocatable files, the usual method for locating consolidated data in a module is to read its section table. This approach avoids the aforementioned problem. The klp_modinfo already stores a copy of the entire section table with the final addresses. Introduce a helper function that scripts/livepatch/init.c can call to obtain the location of the __klp_objects section from this data. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Signed-off-by: Petr Pavlu <petr.pavlu@suse.com> Acked-by: Joe Lawrence <joe.lawrence@redhat.com> Acked-by: Miroslav Benes <mbenes@suse.cz> Reviewed-by: Aaron Tomlin <atomlin@atomlin.com> Link: https://patch.msgid.link/20260123102825.3521961-2-petr.pavlu@suse.com Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
8 daysdriver core: remove device_change_owner() exportGreg Kroah-Hartman
The function, device_change_owner() is exported for modules to use, but there are no in-kernel users of it, so remove the export to prevent out-of-tree code from thinking this is a safe function to call. Reviewed-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Link: https://patch.msgid.link/2026020543-molar-childcare-af20@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8 dayssysfs: remove exports of sysfs_*change_owner()Greg Kroah-Hartman
Both sysfs_change_owner() and sysfs_file_change_owner() are exported to modules, but there are no in-kernel module users, so remove the exports so that crazy out-of-tree drivers don't get the impression that it is safe to call these functions at all. Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Reported-by: Lee Jones <lee@kernel.org> Reviewed-by: Lee Jones <lee@kernel.org> Link: https://patch.msgid.link/2026020541-energize-graduate-981a@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8 daysMerge tag 'nvme-6.19-2026-02-05' of git://git.infradead.org/nvme into block-6.19Jens Axboe
Pull NVMe fixes from Keith: "- Fix NULL pointer access setting up dma mappings (Keith) - Fix invalid memory access from malformed TCP PDU (YunJe)" * tag 'nvme-6.19-2026-02-05' of git://git.infradead.org/nvme: nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec nvme-pci: handle changing device dma map requirements
8 dayspkcs7: Change a pr_warn() to pr_warn_once()David Howells
Only display the "PKCS7: Waived invalid module sig (has authattrs)" once. Suggested-by: Lenny Szubowicz <lszubowi@redhat.com> Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: Lenny Szubowicz <lszubowi@redhat.com> cc: Lukas Wunner <lukas@wunner.de> cc: Ignat Korchagin <ignat@cloudflare.com> cc: Jarkko Sakkinen <jarkko@kernel.org> cc: Stephan Mueller <smueller@chronox.de> cc: Eric Biggers <ebiggers@kernel.org> cc: Herbert Xu <herbert@gondor.apana.org.au> cc: keyrings@vger.kernel.org cc: linux-crypto@vger.kernel.org
8 daysnet: add vlan_get_protocol_offset_inline() helperEric Dumazet
skb_protocol() is bloated, and forces slow stack canaries in many fast paths. Add vlan_get_protocol_offset_inline() which deals with the non-vlan common cases. __vlan_get_protocol_offset() is now out of line. It returns a vlan_type_depth struct to avoid stack canaries in callers. struct vlan_type_depth { __be16 type; u16 depth; }; $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new add/remove: 0/2 grow/shrink: 0/22 up/down: 0/-6320 (-6320) Function old new delta vlan_get_protocol_dgram 61 59 -2 __pfx_skb_protocol 16 - -16 __vlan_get_protocol_offset 307 273 -34 tap_get_user 1374 1207 -167 ip_md_tunnel_xmit 1625 1452 -173 tap_sendmsg 940 753 -187 netif_skb_features 1079 866 -213 netem_enqueue 3017 2800 -217 vlan_parse_protocol 271 50 -221 tso_start 567 344 -223 fq_dequeue 1908 1685 -223 skb_network_protocol 434 205 -229 ip6_tnl_xmit 2639 2409 -230 br_dev_queue_push_xmit 474 236 -238 skb_protocol 258 - -258 packet_parse_headers 621 357 -264 __ip6_tnl_rcv 1306 1039 -267 skb_csum_hwoffload_help 515 224 -291 ip_tunnel_xmit 2635 2339 -296 sch_frag_xmit_hook 1582 1233 -349 bpf_skb_ecn_set_ce 868 457 -411 IP6_ECN_decapsulate 1297 768 -529 ip_tunnel_rcv 2121 1489 -632 ipip6_rcv 2572 1922 -650 Total: Before=24892803, After=24886483, chg -0.03% Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260204053023.1622775-1-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
8 daysnvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovecYunJe Shin
nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec. Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Signed-off-by: YunJe Shin <ioerts@kookmin.ac.kr> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Joonkyo Jung <joonkyoj@yonsei.ac.kr> Signed-off-by: Keith Busch <kbusch@kernel.org>
8 daysnvme-pci: handle changing device dma map requirementsKeith Busch
The initial state of dma_needs_unmap may be false, but change to true while mapping the data iterator. Enabling swiotlb is one such case that can change the result. The nvme driver needs to save the mapped dma vectors to be unmapped later, so allocate as needed during iteration rather than assume it was always allocated at the beginning. This fixes a NULL dereference from accessing an uninitialized dma_vecs when the device dma unmapping requirements change mid-iteration. Fixes: b8b7570a7ec8 ("nvme-pci: fix dma unmapping when using PRPs and not using the IOVA mapping") Link: https://lore.kernel.org/linux-nvme/20260202125738.1194899-1-pradeep.pragallapati@oss.qualcomm.com/ Reported-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
8 daysflow_offload: add const qualifiers to function argumentsDavid Yang
Some functions do not modify the pointed-to data, but lack const qualifiers. Add const qualifiers to the arguments of flow_rule_match_has_control_flags() and flow_cls_offload_flow_rule(). Signed-off-by: David Yang <mmyangfl@gmail.com> Link: https://patch.msgid.link/20260204052839.198602-1-mmyangfl@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
8 daysMerge branch 'dpll-core-improvements-and-ice-e825-c-synce-support'Paolo Abeni
Ivan Vecera says: ==================== dpll: Core improvements and ice E825-C SyncE support This series introduces Synchronous Ethernet (SyncE) support for the Intel E825-C Ethernet controller. Unlike previous generations where DPLL connections were implicitly assumed, the E825-C architecture relies on the platform firmware (ACPI) to describe the physical connections between the Ethernet controller and external DPLLs (such as the ZL3073x). To accommodate this, the series extends the DPLL subsystem to support firmware node (fwnode) associations, asynchronous discovery via notifiers, and dynamic pin management. Additionally, a significant refactor of the DPLL reference counting logic is included to ensure robustness and debuggability. DPLL Core Extensions: * Firmware Node Association: Pins can now be associated with a struct fwnode_handle after allocation via dpll_pin_fwnode_set(). This allows drivers to link pin objects with their corresponding DT/ACPI nodes. * Asynchronous Notifiers: A raw notifier chain is added to the DPLL core. This allows the Ethernet driver to subscribe to events and react when the platform DPLL driver registers the parent pins, resolving probe ordering dependencies. * Dynamic Indexing: Drivers can now request DPLL_PIN_IDX_UNSPEC to have the core automatically allocate a unique pin index. Reference Counting & Debugging: * Refactor: The reference counting logic in the core is consolidated. Internal list management helpers now automatically handle hold/put operations, removing fragile open-coded logic in the registration paths. * Reference Tracking: A new Kconfig option DPLL_REFCNT_TRACKER is added. This allows developers to instrument and debug reference leaks by recording stack traces for every get/put operation. Driver Updates: * zl3073x: Updated to associate pins with fwnode handles using the new setter and support the 'mux' pin type. * ice: Implements the E825-C specific hardware configuration for SyncE (CGU registers). It utilizes the new notifier and fwnode APIs to dynamically discover and attach to the platform DPLLs. Patch Summary: Patch 1: DPLL Core (fwnode association). Patch 2: Driver zl3073x (Set fwnode). Patch 3-4: DPLL Core (Notifiers and dynamic IDs). Patch 5: Driver zl3073x (Mux type). Patch 6: DPLL Core (Refcount refactor). Patch 7-8: Refcount tracking infrastructure and driver updates. Patch 9: Driver ice (E825-C SyncE logic). ==================== Link: https://patch.msgid.link/20260203174002.705176-1-ivecera@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
8 daysice: dpll: Support E825-C SyncE and dynamic pin discoveryArkadiusz Kubalewski
Implement SyncE support for the E825-C Ethernet controller using the DPLL subsystem. Unlike E810, the E825-C architecture relies on platform firmware (ACPI) to describe connections between the NIC's recovered clock outputs and external DPLL inputs. Implement the following mechanisms to support this architecture: 1. Discovery Mechanism: The driver parses the 'dpll-pins' and 'dpll-pin names' firmware properties to identify the external DPLL pins (parents) corresponding to its RCLK outputs ("rclk0", "rclk1"). It uses fwnode_dpll_pin_find() to locate these parent pins in the DPLL core. 2. Asynchronous Registration: Since the platform DPLL driver (e.g. zl3073x) may probe independently of the network driver, utilize the DPLL notifier chain The driver listens for DPLL_PIN_CREATED events to detect when the parent MUX pins become available, then registers its own Recovered Clock (RCLK) pins as children of those parents. 3. Hardware Configuration: Implement the specific register access logic for E825-C CGU (Clock Generation Unit) registers (R10, R11). This includes configuring the bypass MUXes and clock dividers required to drive SyncE signals. 4. Split Initialization: Refactor `ice_dpll_init()` to separate the static initialization path of E810 from the dynamic, firmware-driven path required for E825-C. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Co-developed-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Co-developed-by: Grzegorz Nitka <grzegorz.nitka@intel.com> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com> Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Link: https://patch.msgid.link/20260203174002.705176-10-ivecera@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
8 daysdrivers: Add support for DPLL reference count trackingIvan Vecera
Update existing DPLL drivers to utilize the DPLL reference count tracking infrastructure. Add dpll_tracker fields to the drivers' internal device and pin structures. Pass pointers to these trackers when calling dpll_device_get/put() and dpll_pin_get/put(). This allows developers to inspect the specific references held by this driver via debugfs when CONFIG_DPLL_REFCNT_TRACKER is enabled, aiding in the debugging of resource leaks. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Link: https://patch.msgid.link/20260203174002.705176-9-ivecera@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
8 daysdpll: Add reference count tracking supportIvan Vecera
Add support for the REF_TRACKER infrastructure to the DPLL subsystem. When enabled, this allows developers to track and debug reference counting leaks or imbalances for dpll_device and dpll_pin objects. It records stack traces for every get/put operation and exposes this information via debugfs at: /sys/kernel/debug/ref_tracker/dpll_device_* /sys/kernel/debug/ref_tracker/dpll_pin_* The following API changes are made to support this: 1. dpll_device_get() / dpll_device_put() now accept a 'dpll_tracker *' (which is a typedef to 'struct ref_tracker *' when enabled, or an empty struct otherwise). 2. dpll_pin_get() / dpll_pin_put() and fwnode_dpll_pin_find() similarly accept the tracker argument. 3. Internal registration structures now hold a tracker to associate the reference held by the registration with the specific owner. All existing in-tree drivers (ice, mlx5, ptp_ocp, zl3073x) are updated to pass NULL for the new tracker argument, maintaining current behavior while enabling future debugging capabilities. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Co-developed-by: Petr Oros <poros@redhat.com> Signed-off-by: Petr Oros <poros@redhat.com> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Link: https://patch.msgid.link/20260203174002.705176-8-ivecera@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
8 daysdpll: Enhance and consolidate reference counting logicIvan Vecera
Refactor the reference counting mechanism for DPLL devices and pins to improve consistency and prevent potential lifetime issues. Introduce internal helpers __dpll_{device,pin}_{hold,put}() to centralize reference management. Update the internal XArray reference helpers (dpll_xa_ref_*) to automatically grab a reference to the target object when it is added to a list, and release it when removed. This ensures that objects linked internally (e.g., pins referenced by parent pins) are properly kept alive without relying on the caller to manually manage the count. Consequently, remove the now redundant manual `refcount_inc/dec` calls in dpll_pin_on_pin_{,un}register()`, as ownership is now correctly handled by the dpll_xa_ref_* functions. Additionally, ensure that dpll_device_{,un}register()` takes/releases a reference to the device, ensuring the device object remains valid for the duration of its registration. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Link: https://patch.msgid.link/20260203174002.705176-7-ivecera@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
8 daysdpll: zl3073x: Add support for mux pin typeIvan Vecera
Add parsing for the "mux" string in the 'connection-type' pin property mapping it to DPLL_PIN_TYPE_MUX. Recognizing this type in the driver allows these pins to be taken as parent pins for pin-on-pin pins coming from different modules (e.g. network drivers). Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Link: https://patch.msgid.link/20260203174002.705176-6-ivecera@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
8 daysdpll: Support dynamic pin index allocationIvan Vecera
Allow drivers to register DPLL pins without manually specifying a pin index. Currently, drivers must provide a unique pin index when calling dpll_pin_get(). This works well for hardware-mapped pins but creates friction for drivers handling virtual pins or those without a strict hardware indexing scheme. Introduce DPLL_PIN_IDX_UNSPEC (U32_MAX). When a driver passes this value as the pin index: 1. The core allocates a unique index using an IDA 2. The allocated index is mapped to a range starting above `INT_MAX` This separation ensures that dynamically allocated indices never collide with standard driver-provided hardware indices, which are assumed to be within the `0` to `INT_MAX` range. The index is automatically freed when the pin is released in dpll_pin_put(). Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Link: https://patch.msgid.link/20260203174002.705176-5-ivecera@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
8 daysdpll: Add notifier chain for dpll eventsPetr Oros
Currently, the DPLL subsystem reports events (creation, deletion, changes) to userspace via Netlink. However, there is no mechanism for other kernel components to be notified of these events directly. Add a raw notifier chain to the DPLL core protected by dpll_lock. This allows other kernel subsystems or drivers to register callbacks and receive notifications when DPLL devices or pins are created, deleted, or modified. Define the following: - Registration helpers: {,un}register_dpll_notifier() - Event types: DPLL_DEVICE_CREATED, DPLL_PIN_CREATED, etc. - Context structures: dpll_{device,pin}_notifier_info to pass relevant data to the listeners. The notification chain is invoked alongside the existing Netlink event generation to ensure in-kernel listeners are kept in sync with the subsystem state. Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Co-developed-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: Petr Oros <poros@redhat.com> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Link: https://patch.msgid.link/20260203174002.705176-4-ivecera@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
8 daysdpll: zl3073x: Associate pin with fwnode handleIvan Vecera
Associate the registered DPLL pin with its firmware node by calling dpll_pin_fwnode_set(). This links the created pin object to its corresponding DT/ACPI node in the DPLL core. Consequently, this enables consumer drivers (such as network drivers) to locate and request this specific pin using the fwnode_dpll_pin_find() helper. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Link: https://patch.msgid.link/20260203174002.705176-3-ivecera@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
8 daysdpll: Allow associating dpll pin with a firmware nodeIvan Vecera
Extend the DPLL core to support associating a DPLL pin with a firmware node. This association is required to allow other subsystems (such as network drivers) to locate and request specific DPLL pins defined in the Device Tree or ACPI. * Add a .fwnode field to the struct dpll_pin * Introduce dpll_pin_fwnode_set() helper to allow the provider driver to associate a pin with a fwnode after the pin has been allocated * Introduce fwnode_dpll_pin_find() helper to allow consumers to search for a registered DPLL pin using its associated fwnode handle * Ensure the fwnode reference is properly released in dpll_pin_put() Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Link: https://patch.msgid.link/20260203174002.705176-2-ivecera@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
8 daystracing: Fix ftrace event field alignmentsSteven Rostedt
The fields of ftrace specific events (events used to save ftrace internal events like function traces and trace_printk) are generated similarly to how normal trace event fields are generated. That is, the fields are added to a trace_events_fields array that saves the name, offset, size, alignment and signness of the field. It is used to produce the output in the format file in tracefs so that tooling knows how to parse the binary data of the trace events. The issue is that some of the ftrace event structures are packed. The function graph exit event structures are one of them. The 64 bit calltime and rettime fields end up 4 byte aligned, but the algorithm to show to userspace shows them as 8 byte aligned. The macros that create the ftrace events has one for embedded structure fields. There's two macros for theses fields: __field_desc() and __field_packed() The difference of the latter macro is that it treats the field as packed. Rename that field to __field_desc_packed() and create replace the __field_packed() to be a normal field that is packed and have the calltime and rettime use those. This showed up on 32bit architectures for function graph time fields. It had: ~# cat /sys/kernel/tracing/events/ftrace/funcgraph_exit/format [..] field:unsigned long func; offset:8; size:4; signed:0; field:unsigned int depth; offset:12; size:4; signed:0; field:unsigned int overrun; offset:16; size:4; signed:0; field:unsigned long long calltime; offset:24; size:8; signed:0; field:unsigned long long rettime; offset:32; size:8; signed:0; Notice that overrun is at offset 16 with size 4, where in the structure calltime is at offset 20 (16 + 4), but it shows the offset at 24. That's because it used the alignment of unsigned long long when used as a declaration and not as a member of a structure where it would be aligned by word size (in this case 4). By using the proper structure alignment, the format has it at the correct offset: ~# cat /sys/kernel/tracing/events/ftrace/funcgraph_exit/format [..] field:unsigned long func; offset:8; size:4; signed:0; field:unsigned int depth; offset:12; size:4; signed:0; field:unsigned int overrun; offset:16; size:4; signed:0; field:unsigned long long calltime; offset:20; size:8; signed:0; field:unsigned long long rettime; offset:28; size:8; signed:0; Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Mark Rutland <mark.rutland@arm.com> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reported-by: "jempty.liang" <imntjempty@163.com> Link: https://patch.msgid.link/20260204113628.53faec78@gandalf.local.home Fixes: 04ae87a52074e ("ftrace: Rework event_create_dir()") Closes: https://lore.kernel.org/all/20260130015740.212343-1-imntjempty@163.com/ Closes: https://lore.kernel.org/all/20260202123342.2544795-1-imntjempty@163.com/ Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
8 daysnet/mlx5: Support devlink port state for host PFMoshe Shemesh
Add support for devlink port function state get/set operations for the host physical function (PF). Until now, mlx5 only allowed state get/set for subfunctions (SFs) ports. This change enables an administrator with eSwitch manager privileges to query or modify the host PF’s function state, allowing it to be explicitly inactivated or activated. While inactivated, the administrator can modify the functions attributes, such as enable/disable roce. $ devlink port show pci/0000:03:00.0/196608 pci/0000:03:00.0/196608: type eth netdev eth1 flavour pcipf controller 1 pfnum 0 external true splittable false function: hw_addr a0:88:c2:45:17:7c state active opstate attached roce enable max_io_eqs 120 $ devlink port function set pci/0000:03:00.0/196608 state inactive $ devlink port show pci/0000:03:00.0/196608 pci/0000:03:00.0/196608: type eth netdev eth1 flavour pcipf controller 1 pfnum 0 external true splittable false function: hw_addr a0:88:c2:45:17:7c state inactive opstate detached roce enable max_io_eqs 120 Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260203102402.1712218-1-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
8 daysMerge branch 'acpi-apei'Rafael J. Wysocki
Merge ACPI APEI support updates for 6.20-rc1/7.0-rc1: - Make read-only array non_mmio_desc[] static const (Colin Ian King) - Prevent the APEI GHES support code on ARM from accessing memory out of bounds or going past the ARM processor CPER record buffer (Mauro Carvalho Chehab) - Prevent cper_print_fw_err() from dumping the entire memory on systems with defective firmware (Mauro Carvalho Chehab) - Improve ghes_notify_nmi() status check to avoid unnecessary overhead in the NMI handler by carrying out all of the requisite preparations and the NMI registration time (Tony Luck) - Refactor the GHES driver by extracting common functionality into reusable helper functions to reduce code duplication and improve the ghes_notify_sea() status check in analogy with the previous ghes_notify_nmi() status check improvement (Shuai Xue) - Make ELOG and GHES log and trace consistently and support the CPER CXL protocol analogously (Fabio De Francesco) - Disable KASAN instrumentation in the APEI GHES driver when compile testing with clang < 18 (Nathan Chancellor) - Let ghes_edac be the preferred driver to load on __ZX__ and _BYO_ systems by extending the platform detection list in the APEI GHES driver (Tony W Wang-oc) * acpi-apei: ACPI: APEI: GHES: Add ghes_edac support for __ZX__ and _BYO_ systems ACPI: APEI: GHES: Disable KASAN instrumentation when compile testing with clang < 18 ACPI: extlog: Trace CPER CXL Protocol Error Section ACPI: APEI: GHES: Add helper to copy CPER CXL protocol error info to work struct ACPI: APEI: GHES: Add helper for CPER CXL protocol errors checks ACPI: extlog: Trace CPER PCI Express Error Section ACPI: extlog: Trace CPER Non-standard Section Body ACPI: APEI: GHES: Improve ghes_notify_sea() status check ACPI: APEI: GHES: Extract helper functions for error status handling ACPI: APEI: GHES: Improve ghes_notify_nmi() status check EFI/CPER: don't dump the entire memory region APEI/GHES: ensure that won't go past CPER allocated record EFI/CPER: don't go past the ARM processor CPER record buffer APEI/GHES: ARM processor Error: don't go past allocated memory ACPI: APEI: EINJ: make read-only array non_mmio_desc static const
8 daysMerge branch 'acpi-processor'Rafael J. Wysocki
Merge ACPI processor driver changes for 6.20-rc1/7.0-rc1: - Rework the ACPI idle driver initialization to register it directly from the common initialization code instead of doing that from a CPU hotplug "online" callback and clean it up (Huisong Li, Rafael Wysocki) - Fix a possible NULL pointer dereference in acpi_processor_errata_piix4() (Tuo Li) * acpi-processor: ACPI: processor: idle: Rework the handling of acpi_processor_ffh_lpi_probe() ACPI: processor: idle: Convert acpi_processor_setup_cpuidle_dev() to void ACPI: processor: idle: Convert acpi_processor_setup_cpuidle_states() to void ACPI: processor: idle: Add debug log for states with invalid entry methods ACPI: processor: Fix NULL-pointer dereference in acpi_processor_errata_piix4() ACPI: processor: Do not expose global variable acpi_idle_driver ACPI: processor: idle: Rearrange declarations in header file ACPI: processor: idle: Redefine two functions as void ACPI: processor: Update cpuidle driver check in __acpi_processor_start() ACPI: processor: Remove unused empty stubs of some functions ACPI: processor: idle: Optimize ACPI idle driver registration
8 daysMerge branches 'acpi-battery' and 'acpi-misc'Rafael J. Wysocki
Merge ACPI battery driver changes and a generic ACPI watchdog device driver change for 6.20-rc1/7.0-rc1: - Convert the generic ACPI battery driver to a proper platform driver using struct platform_driver for device binding (Rafael Wysocki) - Fix incorrect charging status when current is zero in the generic ACPI battery driver (Ata İlhan Köktürk) - Use LIST_HEAD() for initializing a stack-allocated list in the generic ACPI watchdog device driver (Can Peng) * acpi-battery: ACPI: battery: fix incorrect charging status when current is zero ACPI: battery: Convert the driver to a platform one ACPI: battery: Reduce code duplication related to cleanup ACPI: battery: Adjust event notification routine * acpi-misc: ACPI: acpi_watchdog: use LIST_HEAD for stack-allocated list
generated by cgit v1.2.3 (git 2.0.4) at 2026-02-13 13:39:08 +0000