summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-07-21sctp: close UDP tunnel sockets during netns teardownZhiling Zou
proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed. Fixes: 046c052b475e ("sctp: enable udp tunneling socks") Cc: stable@vger.kernel.org Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/b9f1f02b0780ad6a719e2413f5f0bb8eb7702d94.1782585631.git.roxy520tt%40gmail.com Signed-off-by: Zhiling Zou <roxy520tt@gmail.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Acked-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/6dab75f22855cb219e2e30a5497cab03b970ab91.1784033357.git.roxy520tt@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21sctp: avoid auth_enable sysctl UAF during netns teardownZhiling Zou
proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper. Fixes: 15649fd5415e ("sctp: sysctl: auth_enable: avoid using current->nsproxy") Cc: stable@vger.kernel.org Reported-by: Yuan Tan <yuantan098@gmail.com> Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Reported-by: Xin Liu <bird@lzu.edu.cn> Co-developed-by: Qi Tang <tpluszz77@gmail.com> Signed-off-by: Qi Tang <tpluszz77@gmail.com> Signed-off-by: Zhiling Zou <roxy520tt@gmail.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Acked-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/390cd5e91ed60eea27b0b64d0468301a9e73b808.1784033357.git.roxy520tt@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21ACPI: bus: Use correct struct member namesRandy Dunlap
Avoid kernel-doc warnings by using the correct struct member names: Warning: ./include/acpi/acpi_bus.h:429 struct member 'crs_csi2_local' not described in 'acpi_device_software_node_port' Warning: ./include/acpi/acpi_bus.h:429 Excess struct member 'crs_crs2_local' description in 'acpi_device_software_node_port' Warning: ./include/acpi/acpi_bus.h:445 struct member 'nodeptrs' not described in 'acpi_device_software_nodes' Warning: ./include/acpi/acpi_bus.h:445 Excess struct member 'nodeprts' description in 'acpi_device_software_nodes' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260720032341.3087008-2-rdunlap@infradead.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-21ACPI: fan: Use correct function parameter name in kernel-docRandy Dunlap
Fix kernel-doc warnings by using the correct function parameter name: Warning: ./drivers/acpi/fan.h:83 function parameter 'speed' not described in 'acpi_fan_speed_valid' Warning: ./drivers/acpi/fan.h:83 Excess function parameter 'speeed' description in 'acpi_fan_speed_valid' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260720032341.3087008-1-rdunlap@infradead.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-21sctp: validate stream count in sctp_process_strreset_inreq()Cen Zhang (Microsoft)
When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer. Fixes: 7f9d68ac944e ("sctp: implement sender-side procedures for SSN Reset Request Parameter") Reported-by: AutonomousCodeSecurity@microsoft.com Closes: https://lore.kernel.org/all/20260707203215.2752-1-blbllhy@gmail.com/ Suggested-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: Cen Zhang (Microsoft) <blbllhy@gmail.com> Acked-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/20260710010718.20318-1-blbllhy@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21MAINTAINERS: BPF: Add self as reviewerIhor Solodrai
Add myself as a reviewer for the BPF areas where I've been active. Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/20260721172104.3689982-1-ihor.solodrai@linux.dev Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-21net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()Hidayath Khan
afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated. Fixes: 3881ac441f64 ("af_iucv: add HiperSockets transport") Cc: stable@vger.kernel.org Reviewed-by: Alexandra Winter <wintera@linux.ibm.com> Signed-off-by: Hidayath Khan <hidayath@linux.ibm.com> Link: https://patch.msgid.link/20260709191732.124092-1-hidayath@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21power: supply: cw2015_battery: add missing MODULE_DEVICE_TABLE()Pengpeng Hou
The driver has a match table for the i2c bus wired into its driver structure, but the table is not exported with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE() entry so module alias information is generated for automatic module loading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the driver registration structure, and the missing module alias publication. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Link: https://patch.msgid.link/20260704152428.51844-1-pengpeng@iscas.ac.cn Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-21power: reset: piix4-poweroff: add missing MODULE_DEVICE_TABLE()Pengpeng Hou
The driver has a match table for the pci bus wired into its driver structure, but the table is not exported with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE() entry so module alias information is generated for automatic module loading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the driver registration structure, and the missing module alias publication. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Link: https://patch.msgid.link/20260704152336.51384-1-pengpeng@iscas.ac.cn Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-21power: supply: bq256xx: drop always-true inner conditionAnas Khan
In bq256xx_array_parse() the inner "if (val < array[i])" repeats the second half of the enclosing "if (val > array[i - 1] && val < array[i])", so it is always true and the "else return i" arm is dead code. The function performs a round-down table lookup, so returning i - 1 for a value that falls strictly between two entries is the intended result. Collapse the redundant branch into a single "return i - 1;"; no functional change. Signed-off-by: Anas Khan <anxkhn28@gmail.com> Link: https://patch.msgid.link/20260702194547.65209-1-anxkhn28@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-21dt-bindings: power: reset: qcom,pon: Narrow allowed reboot modesKrzysztof Kozlowski
reboot-mode schema allows arbitrary "mode-.* properties but only a subset actually makes sense and is valid. Provide negative look-ahead pattern to disallow any modes not supported by the device, which tightens the binding. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260701105907.197150-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-21power: supply: leds: create triggers based on properties, not typeSteffen Dirkwinkel
Currently only battery power supplies get triggers for other properties and other supplies only get the online trigger. This changes it to provide the triggers for any power supply depending on what properties are available. Batteries will still get the same triggers if the properties are there, but now other power supplies can get the triggers too. Signed-off-by: Steffen Dirkwinkel <s.dirkwinkel@beckhoff.com> Link: https://patch.msgid.link/20260625-std-power-supply-triggers-v1-1-d80db570d329@beckhoff.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-21power: supply: sbs-battery: Add PbAc, NiZn, RAM, and ZnAr supportBoris Shtrasman
Add support for PbAc, NiZn, RAM, and ZnAr chemistries as defined in the Smart Battery Data Specification v1.1 (Section 5.1.30 DeviceChemistry). Currently, the sbs-battery driver only handles LION, LiP, NiCd and NiMH. The Smart Battery specification defines 8 possible values: - Lead Acid (PbAc) - Lithium Ion (LION) - Nickel Cadmium (NiCd) - Nickel Metal Hydride (NiMH) - Nickel Zinc (NiZn) - Rechargeable Alkaline-Manganese (RAM) - Zinc Air (ZnAr) - Lithium Polymer (LiP) Link: https://sbs-forum.org/specs/sbdat110.pdf Signed-off-by: Boris Shtrasman <borissh1983@gmail.com> Link: https://patch.msgid.link/20260624135718.286771-3-borissh1983@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-21power: supply: Add PbAc, NiZn, RAM, and ZnAr supportBoris Shtrasman
Add four new members to the POWER_SUPPLY_TECHNOLOGY enum and sysfs interface to represent the Smart Battery Data Specification v1.1 (Section 5.1.30 DeviceChemistry) battery types: - Lead Acid (PbAc) - Nickel Zinc (NiZn) - Rechargeable Alkaline-Manganese (RAM) - Zinc Air (ZnAr) Update documentation to express these types. Update ABI testing for these types. Link: https://sbs-forum.org/specs/sbdat110.pdf Signed-off-by: Boris Shtrasman <borissh1983@gmail.com> Link: https://patch.msgid.link/20260624135718.286771-2-borissh1983@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-21selftests: helpers: handle multi line in test_sysfs_prop_optional_listBoris Shtrasman
Modify test_sysfs_prop_optional_list to allow multi line parameters, in order to comply with checkpatch output that limit line by 100 chars. Allow use cases like: test_sysfs_prop_optional_list \ property_name "value1","value2","val3","very_long_option"\ ,"extra_long_option" \ ,"even_more_data" Signed-off-by: Boris Shtrasman <borissh1983@gmail.com> Link: https://patch.msgid.link/20260625160556.54830-2-borissh1983@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-21power: reset: add MCF5441x RCM power-on reason driverJean-Michel Hautbois
Add a driver that decodes the Reset Status Register (RSR) of the Freescale ColdFire MCF5441x Reset Controller Module at probe time and exposes the cause via the power_on_reason sysfs ABI. The RSR can latch several cause bits simultaneously (Reference Manual chapter 12.3.2); the driver picks one cause per a priority that favours the most explanatory diagnostic. The register layout is described in the driver so it can be built with COMPILE_TEST on any architecture. Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org> Link: https://patch.msgid.link/20260617-coldfire-rcm-power-on-reason-v3-1-1a7c7b6b14e7@yoseli.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-21power: supply: cros_usbpd-charger: bound the EC-reported port countBryam Vargas
cros_usbpd_charger_probe() reads two port counts from the EC and uses one of them, num_charger_ports, as the loop bound when populating a fixed-size array: struct port_data *ports[EC_USB_PD_MAX_PORTS]; /* 8 entries */ ... for (i = 0; i < charger->num_charger_ports; i++) charger->ports[charger->num_registered_psy++] = port; Both num_usbpd_ports (from EC_CMD_USB_PD_PORTS) and num_charger_ports (from EC_CMD_CHARGE_PORT_COUNT) are u8 values reported by the EC. The only validation is a sanity check that compares the two EC-reported values against each other: if (num_charger_ports < num_usbpd_ports || num_charger_ports > num_usbpd_ports + 1) return -EPROTO; It never checks either count against EC_USB_PD_MAX_PORTS, the size of the ports[] array. A malfunctioning, malicious or compromised EC that reports num_usbpd_ports == num_charger_ports == N for any N > 8 (for example both 255) passes this check, and the loop then writes N pointers into the 8-entry ports[] array embedded in the devm_kzalloc()'d charger_data, overflowing it by up to 255 - 8 = 247 entries (~1976 bytes): a slab out-of-bounds write. Reject a port count larger than the ports[] array can hold. Fixes: f68b883e8fad ("power: supply: add cros-ec USBPD charger driver.") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://patch.msgid.link/20260616-b4-disp-5e197080-v2-1-8aa5bffce945@proton.me Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-21power: supply: cros_pchg: unregister EC notifierPengpeng Hou
cros_pchg_probe() registers an EC event notifier whose callback uses the devm-allocated charger_data via container_of(). The driver has no remove callback and does not unregister the notifier, so the notifier chain can retain a pointer to freed driver state after unbind or probe cleanup. Register a devm cleanup action immediately after the notifier is installed so the notifier is unregistered before the driver state is released. Also fail probe if the notifier cannot be registered, instead of leaving a charger device that cannot receive EC events. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://patch.msgid.link/20260615063105.39152-1-pengpeng@iscas.ac.cn Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-21power: reset: syscon-reboot: Read "priority" as unsignedRob Herring (Arm)
The restart-handler binding documents "priority" as a uint32 value in the range 0 to 255. The syscon reboot driver stored it in an int and used the signed DT helper, which makes the helper type disagree with the schema. Read "priority" as u32 so the driver follows the binding while preserving the same default value. Assisted-by: Codex:gpt-5-5 Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260612215325.1889302-1-robh@kernel.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-21power: supply: Match DT value typesRob Herring (Arm)
The battery drivers read properties whose bindings use signed values for temperature thresholds and unsigned values for voltage thresholds. Some helpers used the opposite signedness, which makes property type checking report real mismatches. Use signed helpers where the binding and DTS allow negative values, and use unsigned helpers for voltage properties documented as uint32 cells. Assisted-by: Codex:gpt-5-5 Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260612215308.1888834-1-robh@kernel.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-21dt-bindings: net: microchip,lan78xx: convert to DT schemaMikhail Lukianchikov
Convert the Microchip LAN78xx family (LAN7800, LAN7801, LAN7850) binding documentation from plain text to DT schema. Restoring a mistakenly deleted email in MAINTAINERS file and fixing microchip,lan7800.yaml. Signed-off-by: Mikhail Lukianchikov <avermoal@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260712113821.12543-1-avermoal@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21accel: ethosu: Handle U85 internal chaining bufferRob Herring (Arm)
The Ethos-U85 supports an internal chaining buffer as temporary storage between some operations. When chaining is activated, the IFM/OFM region setting selects a chaining buffer rather than a region, and the IFM/OFM base addresses don't matter. In this case, the feature matrix size calculations should be skipped. Otherwise, the command stream will be intermittently rejected depending on prior feature matrix base addresses. Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver") Acked-by: Tomeu Vizoso <tomeu@tomeuvizoso.net> Link: https://patch.msgid.link/20260720231450.485221-2-robh@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-07-21accel: ethosu: Fix element size accounting for cmd stream validationRob Herring (Arm)
There are 2 issues with the element size handling in the command stream validation which result in too small of a size calculated when the element size is 16/32/64 bits. For NHWC format, the element size is simply missing from the calculation. The bitfield for the element size is different between IFM/IFM2 and OFM. IFM and IFM2 encode the precision in parameter bits 2:3, while OFM uses bits 1:2. Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver") Acked-by: Tomeu Vizoso <tomeu@tomeuvizoso.net> Link: https://patch.msgid.link/20260720231450.485221-1-robh@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-07-21smb: client: handle STATUS_STOPPED_ON_SYMLINK responses without a symlink targetCarl Johnson
The macOS built-in SMB server returns STATUS_STOPPED_ON_SYMLINK for a CREATE on a path whose final component is a symlink, but it does not include a Symbolic Link Error Response in the error data: both ErrorContextCount and ByteCount are zero, so the symlink target is not present in the response at all. Per [MS-SMB2] section 2.2.2 such a response should carry a valid Symbolic Link Error Response, so this is a server bug, but the target can still be retrieved with FSCTL_GET_REPARSE_POINT. Frame from a capture against macOS 26.5.2 (build 25F84): SMB2 hdr : Status=0x8000002d STATUS_STOPPED_ON_SYMLINK, Cmd=Create Error Rsp: StructureSize=0x0009 Error Context Count: 0 Byte Count: 0 Error Data: 00 symlink_data() cannot find a struct smb2_symlink_err_rsp in such a response and returns -EINVAL, which parse_create_response() propagates, so smb2_query_path_info() bails out at if (rc || !data->reparse_point) goto out; before it can retry with SMB2_OP_GET_REPARSE. stat(), readlink() and ls of any server-side symlink then fail with -EINVAL: $ ls -la Config l????????? ? ? ? ? ? Config.json $ stat Config/Config.json stat: cannot statx 'Config/Config.json': Invalid argument A 5.10 client resolves these symlinks correctly against the same server and share, so this is a regression for Apple SMB servers. Handle it in several places: - symlink_data() detects the empty response (ErrorContextCount and ByteCount both zero) and returns a distinct -ENODATA, so that "server did not send the target" can be told apart from a genuinely malformed response and only this case is worked around. - parse_create_response() treats -ENODATA like STATUS_IO_REPARSE_TAG_NOT_HANDLED, which does not carry the target either: leave the reparse tag unset and clear rc, so the existing SMB2_OP_GET_REPARSE path retrieves the target. - smb2_query_path_info() only fixes up the symlink target type when the target is already known. SMB2_OP_GET_REPARSE sets data->reparse.tag but does not parse the target out of the reparse buffer; that happens later, in reparse_info_to_fattr(). Without this check smb2_fix_symlink_target_type() is called with a NULL target and returns -EIO. This could not happen with servers that send the target inline and therefore skip SMB2_OP_GET_REPARSE. - smb2_open_file() maps -ENODATA to -EIO, matching STATUS_IO_REPARSE_TAG_NOT_HANDLED, so its callers retrieve the target with SMB2_OP_GET_REPARSE as well. Tested on Debian 13, kernel 6.18.38 (armv7), against macOS 26.5.2: symlinks now resolve, including relative, parent-traversing and directory symlinks, and reads through symlinks succeed. Cc: stable@vger.kernel.org Co-developed-by: Pali Rohár <pali@kernel.org> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Carl Johnson <carl@jpartners.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2026-07-21ACPI: battery: Use kstrtoul() over sscanf("%lu\n")Rong Zhang
It is more preferred to use kstrto*() to parse a single number. The function family properly returns an errno on error and is the correct mechanism to parse data from sysfs. The number base is set to 10 in order not to break the ABI. Tested-by: Avraham Hollander <anhollander516@gmail.com> Signed-off-by: Rong Zhang <i@rong.moe> Link: https://patch.msgid.link/20260718-b4-acpi-battery-notification-v4-2-599c8ed1072f@rong.moe Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-21ACPI: battery: Merge consecutive battery notificationsRong Zhang
It's a very common pattern to emit consecutive battery notifications, for example: Method (_Qxx, 0, NotSerialized) { Notify (BAT0, 0x80) // Status Change Notify (BAT0, 0x81) // Information Change } In this case, the current code path will update battery state twice within a short period, which is not optimal, as the same data are fetched twice. Moreover, both notifications are likely to call power_supply_changed(), causing power_supply_uevent() to read all battery properties in order to assemble uevents. Even worse, after the first uevent reaches userspace, some userspace processes start to read all battery properties in order to refresh their internal states, which competes with the second notification's handling and uevent assembling. This generates significant pressure on _STA, _BST and _BIX/_BIF methods. Not only that, power_supply_ext properties may also rely on some other ACPI methods, so both uevent assembling and userspace processes call them. It becomes a nightmare when all these methods share the same ACPI mutex protecting EC accesses and hence vulnerable to lock starvation. This is exactly the case of some Lenovo devices, where the mentioned EC query pattern eventually leads to a catastrophic situation that a bunch of ACPI methods (including but not limited to the mentioned ones) fail to acquire the same mutex due to timeout. These devices don't handle mutex acquisition failure gracefully and return garbage data, causing even more chaos. Improve battery notification handling by merging at most 16 consecutive battery notifications within 10ms using a delayed work, so that they only refresh and/or update battery state once. ACPI netlink event and notifier call chain are still triggered multiple times in order not to break other components. Finally, call power_supply_changed() once and lead to a single uevent instead of a bunch, preventing userspace programs from causing too much pressure on power supply properties and underlying ACPI methods. If more than 16 battery notifications are queued within 10ms, the firmware/hardware is anyway buggy, and extra notifications will be dropped. Tested-by: Jeffrey Wälti <jeffrey@waelti.dev> Tested-by: Avraham Hollander <anhollander516@gmail.com> Reported-by: Rick <rickk1166@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221065 Signed-off-by: Rong Zhang <i@rong.moe> Link: https://patch.msgid.link/20260718-b4-acpi-battery-notification-v4-1-599c8ed1072f@rong.moe Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-21Merge patch series "Fix for unintended FUSE ACL cache"Christian Brauner
Amir Goldstein <amir73il@gmail.com> says: Fix for unintended FUSE ACL cache. Christian, I bet you did not miss fuse acls... Ghosts from the past have come back to haunt me now. * patches from https://patch.msgid.link/20260713220932.413004-1-amir73il@gmail.com: selftests/fuse: add ACL_DONT_CACHE regression test fs: preserve ACL_DONT_CACHE state in forget_cached_acl() Link: https://patch.msgid.link/20260713220932.413004-1-amir73il@gmail.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-21selftests/fuse: add ACL_DONT_CACHE regression testAmir Goldstein
Add a test that reproduces the stale ACL bug fixed by: "fs: preserve ACL_DONT_CACHE state in forget_cached_acl()" A FUSE mount that does not negotiate FUSE_POSIX_ACL initialises inodes with i_acl = ACL_DONT_CACHE. Before the fix, calling forget_all_cached_acls() (e.g. from fuse_update_get_attr() on a statx(AT_STATX_FORCE_SYNC)) would silently replace ACL_DONT_CACHE with ACL_NOT_CACHED, enabling the kernel ACL cache. A subsequent getxattr would populate the cache, and because fuse_set_acl() skips forget_all_cached_acls() for !fc->posix_acl, later ACL changes were not visible to callers — getxattr returned stale data. The test mounts a minimal libfuse3 lowlevel filesystem (no FUSE_POSIX_ACL negotiated) and: 1. Issues two getxattrs — both must reach the daemon, proving ACL_DONT_CACHE suppresses caching before any trigger. 2. Calls statx(AT_STATX_FORCE_SYNC) to trigger forget_all_cached_acls(). 3. Issues another getxattr (populates the cache on a buggy kernel). 4. Switches the daemon to a different-sized ACL (ACL_B). 5. Issues a final getxattr — expects ACL_B (44 bytes) and daemon call count 4; a buggy kernel returns stale ACL_A (28 bytes). fuse_acl_cache_test is only built when libfuse3 is detected via pkg-config. Christian Brauner <brauner@kernel.org> says: Changed do_force_statx() to call the statx() libc wrapper instead of syscall(SYS_statx, ...) as requested by Amir after review feedback from Luis Henriques, and dropped the now unused <sys/syscall.h> include. Signed-off-by: Amir Goldstein <amir73il@gmail.com> Link: https://patch.msgid.link/20260713220932.413004-3-amir73il@gmail.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-21fs: preserve ACL_DONT_CACHE state in forget_cached_acl()Amir Goldstein
The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 ("fuse: fixes after adapting to new posix acl api") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE. Fixes: facd61053cff1 ("fuse: fixes after adapting to new posix acl api") Cc: stable@vger.kernel.org Signed-off-by: Amir Goldstein <amir73il@gmail.com> Link: https://patch.msgid.link/20260713220932.413004-2-amir73il@gmail.com Reviewed-by: Luis Henriques <luis@igalia.com> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-21pds_core: check for workqueue allocation failureNikhil P. Rao
pdsc_init_pf() does not check whether create_singlethread_workqueue() succeeded. Fail probe on failure. The workqueue is set up before the timer and mutexes, so its failure path must unwind only the earlier setup. Fixes: c2dbb0904310 ("pds_core: health timer and workqueue") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260629200358.2626129-1-nikhil.rao%40amd.com?part=2 Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com> Reviewed-by: Brett Creeley <brett.creeley@amd.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Link: https://patch.msgid.link/20260714212713.1788438-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21pds_core: fix auxiliary device add/del racesNikhil P. Rao
Two paths add or delete the same slot (pf->vfs[vf_id].padev): a VF's pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler. They serialize on config_lock, but neither guards the slot under it correctly. add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside config_lock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer. Check and update the slot under config_lock in both paths. Fixes: b699bdc720c0 ("pds_core: specify auxiliary_device to be created") Reported-by: sashiko-bot@kernel.org # Running on a local machine Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com> Reviewed-by: Brett Creeley <brett.creeley@amd.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Link: https://patch.msgid.link/20260714210745.1785625-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21pds_core: order completion reads after the ownership checkNikhil P. Rao
pdsc_process_adminq() and pdsc_process_notifyq() decide a completion is valid from its ownership field - the color bit for the adminq, the event id for the notifyq - then read the rest of the descriptor, with no barrier in between. On a weakly ordered architecture the CPU may read the payload first. Add dma_rmb() between the ownership read and the payload reads. Fixes: 7e82a8745b95 ("pds_core: Prevent race issues involving the adminq") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260629200358.2626129-1-nikhil.rao%40amd.com?part=2 Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com> Reviewed-by: Eric Joyner <eric.joyner@amd.com> Link: https://patch.msgid.link/20260714204145.1782390-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21pds_core: yield the CPU while waiting for the adminq to drainNikhil P. Rao
pdsc_adminq_wait_and_dec_once_unused() busy-waits for adminq_refcnt to drop to one: while (!refcount_dec_if_one(&pdsc->adminq_refcnt)) cpu_relax(); The refcount is held by pdsc_adminq_post() for the duration of an in-flight command, which can wait up to devcmd_timeout seconds (PDS_CORE_DEVCMD_TIMEOUT is 5) for the hardware to complete. cpu_relax() is not a reschedule point, so on a non-preemptible kernel this loop can spin on the CPU for several seconds, starving other tasks on that core. Add cond_resched() to the loop so the waiter yields to other runnable tasks while it polls, keeping cpu_relax() as the busy-wait hint between checks. Fixes: 7e82a8745b95 ("pds_core: Prevent race issues involving the adminq") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260629200358.2626129-1-nikhil.rao%40amd.com?part=2 Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com> Reviewed-by: Eric Joyner <eric.joyner@amd.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Link: https://patch.msgid.link/20260714201456.1776153-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21Merge branch 'pds_core-fix-use-after-free-on-workqueue-during-remove'Jakub Kicinski
Nikhil P. Rao says: ==================== pds_core: fix use-after-free on workqueue during remove This series fixes a use-after-free on the workqueue during driver remove. Patch 1 fixes a pre-existing deadlock between the PCI reset worker and pdsc_remove() that was identified during review of v1. Patch 2 is the reworked UAF fix that moves destroy_workqueue() after pdsc_teardown() and adds proper work synchronization. ==================== Link: https://patch.msgid.link/20260714180223.1642792-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21pds_core: fix use-after-free on workqueue during removeNikhil P. Rao
In pdsc_remove(), the workqueue is destroyed before pdsc_teardown() is called. This ordering allows two paths to queue work on the destroyed workqueue: 1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error path in pdsc_devcmd_locked() queues health_work. 2. A NotifyQ event can trigger the ISR and queue work before free_irq() is called in pdsc_teardown(). Fix by moving destroy_workqueue() after pdsc_teardown() so the workqueue outlives every queuer; destroy_workqueue() then flushes any work still pending. Draining the queued work also requires ordering the teardown so the resources that work touches are freed last: - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync() the queue's work and only then clear qcq->intx, so pdsc_process_adminq()'s read of qcq->intx for interrupt-credit return cannot race with the clear. - Free adminqcq before notifyqcq: the shared adminq ISR is released when adminqcq is freed, and the adminq work accesses notifyqcq, so both must be stopped before notifyqcq is freed. Fixes: 01ba61b55b20 ("pds_core: Add adminq processing and commands") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Closes: https://patchwork.kernel.org/comment/27002369/ Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com> Link: https://patch.msgid.link/20260714180223.1642792-3-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21pds_core: fix deadlock between reset thread and removeNikhil P. Rao
pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence. Fixes: 81665adf25d2 ("pds_core: Fix pdsc_check_pci_health function to use work thread") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Closes: https://patchwork.kernel.org/comment/27002369/ Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Link: https://patch.msgid.link/20260714180223.1642792-2-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21mailmap: fix wrong canonical name for mgr@kernel.orgMichael Grzeschik
After picking up some pending patches for the kernel to work on, I realized my name in the mailmap file somehow got mixed up. When switching to my kernel.org Address some time ago, I had never the intention to use a scrambled variant of Polish and German used for my first name to be found in this file. However, so here we are. Lets fix it for good. Signed-off-by: Michael Grzeschik <mgr@kernel.org> Link: https://patch.msgid.link/20260713-mailmap-v1-1-cb40979cb190@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkidHanQuan
sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity. Fixes: 1f485649f529 ("[SCTP]: Implement SCTP-AUTH internals") Signed-off-by: HanQuan <eilaimemedsnaimel@gmail.com> Acked-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/20260713032021.3491702-1-zhoujian.zja@antgroup.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21ACPI: NHLT: Remove always included kconfig.hAndy Shevchenko
The inclusion of <linux/kconfig.h> is unneeded as it's guaranteed by the build starting from the commit 2a11c8ea20bf ("kconfig: Introduce IS_ENABLED(), IS_BUILTIN() and IS_MODULE()"). Remove it here. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260717171635.1783543-1-andriy.shevchenko@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-21Merge branch 'align-ipv4-teardown-with-ipv6-and-fix-driver-regressions'Jakub Kicinski
Yuyang Huang says: ==================== align IPv4 teardown with IPv6 and fix driver regressions This series aligns the IPv4 address teardown sequence with IPv6 by clearing dev->ip_ptr early in inetdev_destroy() before freeing the multicast list and individual IP addresses. This prevents RCU readers from accessing a partially destroyed in_device structure. However, clearing dev->ip_ptr early causes __in_dev_get_rtnl() to return NULL during the notifier loop in inetdev_destroy(). This causes regressions in some drivers (prestera and mac80211) that use this lookup helper in their inetaddr notifier callbacks. To prevent regressions and maintain bisectability, this series first fixes the affected drivers (Patch 1 and 2) before applying the core IPv4 change (Patch 3). An audit was performed on all other registered inetaddr and inet6addr notifier listeners, and no other drivers were found to be affected. ==================== Link: https://patch.msgid.link/20260711005405.2861680-1-yuyanghuang@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net: ipv4: clear dev->ip_ptr before destroying inetdevYuyang Huang
To prevent RCU readers from accessing a partially destroyed in_device, clear dev->ip_ptr early in inetdev_destroy() before freeing the multicast list and individual IP addresses. This aligns the IPv4 teardown sequence with the IPv6 implementation. Cc: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Yuyang Huang <yuyanghuang@google.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260711005405.2861680-4-yuyanghuang@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21wifi: mac80211: use ifa_dev from event argumentYuyang Huang
During address teardown, the netdevice's ip_ptr might be cleared before the inetaddr notifier is called. In this case, __in_dev_get_rtnl() returns NULL, causing the notifier to abort early and fail to update the ARP filter. Fix this by using the in_device pointer from the event argument (ifa->ifa_dev) which is guaranteed to be valid. Cc: Ido Schimmel <idosch@nvidia.com> Cc: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Yuyang Huang <yuyanghuang@google.com> Link: https://patch.msgid.link/20260711005405.2861680-3-yuyanghuang@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net: prestera: ignore duplicate RIF destruction eventsYuyang Huang
During address teardown, the inetaddr notifier may be called multiple times for the same interface. Ignore NETDEV_DOWN events if the RIF has already been destroyed, rather than returning -EEXIST, which aborts the notifier chain. Cc: Ido Schimmel <idosch@nvidia.com> Cc: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Yuyang Huang <yuyanghuang@google.com> Link: https://patch.msgid.link/20260711005405.2861680-2-yuyanghuang@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net: txgbe: fix FDIR filter leak on removeChenguang Zhao
Perfect FDIR filters can be added while the interface is down and are kept on the software list for later restore. unregister_netdev() only calls ndo_stop when the device is up, so txgbe_fdir_filter_exit() in txgbe_close() is skipped in that case and the filters are leaked on driver remove. Free the filter list from txgbe_remove() as well. Fixes: 4bdb441105dc ("net: txgbe: support Flow Director perfect filters") Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260713091911.1614795-1-chenguang.zhao@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21ACPI: fan: Update ACPI fan IDs to follow modern styleAndy Shevchenko
Follow modern style of defining ACPI IDs by using C99 initialisers. This is a missing part to bigger rework that's ongoing in the kernel. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260717170951.1782863-3-andriy.shevchenko@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-21ACPI: fan: Don't use "proxy" headersAndy Shevchenko
Update header inclusions to follow IWYU (Include What You Use) principle. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260717170951.1782863-2-andriy.shevchenko@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-21Merge branch 'riscv-bpf-add-support-for-signed-operations-and-32-bit-atomics'Kumar Kartikeya Dwivedi
Kuan-Wei Chiu says: ==================== riscv, bpf: Add support for signed operations and 32-bit atomics Add support for missing signed operations and 32-bit atomics in the RV32 BPF JIT compiler. The current implementation lacks support for BPF_SDIV, BPF_SMOD, and BPF_MOVSX, ignoring the instruction offset field and treating them as unsigned or zero-extended. Introduce support for these operations by checking the offset field and emitting the corresponding instructions. Additionally, we leverage the mandatory A extension to natively support 32-bit BPF atomics (and, or, xor, xchg) by mapping them directly to amo*.w instructions. BPF_CMPXCHG continues to fall back to the interpreter. As a result, test_bpf.ko now runs with 0 failures, and the total number of successfully JIT'ed test cases increases from 843 to 902. Tested-by: Pu Lehui <pulehui@huawei.com> --- Changes in v4: - Add a 'dst' param to emit_bpf_atomic(). Changes in v3: - Pass insn directly to emit_alu_r32(). - Remove the Fixes: tag and update title. - Consolidate size, mode, and off into insn for emit_store_r64(). Changes in v2: - Add missing Fixes tags. - Fix memory ordering by emitting aq=1, rl=1 Kuan-Wei Chiu (3): riscv, bpf: Add support for BPF_SDIV and BPF_SMOD in RV32 JIT riscv, bpf: Add support for BPF_MOVSX in RV32 JIT riscv, bpf: Add 32 bit atomic operations to RV32 JIT arch/riscv/net/bpf_jit_comp32.c | 111 +++++++++++++++++++++++++++----- 1 file changed, 95 insertions(+), 16 deletions(-) ==================== Link: https://patch.msgid.link/20260714002451.4091139-1-visitorckw@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-21riscv, bpf: Add 32 bit atomic operations to RV32 JITKuan-Wei Chiu
The RV32 BPF JIT compiler currently only supports the BPF_ADD atomic operation. Other 32 bit atomic operations (and, or, xor, xchg) and their BPF_FETCH variants are not supported and gracefully fall back to the interpreter. Since the RISC-V A extension is required for Linux on RV32, we can natively support these 32-bit BPF atomic operations by mapping them directly to the corresponding RISC-V amo*.w instructions. Implement BPF_ADD, BPF_AND, BPF_OR, BPF_XOR, and BPF_XCHG with and without BPF_FETCH. BPF_CMPXCHG requires a more complex lr.w/sc.w loop and is left to fall back to the interpreter. Before this patch: [ 138.862161] test_bpf: Summary: 1054 PASSED, 0 FAILED, [843/1042 JIT'ed] After this patch: [ 157.024124] test_bpf: Summary: 1054 PASSED, 0 FAILED, [902/1042 JIT'ed] Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com> Reviewed-by: Pu Lehui <pulehui@huawei.com> Link: https://lore.kernel.org/bpf/20260714002451.4091139-4-visitorckw@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-21riscv, bpf: Add support for BPF_MOVSX in RV32 JITKuan-Wei Chiu
The current rv32 bpf jit compiler incorrectly treats BPF_MOVSX as a standard zero-extended move operation. The bpf instruction set allows sign-extension moves by reusing the BPF_MOV opcode with the instruction offset set to 8, 16, or 32. Update the bpf_jit_emit_insn() function to check the offset field for both ALU and ALU64 MOV operations. If the offset is non-zero, emit the correct slli and srai instructions to perform the sign extension. Before this patch: [ 19.549705] test_bpf: #82 ALU_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) [ 19.551354] test_bpf: #83 ALU_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) [ 19.552576] test_bpf: #84 ALU64_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) [ 19.553542] test_bpf: #85 ALU64_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) [ 19.554807] test_bpf: #86 ALU64_MOVSX | BPF_W jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) After this patch: [ 17.931172] test_bpf: #82 ALU_MOVSX | BPF_B jited:1 125 PASS [ 17.932198] test_bpf: #83 ALU_MOVSX | BPF_H jited:1 124 PASS [ 17.933039] test_bpf: #84 ALU64_MOVSX | BPF_B jited:1 124 PASS [ 17.933918] test_bpf: #85 ALU64_MOVSX | BPF_H jited:1 124 PASS [ 17.934751] test_bpf: #86 ALU64_MOVSX | BPF_W jited:1 122 PASS Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com> Reviewed-by: Pu Lehui <pulehui@huawei.com> Link: https://lore.kernel.org/bpf/20260714002451.4091139-3-visitorckw@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-21riscv, bpf: Add support for BPF_SDIV and BPF_SMOD in RV32 JITKuan-Wei Chiu
The current rv32 bpf jit compiler incorrectly treats BPF_SDIV and BPF_SMOD as unsigned operations. The BPF instruction set allows signed division and modulo by reusing the BPF_DIV and BPF_MOD opcodes with the instruction offset set to 1. Update the emit_alu_r32() function to accept an 'is_sdiv' variable and emit the correct div and rem instructions when the offset is 1. Before this patch: [ 44.161771] test_bpf: #165 ALU_SDIV_X: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times) [ 44.167385] test_bpf: #166 ALU_SDIV_K: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times) [ 44.171053] test_bpf: #169 ALU_SMOD_X: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times) [ 44.172081] test_bpf: #170 ALU_SMOD_K: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times) After this patch: [ 16.002192] test_bpf: #165 ALU_SDIV_X: -6 / 2 = -3 jited:1 95 PASS [ 16.002983] test_bpf: #166 ALU_SDIV_K: -6 / 2 = -3 jited:1 1059 PASS [ 16.017167] test_bpf: #169 ALU_SMOD_X: -7 % 2 = -1 jited:1 136 PASS [ 16.023002] test_bpf: #170 ALU_SMOD_K: -7 % 2 = -1 jited:1 109 PASS Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com> Reviewed-by: Pu Lehui <pulehui@huawei.com> Link: https://lore.kernel.org/bpf/20260714002451.4091139-2-visitorckw@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-06 09:07:03 +0000