summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)AuthorFilesLines
2026-06-04Merge tag 'zynqmp-soc-for-7.2' of https://github.com/Xilinx/linux-xlnx into ↵Linus Walleij1-1/+3
soc/drivers arm64: Xilinx SOC changes for 7.2 firmware: - Add CSU register discovery with sysfs interface zynqmp_power: - Fix race condition in event registration - Fix shutdown and free rx mailbox channel * tag 'zynqmp-soc-for-7.2' of https://github.com/Xilinx/linux-xlnx: firmware: zynqmp: Add dynamic CSU register discovery and sysfs interface Documentation: ABI: add sysfs interface for ZynqMP CSU registers soc: xilinx: Shutdown and free rx mailbox channel soc: xilinx: Fix race condition in event registration Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-06-03Merge tag 'for-net-2026-06-03' of ↵Jakub Kicinski1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - hci_core: fix memory leak in error path of hci_alloc_dev() - hci_sync: reject oversized Broadcast Announcement prepend - MGMT: Fix backward compatibility with userspace - MGMT: validate advertising TLV before type checks - L2CAP: reject BR/EDR signaling packets over MTUsig - RFCOMM: validate skb length in MCC handlers - RFCOMM: hold listener socket in rfcomm_connect_ind() - ISO: Fix not releasing hdev reference on iso_conn_big_sync - ISO: Fix a use-after-free of the hci_conn pointer - ISO: Fix data-race on iso_pi fields in hci_get_route calls - SCO: Fix data-race on sco_pi fields in sco_connect - BNEP: reject short frames before parsing * tag 'for-net-2026-06-03' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: MGMT: Fix backward compatibility with userspace Bluetooth: SCO: Fix data-race on sco_pi fields in sco_connect Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls Bluetooth: ISO: Fix a use-after-free of the hci_conn pointer Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync Bluetooth: fix memory leak in error path of hci_alloc_dev() Bluetooth: bnep: reject short frames before parsing Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig Bluetooth: RFCOMM: validate skb length in MCC handlers Bluetooth: MGMT: validate advertising TLV before type checks Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() ==================== Link: https://patch.msgid.link/20260603162714.342496-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03mptcp: change mptcp_established_options() to return opt_sizeEric Dumazet1-9/+8
Instead of passing opt_size address to mptcp_established_options(), change this function to return it by value. This removes the need for an expensive stack canary in tcp_established_options() when CONFIG_STACKPROTECTOR_STRONG=y. $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-92 (-92) Function old new delta tcp_options_write.isra 1423 1407 -16 mptcp_established_options 2746 2720 -26 tcp_established_options 553 503 -50 Total: Before=22110750, After=22110658, chg -0.00% Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260602125138.2317015-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03mptcp: fix uninit-value in mptcp_established_optionsPaolo Abeni1-2/+5
syzbot reported the following uninit splat: BUG: KMSAN: uninit-value in mptcp_write_data_fin net/mptcp/options.c:542 [inline] BUG: KMSAN: uninit-value in mptcp_established_options_dss net/mptcp/options.c:590 [inline] BUG: KMSAN: uninit-value in mptcp_established_options+0x112f/0x3530 net/mptcp/options.c:874 mptcp_write_data_fin net/mptcp/options.c:542 [inline] mptcp_established_options_dss net/mptcp/options.c:590 [inline] mptcp_established_options+0x112f/0x3530 net/mptcp/options.c:874 tcp_established_options+0x312/0xcc0 net/ipv4/tcp_output.c:1192 __tcp_transmit_skb+0x5dc/0x5fe0 net/ipv4/tcp_output.c:1575 __tcp_send_ack+0x967/0xad0 net/ipv4/tcp_output.c:4499 tcp_send_ack+0x3d/0x60 net/ipv4/tcp_output.c:4505 mptcp_subflow_shutdown+0x164/0x690 net/mptcp/protocol.c:3137 mptcp_check_send_data_fin+0x31b/0x3d0 net/mptcp/protocol.c:3218 __mptcp_wr_shutdown net/mptcp/protocol.c:3234 [inline] __mptcp_close+0x860/0x1360 net/mptcp/protocol.c:3313 mptcp_close+0x42/0x260 net/mptcp/protocol.c:3367 inet_release+0x1ee/0x2a0 net/ipv4/af_inet.c:442 __sock_release net/socket.c:722 [inline] sock_close+0xd6/0x2f0 net/socket.c:1514 __fput+0x60e/0x1010 fs/file_table.c:510 ____fput+0x25/0x30 fs/file_table.c:538 task_work_run+0x208/0x2b0 kernel/task_work.c:233 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] __exit_to_user_mode_loop kernel/entry/common.c:67 [inline] exit_to_user_mode_loop+0x306/0x1b60 kernel/entry/common.c:98 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:238 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:318 [inline] __do_fast_syscall_32+0x2c7/0x460 arch/x86/entry/syscall_32.c:310 do_fast_syscall_32+0x37/0x80 arch/x86/entry/syscall_32.c:332 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:370 entry_SYSENTER_compat_after_hwframe+0x84/0x8e Local variable opts created at: __tcp_transmit_skb+0x4d/0x5fe0 net/ipv4/tcp_output.c:1536 __tcp_send_ack+0x967/0xad0 net/ipv4/tcp_output.c:4499 The output path currently omits initializing the mptcp extension `use_map` flag in a few corner cases. Address the issue always zeroing all the extensions flags before eventually initializing the individual bits. To that extent, introduce and use a struct_group to avoid multiple bitwise operations. Fixes: cfcceb7a39fc ("tcp: shrink per-packet memset in __tcp_transmit_skb()") Cc: stable@vger.kernel.org Reported-by: syzbot+ff020673c5e3d94d9478@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ff020673c5e3d94d9478 Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-10-856831229976@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03geneve: Introduce IFLA_GENEVE_LOCAL and IFLA_GENEVE_LOCAL6.Kuniyuki Iwashima1-0/+2
By default, a GENEVE device bind()s its underlying UDP socket(s) to the IPv4 or IPv6 wildcard address because there is no way to specify a specific local IP address to bind() to. This prevents deploying multiple GENEVE devices on a multi-homed host where each device should be isolated and bound to a different local IP address on the same UDP port. Let's introduce new options, IFLA_GENEVE_LOCAL and IFLA_GENEVE_LOCAL6, to allow specifying a local IPv4/IPv6 address for the backend UDP socket. By default, when collect metadata mode (IFLA_GENEVE_COLLECT_METADATA) is enabled, both IPv4 and IPv6 sockets are created. However, if a source address is specified via the new attributes, only a single socket corresponding to that specific address family is created. Accordingly, geneve_find_sock() and geneve_find_dev() are updated to take the source address into account, ensuring that multiple devices and sockets configured with different source addresses can coexist without conflict. In addition, the source address is validated in geneve_xmit_skb() and geneve6_xmit_skb(), so the BPF prog must set it in bpf_tunnel_key. With this change, multiple GENEVE devices can be successfully created and bound to their respective local IP addresses: (*) "local" is the keyword for IFLA_GENEVE_LOCAL / IFLA_GENEVE_LOCAL6 # for i in $(seq 1 2); do ip link add geneve4_${i} type geneve local 192.168.0.${i} external ip addr add 192.168.0.${i}/24 dev geneve4_${i} ip link set geneve4_${i} up ip link add geneve6_${i} type geneve local 2001:9292::${i} external ip addr add 2001:9292::${i}/64 dev geneve6_${i} nodad ip link set geneve6_${i} up done # ip -d l | grep geneve 9: geneve4_1: <BROADCAST,MULTICAST,UP,LOWER_UP> ... geneve external id 0 local 192.168.0.1 ... 10: geneve6_1: <BROADCAST,MULTICAST,UP,LOWER_UP> ... geneve external id 0 local 2001:9292::1 ... 11: geneve4_2: <BROADCAST,MULTICAST,UP,LOWER_UP> ... geneve external id 0 local 192.168.0.2 ... 12: geneve6_2: <BROADCAST,MULTICAST,UP,LOWER_UP> ... geneve external id 0 local 2001:9292::2 ... # ss -ua | grep geneve UNCONN 0 0 192.168.0.2:geneve 0.0.0.0:* UNCONN 0 0 192.168.0.1:geneve 0.0.0.0:* UNCONN 0 0 [2001:9292::2]:geneve *:* UNCONN 0 0 [2001:9292::1]:geneve *:* Note that even if the local address is explicitly configured with the wildcard address, kernel does not dump it except for devices with IFLA_GENEVE_COLLECT_METADATA. This is consistent with the behaviour of is_tnl_info_zero(), which treats the wildcard remote address as not configured. ## ynl example. # ./tools/net/ynl/pyynl/cli.py \ --spec ./Documentation/netlink/specs/rt-link.yaml \ --do newlink --create \ --json '{"ifname": "geneve0", "linkinfo": {"kind":"geneve", "data": {"local": "0.0.0.0", "collect-metadata": true}}}' # ./tools/net/ynl/pyynl/cli.py \ --spec ./Documentation/netlink/specs/rt-link.yaml \ --do getlink \ --json '{"ifname": "geneve0"}' --output-json | \ jq .linkinfo.data.local "0.0.0.0" Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260602190436.139591-6-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03power: supply: Remove unused jz4740-battery.hCosta Shulyupin1-15/+0
The last user was removed in commit aea12071d6fc ("power/supply: Drop obsolete JZ4740 driver") and replaced by a self-contained IIO-based driver. No file includes this header. Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Costa Shulyupin <costa.shul@redhat.com> Link: https://patch.msgid.link/20260515185043.1523363-1-costa.shul@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-06-04Merge tag 'drm-msm-next-2026-05-30' of ↵Dave Airlie2-0/+70
https://gitlab.freedesktop.org/drm/msm into drm-next Changes for v7.2 Core: - Fixed documentation for msm_gem_shrinker functions - IFPC related enablement/fixes for gen8 - PERFCNTR_CONFIG ioctl support GPU - Reworked handling of UBWC configuration - a810 suppport MDSS: - Added Milos platform support - Reworked handling of UBWC configuration DisplayPort: - Reworked HPD handling, preparing for the MST support DPU: - Added Milos platform support - Reworked handling of UBWC configuration DSI: - Added Milos platform support Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <rob.clark@oss.qualcomm.com> Link: https://patch.msgid.link/CACSVV00DXZcvFH2-C3fouve5DGs0DGa-vvsJPuaRmUZZVNKOfg@mail.gmail.com
2026-06-03power: supply: max17042_battery: use ModelCfg refresh on max17055Sebastian Krzyszkowiak1-0/+3
Unlike other models, max17055 doesn't require cell characterization data and operates on a smaller set of input variables (`DesignCap`, `VEmpty`, `IChgTerm`, and `ModelCfg`). Those values can be filled in through `max17042_override_por_values()`, but the refresh bit has to be set afterward in order to make them apply. Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Signed-off-by: Vincent Cloutier <vincent@cloutier.co> Link: https://patch.msgid.link/20260406205759.493288-8-vincent.cloutier@icloud.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-06-03power: supply: max17042_battery: Remove unused platform-data plumbingVincent Cloutier1-29/+0
No in-tree user still provides `max17042_platform_data` or `max17042_reg_data`. Move the simple runtime fields into `struct max17042_chip`, populate them directly from DT or the default hardware state, and drop the unused public platform-data interface. While here, write the MAX17047/MAX17050 default `FullSOCThr` value directly in probe instead of carrying it through an `init_data` table. Signed-off-by: Vincent Cloutier <vincent@cloutier.co> Link: https://patch.msgid.link/20260406205759.493288-7-vincent.cloutier@icloud.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-06-03liveupdate: Remove limit on the number of files per sessionPasha Tatashin1-6/+7
To remove the fixed limit on the number of preserved files per session, transition the file metadata serialization from a single contiguous memory block to a chain of linked blocks. Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Reviewed-by: Pratyush Yadav (Google) <pratyush@kernel.org> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com> Link: https://patch.msgid.link/20260603154402.468928-11-pasha.tatashin@soleen.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2026-06-03liveupdate: Remove limit on the number of sessionsPasha Tatashin1-21/+2
Currently, the number of LUO sessions is limited by a fixed number of pre-allocated pages for serialization (16 pages, allowing for ~819 sessions). This limitation is problematic if LUO is used to support things such as systemd file descriptor store, and would be used not just as VM memory but to save other states on the machine. Remove this limit by transitioning to a linked-block approach for session metadata serialization. Instead of a single contiguous block, session metadata is now stored in a chain of 16-page blocks. Each block starts with a header containing the physical address of the next block and the number of session entries in the current block. Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Reviewed-by: Pratyush Yadav (Google) <pratyush@kernel.org> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com> Link: https://patch.msgid.link/20260603154402.468928-10-pasha.tatashin@soleen.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2026-06-03kho: add support for linked-block serializationPasha Tatashin3-1/+161
Introduce a linked-block serialization mechanism for state handover. Previously, LUO used contiguous memory blocks for serializing sessions and files, which imposed limits on the total number of items that could be preserved across a live update. This commit adds the infrastructure for a more flexible, block-based approach where serialized data is stored in a chain of linked blocks. This is a generic KHO serialization block infrastructure that can be used by multiple subsystems. Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com> Link: https://patch.msgid.link/20260603154402.468928-8-pasha.tatashin@soleen.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2026-06-03liveupdate: register luo_ser as KHO subtreePasha Tatashin1-36/+21
Entirely remove the LUO FDT wrapper since the FDT only carries the compatible string and the pointer to the centralized struct luo_ser. Instead, register the struct luo_ser via the KHO raw subtree API, placing the compatibility string inside the structure itself. Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Reviewed-by: Pratyush Yadav (Google) <pratyush@kernel.org> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com> Link: https://patch.msgid.link/20260603154402.468928-5-pasha.tatashin@soleen.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2026-06-03liveupdate: centralize state management into struct luo_serPasha Tatashin1-60/+31
Transition the LUO to ABI v2, which centralizes state management into a single struct luo_ser header. Previously, LUO state was spread across multiple FDT properties and subnodes. ABI v2 simplifies this by placing all core state, including the liveupdate number and physical addresses for sessions and FLB headers into a centralized struct luo_ser. Note that this change introduces a semantic difference: the sessions and FLB serialization formats are no longer completely independent of the core LUO. Their metadata (such as physical addresses for sessions and FLB headers) is now coupled to and managed via the centralized struct luo_ser. Reviewed-by: Pratyush Yadav (Google) <pratyush@kernel.org> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com> Link: https://patch.msgid.link/20260603154402.468928-4-pasha.tatashin@soleen.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2026-06-03mm: simplify the mempool_alloc_bulk APIChristoph Hellwig1-1/+1
The mempool_alloc_bulk was modelled after the alloc_pages_bulk API, including some misunderstanding of it. Remove checking for NULL slots in the array, as alloc_pages_bulk and kmem_cache_alloc_bulk always fill the array from the beginning and thus we know the offset of the first failing allocation. This removes support for working well with alloc_pages_bulk used to refill page arrays that might have an entry removed from in the middle, but that is only used by sunrpc and hopefully on it's way out. Also remove the allocated parameter as it is redundant because the caller can simply specific and offset into the entries array. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260602160038.3976341-1-hch@lst.de Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
2026-06-03mm/slab: improve kmem_cache_alloc_bulkChristoph Hellwig1-2/+4
The kmem_cache_alloc_bulk return value is weird. It returns the number of allocated objects, but that must always be 0 or the requested number based on the implementations and the handling in the callers, but that assumption is not actually documented anywhere, which confuses automated review tools. Fix this by returning a bool if the allocation succeeded and adding a kerneldoc comment explaining the API. [rob.clark@oss.qualcomm.com: fixups in msm_iommu_pagetable_prealloc_allocate() ] Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> # skbuff Link: https://patch.msgid.link/20260528093437.2519248-2-hch@lst.de Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
2026-06-03Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsigMichael Bommarito1-0/+1
net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag. Cc: stable@vger.kernel.org Suggested-by: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Link: https://lore.kernel.org/r/20260518002800.1361430-1-michael.bommarito@gmail.com Link: https://lore.kernel.org/r/20260520135034.1060859-1-michael.bommarito@gmail.com Link: https://lore.kernel.org/r/20260521000555.3712030-1-michael.bommarito@gmail.com Assisted-by: Claude:claude-opus-4-7 Assisted-by: Codex:gpt-5-5-xhigh Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-06-03ext4: fast commit: add lock_updates tracepointLi Chen1-0/+61
Commit-time fast commit snapshots run under jbd2_journal_lock_updates(), so it is useful to quantify the time spent with updates locked and to understand why snapshotting can fail. Add a new tracepoint, ext4_fc_lock_updates, reporting the time spent in the updates-locked window along with the number of snapshotted inodes and ranges. Record the first snapshot failure reason in a stable snap_err field for tooling. Signed-off-by: Li Chen <chenl311@chinatelecom.cn> Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org> Link: https://patch.msgid.link/20260515091829.194810-7-me@linux.beauty Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2026-06-03Merge tag 'tegra-for-7.2-arm-dt' of ↵Linus Walleij1-0/+67
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/dt ARM: tegra: Device tree changes for v7.2-rc1 The bulk of this is various improvements for some of the older ASUS and LG devices, but there's also support for interconnects on Tegra114 to help improve memory frequency scaling. * tag 'tegra-for-7.2-arm-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: ARM: tegra: tf600t: Invert accelerometer calibration matrix ARM: tegra: tf600t: Drop backlight regulator ARM: tegra: tf600t: Configure panel ARM: tegra: transformers: Add connector node for common trees ARM: tegra: transformer: Add support for front camera ARM: tegra: grouper: Add support for front camera ARM: tegra: p880: Lower CPU thermal limit ARM: tegra: lg-x3: Set PMIC's RTC address ARM: tegra: lg-x3: Complete video device graph ARM: tegra: Configure Tegra114 power domains ARM: tegra: Add DC interconnections for Tegra114 ARM: tegra: Add EMC OPP and ICC properties to Tegra114 EMC and ACTMON device-tree nodes ARM: tegra: Add #{address,size}-cells to Chromium-based /firmware dt-bindings: memory: Document Tegra114 External Memory Controller dt-bindings: memory: Document Tegra114 Memory Controller Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-06-03wifi: mac80211: AP: handle DBE for clientsJohannes Berg2-3/+29
In AP mode, track the BSS non-DBE bandwidth and apply that to all non-DBE clients, then track OMP updates from the clients and enable/disable DBE accordingly. For now don't send a response, clients need to have a timer anyway (it's up to the driver to set the right timeout in UHR capabilities.) Link: https://patch.msgid.link/20260529102644.be84f2b055cc.I4d2c067dfe54c47621d5a872ca07a0e754d6c20f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: parse and apply UHR DBE channelJohannes Berg2-7/+103
When a UHR AP has DBE enabled, parse the channel and apply it to the chandef. Apply for TX only after the OMP response (or timeout) so that the AP doesn't receive frames with DBE width before the station completed transition to DBE. Link: https://patch.msgid.link/20260529102644.cb810f212128.Ife37c2673251346e84e4250b242b31f0895520ab@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: Update UHR MAC capabilities to D1.4Johannes Berg1-1/+1
There are now 8 more reserved bits in D1.4, update the code accordingly. Link: https://patch.msgid.link/20260529102644.6e27c54cfceb.Id395c07ffde286011494fc75190dc6060117436e@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: Update UHR PHY capabilities to D1.4Johannes Berg1-9/+31
There are new capabilities in D1.4, and some reserved bits. Update the code accordingly. Link: https://patch.msgid.link/20260529102644.f146932b21e2.I12bad84157bf809fbe285b79420143b3c456d9d2@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: ieee80211: define some UHR link reconfiguration frame typesJohannes Berg2-0/+68
Define some values needed for UHR link reconfiguration frames, in particular to prepare for UHR mode change request/handling. Link: https://patch.msgid.link/20260529102644.03029bae6447.If22b0c1e10d9db712dca408a420469b3d385b4ea@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: basic S1G rx rate reporting supportLachlan Hodges1-0/+1
Introduce basic rate encoding/decoding for S1G stas such that the usermode rx reporting is relevant as it currently uses VHT calculations which are obviously wildy different to S1G. Sample iw output (with the associated iw patches applied): Connected to 0c:bf:74:00:21:c4 (on wlan0) SSID: wifi_halow freq: 923.500 RX: 7325230 bytes (4756 packets) TX: 190044 bytes (2238 packets) signal: -38 dBm rx bitrate: 43.3 MBit/s S1G-MCS 9 8MHz short GI S1G-NSS 1 tx bitrate: 43.3 MBit/s S1G-MCS 9 8MHz short GI S1G-NSS 1 bss flags: dtim period: 1 beacon int: 100 Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20260602062224.1792985-1-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: Fix PERR frame processingMasashi Honma1-0/+36
There are no issues with the PERR processing itself; however, to maintain consistency with the previous PREQ/PREP code modifications, I will create a new mesh_path_parse_error_frame() function to separately implement the frame format validation and the "not supported" check. Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Link: https://patch.msgid.link/20260529230952.124754-6-masashi.honma@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: Fix overread in PREP frame processingMasashi Honma1-0/+16
When the AF flag is enabled, hwmp_prep_frame_process() overreads orig_addr by 2 bytes. Since this occurs within the socket buffer, it does not read across memory boundaries and therefore poses no security risk; however, we will fix it as a precaution. In this fix, a new function mesh_path_parse_reply_frame() is established to separate the implementation of frame format validation and the check for unsupported features. This is intended to facilitate future work when implementing the currently unsupported parts. Assisted-by: Claude:Sonnet 4.6 Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Link: https://patch.msgid.link/20260529230952.124754-5-masashi.honma@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: Fix overread in PREQ frame processingMasashi Honma1-0/+29
When the AF flag is enabled, hwmp_preq_frame_process() overreads target_addr by 2 bytes. Since this occurs within the socket buffer, it does not read across memory boundaries and therefore poses no security risk; however, we will fix it as a precaution. In this fix, a new function mesh_path_parse_request_frame() is established to separate the implementation of frame format validation and the check for unsupported features. This is intended to facilitate future work when implementing the currently unsupported parts. Assisted-by: Claude:Sonnet 4.6 Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Link: https://patch.msgid.link/20260529230952.124754-4-masashi.honma@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: Use struct instead of macro for PERR frameMasashi Honma1-0/+62
The existing PERR_IE_* macros access HWMP PERR frame fields via hardcoded byte offsets. Each PERR destination entry contains an optional 6-byte AE (Address Extension) address followed by a reason code, making offset-based access error-prone. Introduce typed packed C structs to represent the PERR frame layout: - ieee80211_mesh_hwmp_perr: top-level frame containing TTL and destination count - ieee80211_mesh_hwmp_perr_dst: per-destination entry with optional AE address and variable-position reason code Add ieee80211_mesh_hwmp_perr_get_rcode() to locate the reason code in each destination entry depending on whether the AE flag is set. This refactoring makes the PERR processing code consistent with the struct-based approach adopted for PREQ and PREP in preceding patches. Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Link: https://patch.msgid.link/20260529230952.124754-3-masashi.honma@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: Use struct instead of macro for PREP frameMasashi Honma1-0/+27
The existing PREP_IE_* macros access HWMP PREP frame fields via hardcoded byte offsets. When the AE (Address Extension) flag is set, an additional 6 bytes appear mid-frame, making the offset arithmetic error-prone. Introduce typed packed C structs to represent the PREP frame layout: - ieee80211_mesh_hwmp_prep_top: fixed fields before the optional AE address - ieee80211_mesh_hwmp_prep_bottom: fields after the optional AE address Add ieee80211_mesh_hwmp_prep_get_bottom() to locate the bottom struct correctly based on whether the AE flag is set. This preparatory refactoring is needed to fix a 2-byte overread of orig_addr in hwmp_prep_frame_process() when AE is enabled, which is addressed in a subsequent patch. Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Link: https://patch.msgid.link/20260529230952.124754-2-masashi.honma@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: mac80211: Use struct instead of macro for PREQ frameMasashi Honma1-0/+42
The existing PREQ_IE_* macros access HWMP PREQ frame fields via hardcoded byte offsets. When the AE (Address Extension) flag is set, an additional 6 bytes appear mid-frame, and the macros handle this with conditional arithmetic (e.g., AE_F_SET(x) ? x + N+6 : x + N). This approach obscures the frame layout and is prone to miscalculation. Introduce typed packed C structs to represent the PREQ frame layout: - ieee80211_mesh_hwmp_preq_top: fixed fields before the optional AE address - ieee80211_mesh_hwmp_preq_bottom: fields after the optional AE address - ieee80211_mesh_hwmp_preq_target: per-target fields Add ieee80211_mesh_hwmp_preq_get_bottom() to locate the bottom struct correctly based on whether the AE flag is set. This preparatory refactoring is needed to fix a 2-byte overread of target_addr in hwmp_preq_frame_process() when AE is enabled, which is addressed in a subsequent patch. Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Link: https://patch.msgid.link/20260529230952.124754-1-masashi.honma@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03wifi: cfg80211: remove 5/10 MHz channel supportJohannes Berg1-2/+0
Remove WIPHY_FLAG_SUPPORTS_5_10_MHZ and 5/10 MHz channel width support. We contemplated this back in early 2023 and didn't do it yet, but nobody stepped up to maintain it. It's already _mostly_ dead code since it can really only be used for AP and maybe IBSS and monitor, but not on a client since there's no way to scan (and hasn't been in a very long time, if ever), so the only thing that ever could really happen with it was run syzbot and trip over assumptions in the code. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20260529084502.080c5885f0b7.I77cc94485b523c3c006005b9233db13cd4e077b3@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-03rv: Prevent task migration while handling per-CPU eventsGabriele Monaco1-0/+11
Tracepoint handlers are fully preemptible after a46023d5616 ("tracing: Guard __DECLARE_TRACE() use of __DO_TRACE_CALL() with SRCU-fast"). When a per-CPU monitor handles an event, it retrieves the monitor state using a per-CPU pointer. If the event itself doesn't disable preemption, the task can migrate to a different CPU and we risk updating the wrong monitor. Mitigate this by explicitly disabling task migration before acquiring the monitor pointer. This cannot guarantee the monitor runs on the correct CPU but reduces the race condition window and prevents warnings. Reviewed-by: Wen Yang <wen.yang@linux.dev> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://lore.kernel.org/r/20260601153840.124372-10-gmonaco@redhat.com Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
2026-06-03rv: Ensure synchronous cleanup for HA monitorsGabriele Monaco2-5/+41
HA monitors may start timers, all cleanup functions currently stop the timers asynchronously to avoid sleeping in the wrong context. Nothing makes sure running callbacks terminate on cleanup. Run the entire HA timer callback in an RCU read-side critical section, this way we can simply synchronize_rcu() with any pending timer and are sure any cleanup using kfree_rcu() runs after callbacks terminated. Additionally make sure any unlikely callback running late won't run any code if the monitor is marked as disabled or if destruction started. Use memory barriers to serialise with racing resets. Fixes: f5587d1b6ec9 ("rv: Add Hybrid Automata monitor type") Fixes: 4a24127bd6cb ("rv: Add support for per-object monitors in DA/HA") Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://lore.kernel.org/r/20260601153840.124372-9-gmonaco@redhat.com Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
2026-06-03rv: Add automatic cleanup handlers for per-task HA monitorsGabriele Monaco1-0/+60
Hybrid automata monitors may start timers, depending on the model, these may remain active on an exiting task and cause false positives or even access freed memory. Add an enable/disable hook in the HA code, currently only populated by the per-task handler for registration and deregistration. This hooks to the sched_process_exit event and ensures the timer is stopped for every exiting task. The handler is enabled automatically but may be disabled, for instance if the monitor uses the event for another purpose (but should still manually ensure timers are stopped). Fixes: f5587d1b6ec9 ("rv: Add Hybrid Automata monitor type") Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://lore.kernel.org/r/20260601153840.124372-8-gmonaco@redhat.com Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
2026-06-03rv: Do not rely on clean monitor when initialising HAGabriele Monaco2-17/+76
Hybrid Automata monitors hook into the DA implementation when doing da_monitor_reset(). This function is called both on initialisation and teardown, HA monitors try to cancel a timer only when it's initialised relying on the da_mon->monitoring flag. This flag could however be corrupted during initialisation. This happens for instance on per-task monitors that share the same storage with different type of monitors like LTL or in case of races during a previous teardown. Stop relying on the monitoring flag during initialisation, assume that can have any value, so use a separate da_reset_state() skiping timer cancellation. New monitors (e.g. new tasks) are always zero-initialised so it is safe to rely on the monitoring flag for those. Reported-by: Wen Yang <wen.yang@linux.dev> Closes: https://lore.kernel.org/lkml/d02c656aada7d071f083460a5c9a454363669b61.1778522945.git.wen.yang@linux.dev Suggested-by: Nam Cao <namcao@linutronix.de> Fixes: f5587d1b6ec9 ("rv: Add Hybrid Automata monitor type") Reviewed-by: Wen Yang <wen.yang@linux.dev> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://lore.kernel.org/r/20260601153840.124372-7-gmonaco@redhat.com Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
2026-06-03rv: Fix monitor start ordering and memory ordering for monitoring flagWen Yang1-3/+5
da_monitor_start() set monitoring=1 before calling da_monitor_init_hook(), may racing with the sched_switch handler: da_monitor_start() sched_switch handler ------------------------- --------------------------------- da_mon->monitoring = 1; if (da_monitoring(da_mon)) /* true */ ha_start_timer_ns(...); /* hrtimer->base == NULL, crash */ da_monitor_init_hook(da_mon); /* hrtimer_setup() sets base */ Fix the ordering and pair with release/acquire semantics: da_monitor_init_hook(da_mon); smp_store_release(&da_mon->monitoring, 1); /* da_monitor_start() */ return smp_load_acquire(&da_mon->monitoring); /* da_monitoring() */ On ARM64 a plain STR + LDR does not form a release-acquire pair, so the load can observe monitoring=1 while hrtimer->base is still NULL. The plain accesses are also data races under KCSAN. Use WRITE_ONCE for the monitoring=0 store in da_monitor_reset() to cover the reset path. Fixes: 792575348ff7 ("rv/include: Add deterministic automata monitor definition via C macros") Signed-off-by: Wen Yang <wen.yang@linux.dev> Reviewed-by: Gabriele Monaco <gmonaco@redhat.com> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://lore.kernel.org/r/20260601153840.124372-6-gmonaco@redhat.com Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
2026-06-03rv: Ensure all pending probes terminate on per-obj monitor destroyGabriele Monaco1-2/+3
The monitor disable/destroy sequence detaches all probes and resets the monitor's data, however it doesn't wait for pending probes. This is an issue with per-object monitors, which free the monitor storage. Call tracepoint_synchronize_unregister() to make sure to wait for all pending probes before destroying the monitor storage. Fixes: 4a24127bd6cb ("rv: Add support for per-object monitors in DA/HA") Reviewed-by: Wen Yang <wen.yang@linux.dev> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://lore.kernel.org/r/20260601153840.124372-5-gmonaco@redhat.com Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
2026-06-03rv: Prevent in-flight per-task handlers from using invalid slotsGabriele Monaco2-0/+5
Per-task monitors use a slot in the task_struct->rv[] array and store that locally (e.g. task_mon_slot), this slot is returned during the destruction process but currently hanlers can be running while that slot is returning and this race may lead to accessing an invalid slot. Synchronise with all in-flight tracepoint handlers using tracepoint_synchronize_unregister() before returning the slot. Fixes: f5587d1b6ec9 ("rv: Add Hybrid Automata monitor type") Fixes: a9769a5b9878 ("rv: Add support for LTL monitors") Suggested-by: Wen Yang <wen.yang@linux.dev> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://lore.kernel.org/r/20260601153840.124372-4-gmonaco@redhat.com Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
2026-06-03rv: Reset per-task DA monitors before releasing the slotGabriele Monaco1-2/+3
Per-task monitors use task_mon_slot to determine which slot in the array to use for the monitor. During destruction, this slot is returned but this is done before resetting the monitor. As a result, the monitor's reset is in fact resetting a slot that is outside of the array (RV_PER_TASK_MONITOR_INIT). Release the slot only after the reset to avoid out-of-bound memory access. Fixes: f5587d1b6ec93 ("rv: Add Hybrid Automata monitor type") Cc: stable@vger.kernel.org Suggested-by: Wen Yang <wen.yang@linux.dev> Reviewed-by: Wen Yang <wen.yang@linux.dev> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://lore.kernel.org/r/20260601153840.124372-3-gmonaco@redhat.com Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
2026-06-03pmdomain: Merge branch dt into nextUlf Hansson1-8/+10
Merge the immutable branch dt into next, to allow the updated DT bindings to be tested together with the pmdomain changes that are targeted for the next release. Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-06-03futex: Provide infrastructure to plug the non contended robust futex unlock raceThomas Gleixner2-1/+90
When the FUTEX_ROBUST_UNLOCK mechanism is used for unlocking (PI-)futexes, then the unlock sequence in user space looks like this: 1) robust_list_set_op_pending(mutex); 2) robust_list_remove(mutex); lval = gettid(); 3) if (atomic_try_cmpxchg(&mutex->lock, lval, 0)) 4) robust_list_clear_op_pending(); else 5) sys_futex(OP | FUTEX_ROBUST_UNLOCK, ....); That still leaves a minimal race window between #3 and #4 where the mutex could be acquired by some other task, which observes that it is the last user and: 1) unmaps the mutex memory 2) maps a different file, which ends up covering the same address When then the original task exits before reaching #5 then the kernel robust list handling observes the pending op entry and tries to fix up user space. In case that the newly mapped data contains the TID of the exiting thread at the address of the mutex/futex the kernel will set the owner died bit in that memory and therefore corrupt unrelated data. On X86 this boils down to this simplified assembly sequence: mov %esi,%eax // Load TID into EAX xor %ecx,%ecx // Set ECX to 0 #3 lock cmpxchg %ecx,(%rdi) // Try the TID -> 0 transition .Lstart: jnz .Lend #4 movq %rcx,(%rdx) // Clear list_op_pending .Lend: If the cmpxchg() succeeds and the task is interrupted before it can clear list_op_pending in the robust list head (#4) and the task crashes in a signal handler or gets killed then it ends up in do_exit() and subsequently in the robust list handling, which then might run into the unmap/map issue described above. This is only relevant when user space was interrupted and a signal is pending. The fix-up has to be done before signal delivery is attempted because: 1) The signal might be fatal so get_signal() ends up in do_exit() 2) The signal handler might crash or the task is killed before returning from the handler. At that point the instruction pointer in pt_regs is not longer the instruction pointer of the initially interrupted unlock sequence. The right place to handle this is in __exit_to_user_mode_loop() before invoking arch_do_signal_or_restart() as this covers obviously both scenarios. As this is only relevant when the task was interrupted in user space, this is tied to RSEQ and the generic entry code as RSEQ keeps track of user space interrupts unconditionally even if the task does not have a RSEQ region installed. That makes the decision very lightweight: if (current->rseq.user_irq && within(regs, csr->unlock_ip_range)) futex_fixup_robust_unlock(regs, csr); futex_fixup_robust_unlock() then invokes a architecture specific function to return the pending op pointer or NULL. The function evaluates the register content to decide whether the pending ops pointer in the robust list head needs to be cleared. Assuming the above unlock sequence, then on x86 this decision is the trivial evaluation of the zero flag: return regs->eflags & X86_EFLAGS_ZF ? regs->dx : NULL; Other architectures might need to do more complex evaluations due to LLSC, but the approach is valid in general. The size of the pointer is determined from the matching range struct, which covers both 32-bit and 64-bit builds including COMPAT. The unlock sequence is going to be placed in the VDSO so that the kernel can keep everything synchronized, especially the register usage. The resulting code sequence for user space is: if (__vdso_futex_robust_list$SZ_try_unlock(lock, tid, &pending_op) != tid) err = sys_futex($OP | FUTEX_ROBUST_UNLOCK,....); Both the VDSO unlock and the kernel side unlock ensure that the pending_op pointer is always cleared when the lock becomes unlocked. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: André Almeida <andrealmeid@igalia.com> Link: https://patch.msgid.link/20260602090535.773669210@kernel.org
2026-06-03futex: Add robust futex unlock IP rangeThomas Gleixner2-3/+46
There will be a VDSO function to unlock robust futexes in user space. The unlock sequence is racy vs. clearing the list_pending_op pointer in the tasks robust list head. To plug this race the kernel needs to know the instruction window. As the VDSO is per MM the addresses are stored in mm_struct::futex. Architectures which implement support for this have to update these addresses when the VDSO is (re)mapped and indicate the pending op pointer size which is matching the IP. Arguably this could be resolved by chasing mm->context->vdso->image, but that's architecture specific and requires to touch quite some cache lines. Having it in mm::futex reduces the cache line impact and avoids having yet another set of architecture specific functionality. To support multi size robust list applications (gaming) this provides two ranges when COMPAT is enabled. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: André Almeida <andrealmeid@igalia.com> Link: https://patch.msgid.link/20260602090535.718926819@kernel.org
2026-06-03futex: Add support for unlocking robust futexesThomas Gleixner1-1/+28
Unlocking robust non-PI futexes happens in user space with the following sequence: 1) robust_list_set_op_pending(mutex); 2) robust_list_remove(mutex); lval = 0; 3) lval = atomic_xchg(lock, lval); 4) if (lval & WAITERS) 5) sys_futex(WAKE,....); 6) robust_list_clear_op_pending(); That opens a window between #3 and #6 where the mutex could be acquired by some other task which observes that it is the last user and: A) unmaps the mutex memory B) maps a different file, which ends up covering the same address When the original task exits before reaching #6 then the kernel robust list handling observes the pending op entry and tries to fix up user space. In case that the newly mapped data contains the TID of the exiting thread at the address of the mutex/futex the kernel will set the owner died bit in that memory and therefore corrupting unrelated data. PI futexes have a similar problem both for the non-contented user space unlock and the in kernel unlock: 1) robust_list_set_op_pending(mutex); 2) robust_list_remove(mutex); lval = gettid(); 3) if (!atomic_try_cmpxchg(lock, lval, 0)) 4) sys_futex(UNLOCK_PI,....); 5) robust_list_clear_op_pending(); Address the first part of the problem where the futexes have waiters and need to enter the kernel anyway. Add a new FUTEX_ROBUST_UNLOCK flag, which is valid for the sys_futex() FUTEX_UNLOCK_PI, FUTEX_WAKE, FUTEX_WAKE_BITSET operations. This deliberately omits FUTEX_WAKE_OP from this treatment as it's unclear whether this is needed and there is no usage of it in glibc either to investigate. For the futex2 syscall family this needs to be implemented with a new syscall. The sys_futex() case [ab]uses the @uaddr2 argument to hand the pointer to robust_list_head::list_pending_op into the kernel. This argument is only evaluated when the FUTEX_ROBUST_UNLOCK bit is set and is therefore backward compatible. This is an explicit argument to avoid the lookup of the robust list pointer and retrieving the pending op pointer from there. User space has the pointer already available so it can just put it into the @uaddr2 argument. Aside of that this allows the usage of multiple robust lists in the future without any changes to the internal functions as they just operate on the provided pointer. This requires a second flag FUTEX_ROBUST_LIST32 which indicates that the robust list pointer points to an u32 and not to an u64. This is required for two reasons: 1) sys_futex() has no compat variant 2) The gaming emulators use both both 64-bit and compat 32-bit robust lists in the same 64-bit application As a consequence 32-bit applications have to set this flag unconditionally so they can run on a 64-bit kernel in compat mode unmodified. 32-bit kernels return an error code when the flag is not set. 64-bit kernels will happily clear the full 64 bits if user space fails to set it. In case of FUTEX_UNLOCK_PI this clears the robust list pending op when the unlock succeeded. In case of errors, the user space value is still locked by the caller and therefore the above cannot happen. In case of FUTEX_WAKE* this does the unlock of the futex in the kernel and clears the robust list pending op when the unlock was successful. If not, the user space value is still locked and user space has to deal with the returned error. That means that the unlocking of non-PI robust futexes has to use the same try_cmpxchg() unlock scheme as PI futexes. If the clearing of the pending list op fails (fault) then the kernel clears the registered robust list pointer if it matches to prevent that exit() will try to handle invalid data. That's a valid paranoid decision because the robust list head sits usually in the TLS and if the TLS is not longer accessible then the chance for fixing up the resulting mess is very close to zero. The problem of non-contended unlocks still exists and will be addressed separately. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: André Almeida <andrealmeid@igalia.com> Link: https://patch.msgid.link/20260602090535.670514505@kernel.org
2026-06-03futex: Cleanup UAPI definesThomas Gleixner1-14/+13
Make the operand defines tabular for readability sake. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: André Almeida <andrealmeid@igalia.com> Link: https://patch.msgid.link/20260602090535.615600933@kernel.org
2026-06-03uaccess: Provide unsafe_atomic_store_release_user()Thomas Gleixner1-0/+11
The upcoming support for unlocking robust futexes in the kernel requires store release semantics. Syscalls do not imply memory ordering on all architectures so the unlock operation requires a barrier. This barrier can be avoided when stores imply release like on x86. Provide a generic version with a smp_mb() before the unsafe_put_user(), which can be overridden by architectures. Provide also a ARCH_MEMORY_ORDER_TSO Kconfig option, which can be selected by architectures with Total Store Order (TSO), where store implies release, so that the smp_mb() in the generic implementation can be avoided. If that is set a barrier() is used instead of smp_mb(), which is not required for the use case at hand, but makes it future proof for other usage to prevent the compiler from reordering. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: André Almeida <andrealmeid@igalia.com> Link: https://patch.msgid.link/20260602090535.513181528@kernel.org
2026-06-03futex: Provide UABI defines for robust list entry modifiersThomas Gleixner1-0/+4
The marker for PI futexes in the robust list is a hardcoded 0x1 which lacks any sensible form of documentation. Provide proper defines for the bit and the mask and fix up the usage sites. Thereby convert the boolean pi argument into a modifier argument, which allows new modifier bits to be trivially added and conveyed. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Reviewed-by: André Almeida <andrealmeid@igalia.com> Link: https://patch.msgid.link/20260602090535.458758556@kernel.org
2026-06-03futex: Move futex related mm_struct data into a structThomas Gleixner2-11/+37
Having all these members in mm_struct along with the required #ifdeffery is annoying, does not allow efficient initializing of the data with memset() and makes extending it tedious. Move it into a data structure and fix up all usage sites. The extra struct for the private hash is intentional to make integration of other conditional mechanisms easier in terms of initialization and separation. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260602090535.407756793@kernel.org
2026-06-03futex: Make futex_mm_init() voidThomas Gleixner1-17/+11
Nothing fails there. Mop up the leftovers of the early version of this, which did an allocation. While at it clean up the stubs and the #ifdef comments to make the header file readable. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260602090535.356789395@kernel.org
2026-06-03futex: Move futex task related data into a structThomas Gleixner3-20/+44
Having all these members in task_struct along with the required #ifdeffery is annoying, does not allow efficient initializing of the data with memset() and makes extending it tedious. Move it into a data structure and fix up all usage sites. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Reviewed-by: André Almeida <andrealmeid@igalia.com> Link: https://patch.msgid.link/20260602090535.308220888@kernel.org
generated by cgit (git 2.54.0.dirty) at 2026-09-29 20:31:05 +0000