summaryrefslogtreecommitdiff
path: root/include/linux
AgeCommit message (Collapse)Author
2026-06-04timekeeping: Remove system_time_snapshot::real/boot/rawThomas Gleixner
All users are converted over to ktime_get_snapshot_id() and system_time_snapshot::systime and ::monoraw. Remove the leftovers. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: David Woodhouse <dwmw@amazon.co.uk> Tested-by: Arthur Kiyanovski <akiyano@amazon.com> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260529195557.330029635@kernel.org
2026-06-04tracing: Fix CFI violation in probestub being called by tprobesEva Kurchatova
The probestub is a function to allow tprobes to hook to a tracepoint to gain access to its parameters. The function itself is only referenced by the tracepoint structure which lives in the __tracepoint section. objtool explicitly ignores that section and when processing functions in the kernel, if it detects one that has no references it will seal it to have its ENDBR stripped on boot up. This means when a tprobe is attached to the sched_wakeup tracepoint, when it is triggered it will call __probestub_sched_wakeup and due to the missing ENDBR on a CFI-enabled machine it will take a #CP exception. Fix this by adding CFI_NOSEAL annotation to probestub declaration. Cc: stable@vger.kernel.org Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Link: https://patch.msgid.link/20260603153147.573589-1-eva.kurchatova@virtuozzo.com Fixes: d5173f753750 ("objtool: Exclude __tracepoints data from ENDBR checks") Signed-off-by: Eva Kurchatova <eva.kurchatova@virtuozzo.com> [ Updated change log ] Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-06-04cpu: Add lockdep_is_cpus_held()/lockdep_is_cpus_write_held() stubs for ↵refs/merge-window/1f2df8a15dad238c66ff0b664ad65e635ef4d482Reinette Chatre
!CONFIG_HOTPLUG_CPU lockdep_is_cpus_held() and lockdep_is_cpus_write_held() are undefined when !CONFIG_HOTPLUG_CPU. This is ok because their few callers protect the calls with a "if (IS_ENABLED(CONFIG_HOTPLUG_CPU) ..." check. It is error prone to require callers to protect lockdep_is_cpus_held() and lockdep_is_cpus_write_held() with an IS_ENABLED(CONFIG_HOTPLUG_CPU) check while the custom for equivalent functions, for example the more prevalent lockdep_is_held(), is to not require similar protection. It is also inconsistent with CPU hotplug lockdep code self since related call lockdep_assert_cpus_held() does not require protection. Create stubs for lockdep_is_cpus_held() and lockdep_is_cpus_write_held() that returns 1 (LOCK_STATE_UNKNOWN/LOCK_STATE_HELD) when !CONFIG_HOTPLUG_CPU. This makes the CPU hotplug lockdep checks consistent while following existing lockdep custom. Drop the "extern" from the function declaration as part of the move to match kernel coding style. Keep the IS_ENABLED(CONFIG_HOTPLUG_CPU) checks in existing users since removing them would change the logic of these expressions. Reported-by: Sashiko <sashiko-bot@kernel.org> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/7484f0b58fd86153d445819cc4e172adba16cff9.1780543665.git.reinette.chatre@intel.com Closes: https://sashiko.dev/#/patchset/cover.1780456704.git.reinette.chatre%40intel.com?part=1
2026-06-04buffer: Remove end_buffer_write_sync()Matthew Wilcox (Oracle)
It has no callers left, so delete it. Inline __end_buffer_write_sync() into bh_end_write(). Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Link: https://patch.msgid.link/20260528173150.1093780-35-willy@infradead.org Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-06-04buffer: Remove b_end_ioMatthew Wilcox (Oracle)
This shrinks buffer_head by 8 bytes, letting us pack more buffer heads per slab. With a Debian config, it shrinks from 104 bytes to 96 bytes which is 42 objects per 4KiB page rather than 39, a 7% reduction in the amount of memory used. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Link: https://patch.msgid.link/20260528173150.1093780-33-willy@infradead.org Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-06-04buffer: Remove submit_bh()Matthew Wilcox (Oracle)
No users are left; remove this API. Also remove/fix comments mentioning it, and end_bio_bh_io_sync() as it's now unused. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Link: https://patch.msgid.link/20260528173150.1093780-32-willy@infradead.org Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-06-04buffer: Remove mark_buffer_async_write()Matthew Wilcox (Oracle)
There are no more callers of this function, so delete it. end_buffer_async_write() then has only one caller left, so inline it into bh_end_async_write(). Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Link: https://patch.msgid.link/20260528173150.1093780-27-willy@infradead.org Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-06-04buffer: Add bh_end_read(), bh_end_write() and bh_end_async_write()Matthew Wilcox (Oracle)
These are the bio_end_io_t versions of end_buffer_read_sync(), end_buffer_write_sync() and end_buffer_async_write(). They do not contain a put_bh() call as it is no longer necessary. Also add the helper function bio_endio_bh(). Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Link: https://patch.msgid.link/20260528173150.1093780-5-willy@infradead.org Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-06-04buffer: Add bh_submit()Matthew Wilcox (Oracle)
bh_submit() takes a bio_end_io allowing users to avoid the indirect function call through bh->b_end_io, and eventually allowing us to remove bh->b_end_io. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Link: https://patch.msgid.link/20260528173150.1093780-3-willy@infradead.org Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-06-04mm: kick writeback flusher for IOCB_DONTCACHE with targeted dirty trackingJeff Layton
The IOCB_DONTCACHE writeback path in generic_write_sync() calls filemap_flush_range() on every write, submitting writeback inline in the writer's context. Perf lock contention profiling shows the performance problem is not lock contention but the writeback submission work itself — walking the page tree and submitting I/O blocks the writer for milliseconds, inflating p99.9 latency from 23ms (buffered) to 93ms (dontcache). Replace the inline filemap_flush_range() call with a flusher kick that drains dirty pages in the background. This moves writeback submission completely off the writer's hot path. To avoid flushing unrelated buffered dirty data, add a dedicated WB_start_dontcache bit and wb_check_start_dontcache() handler that uses the per-wb WB_DONTCACHE_DIRTY counter to determine how many pages to write back. The flusher writes back that many pages from the oldest dirty inodes (not restricted to dontcache-specific inodes). This helps preserve I/O batching while limiting the scope of expedited writeback. Like WB_start_all, the WB_start_dontcache bit coalesces multiple DONTCACHE writes into a single flusher wakeup without per-write allocations. Use test_and_clear_bit to atomically consume the kick request before reading the dirty counter and starting writeback, so that concurrent DONTCACHE writes during writeback can re-set the bit and schedule a follow-up flusher run. Read the dirty counter with wb_stat_sum() (aggregating per-CPU batches) rather than wb_stat() (which reads only the global counter) to ensure small writes below the percpu batch threshold are visible to the flusher. In filemap_dontcache_kick_writeback(), set the WB_start_dontcache bit inside the unlocked_inode_to_wb_begin/end section for correct cgroup writeback domain targeting, but defer the wb_wakeup() call until after the section ends, since wb_wakeup() uses spin_unlock_irq() which would unconditionally re-enable interrupts while the i_pages xa_lock may still be held under irqsave during a cgroup writeback switch. Pin the wb with wb_get() inside the RCU critical section before calling wb_wakeup() outside it, since cgroup bdi_writeback structures are RCU-freed and the wb pointer could become invalid after unlocked_inode_to_wb_end() drops the RCU read lock. Also add WB_REASON_DONTCACHE as a new writeback reason for tracing visibility. dontcache-bench results (same host, T6F_SKL_1920GBF, 251 GiB RAM, xfs on NVMe, fio io_uring): Buffered and direct I/O paths are unaffected by this patchset. All improvements are confined to the dontcache path: Single-stream throughput (MB/s): Before After Change seq-write/dontcache 298 897 +201% rand-write/dontcache 131 236 +80% Tail latency improvements (seq-write/dontcache): p99: 135,266 us -> 23,986 us (-82%) p99.9: 8,925,479 us -> 28,443 us (-99.7%) Multi-writer (4 jobs, sequential write): Before After Change dontcache aggregate (MB/s) 2,529 4,532 +79% dontcache p99 (us) 8,553 1,002 -88% dontcache p99.9 (us) 109,314 1,057 -99% Dontcache multi-writer throughput now matches buffered (4,532 vs 4,616 MB/s). 32-file write (Axboe test): Before After Change dontcache aggregate (MB/s) 1,548 3,499 +126% dontcache p99 (us) 10,170 602 -94% Peak dirty pages (MB) 1,837 213 -88% Dontcache now reaches 81% of buffered throughput (was 35%). Competing writers (dontcache vs buffered, separate files): Before After buffered writer 868 433 MB/s dontcache writer 415 433 MB/s Aggregate 1,284 866 MB/s Previously the buffered writer starved the dontcache writer 2:1. With per-bdi_writeback tracking, both writers now receive equal bandwidth. The aggregate matches the buffered-vs-buffered baseline (863 MB/s), indicating fair sharing regardless of I/O mode. The dontcache writer's p99.9 latency collapsed from 119 ms to 33 ms (-73%), eliminating the severe periodic stalls seen in the baseline. Both writers now share identical latency profiles, matching the buffered-vs-buffered pattern. The per-bdi_writeback dirty tracking dramatically reduces peak dirty pages in dontcache workloads, with the 32-file test dropping from 1.8 GB to 213 MB. Dontcache sequential write throughput triples and multi-writer throughput reaches parity with buffered I/O, with tail latencies collapsing by 1-2 orders of magnitude. Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Jeff Layton <jlayton@kernel.org> Link: https://patch.msgid.link/20260511-dontcache-v7-3-2848ddce8090@kernel.org Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-06-04mm: track DONTCACHE dirty pages per bdi_writebackJeff Layton
Add a per-wb WB_DONTCACHE_DIRTY counter that tracks the number of dirty pages with the dropbehind flag set (i.e., pages dirtied via RWF_DONTCACHE writes). Increment the counter alongside WB_RECLAIMABLE in folio_account_dirtied() when the folio has the dropbehind flag set, and decrement it in folio_clear_dirty_for_io() and folio_account_cleaned(). Also decrement it when a non-DONTCACHE lookup atomically clears the dropbehind flag on a dirty folio in __filemap_get_folio_mpol(), using folio_test_clear_dropbehind() to prevent concurrent lookups from double-decrementing the counter, and guarding the decrement with mapping_can_writeback() to match the increment path. Transfer the counter alongside WB_RECLAIMABLE in inode_do_switch_wbs() so that the stat is properly migrated when an inode switches cgroup writeback domains. The counter will be used by the writeback flusher to determine how many pages to write back when expediting writeback for IOCB_DONTCACHE writes, without flushing the entire BDI's dirty pages. Suggested-by: Jan Kara <jack@suse.cz> Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Jeff Layton <jlayton@kernel.org> Link: https://patch.msgid.link/20260511-dontcache-v7-2-2848ddce8090@kernel.org Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-06-04lib/fonts: Look up glyph data with font_data_glyph_buf()Thomas Zimmermann
Add font_data_glyph_buf() to retrieve a character's glyph data or NULL otherwise. Console fonts can currently contain 256 or 512 glyphs. The kernel-internal characters are of type char, unsigned short or unsigned int. Catch all of them by accepting unsigned int. Callers possibly have to cast from signed to unsigned types to reach all glyphs in a font. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patch.msgid.link/20260529140759.529929-2-tzimmermann@suse.de
2026-06-04Merge tag 'zynqmp-soc-for-7.2' of https://github.com/Xilinx/linux-xlnx into ↵Linus Walleij
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-03power: supply: Remove unused jz4740-battery.hCosta Shulyupin
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 Airlie
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 Krzyszkowiak
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 Cloutier
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 Tatashin
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 Tatashin
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 Tatashin
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 Tatashin
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 Tatashin
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 Hellwig
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 Hellwig
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-03wifi: mac80211: AP: handle DBE for clientsJohannes Berg
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 Berg
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 Berg
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 Berg
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 Berg
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: Fix PERR frame processingMasashi Honma
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 Honma
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 Honma
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 Honma
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 Honma
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 Honma
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-03futex: Provide infrastructure to plug the non contended robust futex unlock raceThomas Gleixner
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 Gleixner
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-03uaccess: Provide unsafe_atomic_store_release_user()Thomas Gleixner
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: Move futex related mm_struct data into a structThomas Gleixner
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 Gleixner
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 Gleixner
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
2026-06-03percpu: Sanitize __percpu_qual include hellThomas Gleixner
Slapping __percpu_qual into the next available header is sloppy at best. It's required by __percpu which is defined in compiler_types.h and that is meant to be included without requiring a boatload of other headers so that a struct or function declaration can contain a __percpu qualifier w/o further prerequisites. This implicit dependency on linux/percpu.h makes that impossible and causes a major problem when trying to separate headers. Create asm/percpu_types.h and move it there. Include that from compiler_types.h and the whole recursion problem goes away. Fix up UM so it uses the generic header and includes it in the UM_HOST build, which pulls in compiler_types.h. The USER_CFLAGS fix was suggested by Richard. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260602090535.254874125@kernel.org
2026-06-03cleanup: Remove NULL check from unconditional guardsDmitry Ilvokhin
The unconditional guard destructors check whether the lock pointer is NULL before unlocking. This check is dead code because unconditional guards guarantee a non-NULL lock pointer at destructor time. DEFINE_GUARD() runs the lock operation unconditionally in the constructor. If the pointer were NULL, the lock operation (e.g. mutex_lock(NULL)) would crash before the constructor returns. The destructor never runs with a NULL pointer. All DEFINE_GUARD() users dereference the pointer in their lock. Verified by auditing every instance found by: git grep -n -A 1 'DEFINE_GUARD('. The only exception is xe_pm_runtime_release_only, whose constructor is a noop, but it has no callers. __DEFINE_UNLOCK_GUARD() has only a few usages outside of include/linux/cleanup.h: tty_port_tty (NULL-checks in its tty_kref_put() call), irqdesc_lock (fixed earlier) and two guards in kernel/sched/sched.h (dereference the pointer unconditionally in their lock constructors). DEFINE_LOCK_GUARD_1() sets .lock from its argument and runs the lock operation in the constructor. Same reasoning applies. All DEFINE_LOCK_GUARD_1() users dereference the pointer in their lock. Also, verified by auditing every match of: git grep -n 'DEFINE_LOCK_GUARD_1('. DEFINE_LOCK_GUARD_0() hardcodes .lock = (void *)1 in the constructor, so it is never NULL by construction. Conditional (_try) variants: DEFINE_GUARD_COND() and DEFINE_LOCK_GUARD_1_COND() use EXTEND_CLASS_COND(), whose wrapper destructor returns early when the lock was not acquired, before reaching the base destructor since commit 2deccd5c862a ("cleanup: Optimize guards"): if (_cond) return; class_##_name##_destructor(_T); As compiled by GCC-11 with defconfig on top of the locking/core: Total: Before=23889980, After=23834334, chg -0.23% Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/0503a089389b2270c478a873e095cf0a4ff26d24.1780064327.git.d@ilvokhin.com
2026-06-03cleanup: Annotate guard constructors with nonnullDmitry Ilvokhin
Add __nonnull_args() to unconditional guard constructors so the compiler warns when NULL is statically known to be passed: - DEFINE_GUARD(): re-declare the constructor with __nonnull_args(). - __DEFINE_LOCK_GUARD_1(): annotate the constructor directly. DEFINE_LOCK_GUARD_0() needs no annotation: its constructor takes no pointer arguments (.lock is hardcoded to (void *)1). Define the __nonnull_args() macro in compiler_attributes.h, following the existing convention for attribute wrappers. Deliberately not named '__nonnull', to avoid clashing with glibc's __nonnull() when kernel and userspace headers are combined (User Mode Linux for example). Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/85fee12eec20abfcf711443518e8f0caec982a86.1780064327.git.d@ilvokhin.com
2026-06-03thermal/core: Fix missing stub for devm_thermal_cooling_device_registerDaniel Lezcano
Even it is very unlikely the thermal framework is disabled, the newly added devm_thermal_cooling_device_register() function has not the stub when the thermal framework is optout in the kernel. Add it. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202605301554.S9n45bfQ-lkp@intel.com/ Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Link: https://patch.msgid.link/20260601090152.1243983-2-daniel.lezcano@kernel.org
2026-06-03thermal/of: Pass cdev_id and introduce devm registration helperDaniel Lezcano
Extend the OF cooling device registration to support an explicit cooling device identifier (cdev_id), preparing for upcoming DT bindings where cooling devices are identified by a tuple (device node, id) instead of relying on child nodes. Introduce a new helper: devm_thermal_of_cooling_device_register() which registers a cooling device using the device's of_node and an explicit cdev_id. This complements the existing devm_thermal_of_child_cooling_device_register() helper, which remains dedicated to the legacy child-node based bindings. Internally, factorize the devm registration logic into a common helper to avoid code duplication. Existing users are unaffected, as the child-based helper continues to pass a default cdev_id of 0, preserving current behavior. This change is a preparatory step for supporting indexed cooling devices in thermal OF bindings. Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Link: https://patch.msgid.link/20260526140802.1059293-20-daniel.lezcano@oss.qualcomm.com
2026-06-03thermal/of: Add cooling device ID supportDaniel Lezcano
Introduce an identifier (cdev_id) for cooling devices registered from device tree. This prepares support for a new DT binding where cooling devices are identified by a tuple (device node, ID), instead of relying on child nodes. Existing users are updated to pass a default ID of 0, preserving the current behavior. Future changes will extend the cooling map parsing to match cooling devices based on both the device node and the ID. No functional change intended. Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Link: https://patch.msgid.link/20260526140802.1059293-19-daniel.lezcano@oss.qualcomm.com
2026-06-03thermal/of: Rename the devm_thermal_of_cooling_device_register() functionDaniel Lezcano
To clarify that the function operates on child nodes, rename: devm_thermal_of_cooling_device_register() | v devm_thermal_of_child_cooling_device_register() Used the command: find . -type f -name '*.[ch]' -exec \ sed -i 's/devm_thermal_of_cooling_device_register/\ devm_thermal_of_child_cooling_device_register/g' {} \; Did not used clang-format-diff because it does not indent correctly and checkpatch complained. Manually reindented to make checkpatch happy This prepares for upcoming support of cooling devices identified by an ID rather than device tree child nodes. No functional change. Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Link: https://patch.msgid.link/20260526140802.1059293-18-daniel.lezcano@oss.qualcomm.com
2026-06-03thermal/core: Make cooling device OF node conditional on CONFIG_THERMAL_OFDaniel Lezcano
The device node pointer stored in struct thermal_cooling_device is only used by the OF-specific thermal code to associate cooling devices with thermal zones defined in device tree. Now that OF and non-OF registration paths are separated and non-OF users no longer rely on devm_thermal_of_cooling_device_register() with a NULL device node, the np field is no longer required for non-OF configurations. Make this field conditional on CONFIG_THERMAL_OF to reduce memory footprint and better reflect its usage. Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://patch.msgid.link/20260526140802.1059293-16-daniel.lezcano@oss.qualcomm.com
2026-06-03thermal/of: Move cooling device OF helpers out of thermal coreDaniel Lezcano
The functions: - thermal_of_cooling_device_register() - devm_thermal_of_cooling_device_register() are specific to device tree usage but are currently implemented in thermal_core.c. Move them to thermal_of.c to better reflect the separation between generic thermal core code and OF-specific logic. This change is enabled by the recent split of the cooling device registration into allocation and addition phases, allowing OF-specific handling (such as device node assignment) to be isolated from the core. No functional change intended. Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Link: https://patch.msgid.link/20260526140802.1059293-17-daniel.lezcano@oss.qualcomm.com
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-07 02:52:27 +0000