summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-01-14mm/damon/sysfs: cleanup attrs subdirs on context dir setup failureSeongJae Park
When a context DAMON sysfs directory setup is failed after setup of attrs/ directory, subdirectories of attrs/ directory are not cleaned up. As a result, DAMON sysfs interface is nearly broken until the system reboots, and the memory for the unremoved directory is leaked. Cleanup the directories under such failures. Link: https://lkml.kernel.org/r/20251225023043.18579-3-sj@kernel.org Fixes: c951cd3b8901 ("mm/damon: implement a minimal stub for sysfs-based DAMON interface") Signed-off-by: SeongJae Park <sj@kernel.org> Cc: chongjiapeng <jiapeng.chong@linux.alibaba.com> Cc: <stable@vger.kernel.org> # 5.18.x Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-14mm/damon/sysfs: cleanup intervals subdirs on attrs dir setup failureSeongJae Park
Patch series "mm/damon/sysfs: free setup failures generated zombie sub-sub dirs". Some DAMON sysfs directory setup functions generates its sub and sub-sub directories. For example, 'monitoring_attrs/' directory setup creates 'intervals/' and 'intervals/intervals_goal/' directories under 'monitoring_attrs/' directory. When such sub-sub directories are successfully made but followup setup is failed, the setup function should recursively clean up the subdirectories. However, such setup functions are only dereferencing sub directory reference counters. As a result, under certain setup failures, the sub-sub directories keep having non-zero reference counters. It means the directories cannot be removed like zombies, and the memory for the directories cannot be freed. The user impact of this issue is limited due to the following reasons. When the issue happens, the zombie directories are still taking the path. Hence attempts to generate the directories again will fail, without additional memory leak. This means the upper bound memory leak is limited. Nonetheless this also implies controlling DAMON with a feature that requires the setup-failed sysfs files will be impossible until the system reboots. Also, the setup operations are quite simple. The certain failures would hence only rarely happen, and are difficult to artificially trigger. This patch (of 4): When attrs/ DAMON sysfs directory setup is failed after setup of intervals/ directory, intervals/intervals_goal/ directory is not cleaned up. As a result, DAMON sysfs interface is nearly broken until the system reboots, and the memory for the unremoved directory is leaked. Cleanup the directory under such failures. Link: https://lkml.kernel.org/r/20251225023043.18579-1-sj@kernel.org Link: https://lkml.kernel.org/r/20251225023043.18579-2-sj@kernel.org Fixes: 8fbbcbeaafeb ("mm/damon/sysfs: implement intervals tuning goal directory") Signed-off-by: SeongJae Park <sj@kernel.org> Cc: chongjiapeng <jiapeng.chong@linux.alibaba.com> Cc: <stable@vger.kernel.org> # 6.15.x Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-14mm/damon/core: remove call_control in inactive contextsSeongJae Park
If damon_call() is executed against a DAMON context that is not running, the function returns error while keeping the damon_call_control object linked to the context's call_controls list. Let's suppose the object is deallocated after the damon_call(), and yet another damon_call() is executed against the same context. The function tries to add the new damon_call_control object to the call_controls list, which still has the pointer to the previous damon_call_control object, which is deallocated. As a result, use-after-free happens. This can actually be triggered using the DAMON sysfs interface. It is not easily exploitable since it requires the sysfs write permission and making a definitely weird file writes, though. Please refer to the report for more details about the issue reproduction steps. Fix the issue by making two changes. Firstly, move the final kdamond_call() for cancelling all existing damon_call() requests from terminating DAMON context to be done before the ctx->kdamond reset. This makes any code that sees NULL ctx->kdamond can safely assume the context may not access damon_call() requests anymore. Secondly, let damon_call() to cleanup the damon_call_control objects that were added to the already-terminated DAMON context, before returning the error. Link: https://lkml.kernel.org/r/20251231012315.75835-1-sj@kernel.org Fixes: 004ded6bee11 ("mm/damon: accept parallel damon_call() requests") Signed-off-by: SeongJae Park <sj@kernel.org> Reported-by: JaeJoon Jung <rgbi3307@gmail.com> Closes: https://lore.kernel.org/20251224094401.20384-1-rgbi3307@gmail.com Cc: <stable@vger.kernel.org> # 6.17.x Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-14powerpc/watchdog: add support for hardlockup_sys_info sysctlFeng Tang
Commit a9af76a78760 ("watchdog: add sys_info sysctls to dump sys info on system lockup") adds 'hardlock_sys_info' systcl knob for general kernel watchdog to control what kinds of system debug info to be dumped on hardlockup. Add similar support in powerpc watchdog code to make the sysctl knob more general, which also fixes a compiling warning in general watchdog code reported by 0day bot. Link: https://lkml.kernel.org/r/20251231080309.39642-1-feng.tang@linux.alibaba.com Fixes: a9af76a78760 ("watchdog: add sys_info sysctls to dump sys info on system lockup") Signed-off-by: Feng Tang <feng.tang@linux.alibaba.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202512030920.NFKtekA7-lkp@intel.com/ Suggested-by: Petr Mladek <pmladek@suse.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Cc: Madhavan Srinivasan <maddy@linux.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-14mips: fix HIGHMEM initializationMike Rapoport (Microsoft)
Commit 6faea3422e3b ("arch, mm: streamline HIGHMEM freeing") overzealously removed mem_init_free_highmem() function that beside freeing high memory pages checked for CPU support for high memory as a prerequisite. Partially restore mem_init_free_highmem() with a new highmem_init() name and make it discard high memory in case there is no CPU support for it. Link: https://lkml.kernel.org/r/20251231105701.519711-1-rppt@kernel.org Fixes: 6faea3422e3b ("arch, mm: streamline HIGHMEM freeing") Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Reported-by: Markus Stockhausen <markus.stockhausen@gmx.de> Cc: Chris Packham <chris.packham@alliedtelesis.co.nz> Cc: Hauke Mehrtens <hauke@hauke-m.de> Cc: Jonas Jelonek <jelonek.jonas@gmail.com> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Thomas Gleinxer <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-14mm/hugetlb: ignore hugepage kernel args if hugepages are unsupportedSourabh Jain
Skip processing hugepage kernel arguments (hugepagesz, hugepages, and default_hugepagesz) when hugepages are not supported by the architecture. Some architectures may need to disable hugepages based on conditions discovered during kernel boot. The hugepages_supported() helper allows architecture code to advertise whether hugepages are supported. Currently, normal hugepage allocation is guarded by hugepages_supported(), but gigantic hugepages are allocated regardless of this check. This causes problems on powerpc for fadump (firmware- assisted dump). In the fadump (firmware-assisted dump) scenario, a production kernel crash causes the system to boot into a special kernel whose sole purpose is to collect the memory dump and reboot. Features such as hugepages are not required in this environment and should be disabled. For example, when the fadump kernel boots with the following kernel arguments: default_hugepagesz=1GB hugepagesz=1GB hugepages=200 Before this patch, the kernel prints the following logs: HugeTLB: allocating 200 of page size 1.00 GiB failed. Only allocated 58 hugepages. HugeTLB support is disabled! HugeTLB: huge pages not supported, ignoring associated command-line parameters hugetlbfs: disabling because there are no supported hugepage sizes Even though the logs state that HugeTLB support is disabled, gigantic hugepages are still allocated. This causes the fadump kernel to run out of memory during boot. After this patch is applied, the kernel prints the following logs for the same command line: HugeTLB: hugepages unsupported, ignoring default_hugepagesz=1GB cmdline HugeTLB: hugepages unsupported, ignoring hugepagesz=1GB cmdline HugeTLB: hugepages unsupported, ignoring hugepages=200 cmdline HugeTLB support is disabled! hugetlbfs: disabling because there are no supported hugepage sizes To fix the issue, gigantic hugepage allocation should be guarded by hugepages_supported(). Previously, two approaches were proposed to bring gigantic hugepage allocation under hugepages_supported(): [1] Check hugepages_supported() in the generic code before allocating gigantic hugepages [2] Make arch_hugetlb_valid_size() return false for all hugetlb sizes Approach [2] has two minor issues: 1. It prints misleading logs about invalid hugepage sizes 2. The kernel still processes hugepage kernel arguments unnecessarily To control gigantic hugepage allocation, skip processing hugepage kernel arguments (default_hugepagesz, hugepagesz and hugepages) when hugepages_supported() returns false. Note for backporting: This fix is a partial reversion of the commit mentioned in the Fixes tag and is only valid once the change referenced by the Depends-on tag is present. When backporting this patch, the commit mentioned in the Depends-on tag must be included first. Link: https://lore.kernel.org/all/20250121150419.1342794-1-sourabhjain@linux.ibm.com/ [1] Link: https://lore.kernel.org/all/20250128043358.163372-1-sourabhjain@linux.ibm.com/ [2] Link: https://lkml.kernel.org/r/20251224115524.1272010-1-sourabhjain@linux.ibm.com Fixes: c2833a5bf75b ("hugetlbfs: fix changes to command line processing") Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com> Depends-on: 2354ad252b66 ("powerpc/mm: Update default hugetlb size early") Acked-by: David Hildenbrand (Red Hat) <david@kernel.org> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Madhavan Srinivasan <maddy@linux.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Muchun Song <muchun.song@linux.dev> Cc: Oscar Salvador <osalvador@suse.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-14mm/page_alloc: make percpu_pagelist_high_fraction reads lock-freeAboorva Devarajan
When page isolation loops indefinitely during memory offline, reading /proc/sys/vm/percpu_pagelist_high_fraction blocks on pcp_batch_high_lock, causing hung task warnings. Make procfs reads lock-free since percpu_pagelist_high_fraction is a simple integer with naturally atomic reads, writers still serialize via the mutex. This prevents hung task warnings when reading the procfs file during long-running memory offline operations. [akpm@linux-foundation.org: add comment, per Michal] Link: https://lkml.kernel.org/r/aS_y9AuJQFydLEXo@tiehlicka Link: https://lkml.kernel.org/r/20251201060009.1420792-1-aboorvad@linux.ibm.com Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com> Acked-by: Michal Hocko <mhocko@suse.com> Cc: Brendan Jackman <jackmanb@google.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Zi Yan <ziy@nvidia.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-14mm/damon/core: get memcg reference before accessShakeel Butt
The commit b74a120bcf507 ("mm/damon/core: implement DAMOS_QUOTA_NODE_MEMCG_USED_BP") added accesses to memcg structure without getting reference to it. This is unsafe. Let's get the reference before accessing the memcg. Link: https://lkml.kernel.org/r/20251225002904.139543-1-shakeel.butt@linux.dev Fixes: b74a120bcf507 ("mm/damon/core: implement DAMOS_QUOTA_NODE_MEMCG_USED_BP") Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev> Reviewed-by: SeongJae Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-14kho: validate preserved memory map during populationPasha Tatashin
If the previous kernel enabled KHO but did not call kho_finalize() (e.g., CONFIG_LIVEUPDATE=n or userspace skipped the finalization step), the 'preserved-memory-map' property in the FDT remains empty/zero. Previously, kho_populate() would succeed regardless of the memory map's state, reserving the incoming scratch regions in memblock. However, kho_memory_init() would later fail to deserialize the empty map. By that time, the scratch regions were already registered, leading to partial initialization and subsequent list corruption (freeing scratch area twice) during kho_init(). Move the validation of the preserved memory map earlier into kho_populate(). If the memory map is empty/NULL: 1. Abort kho_populate() immediately with -ENOENT. 2. Do not register or reserve the incoming scratch memory, allowing the new kernel to reclaim those pages as standard free memory. 3. Leave the global 'kho_in' state uninitialized. Consequently, kho_memory_init() sees no active KHO context (kho_in.mem_chunks_phys is 0) and falls back to kho_reserve_scratch(), allocating fresh scratch memory as if it were a standard cold boot. Link: https://lkml.kernel.org/r/20251223140140.2090337-1-pasha.tatashin@soleen.com Fixes: de51999e687c ("kho: allow memory preservation state updates after finalization") Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com> Reported-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Closes: https://lore.kernel.org/all/20251218215613.GA17304@ranerica-svr.sc.intel.com Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Tested-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Reviewed-by: Pratyush Yadav <pratyush@kernel.org> Cc: Alexander Graf <graf@amazon.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-14lib/buildid: use __kernel_read() for sleepable contextShakeel Butt
Prevent a "BUG: unable to handle kernel NULL pointer dereference in filemap_read_folio". For the sleepable context, convert freader to use __kernel_read() instead of direct page cache access via read_cache_folio(). This simplifies the faultable code path by using the standard kernel file reading interface which handles all the complexity of reading file data. At the moment we are not changing the code for non-sleepable context which uses filemap_get_folio() and only succeeds if the target folios are already in memory and up-to-date. The reason is to keep the patch simple and easier to backport to stable kernels. Syzbot repro does not crash the kernel anymore and the selftests run successfully. In the follow up we will make __kernel_read() with IOCB_NOWAIT work for non-sleepable contexts. In addition, I would like to replace the secretmem check with a more generic approach and will add fstest for the buildid code. Link: https://lkml.kernel.org/r/20251222205859.3968077-1-shakeel.butt@linux.dev Fixes: ad41251c290d ("lib/buildid: implement sleepable build_id_parse() API") Reported-by: syzbot+09b7d050e4806540153d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=09b7d050e4806540153d Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev> Reviewed-by: Christoph Hellwig <hch@lst.de> Tested-by: Jinchao Wang <wangjinchao600@gmail.com> Link: https://lkml.kernel.org/r/aUteBPWPYzVWIZFH@ndev Reviewed-by: Christian Brauner <brauner@kernel.org> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Andrii Nakryiko <andrii@kernel.org> Cc: Daniel Borkman <daniel@iogearbox.net> Cc: "Darrick J. Wong" <djwong@kernel.org> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-14docs: kernel-parameters: add kfence parametersMarco Elver
Add a brief summary for KFENCE's kernel command-line parameters in admin-guide/kernel-parameters. Link: https://lkml.kernel.org/r/20251222150018.1349672-1-elver@google.com Signed-off-by: Marco Elver <elver@google.com> Cc: Alexander Potapenko <glider@google.com> Cc: Dmitriy Vyukov <dvyukov@google.com> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-14mailmap: update email address for Szymon WilczekSzymon Wilczek
Map my old address <szymonwilczek@gmx.com> to my new address <swilczek.lx@gmail.com>. The old account is no longer accessible due to provider blocking access. Link: https://lkml.kernel.org/r/20251221151710.13747-1-swilczek.lx@gmail.com Signed-off-by: Szymon Wilczek <swilczek.lx@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-14mm, kfence: describe @slab parameter in __kfence_obj_info()Bagas Sanjaya
Sphinx reports kernel-doc warning: WARNING: ./include/linux/kfence.h:220 function parameter 'slab' not described in '__kfence_obj_info' Fix it by describing @slab parameter. Link: https://lkml.kernel.org/r/20251219014006.16328-6-bagasdotme@gmail.com Fixes: 2dfe63e61cc3 ("mm, kfence: support kmem_dump_obj() for KFENCE objects") Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Acked-by: Marco Elver <elver@google.com> Acked-by: David Hildenbrand (Red Hat) <david@kernel.org> Acked-by: Harry Yoo <harry.yoo@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-14mm: vmalloc: fix up vrealloc_node_align() kernel-doc macro nameBagas Sanjaya
Sphinx reports kernel-doc warning: WARNING: ./mm/vmalloc.c:4284 expecting prototype for vrealloc_node_align_noprof(). Prototype was for vrealloc_node_align() instead Fix the macro name in vrealloc_node_align_noprof() kernel-doc comment. Link: https://lkml.kernel.org/r/20251219014006.16328-5-bagasdotme@gmail.com Fixes: 4c5d3365882d ("mm/vmalloc: allow to set node and align in vrealloc") Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Reviewed-by: Vishal Moola (Oracle) <vishal.moola@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-14textsearch: describe @list member in ts_ops searchBagas Sanjaya
Sphinx reports kernel-doc warning: WARNING: ./include/linux/textsearch.h:49 struct member 'list' not described in 'ts_ops' Describe @list member to fix it. Link: https://lkml.kernel.org/r/20251219014006.16328-4-bagasdotme@gmail.com Fixes: 2de4ff7bd658 ("[LIB]: Textsearch infrastructure.") Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Cc: Thomas Graf <tgraf@suug.ch> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-14mm: describe @flags parameter in memalloc_flags_save()Bagas Sanjaya
Patch series "mm kernel-doc fixes". Here are kernel-doc fixes for mm subsystem. I'm also including textsearch fix since there's currently no maintainer for include/linux/textsearch.h (get_maintainer.pl only shows LKML). This patch (of 4): Sphinx reports kernel-doc warning: WARNING: ./include/linux/sched/mm.h:332 function parameter 'flags' not described in 'memalloc_flags_save' Describe @flags to fix it. Link: https://lkml.kernel.org/r/20251219014006.16328-2-bagasdotme@gmail.com Link: https://lkml.kernel.org/r/20251219014006.16328-3-bagasdotme@gmail.com Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Fixes: 3f6d5e6a468d ("mm: introduce memalloc_flags_{save,restore}") Acked-by: David Hildenbrand (Red Hat) <david@kernel.org> Acked-by: Harry Yoo <harry.yoo@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-14io_uring/uring_cmd: explicitly disallow cancelations for IOPOLLJens Axboe
This currently isn't supported, and due to a recent commit, it also cannot easily be supported by io_uring due to hash_node and IOPOLL completion data overlapping. This can be revisited if we ever do support cancelations of requests that have gone to the block stack. Suggested-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-01-14io_uring: fix IOPOLL with passthrough I/OJens Axboe
A previous commit improving IOPOLL made an incorrect assumption that task_work isn't used with IOPOLL. This can cause crashes when doing passthrough I/O on nvme, where queueing the completion task_work will trample on the same memory that holds the completed list of requests. Fix it up by shuffling the members around, so we're not sharing any parts that end up getting used in this path. Fixes: 3c7d76d6128a ("io_uring: IOPOLL polling improvements") Reported-by: Yi Zhang <yi.zhang@redhat.com> Link: https://lore.kernel.org/linux-block/CAHj4cs_SLPj9v9w5MgfzHKy+983enPx3ZQY2kMuMJ1202DBefw@mail.gmail.com/ Tested-by: Yi Zhang <yi.zhang@redhat.com> Cc: Ming Lei <ming.lei@redhat.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-01-15ntfs3: Refactor duplicate kmemdup pattern in do_action()Baolin Liu
Extract the repeated pattern of duplicating attribute and updating OpenAttr into a helper function to reduce code duplication and improve maintainability. Signed-off-by: Baolin Liu <liubaolin@kylinos.cn> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-01-15fs/ntfs3: prevent infinite loops caused by the next valid being the sameEdward Adam Davis
When processing valid within the range [valid : pos), if valid cannot be retrieved correctly, for example, if the retrieved valid value is always the same, this can trigger a potential infinite loop, similar to the hung problem reported by syzbot [1]. Adding a check for the valid value within the loop body, and terminating the loop and returning -EINVAL if the value is the same as the current value, can prevent this. [1] INFO: task syz.4.21:6056 blocked for more than 143 seconds. Call Trace: rwbase_write_lock+0x14f/0x750 kernel/locking/rwbase_rt.c:244 inode_lock include/linux/fs.h:1027 [inline] ntfs_file_write_iter+0xe6/0x870 fs/ntfs3/file.c:1284 Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Reported-by: syzbot+bcf9e1868c1a0c7e04f1@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=bcf9e1868c1a0c7e04f1 Signed-off-by: Edward Adam Davis <eadavis@qq.com> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-01-15fs/ntfs3: make ntfs_writeback_ops staticsunliming
Fix below sparse warnings: fs/ntfs3/inode.c:972:34: sparse: sparse: symbol 'ntfs_writeback_ops' was not declared. Should it be static? Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202601061424.nbKLNwC5-lkp@intel.com/ Signed-off-by: sunliming <sunliming@kylinos.cn> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-01-15ntfs3: fix circular locking dependency in run_unpack_exSzymon Wilczek
Syzbot reported a circular locking dependency between wnd->rw_lock (sbi->used.bitmap) and ni->file.run_lock. The deadlock scenario: 1. ntfs_extend_mft() takes ni->file.run_lock then wnd->rw_lock. 2. run_unpack_ex() takes wnd->rw_lock then tries to acquire ni->file.run_lock inside ntfs_refresh_zone(). This creates an AB-BA deadlock. Fix this by using down_read_trylock() instead of down_read() when acquiring run_lock in run_unpack_ex(). If the lock is contended, skip ntfs_refresh_zone() - the MFT zone will be refreshed on the next MFT operation. This breaks the circular dependency since we never block waiting for run_lock while holding wnd->rw_lock. Reported-by: syzbot+d27edf9f96ae85939222@syzkaller.appspotmail.com Tested-by: syzbot+d27edf9f96ae85939222@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d27edf9f96ae85939222 Signed-off-by: Szymon Wilczek <swilczek.lx@gmail.com> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-01-15Merge tag 'amd-drm-next-6.20-2026-01-09' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.20-2026-01-09: amdgpu: - GPUVM updates - Initial support for larger GPU address spaces - Initial SMUIO 15.x support - Documentation updates - Initial PSP 15.x support - Initial IH 7.1 support - Initial IH 6.1.1 support - SMU 13.0.12 updates - RAS updates - Initial MMHUB 3.4 support - Initial MMHUB 4.2 support - Initial GC 12.1 support - Initial GC 11.5.4 support - HDMI fixes - Panel replay improvements - DML updates - DC FP fixes - Initial SDMA 6.1.4 support - Initial SDMA 7.1 support - Userq updates - DC HPD refactor - SwSMU cleanups and refactoring - TTM memory ops parallelization - DCN 3.5 fixes - DP audio fixes - Clang fixes - Misc spelling fixes and cleanups - Initial SDMA 7.11.4 support - Convert legacy DRM logging helpers to new drm logging helpers - Initial JPEG 5.3 support - Add support for changing UMA size via the driver - DC analog fixes - GC 9 gfx queue reset support - Initial SMU 15.x support amdkfd: - Reserved SDMA rework - Refactor SPM - Initial GC 12.1 support - Initial GC 11.5.4 support - Initial SDMA 7.1 support - Initial SDMA 6.1.4 support - Increase the kfd process hash table - Per context support - Topology fixes radeon: - Convert legacy DRM logging helpers to new drm logging helpers - Use devm for i2c adapters - Variable sized array fix - Misc cleanups UAPI: - KFD context support. Proposed userspace: https://github.com/ROCm/rocm-systems/pull/1705 https://github.com/ROCm/rocm-systems/pull/1701 - Add userq metadata queries for more queue types. Proposed userspace: https://gitlab.freedesktop.org/yogeshmohan/mesa/-/commits/userq_query From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260109154713.3242957-1-alexander.deucher@amd.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-01-14fortify: Cleanup temp file also on non-successful exitNicolas Schier
Ensure cleanup of test_fortify.sh's temporary file also on script interruption, or some common signals. Reported-by: WangYuli <wangyuli@aosc.io> Closes: https://lore.kernel.org/linux-kbuild/20251112114725.287349-1-wangyuli@aosc.io/ Reviewed-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: WangYuli <wangyuli@aosc.io> Signed-off-by: Nicolas Schier <nsc@kernel.org> Link: https://patch.msgid.link/20260114-fortify-improve-handling-of-tempfile-v2-2-63b86c4dbd0e@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2026-01-14fortify: Rename temporary file to match ignore patternNicolas Schier
test_fortify.sh uses a temporary file that might appear as untracked file in some rare sitations. Rename it to match one of top-level's gitignore patterns. Reported-by: WangYuli <wangyuli@aosc.io> Closes: https://lore.kernel.org/linux-kbuild/20251112114725.287349-1-wangyuli@aosc.io/ Reviewed-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: WangYuli <wangyuli@aosc.io> Signed-off-by: Nicolas Schier <nsc@kernel.org> Link: https://patch.msgid.link/20260114-fortify-improve-handling-of-tempfile-v2-1-63b86c4dbd0e@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2026-01-14fortify: Use C arithmetic not FIELD_xxx() in FORTIFY_REASON definesDavid Laight
FIELD_GET() and FIELD_PREP() are mainly useful for hardware register accesses, but here they are being used for some very simple oprations. This wouldn't matter much, but they contain a lot of compile-time checks (that really aren't needed here) that bloat the expansion of FIELD_GET(GENMASK(7, 1), func) to over 18KB. Even with the 'bloat reduced' FIELD_GET/PREP they are still hundreds of characters. Replace FIELD_GET(BIT(0), r) with ((r) & 1), FIELD_GET(GENMASK(7, 1), r) with (r) >> 1), and (FIELD_PREP(BIT(0), write) | FIELD_PREP(GENMASK(7, 1), func)) with ((func) << 1 | (write)). The generated code is the same, but it makes the .c file less obfuctaced, the .i file much easier to read, and should marginally decrease compilation time. Signed-off-by: David Laight <david.laight.linux@gmail.com> Link: https://patch.msgid.link/20251214125857.3308-1-david.laight.linux@gmail.com Signed-off-by: Kees Cook <kees@kernel.org>
2026-01-14Merge branch 'bpf-live-registers-computation-with-gotox'Alexei Starovoitov
Anton Protopopov says: ==================== bpf: Live registers computation with gotox While adding a selftest for live registers computation with gotox, I've noticed that the code is actually incomplete. Namely, the destination register rX in `gotox rX` wasn't actually considered as used. Fix this and add a selftest. v1 -> v2: * only enable the new selftest on x86 and arm64 v1: https://lore.kernel.org/bpf/20260114113314.32649-1-a.s.protopopov@gmail.com/T/#t ==================== Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://patch.msgid.link/20260114162544.83253-1-a.s.protopopov@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-14selftests/bpf: Extend live regs tests with a test for gotoxAnton Protopopov
Add a test which checks that the destination register of a gotox instruction is marked as used and that the union of jump targets is considered as live. Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com> Link: https://lore.kernel.org/r/20260114162544.83253-3-a.s.protopopov@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-14bpf: Properly mark live registers for indirect jumpsAnton Protopopov
For a `gotox rX` instruction the rX register should be marked as used in the compute_insn_live_regs() function. Fix this. Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com> Link: https://lore.kernel.org/r/20260114162544.83253-2-a.s.protopopov@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-14clk: thead: th1520-ap: Support CPU frequency scalingYao Zi
On TH1520 SoC, c910_clk feeds the CPU cluster. It could be glitchlessly reparented to one of the two PLLs: either to cpu_pll0 indirectly through c910_i0_clk, or to cpu_pll1 directly. To achieve glitchless rate change, customized clock operations are implemented for c910_clk: on rate change, the PLL not currently in use is configured to the requested rate first, then c910_clk reparents to it. Additionally, c910_bus_clk, which in turn takes c910_clk as parent, has a frequency limit of 750MHz. A clock notifier is registered on c910_clk to adjust c910_bus_clk on c910_clk rate change. Reviewed-by: Drew Fustini <fustini@kernel.org> Signed-off-by: Yao Zi <ziyao@disroot.org> Signed-off-by: Drew Fustini <fustini@kernel.org>
2026-01-15wifi: rtw89: pci: consider RTL8922D in PCI common flowPing-Ke Shih
Clear TX/RX ring index, PCI operating mode, SER setting, PCI LTR and preinit settings. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260110022019.2254969-9-pkshih@realtek.com
2026-01-15wifi: rtw89: mac: consider RTL8922D in MAC common flowPing-Ke Shih
The MAC settings are different from RTL8922A to RTL8922D, including scheduler, DLE, DCPU, MLO, NAV, TMAC, TX/RX protocol, RMAC, IMR, host RPT, AMSDU. Update them accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260110022019.2254969-8-pkshih@realtek.com
2026-01-15wifi: rtw89: mac: correct page number for CSI responsePing-Ke Shih
For beamforming procedure, hardware reserve memory page for CSI response. The unit of register is (value - 1), so add one accordingly as expected. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260110022019.2254969-7-pkshih@realtek.com
2026-01-15wifi: rtw89: align CUSTID defined by firmwarePing-Ke Shih
Firmware does customized features by CUSTID, so align the ID definition to have expected features enabled. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260110022019.2254969-6-pkshih@realtek.com
2026-01-15wifi: rtw89: disable EHT protocol by chip capabilitiesPing-Ke Shih
For certain chip models, EHT protocol is disabled, and driver must follow the capabilities. Otherwise, chips become unusable. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260110022019.2254969-5-pkshih@realtek.com
2026-01-15wifi: rtw89: support EHT GI/LTF settingKuan-Chung Chen
Add support for fixed EHT GI/LTF via nl80211. The command example: iw wlan0 set bitrates eht-gi-6 0.8 eht-ltf-6 2 Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260110022019.2254969-4-pkshih@realtek.com
2026-01-15wifi: rtw89: wow: add reason codes for disassociation in WoWLAN modeChin-Yen Lee
Some APs disconnect clients by sending a Disassociation frame rather than a Deauthentication frame. Since these frames use different reason codes in WoWLAN mode, this commit adds support for handling Disassociation to prevent missed disconnection events. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260110022019.2254969-3-pkshih@realtek.com
2026-01-15wifi: rtw89: pci: validate sequence number of TX release reportPing-Ke Shih
Hardware rarely reports abnormal sequence number in TX release report, which will access out-of-bounds of wd_ring->pages array, causing NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 1085 Comm: irq/129-rtw89_p Tainted: G S U 6.1.145-17510-g2f3369c91536 #1 (HASH:69e8 1) Call Trace: <IRQ> rtw89_pci_release_tx+0x18f/0x300 [rtw89_pci (HASH:4c83 2)] rtw89_pci_napi_poll+0xc2/0x190 [rtw89_pci (HASH:4c83 2)] net_rx_action+0xfc/0x460 net/core/dev.c:6578 net/core/dev.c:6645 net/core/dev.c:6759 handle_softirqs+0xbe/0x290 kernel/softirq.c:601 ? rtw89_pci_interrupt_threadfn+0xc5/0x350 [rtw89_pci (HASH:4c83 2)] __local_bh_enable_ip+0xeb/0x120 kernel/softirq.c:499 kernel/softirq.c:423 </IRQ> <TASK> rtw89_pci_interrupt_threadfn+0xf8/0x350 [rtw89_pci (HASH:4c83 2)] ? irq_thread+0xa7/0x340 kernel/irq/manage.c:0 irq_thread+0x177/0x340 kernel/irq/manage.c:1205 kernel/irq/manage.c:1314 ? thaw_kernel_threads+0xb0/0xb0 kernel/irq/manage.c:1202 ? irq_forced_thread_fn+0x80/0x80 kernel/irq/manage.c:1220 kthread+0xea/0x110 kernel/kthread.c:376 ? synchronize_irq+0x1a0/0x1a0 kernel/irq/manage.c:1287 ? kthread_associate_blkcg+0x80/0x80 kernel/kthread.c:331 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> To prevent crash, validate rpp_info.seq before using. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260110022019.2254969-2-pkshih@realtek.com
2026-01-14riscv: suspend: Fix stimecmp update hazard on RV32Naohiko Shimizu
On RV32, updating the 64-bit stimecmp (or vstimecmp) CSR requires two separate 32-bit writes. A race condition exists if the timer triggers during these two writes. The RISC-V Privileged Specification (e.g., Section 3.2.1 for mtimecmp) recommends a specific 3-step sequence to avoid spurious interrupts when updating 64-bit comparison registers on 32-bit systems: 1. Set the low-order bits (stimecmp) to all ones (ULONG_MAX). 2. Set the high-order bits (stimecmph) to the desired value. 3. Set the low-order bits (stimecmp) to the desired value. Current implementation writes the LSB first without ensuring a future value, which may lead to a transient state where the 64-bit comparison is incorrectly evaluated as "expired" by the hardware. This results in spurious timer interrupts. This patch adopts the spec-recommended 3-step sequence to ensure the intermediate 64-bit state is never smaller than the current time. Fixes: ffef54ad4110 ("riscv: Add stimecmp save and restore") Signed-off-by: Naohiko Shimizu <naohiko.shimizu@gmail.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://patch.msgid.link/20260104135938.524-4-naohiko.shimizu@gmail.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-14riscv: kvm: Fix vstimecmp update hazard on RV32Naohiko Shimizu
On RV32, updating the 64-bit stimecmp (or vstimecmp) CSR requires two separate 32-bit writes. A race condition exists if the timer triggers during these two writes. The RISC-V Privileged Specification (e.g., Section 3.2.1 for mtimecmp) recommends a specific 3-step sequence to avoid spurious interrupts when updating 64-bit comparison registers on 32-bit systems: 1. Set the low-order bits (stimecmp) to all ones (ULONG_MAX). 2. Set the high-order bits (stimecmph) to the desired value. 3. Set the low-order bits (stimecmp) to the desired value. Current implementation writes the LSB first without ensuring a future value, which may lead to a transient state where the 64-bit comparison is incorrectly evaluated as "expired" by the hardware. This results in spurious timer interrupts. This patch adopts the spec-recommended 3-step sequence to ensure the intermediate 64-bit state is never smaller than the current time. Fixes: 8f5cb44b1bae ("RISC-V: KVM: Support sstc extension") Signed-off-by: Naohiko Shimizu <naohiko.shimizu@gmail.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://patch.msgid.link/20260104135938.524-3-naohiko.shimizu@gmail.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-14riscv: clocksource: Fix stimecmp update hazard on RV32Naohiko Shimizu
On RV32, updating the 64-bit stimecmp (or vstimecmp) CSR requires two separate 32-bit writes. A race condition exists if the timer triggers during these two writes. The RISC-V Privileged Specification (e.g., Section 3.2.1 for mtimecmp) recommends a specific 3-step sequence to avoid spurious interrupts when updating 64-bit comparison registers on 32-bit systems: 1. Set the low-order bits (stimecmp) to all ones (ULONG_MAX). 2. Set the high-order bits (stimecmph) to the desired value. 3. Set the low-order bits (stimecmp) to the desired value. Current implementation writes the LSB first without ensuring a future value, which may lead to a transient state where the 64-bit comparison is incorrectly evaluated as "expired" by the hardware. This results in spurious timer interrupts. This patch adopts the spec-recommended 3-step sequence to ensure the intermediate 64-bit state is never smaller than the current time. Fixes: 9f7a8ff6391f ("RISC-V: Prefer sstc extension if available") Signed-off-by: Naohiko Shimizu <naohiko.shimizu@gmail.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://patch.msgid.link/20260104135938.524-2-naohiko.shimizu@gmail.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-15riscv: dts: sophgo: enable hardware clock (RTC) on the Milk-V PioneerMichael Orlitzky
These boards have a working hardware clock if you put a CR-1220 battery in them. We enable it using information from a 6.1.x vendor kernel. Reviewed-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Michael Orlitzky <michael@orlitzky.com> Link: https://lore.kernel.org/r/20260107112922.20013-2-michael@orlitzky.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2026-01-15rust: auxiliary: add Driver::unbind() callbackDanilo Krummrich
Add missing unbind() callback to auxiliary::Driver, since it will be needed by drivers eventually (e.g. the Nova DRM driver). Acked-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260107103511.570525-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-15rust: i2c: do not drop device private data on shutdown()Danilo Krummrich
We must not drop the device private data on shutdown(); none of the registrations attached to devres that might access the device private data are released before shutdown() is called. Hence, freeing the device private data on shutdown() can cause UAF bugs. Fixes: 57c5bd9aee94 ("rust: i2c: add basic I2C device and driver abstractions") Acked-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Igor Korotin <igor.korotin.linux@gmail.com> Link: https://patch.msgid.link/20260107103511.570525-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-14Documentation: riscv: uabi: Clarify ISA spec version for canonical orderGuodong Xu
Specify that chapter 27 refers to version 20191213 of the RISC-V ISA Unprivileged Architecture. The chapter numbering differs across specification versions - for example, in version 20250508, the ISA Extension Naming Conventions is chapter 36, not chapter 27. Historical versions of the RISC-V specification can be found via Link [1]. Acked-by: Paul Walmsley <pjw@kernel.org> Link: https://riscv.org/specifications/ratified/ [1] Fixes: f07b2b3f9d47 ("Documentation: riscv: add a section about ISA string ordering in /proc/cpuinfo") Signed-off-by: Guodong Xu <guodong@riscstar.com> Link: https://patch.msgid.link/20260115-adding-b-dtsi-v2-1-254dd61cf947@riscstar.com
2026-01-14Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf after rc5Alexei Starovoitov
Cross-merge BPF and other fixes after downstream PR. No conflicts. Adjacent: Auto-merging MAINTAINERS Auto-merging Makefile Auto-merging kernel/bpf/verifier.c Auto-merging kernel/sched/ext.c Auto-merging mm/memcontrol.c Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-15i2c: spacemit: drop useless spacesTroy Mitchell
Previously, the I2C driver had an extra leading space in column 0 of included header lines. This commit removes the redundant whitespace. Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Reviewed-by: Alex Elder <elder@riscstar.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20251226-k1-i2c-ilcr-v5-1-b5807b7dd0e6@linux.spacemit.com
2026-01-14ecryptfs: Annotate struct ecryptfs_message with __counted_byThorsten Blum
Add the __counted_by() compiler attribute to the flexible array member 'data' to improve access bounds-checking via CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Acked-by: Tyler Hicks <code@tyhicks.com> Link: https://patch.msgid.link/20260112115314.739612-2-thorsten.blum@linux.dev Signed-off-by: Kees Cook <kees@kernel.org>
2026-01-14fs/xattr: Annotate struct simple_xattr with __counted_byThorsten Blum
Add the __counted_by() compiler attribute to the flexible array member 'value' to improve access bounds-checking via CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE. Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20260105122057.2347-2-thorsten.blum@linux.dev Signed-off-by: Kees Cook <kees@kernel.org>
2026-01-14crypto: af_alg - Annotate struct af_alg_iv with __counted_byThorsten Blum
Add the __counted_by() compiler attribute to the flexible array member 'iv' to improve access bounds-checking via CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE. Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20260105122402.2685-2-thorsten.blum@linux.dev Signed-off-by: Kees Cook <kees@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-29 09:17:12 +0000