summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
2026-07-30mm/damon: document region size validation in damon_set_regions()SJ Park
The kernel doc comment of damon_region clearly specifies every region should have positive size. But it is unclear who should verify it. damon_set_regions() is the recommended DAMON core function for setting regions from the callers, and has the verification. Update the comment to clarify the callers should be ok to pass any values for region addresses, as long as they use damon_set_regions(). Link: https://lore.kernel.org/20260705155600.96555-7-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/rmap: use huge_ptep_get() in try_to_unmap_one()Dev Jain
Patch series "Fix incorrect access of hugetlb pte entries", v3. There are various places which use ptep_get() to get the pte entry corresponding to a hugetlb folio. Some arches (like s390) have special handling to compute the pteval, so they provide huge_ptep_get(). Use this helper consistently. Additionally, some code paths may provide huge_ptep_get with an unaligned address. This is a problem on arm64 (I checked other arches and it looks fine for them), which is fixed in patch 1. The fix is made to be backport-friendly: the cleaner fix would be to perhaps pass the hstate to huge_ptep_get() - that is wider churn and we can do that later. This patch (of 5): try_to_unmap_one() handles hugetlb folios when memory failure needs to replace a poisoned hugetlb mapping with a hwpoison entry. In that case page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads it with ptep_get(). On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave. It is not clear whether this has a trivially visible effect to userspace. Just use huge_ptep_get() for dereferencing a huge pte pointer. Link: https://lore.kernel.org/20260703114202.365553-1-dev.jain@arm.com Link: https://lore.kernel.org/20260703114202.365553-3-dev.jain@arm.com Fixes: c7ab0d2fdc84 ("mm: convert try_to_unmap_one() to use page_vma_mapped_walk()") Signed-off-by: Dev Jain <dev.jain@arm.com> Reported-by: David Hildenbrand <david@kernel.org> Reviewed-by: Muchun Song <muchun.song@linux.dev> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Alistair Popple <apopple@nvidia.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Byungchul Park <byungchul@sk.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Gregory Price <gourry@gourry.net> Cc: Harry Yoo <harry@kernel.org> Cc: "Huang, Ying" <ying.huang@linux.alibaba.com> Cc: Jann Horn <jannh@google.com> Cc: Josh Poimboeuf <jpoimboe@kernel.org> Cc: Joshua Hahn <joshua.hahnjy@gmail.com> Cc: Jun'ichi "Nick" Nomura <j-nomura@ce.jp.nec.com> Cc: Kiryl Shutsemau <kas@kernel.org> Cc: Lance Yang <lance.yang@linux.dev> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Naoya Horiguchi <nao.horiguchi@gmail.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Rakie Kim <rakie.kim@sk.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Rik van Riel <riel@surriel.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Will Deacon <will@kernel.org> Cc: Zi Yan <ziy@nvidia.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm: remove the __GFP_NO_OBJ_EXT flagVlastimil Babka (SUSE)
All users of the flag are converted to SLAB_ALLOC_NO_RECURSE or ALLOC_NO_CODETAG (from __GFP_NO_CODETAG which reused the NO_OBJ_EXT bit). Free up the flag bit. [Rebased onto __GFP_NO_CODETAG removal] Link: https://lore.kernel.org/20260703-alloc-trylock-v5-16-c87b714e19d3@google.com Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Signed-off-by: Brendan Jackman <jackmanb@google.com> Acked-by: Hao Ge <hao.ge@linux.dev> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm: replace __GFP_NO_CODETAG with ALLOC_NO_CODETAGBrendan Jackman
Now that alloc_pages has an entrypoint that allows passing alloc_flags, we can take advantage of this to start removing GFP flags that are only used for mm-internal stuff. This requires also plumbing the alloc_flags into some more of the allocator code, in particular __alloc_pages[_noprof]() gets an alloc_flags arg to go along with its callees, and we now need to pass those flags deeper into the allocator so they can reach the alloc_tag code. While moving the flag definition into page_alloc.h, also update the comment per Hao's suggestion. No functional change intended. Link: https://lore.kernel.org/all/b4916118-3537-4e19-8bc8-1d103dd0d225@linux.dev/ Link: https://lore.kernel.org/20260703-alloc-trylock-v5-15-c87b714e19d3@google.com Signed-off-by: Brendan Jackman <jackmanb@google.com> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Tested-by: Hao Ge <hao.ge@linux.dev> Acked-by: Hao Ge <hao.ge@linux.dev> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm: move __alloc_pages() to mm/page_alloc.hBrendan Jackman
It's no longer used outside of mm/. Since this means __alloc_pages_noprof() is no longer visible from gfp.h, this also means moving the definition of alloc_pages_node_noprof into the .c file. Also remove references to this API from the documentation tree - referring to the specific function name was already questionable but now the function is not even public it definitely seems wrong. Link: https://lore.kernel.org/20260703-alloc-trylock-v5-14-c87b714e19d3@google.com Signed-off-by: Brendan Jackman <jackmanb@google.com> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm: remove __alloc_pages_node()Brendan Jackman
There were only a few users, which have been removed. The only advantage of this API over alloc_pages_node() is avoiding a single conditional branch. The disadvantages are: 1. More API surface, more sources of confusion, more maintenance. 2. Worse impact of CPU hotplug bugs: most users of __alloc_pages_node() were using the result of cpu_to_node(); if the CPU gets hotplugged out this will return NUMA_NO_NODE. If one of these paths fails to protect against a concurrent hotplug then page_alloc.c will use NUMA_NO_NODE as an index into NODE_DATA() and cause some horrible memory corruption or other. With alloc_pages_node(), the code might just work fine. Ulterior motive: this frees up the __* variants of the allocator APIs to serve specifically for use as mm-internal API. Link: https://lore.kernel.org/20260703-alloc-trylock-v5-13-c87b714e19d3@google.com Signed-off-by: Brendan Jackman <jackmanb@google.com> Reviewed-by: Suren Baghdasaryan <surenb@google.com> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm: move some stuff to mm/page_alloc.hBrendan Jackman
Some of this stuff in the public header is only used internally so shrink the scope to avoid silently growing new users. drain_local_pages() is still used from kernel/power/snapshot.c so that needs to stay behind. Link: https://lore.kernel.org/20260703-alloc-trylock-v5-7-c87b714e19d3@google.com Signed-off-by: Brendan Jackman <jackmanb@google.com> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/page_alloc: some renames to clarify alloc_flags scopesBrendan Jackman
It's pretty confusing that: - The slowpath and fastpath have a totally distinct set of alloc_flags. - gfp_to_alloc_flags() sounds generic but it only influences the slowpath. Rename some variables to highlight which alloc_flags are fastpath-specific. Rename gfp_to_alloc_flags() to highlight that it's slowpath-specific. gfp_to_alloc_flags_cma() and gfp_to_alloc_flags_nonblocking() currently have perfectly harmless names, but to keep the naming consistent also rename those to the alloc_flags_*() pattern (which already exists for alloc_flags_nofragment()). Link: https://lore.kernel.org/20260703-alloc-trylock-v5-2-c87b714e19d3@google.com Signed-off-by: Brendan Jackman <jackmanb@google.com> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Acked-by: JP Kobryn <jp.kobryn@linux.dev> Reviewed-by: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/damon/core: introduce damon_probe_hits_mvsum()SJ Park
Implement a function for getting a reasonable best effort quality pseudo moving sums of probe_hits on demands. It reuses the internal function for the pseudo moving sum for data access frequency (nr_accesses). Link: https://lore.kernel.org/20260703170605.94472-3-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/damon: add damon_region->last_probe_hitsSJ Park
Patch series "mm/damon: provide pseudo moving sum probe_hits". Data attribute counters (probe_hits) of DAMON are managed in the classical way. The counter value is accumulated every sampling interval, gets the complete view at the end of the aggregation interval, and is reset when the next aggregation interval starts. Hence, the complete view can be retrieved only once per aggregation interval, which can be quite long. With the suggested intervals autotuning setup, it becomes 2-4 seconds in common real production systems. It can span up to 200 seconds in theory. This will restrict online monitoring use case of DAMON. Actually DAMON is already providing online monitoring of probe_hits. DAMON sysfs interface exposes the values via schemes tried regions directory files. However, due to the above mentioned limitation, it usually shows only partially accumulated hit counters and therefore not useful. DAMOS is not using probe_hits at the moment. In the future, using it can further strengthen DAMOS. However, a recommended setup of DAMOS is utilizing sampling/aggregation intervals auto-tuning, and having its own DAMOS apply_interval (1 second is mostly recommended). In the setup, DAMOS will nearly always show incompletely accumulated probe_hits, which will not really be useful. Data frequency counter (nr_accesses) of DAMON solves this problem using the pseudo moving sum value. The infrastructure is not limited to nr_accesses but general sampling based counters. Maintain and provide the pseudo moving sum of probe_hits similar to nr_accesses, using the infrastructure. Tests ===== On an idle system, I ran DAMON with an attribute probe filter for non-anonymous page, using DAMON user-space tool, damo [1], like below. $ sudo ./damo start --probe_filter allow non anon Because the system is idle, nearly all memory is not an anonymous page but a free page, so the probe_hits are expected to be nearly always full. In this setup, since the sampling interval is 5ms and the aggregation interval is 100ms, the counter value is expected to always be near 20. On kernels not having this series, if we retrieve the probe hits in an arbitrary time that is likely not aligned to the aggregation interval, the values are usually much lower than the expectation like below. This is because the tool is showing the incompletely aggregated values. $ sudo ./damo report access --format append region "probe_hits: <probe hits>" heatmap: 00000000000000000000000000000000000000008999999711111111000000000000000000000000 # min/max temperatures: -1,630,000,000, 0, column size: 99.800 MiB intervals: sample 5 ms aggr 100 ms (max access hz 200) 0 addr 4.000 KiB size 3.898 GiB access 0 hz age 16.300 s probe_hits: 11 1 addr 3.898 GiB size 77.859 MiB access 0 hz age 1.500 s probe_hits: 11 2 addr 3.974 GiB size 700.770 MiB access 0 hz age 0 ns probe_hits: 11 3 addr 4.659 GiB size 791.078 MiB access 0 hz age 13.700 s probe_hits: 11 4 addr 5.431 GiB size 1.472 GiB access 0 hz age 15.800 s probe_hits: 11 5 addr 6.903 GiB size 915.059 MiB access 0 hz age 15.300 s probe_hits: 11 memory bw estimate: 0 B per second total size: 7.797 GiB record DAMON intervals: sample 5 ms, aggr 100 ms After applying this series, I was able to reliably show the expected results like below. $ sudo ./damo report access --format append region "probe_hits: <probe hits>" heatmap: 00000000333333330000000166666665111111139999999855555555333333333333333444444444 intervals: sample 5 ms aggr 100 ms (max access hz 200) 0 addr 4.000 KiB size 790.496 MiB access 0 hz age 1 m 33.300 s probe_hits: 20 1 addr 790.500 MiB size 791.160 MiB access 0 hz age 1 m 15.400 s probe_hits: 19 2 addr 1.545 GiB size 792.316 MiB access 0 hz age 1 m 32.400 s probe_hits: 19 3 addr 2.318 GiB size 795.465 MiB access 0 hz age 1 m 2.600 s probe_hits: 19 4 addr 3.095 GiB size 797.102 MiB access 0 hz age 1 m 23.500 s probe_hits: 20 5 addr 3.874 GiB size 797.293 MiB access 0 hz age 47.900 s probe_hits: 20 6 addr 4.652 GiB size 787.516 MiB access 0 hz age 1 m 3.800 s probe_hits: 20 7 addr 5.421 GiB size 784.461 MiB access 0 hz age 1 m 14.400 s probe_hits: 19 8 addr 6.187 GiB size 795.621 MiB access 0 hz age 1 m 15.700 s probe_hits: 20 9 addr 6.964 GiB size 798.000 MiB access 0 hz age 1 m 10.200 s probe_hits: 20 10 addr 7.744 GiB size 54.566 MiB access 0 hz age 1 m 9.300 s probe_hits: 20 memory bw estimate: 0 B per second total size: 7.797 GiB record DAMON intervals: sample 5 ms, aggr 100 ms FYI, 'damo report access' output format has changed on v3.3.0. Above outputs can be reproduced on <3.3.0 versions of damo. Patches Sequence ================ Patch 1 adds probe_hits counters for values that fully accumulated in the last aggregation interval. This is required for using the moving sum infrastructure. Patch 2 introduces a function for getting the moving sum values on demand, using the infrastructure. Finally, patch 3 updates the DAMON sysfs interface to expose the moving sum values to the schemes tried regions directory. This patch (of 3): Add new damon_region filed, last_probe_hits. Maintain fully accumulated probe_hits values from the last aggregation interval in the field. Link: https://lore.kernel.org/20260703170605.94472-1-sj@kernel.org Link: https://lore.kernel.org/20260703170605.94472-2-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm: hugetlb: refactor out hugetlb_alloc_folio()Ackerley Tng
Refactor out hugetlb_alloc_folio() from alloc_hugetlb_folio(), which handles allocation of a folio and memory and HugeTLB charging to cgroups. This refactoring decouples the HugeTLB page allocation from VMAs, specifically: 1. Reservations (as in resv_map) are stored in the vma 2. mpol is stored at vma->vm_policy 3. A vma must be used for allocation even if the pages are not meant to be used by host process. Without this coupling, VMAs are no longer a requirement for allocation. This opens up the allocation routine for usage without VMAs, which will allow guest_memfd to use HugeTLB as a more generic allocator of huge pages, since guest_memfd memory may not have any associated VMAs by design. In addition, direct allocations from HugeTLB could possibly be refactored to avoid the use of a pseudo-VMA. Also, this decouples HugeTLB page allocation from HugeTLBfs, where the subpool is stored at the fs mount. This is also a requirement for guest_memfd, where the plan is to have a subpool created per-fd and stored on the inode. Provide and use alloc_flags to allow more allocation knobs in future without expanding the number of parameters in hugetlb_alloc_folio(). No functional change intended. Link: https://lore.kernel.org/20260702-hugetlb-open-up-v4-6-d53cefcccf34@google.com Signed-off-by: Ackerley Tng <ackerleytng@google.com> Cc: Alistair Popple <apopple@nvidia.com> Cc: Byungchul Park <byungchul@sk.com> Cc: David Hildenbrand <david@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com> Cc: Frank van der Linden <fvdl@google.com> Cc: Gregory Price <gourry@gourry.net> Cc: "Huang, Ying" <ying.huang@linux.alibaba.com> Cc: James Houghton <jthoughton@google.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Jiaqi Yan <jiaqiyan@google.com> Cc: Joshua Hahn <joshua.hahnjy@gmail.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Michal Hocko <mhocko@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Oscar Salvador <osalvador@suse.de> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Pasha Tatashin <pasha.tatashin@soleen.com> Cc: Peter Xu <peterx@redhat.com> Cc: Pratyush Yadav <pratyush@kernel.org> Cc: Rakie Kim <rakie.kim@sk.com> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Sean Christopherson <seanjc@google.com> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: Shivank Garg <shivankg@amd.com> Cc: Vishal Annapurve <vannapurve@google.com> Cc: Yan Zhao <yan.y.zhao@intel.com> Cc: Zi Yan <ziy@nvidia.com> Cc: Qi Zheng <qi.zheng@linux.dev> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm: hugetlb: move mpol interpretation out of ↵Ackerley Tng
alloc_buddy_hugetlb_folio_with_mpol() Move memory policy interpretation out of alloc_buddy_hugetlb_folio_with_mpol() and into alloc_hugetlb_folio() to separate reading and interpretation of memory policy from actual allocation. This will later allow memory policy to be interpreted outside of the process of allocating a hugetlb folio entirely. This opens doors for other callers of the HugeTLB folio allocation function, such as guest_memfd, where memory may not always be mapped and hence may not have an associated vma. Introduce struct mempolicy_interpreted to hold all the components of an interpreted memory policy. Rename alloc_buddy_hugetlb_folio_with_mpol() to alloc_buddy_hugetlb_folio() since the function no longer interprets memory policy. No functional change intended. Link: https://lore.kernel.org/20260702-hugetlb-open-up-v4-2-d53cefcccf34@google.com Signed-off-by: Ackerley Tng <ackerleytng@google.com> Reviewed-by: James Houghton <jthoughton@google.com> Acked-by: Oscar Salvador <osalvador@suse.de> Cc: Alistair Popple <apopple@nvidia.com> Cc: Byungchul Park <byungchul@sk.com> Cc: David Hildenbrand <david@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com> Cc: Frank van der Linden <fvdl@google.com> Cc: Gregory Price <gourry@gourry.net> Cc: "Huang, Ying" <ying.huang@linux.alibaba.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Jiaqi Yan <jiaqiyan@google.com> Cc: Joshua Hahn <joshua.hahnjy@gmail.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Michal Hocko <mhocko@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Pasha Tatashin <pasha.tatashin@soleen.com> Cc: Peter Xu <peterx@redhat.com> Cc: Pratyush Yadav <pratyush@kernel.org> Cc: Qi Zheng <qi.zheng@linux.dev> Cc: Rakie Kim <rakie.kim@sk.com> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Sean Christopherson <seanjc@google.com> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: Shivank Garg <shivankg@amd.com> Cc: Vishal Annapurve <vannapurve@google.com> Cc: Yan Zhao <yan.y.zhao@intel.com> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/damon/core: remove damon_region->nr_accesses_bpSJ Park
No code touches damon_region->nr_accesses_bp field. Remove it. Link: https://lore.kernel.org/20260630040812.149729-19-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Cc: Brendan Higgins <brendan.higgins@linux.dev> Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/damon/core: remove attrs param from damon_update_region_access_rate()SJ Park
damon_update_region_access_rate() is not using attrs parameter. Remove it. Link: https://lore.kernel.org/20260630040812.149729-15-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Cc: Brendan Higgins <brendan.higgins@linux.dev> Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/damon/core: use damon_nr_accesses_mvsum() for damos region tracingSJ Park
damon_nr_accesses_mvsum() returns a value same to nr_accesses_bp. Also the function is more simple and therefore more tolerant to errors. Execution of the function would be more expensive than the simple read of the field, but because the function is quite simple, the overhead should be negligible. Use it in the DAMON region exporting trace points instead of the nr_accesses_bp. Link: https://lore.kernel.org/20260630040812.149729-7-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Cc: Brendan Higgins <brendan.higgins@linux.dev> Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/damon/core: introduce damon_nr_accesses_mvsum()SJ Park
Patch series "mm/damon: optimize out nr_accesses_bp". TLDR: Replace damon_region->nr_accesses_bp, which is easy to be wrong, with a simpler on-demand moving sum function, damon_nr_accesses_mvsum(). Background ========== DAMON's monitoring output (access pattern snapshot, or more technically speaking, damon_region->nr_accesses) is completed once per aggregation interval, which is 100 ms by default. Users can arbitrarily increase the interval for demand. Under the suggested intervals auto-tuning setup, it can span up to 200 seconds. If the aggregation interval is too long, the snapshot users cannot use it in reasonable time. To mitigate this, we introduced a new field of damon_region, namely nr_accesses_bp. It contains a pseudo moving sum of nr_accesses in bp units and is updated for each sampling interval. It turned out keeping it correctly updated every sampling interval is not that easy. From online parameter update feature development and more experimental hacks, we found it is easy to be corrupted. Once it is corrupted, DAMON's monitoring outputs become quite insane. Hence we added a few validation checks. It is easy to be corrupted because it requires every update per sampling interval to be correct. Solution ======== There is no real reason to keep it updated every sampling interval. Due to the simple pseudo-moving sum mechanism and existing helper field (last_nr_accesses), we can also calculate the pseudo moving sum on demand in a much simpler way. Implement a function for getting the pseudo moving sum on demand, and replace nr_accessses_bp uses with the new function. Also remove no more needed tests for nr_accesses_bp and the per-sampling interval update functions. Finally, remove the nr_accesses_bp. The new function is quite simple. Discussion ========== Depending on the use case, multiple nr_accesses readers could be executed in the same kdamond_fn() main loop iteration, which is executed once per sampling interval. Such readers include DAMON region exporting tracepoints (damon_[region_]aggregated and damos_before_apply), DAMOS, and DAMON sysfs interface logic for update_schemes_tried_regions command. In this case, the new function will be called multiple times and this could be overhead compared to the old logic, which simply reads the field without any additional work. Nonetheless, the new function is quite simple. And the new approach does nothing while there is no need to read. The old approach had to execute its update function for each region for every sampling interval. Hence the new approach is believed to be even more lightweight in common case, and the overhead is anyway negligible. One more advantage of this change is that one field from the damon_region struct is removed. On setups that uses a high number of DAMON regions, this could be a potential memory space benefit. Patches Sequence ================ Patch 1 introduces the new function for getting the pseudo moving sum of nr_accesses on demands. Patch 2 implements a unit test for the new function's internal logic. Patch 3 and 4 update monitoring logic and the new function to ready for safe use on the existing logic. Patches 5-7 replace uses of nr_accesses_bp in DAMOS, tracepoints and DAMON sysfs interface with the new function, respectively. Patches 8-10 removes nr_accesses_bp validation functions in DAMON core, one by one. Patches 11 and 12 further remove tests and test helper for nr_accesses_bp, respectively. Patches 13 removes the setups and updates or nr_accesses_bp field. Patches 14-16 cleans up function parameters that are no more being used due to the previous patch. Patch 17 removes the function that was used for updating nr_accesses_bp field with its unit test, which is the single remaining caller of the function. Finally, patch 18 removes damon_region->nr_accesses_bp field. This patch (of 18): Introduce a new DAMON core function, damon_nr_accesses_mvsum(). It returns a pseudo moving sum value of a given region's nr_accesses for the last aggregation interval. The internal logic is the same to nr_accesses_bp. The difference is that nr_accesses_bp is updated for each sampling interval, while the new function needs to be executed only when requested. Hence the function's return value is the same as the value of nr_accesses_bp. Link: https://lore.kernel.org/20260630040812.149729-1-sj@kernel.org Link: https://lore.kernel.org/20260630040812.149729-2-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Cc: Brendan Higgins <brendan.higgins@linux.dev> Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm: gfp_types: fix __GFP_ACCOUNT, GFP_KERNEL_ACCOUNT documentationJohannes Weiner
Gregory points out that these descriptions are cursed and confusing, considering what these flags actually do. This is mostly due to historic implementation choices and cgroup1 baggage. Improve the description of their actual effects. Link: https://lore.kernel.org/20260701182102.1586784-1-hannes@cmpxchg.org Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Reported-by: Gregory Price <gourry@gourry.net> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Acked-by: Shakeel Butt <shakeel.butt@linux.dev> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Reviewed-by: Gregory Price <gourry@gourry.net> Acked-by: SJ Park <sj@kernel.org> Cc: David Hildenbrand <david@kernel.org> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Suren Baghdasaryan <surenb@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/mm_init: handle alloc_percpu failure in free_area_init_core_hotplugGregory Price
We miss a failed allocation check for pgdat->per_cpu_nodestats, which results in a NULL deref when we offset into the per-cpu area. Propagate -ENOMEM up the stack and leave per_cpu_nodestats pointing at boot_nodestats so a later online can retry the allocation. hotadd_init_pgdat() returns NULL on failure, which __try_online_node() already maps to -ENOMEM. On failure nothing needs to be unwound: - the node is never marked online - per_cpu_nodestats is left pointing at boot_nodestats - __add_memory_resource() cleans up pending memblock resources - later online attempts retry the per_cpu_nodestats allocation Link: https://lore.kernel.org/20260701221613.2818148-1-gourry@gourry.net Fixes: 75ef71840539 ("mm, vmstat: add infrastructure for per-node vmstats") Signed-off-by: Gregory Price <gourry@gourry.net> Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://sashiko.dev/#/patchset/20260627202243.758289-1-gourry%40gourry.net Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Mike Rapoport <rppt@kernel.org> Cc: Oscar Salvador <osalvador@suse.de> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm: fix ASSERT_EXCLUSIVE_BITS by passing memdesc_flags_t by pointerHui Zhu
KCSAN reports a data race between page_to_nid()/folio_pgdat() reading page->flags and folio_trylock()/folio_lock() concurrently doing test_and_set_bit_lock(PG_locked, ...) on the same word, e.g.: BUG: KCSAN: data-race in __lruvec_stat_mod_folio / shmem_get_folio_gfp The race is benign: nid/zone bits are set once at page init and never overlap with PG_locked. However, ASSERT_EXCLUSIVE_BITS() inside memdesc_nid/zonenum() was checking a by-value copy of the flags word, not the live page->flags, so it failed to annotate the real access. Change memdesc_nid(), memdesc_zonenum(), memdesc_section(), and memdesc_is_zone_device() to take a const memdesc_flags_t * and update all callers to pass &page->flags / &folio->flags, so ASSERT_EXCLUSIVE_BITS() operates on the actual shared word. Guard the ASSERT_EXCLUSIVE_BITS() call in memdesc_zonenum() under ZONES_WIDTH != 0 to avoid a zero-mask check on configs where the zone field is absent. memdesc_section() needs no such guard, since SECTIONS_WIDTH is never 0 wherever SECTION_IN_PAGE_FLAGS is defined. Under CONFIG_NUMA=n, memdesc_nid() itself is stubbed to "return 0" instead of reading page->flags, since NODES_MASK is 0 and the check can never fire; page_to_nid()/folio_nid() now just call memdesc_nid() unconditionally and rely on that stub, instead of duplicating the CONFIG_NUMA split at each call site. [zhuhui@kylinos.cn: v11] Link: https://lore.kernel.org/20260708083308.747930-1-hui.zhu@linux.dev [ziy@nvidia.com: build fix] Link: https://lore.kernel.org/DJSGLP9VFLRI.355AAWR2VHIEL@nvidia.com Link: https://lore.kernel.org/20260630070810.470763-1-hui.zhu@linux.dev Signed-off-by: Hui Zhu <zhuhui@kylinos.cn> Co-developed-by: David Hildenbrand (Arm) <david@kernel.org> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Axel Rasmussen <axelrasmussen@google.com> Cc: Barry Song <baohua@kernel.org> Cc: Kairui Song <kasong@tencent.com> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Wei Xu <weixugc@google.com> Cc: Yuanchu Xie <yuanchu@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/vmpressure: move v1 userspace eventfd code into memcontrol-v1.cUsama Arif
Clean up mm/vmpressure.c by separating the cgroup v1 userspace eventfd interface from the shared and v2 in-kernel code. Currently, almost half of mm/vmpressure.c exists to serve tree=true: struct vmpressure_event, the events list and its mutex, the work_struct and vmpressure_work_fn that drains tree_scanned/tree_reclaimed, the parent walk, vmpressure_event(), vmpressure_register_event(), vmpressure_unregister_event(), and vmpressure_prio() (which always calls vmpressure() with tree=true). Move it all into mm/memcontrol-v1.c (built only when CONFIG_MEMCG_V1=y) as a single contiguous block, following the per-component layout already used by that file. Keeping the v1 vmpressure code with the rest of the deprecated cgroup v1 memory controller makes the full footprint of the CONFIG_MEMCG_V1 option easy to see in one place, which matters more than component-level file separation for code that has no active development. vmpressure.c keeps the shared bits (constants, vmpressure_calc_level, the runtime hierarchy check, the tree=false body, init/cleanup plumbing) and calls into three small v1 hooks for the tree=true accumulator and the v1 portions of init/cleanup. The hooks have static-inline no-op stubs in include/linux/vmpressure.h for the !MEMCG_V1 case, so callers don't need ifdefs. vmpressure_prio() gets the same treatment, which means vmscan.c's call site disappears at compile time on v2-only kernels. The only #ifdef CONFIG_MEMCG_V1 in source remains around the v1-only fields inside struct vmpressure itself. Memory savings on CONFIG_MEMCG_V1=n (measured with pahole): struct vmpressure : 112B -> 24B struct mem_cgroup : 1664B -> 1536B This split is the first step toward eventually making vmpressure CONFIG_MEMCG_V1 only. The v2 in-kernel socket pressure path (tree=false) cannot be removed today immediately: PSI is not an exact replacement for vmpressure, and switching networking socket-buffer back-off to PSI may regress networking performance or increase memory pressure in workloads that today rely on vmpressure's hysteresis. The medium-term plan is to introduce a PSI-based socket-pressure path, keep vmpressure available for v2 behind a defconfig as an opt-out for several releases, and only then drop the tree=false path entirely, at which point everything that remains of the vmpressure block in mm/memcontrol-v1.c is the whole subsystem. Link: https://lore.kernel.org/20260630112617.1198623-3-usama.arif@linux.dev Signed-off-by: Usama Arif <usama.arif@linux.dev> Acked-by: Shakeel Butt <shakeel.butt@linux.dev> Cc: David Hildenbrand <david@kernel.org> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Michal Koutný <mkoutny@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Tejun Heo <tj@kernel.org> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm: rename ARCH_ENABLE_THP_MIGRATION to ARCH_HAS_PMD_SOFTLEAVESUsama Arif
CONFIG_ARCH_ENABLE_THP_MIGRATION gates PMD-level migration entries. PMD-level device-private entries use the same migration mechanism and therefore require the same architecture support. Upcoming PMD-level swap entries can use the same PMD softleaf helpers without depending on page migration, so rename the architecture gate to CONFIG_ARCH_HAS_PMD_SOFTLEAVES. This describes the PMD entry capability rather than one current user of it. This is a pure rename: the set of selecting architectures (x86, arm64, s390, riscv, loongarch, and powerpc on PPC_BOOK3S_64) and the gating semantics are unchanged. No functional change intended. Link: https://lore.kernel.org/20260706114320.1643046-7-usama.arif@linux.dev Signed-off-by: Usama Arif <usama.arif@linux.dev> Reviewed-by: Zi Yan <ziy@nvidia.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Alexandre Ghiti <alex@ghiti.fr> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Baoquan He <baoquan.he@linux.dev> Cc: Barry Song <baohua@kernel.org> Cc: Chris Li <chrisl@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: "Huang, Ying" <ying.huang@linux.alibaba.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Kairui Song <kasong@tencent.com> Cc: Kemeng Shi <shikemeng@huaweicloud.com> Cc: Kiryl Shutsemau <kas@kernel.org> Cc: Lance Yang <lance.yang@linux.dev> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Nhat Pham <nphamcs@gmail.com> Cc: Nico Pache <npache@redhat.com> Cc: Rik van Riel <riel@surriel.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm: add softleaf_to_pmd() and convert existing callersUsama Arif
Patch series "mm: preparatory patches for PMD level swap entries", v2. This is the preparatory part of the PMD page table swapin work. The full PMD swap entry series has been split into two parts: 1. this preparatory series, which contains the first 6 patches. Zi [1] and Lance [2] suggested to separate this out from the core series. 2. the PMD swap entry core series, which depends on this one. I will send this once the preparatory series is merged in mm-new as v3 as the combined is currently at v2 [1]. I have not marked this prep series as v3, as its not really adding support for PMD swap entries. This series does not introduce PMD swap entries and does not install any new page-table entry type. It only cleans up existing PMD softleaf helpers and call sites so the follow-up PMD swap entry series can be smaller and easier to review. It should be safe to merge independently. The patches are either helper additions, refactors of existing open-coded logic, defensive checks that preserve current migration/device-private behavior, or a mechanical rename of the PMD softleaf Kconfig gate. The follow-up series depends on these helpers, but this series does not depend on the follow-up series. Patch breakdown: 1. mm: add softleaf_to_pmd() and convert existing callers Add the PMD counterpart to softleaf_to_pte() and convert existing swp_entry_to_pmd() users that are constructing PMD softleaf entries. 2. mm: extract mm_prepare_for_swap_entries() helper Hoist the "register mm with swapoff" double-checked-locking pattern out of try_to_unmap_one() and copy_nonpresent_pte() so future PMD-level users do not need another open-coded copy. 3. fs/proc: use softleaf_has_pfn() in pagemap PMD walker Avoid assuming every non-present PMD softleaf entry encodes a PFN. Existing migration/device-private behavior is preserved. 4. mm/huge_memory: move softleaf_to_folio() inside migration branch Keep the folio lookup in change_non_present_huge_pmd() scoped to the migration-entry branch that actually needs it. 5. mm/migrate_device: move softleaf_to_folio() inside device-private branch Apply the same ordering cleanup to migrate_vma_collect_pmd(): only derive a folio after confirming the PMD entry is device-private. 6. mm: rename ARCH_ENABLE_THP_MIGRATION to ARCH_HAS_PMD_SOFTLEAVES Rename the architecture gate to describe what it actually enables: PMD softleaf entries. Migration remains the only current user in this series; the follow-up series adds PMD swap entries. This patch (of 6): Add softleaf_to_pmd() as the PMD counterpart to softleaf_to_pte(), completing the symmetry of the softleaf abstraction for page table leaf entries. The upcoming PMD swap entry support needs to construct PMD entries from swap entries. Converting existing swp_entry_to_pmd() callers to softleaf_to_pmd() in a prep patch keeps the feature patches focused on new functionality rather than mixing refactoring with new code. Link: https://lore.kernel.org/20260706114320.1643046-1-usama.arif@linux.dev Link: https://lore.kernel.org/20260706114320.1643046-2-usama.arif@linux.dev Link: https://lore.kernel.org/all/6E99CC4E-A026-4DE3-8A5A-34216771F521@nvidia.com/ [1] Link: https://lore.kernel.org/all/b08cafbb-a4b7-4609-84ae-dbb2cfcfc8be@linux.dev/#t [2] Link: https://lore.kernel.org/all/20260602142537.198755-1-usama.arif@linux.dev/ [3] Signed-off-by: Usama Arif <usama.arif@linux.dev> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Lance Yang <lance.yang@linux.dev> Cc: Alexandre Ghiti <alex@ghiti.fr> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Baoquan He <baoquan.he@linux.dev> Cc: Barry Song <baohua@kernel.org> Cc: Chris Li <chrisl@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: "Huang, Ying" <ying.huang@linux.alibaba.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Kairui Song <kasong@tencent.com> Cc: Kemeng Shi <shikemeng@huaweicloud.com> Cc: Kiryl Shutsemau <kas@kernel.org> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Nhat Pham <nphamcs@gmail.com> Cc: Nico Pache <npache@redhat.com> Cc: Rik van Riel <riel@surriel.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30net: mctp: usblib: Implement transmit-side packet spanningJeremy Kerr
Add support for packet spanning as defined in DSP0283 v1.1. With the existing v1.0 implementation of multi-packet transfers, all we need here is to adjust the buffer sizes to suit v1.1. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-9-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usblib: Implement receive-side packet spanningJeremy Kerr
Using the existing prepare/complete API, we can persist the rx skb across receives to implement v1.1 packet spanning. Alter the packet-extraction loop to allow truncated packets, returning early with the skb persisted for the next IN urb completion. When we see we have a complete packet, netif_rx() that. If the packet boundary aligns with the urb completion, we can netif_rx() the whole thing. Those intermediate packets are cloned from the original (large-transfer-data) skb. Unlike existing behaviour, if the clone fails, we drop just that clone, instead of the existing transfer skb. This allows us to process the rest of the skb data, and any continuation of the span into the next transfer. One subtle change: the mctp_usblib_rx() helper now handles skbs with the full transport header, so we shift the skb_pull() for the header data to the helper, before doing the rx_bytes stats update. We still need to handle non-spanning mode, so error out on truncated-packet cases there. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-8-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usb: Accommodate DSP0283 v1.1 header formatJeremy Kerr
In the v1.1 update to DSP0283, we have a larger header field, of 13 bits rather than 8. In order to accommodate this, in preparation for proper v1.1 support, expand our struct mctp_usb_hdr's len field to a u16, and endian-convert when necessary. Because we don't yet support spanning mode, we will never receive or transmit with the top 5 bits set, so we always mask out anyway. This allows for a future change where we allow spanning mode with >512-byte transfers. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-7-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usblib: Add support for multi-packet transmitJeremy Kerr
The MCTP over USB spec allows us to pack multiple packets in one transfer. Given the packet max length is 255, and the transfer max length is 512, we can typically include two full-size packets per urb submission. To do this, we allow a struct mctp_usb_tx to persist a tx_ctx, representing the ongoing context for a transmit. If possible, a TX skb will be queued to the context and the send deferred until the context is full, or the device queue reports no more packets. This typically requires a linear buffer for the 512-byte TX, which we allocate along with the TX context. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-6-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usblib: Move TX transfer processing to mctp-usblibJeremy Kerr
With the RX processing in mctp-usblib, add TX processing alongside. To accommodate packed transfers in DSP0283, where a transfer may contain multiple MCTP packets, we move to a split process for the transmit API: * push: create a new transmit context, and add a skb to it. * send: callback to the driver implementation to send the (possibly multi-packet) USB transfer * complete: update skb accounting and release the tx context The actual multi-packet transfer implementation will be added in the next change; no tx context persists beyond the single send at present. However, we use an anchor in the host driver implementation to track the submitted TX urb when necessary. While we're here, fix an inconsistency between tx and rx stats: both should not include the transport header. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-5-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usblib: Move RX transfer processing to a new mctp-usblibJeremy Kerr
The processing of USB receive transfers is common to both sides of a MCTP over USB transport. In order to support a future gadget driver, move the current host-side driver into a new common file, mctp-usblib. This currently handles the submit-complete-packetise process of the receive path of the USB transport. We'll add transmit handling in an upcoming change. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-3-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usb: Use packet-length max for maximum packet-size checkJeremy Kerr
The max packet size is smaller than the max transfer size, as we only have a u8 length field in the transport header. Add a define for the maximum representable length, and use that for our check. Use this for the MTU maximum calculation too. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-2-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usb: Include version indicator in max packet size definesJeremy Kerr
DSP0283 v1.1.0 will introduce larger maximum packet sizes. In preparation, indicate that the current maxima are specific to v1.0.x. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-1-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30vxlan: honor per-nexthop fdb destination portJack Ma
When an fdb entry points at a nexthop group, vxlan_fdb_nh_path_select() resolves the selected leg's remote IP but leaves the UDP destination port at the device default (vxlan->cfg.dst_port). Extend nexthop_path_fdb_result() to also return the selected nexthop's NHA_DST_PORT (0 when unset) and have vxlan_fdb_nh_path_select() store it in rdst->remote_port. vxlan_xmit_one() already prefers rdst->remote_port when non-zero and falls back to the device port otherwise, so nexthops without a port are unaffected. This lets one fdb nexthop group load-balance a flow across legs that share an underlay IP but differ in UDP destination port. Signed-off-by: Jack Ma <jack4it@gmail.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/20260724-b4-vxlan-fdb-port-v5-2-cd1c6aeee058@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: nexthop: add NHA_DST_PORT for fdb nexthopsJack Ma
Commit 1274e1cc4226 ("vxlan: ecmp support for mac fdb entries") lets a single inner MAC be reached through a group of remote VTEPs, with the kernel flow-hashing across the group members. Each member carries its own remote IP, but the UDP destination port is always taken from the VXLAN device (vxlan->cfg.dst_port) and cannot be set per member. Some deployments pack several receivers behind one underlay IP and tell them apart by UDP port, so they need a per-nexthop destination port to spread flows across (IP, port) tuples rather than IP alone. Add a netlink attribute NHA_DST_PORT (__be16, mirroring NDA_PORT) that carries an optional UDP destination port on an fdb nexthop. It is only accepted together with NHA_FDB and NHA_GATEWAY; it is stored in struct nh_info and echoed back on dump. The attribute is named generically rather than fdb-specific so it can be reused should another nexthop type ever need a destination port. This patch is control-plane plumbing only; the VXLAN datapath is wired up in a follow-up patch, so behaviour is unchanged for now. Signed-off-by: Jack Ma <jack4it@gmail.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/20260724-b4-vxlan-fdb-port-v5-1-cd1c6aeee058@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30libnvdimm: nd.h: clean up kernel-doc warningsRandy Dunlap
Add missing struct member, function parameters, and function return values to eliminate all kernel-doc warnings: Warning: include/linux/nd.h:124 struct member 'common' not described in 'nd_namespace_io' Warning: include/linux/nd.h:124 Excess struct member 'dev' description in 'nd_namespace_io' Warning: include/linux/nd.h:166 function parameter 'flags' not described in 'nvdimm_read_bytes' Warning: include/linux/nd.h:166 No description found for return value of 'nvdimm_read_bytes' Warning: include/linux/nd.h:185 function parameter 'flags' not described in 'nvdimm_write_bytes' Warning: include/linux/nd.h:185 No description found for return value of 'nvdimm_write_bytes' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260721172132.3718892-1-rdunlap@infradead.org Signed-off-by: Alison Schofield <alison.schofield@intel.com>
2026-07-30ASoC: SOF: ipc4: Add decoder for RESOURCE_EVENT notifications from firmwarePeter Ujfalusi
Decode and print out the content of currently supported RESOURCE_EVENT notifications from firmware along with the needed data structures and definitions. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://patch.msgid.link/20260730082444.4828-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-30Merge tag 'for-linus-iommufd' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd Pull iommufd fixes from Jason Gunthorpe: "Several bug fixes found by tools and fuzzing: - Incorrect domain passed during replace to ack faults - Block the access API from using dmabuf - Missing unlock on error unwind - Race seeing a partially setup vdevice in the xarray - Do not allow vdevices to have multiple stream ids in SMMUv3 - Possible UAF if racing faults with domain changes" * tag 'for-linus-iommufd' of git://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd: iommu/iommufd: Fix IOPF group ownership UAF iommu/arm-smmu-v3-iommufd: Require exactly one Stream ID for a vDEVICE iommufd/viommu: Publish a vDEVICE only after vdevice_init() succeeds iommufd/viommu: Release the igroup lock on the vdevice_size error path iommufd: Reject DMABUF pages from the access pin path iommufd: Fix wrong hwpt passed to iommufd_auto_response_faults on replace
2026-07-30soc: qcom: smem: Expose DDR data from SMEMKonrad Dybcio
Most modern Qualcomm platforms (>= SM8150) expose information about the DDR memory present on the system via SMEM. Details from this information is used in various scenarios, such as multimedia drivers configuring the hardware based on the "Highest Bank address Bit" (hbb), or the list of valid frequencies in validation scenarios... Add support for parsing v3-v7 version of the structs. Unforunately, they are not versioned, so some elbow grease is necessary to determine which one is present. See for reference: ver 3: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/1d11897d2cfcc7b85f28ff74c445018dbbecac7a ver 4: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/f6e9aa549260bbc0bdcb156c2b05f48dc5963203 ver 5: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/617d3297abe8b1b8dd3de3d1dd69c3961e6f343f ver 5 with 6regions: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/d770e009f9bae58d56d926f7490bbfb45af8341f ver 6: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/62659b557fdb1551b20fae8073d1d701dfa8a62e ver 7: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/734d95599c5ebb1ca0d4e1639142e65c590532b7 Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/1d11897d2cfcc7b85f28ff74c445018dbbecac7a Link: https://lore.kernel.org/r/20260727-topic-smem_dramc-v5-2-66188b3e338d@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30dt-bindings: clock: qcom: Add Maili global clock controllerTaniya Das
Add device tree bindings for the global clock controller (GCC) on the Qualcomm Maili SoC by extending the existing Qualcomm Hawi GCC bindings, since the Maili GCC is identical to the Hawi GCC apart from a few additional clocks. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-maili_initial_clock-v4-3-ed52ade264f0@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30dt-bindings: clock: qcom: gcc-mdm9607: Drop SYSTEM_NOC_BFDCD_CLK_SRCStephan Gerhold
This clock does not exist in the hardware, it has no consumers and reading/writing to the registers fails. Drop it from the bindings. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-9-745565101869@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30soc: qcom: geni-se: Use HW PROG_RAM_DEPTH to validate firmware sizeViken Dadhaniya
The hardcoded MAX_GENI_CFG_RAMn_CNT limit is not accurate for all SoCs: some targets have less CFG RAM than the constant implies, while others like QCS615 need more entries than the old limit of 455 allowed, causing valid firmware to be rejected at load time. Rather than hardcoding a constant, read PROG_RAM_DEPTH from SE_HW_PARAM_2 at runtime to get the actual CFG RAM depth of the hardware instance and use that as the upper bound for firmware size validation. Fixes: d4bf06592ad6 ("soc: qcom: geni-se: Add support to load QUP SE Firmware via Linux subsystem") Cc: stable@vger.kernel.org Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260702-qup-se-increase-ram-cnt-v3-1-80b363373a5b@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30rust: driver: remove open-coded matching logicGary Guo
With device ID info now including pointers instead of indices, the open-coded ACPI/OF matching is no longer needed and can be replaced with `device_get_match_data`. With the removal of open-coded matching, the exposed functions and helpers are also removed; this effectively reverts most of commit 2690d071584e ("rust: ACPI: fix missing match data for PRP0001"). Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20260629-id_info-v2-9-56fccbe9c5ef@garyguo.net [ Consider the serdev code merged in the meantime. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-30Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-7.2-rc6). No conflicts. Adjacent changes: net/ipv4/route.c dbc3791e3b24 ("net: do not send ICMP/NDISC Redirects when peer allocation fails") 7804eaa057fe ("ipv4: snapshot dst.dev in ip_rt_send_redirect() and ip_rt_get_source()") drivers/net/tun.c 23dad2d088df ("tun: no longer rely on RTNL in tun_fill_info()") c3da92af07ea ("Revert "tun/tap: add ptr_ring consume helper with netdev queue wakeup"") drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c 3bd438a58e91 ("octeontx2-af: Block VFs from clobbering special CGX PKIND state") 5ba5611ef946 ("octeontx2-af: reserve 4 PKINDs for skip-size custom use") drivers/net/wireless/ath/ath12k/core.h drivers/net/wireless/ath/ath12k/mac.c drivers/net/wireless/ath/ath12k/peer.c 469d7e6077c1 ("wifi: ath12k: resolve PENDING ML peer ID from MLO_PEER_MAP HTT event") 378e659029d5 ("wifi: ath12k: introduce host_alloc_ml_id hardware parameter") c42b27336eef ("wifi: ath12k: fix survey indexing across bands") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30Merge tag 'pm-7.2-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fixes from Rafael Wysocki: "These fix issues related to cpufreq, in the ACPI CPPC library and the generic CPPC cpufreq driver, in the powernow-k8 and amd-pstate drivers, and in the schedutil governor: - Allow fast frequency switching in the ACPI CPPC library only when every supported control used by the driver callback has an address space already accepted for fast access (Christian Loehle) - Skip writes to unsupported performance controls in the ACPI CPPC library (Christian Loehle) - Update cppc_cpufreq_update_perf_limits() to read policy->min and policy->max once and, if the lockless snapshot is inconsistent, reduce the minimum to the observed maximum, along the lines of cpufreq_driver_resolve_freq() (Christian Loehle) - Fix a possible memory leak in the powernowk8_cpu_init() error paths (Abdun Nihaal) - Loosen the requirement on lowest nonlinear frequency != min freq in the amd-pstate driver that is too tight for new systems some of which actually have the lowest nonlinear frequency identical to the minimum frequency (Mario Limonciello) - Prevent amd-pstate from loading on unsupported hardware (Rong Zhang) - Address an initialization race in the schedutil governor when it runs on multi-CPU cpufreq policies, by making it initialize all per-CPU structures first and only then publish the per-CPU utilization update hooks (Zhongqiu Han)" * tag 'pm-7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpufreq: powernow-k8: Fix possible memory leak in powernowk8_cpu_init() ACPI: CPPC: Skip writes to unsupported performance controls cpufreq/amd-pstate: Prevent the driver from loading on unsupported hardware cpufreq/amd-pstate: Loosen requirement on lowest nonlinear frequency != min freq cpufreq: schedutil: Publish util hooks only after all sg_cpu are initialized cpufreq: cppc: Sanitize lockless policy limit snapshots ACPI: CPPC: Check all controls for fast switching
2026-07-30media: rppx1: lin: Add support for gamma sensor linearizationJai Luthra
Extend the RPPX1 driver to allow setting the gamma sensor linearization configuration parameters. It uses the RPPX1 framework for parameters and its writer abstraction to allow the user to control how, and when, configuration is applied to the RPPX1. Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-30media: rppx1: ga: Add support for gamma out correctionNiklas Söderlund
Extend the RPPX1 driver to allow setting the gamma out correction configuration parameters. It uses the RPPX1 framework for parameters and its writer abstraction to allow the user to control how, and when, configuration is applied to the RPPX1. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Co-developed-by: Jai Luthra <jai.luthra+renesas@ideasonboard.com> Signed-off-by: Jai Luthra <jai.luthra+renesas@ideasonboard.com> Co-developed-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-30media: rppx1: lsc: Add support for lens shade correctionNiklas Söderlund
Extend the RPPX1 driver to allow setting the lens shade correction configuration parameters. It uses the RPPX1 framework for parameters and its writer abstraction to allow the user to control how, and when, configuration is applied to the RPPX1. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Co-developed-by: Jai Luthra <jai.luthra+renesas@ideasonboard.com> Signed-off-by: Jai Luthra <jai.luthra+renesas@ideasonboard.com> Co-developed-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-30media: rppx1: ccor: Add support for color correction matrixNiklas Söderlund
Extend the RPPX1 driver to allow setting the color correction matrix configuration parameters. It uses the RPPX1 framework for parameters and its writer abstraction to allow the user to control how, and when, configuration is applied to the RPPX1. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Co-developed-by: Jai Luthra <jai.luthra+renesas@ideasonboard.com> Signed-off-by: Jai Luthra <jai.luthra+renesas@ideasonboard.com> Co-developed-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-30media: rppx1: bls: Add support for black level compensationNiklas Söderlund
Extend the RPPX1 driver to allow setting the black level measurement and gain configuration. It uses the RPPX1 framework for parameters and its writer abstraction to allow the user to control how, and when, configuration is applied to the RPPX1. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Co-developed-by: Jai Luthra <jai.luthra+renesas@ideasonboard.com> Signed-off-by: Jai Luthra <jai.luthra+renesas@ideasonboard.com> Co-developed-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-30media: rppx1: hist: Add support histogram measurementNiklas Söderlund
Extend the RPPX1 driver to allow setting the histogram measurement configuration and consuming the resulting statistics. It uses the RPPX1 framework for parameters and its writer abstraction to allow the user to control how, and when, configuration is applied to the RPPX1. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Co-developed-by: Jai Luthra <jai.luthra+renesas@ideasonboard.com> Signed-off-by: Jai Luthra <jai.luthra+renesas@ideasonboard.com> Co-developed-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-30media: rppx1: exm: Add support for exposure measurementNiklas Söderlund
Extend the RPPX1 driver to allow setting the exposure measurement configuration and consuming the resulting statistics. It uses the RPPX1 framework for parameters and its writer abstraction to allow the user to control how, and when, configuration is applied to the RPPX1. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Co-developed-by: Jai Luthra <jai.luthra+renesas@ideasonboard.com> Signed-off-by: Jai Luthra <jai.luthra+renesas@ideasonboard.com> Co-developed-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-30media: rppx1: awbg: Add support for white balance gain settingsNiklas Söderlund
Extend the RPPX1 driver to allow setting the white balance gain configuration parameters. It uses the RPPX1 framework for parameters and its writer abstraction to allow the user to control how, and when, configuration is applied to the RPPX1. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Co-developed-by: Jai Luthra <jai.luthra+renesas@ideasonboard.com> Signed-off-by: Jai Luthra <jai.luthra+renesas@ideasonboard.com> Co-developed-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>