kernel/git/next/linux-next.git/mm, branch master

Merge branch 'slab/for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab.git

2026-07-06T14:09:15+00:00

Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/rppt/memblock.git

2026-07-06T14:09:06+00:00

Merge branch 'fs-next' of linux-next

2026-07-06T13:34:30+00:00

Merge branch 'mm-nonmm-unstable' of https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

2026-07-06T13:18:24+00:00

Merge branch 'mm-unstable' of https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

2026-07-06T13:18:22+00:00

Merge branch 'fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/rppt/memblock.git

2026-07-06T13:02:36+00:00

riscv: mm: avoid spurious fault after hotplugging vmemmap

2026-07-05T23:24:19+00:00

section_activate() does not flush TLB after populating new vmemmap pages. On most architectures, this is okay. However it is a problem on RISC-V since there the TLB caching non-present entries is permitted, which causes spurious faults on some hardwares. This seems to be most easily reproduced with DEBUG_VM=y and PAGE_POISONING=y, which causes these newly mapped struct pages to be poisoned i.e. written to immediately after mapping. Add a hook vmemmap_populate_finalize() in __populate_section_memmap() after population, to allow architectures to handle such situations as needed. Then implement it on RISC-V to arrange for the existing exception handler code to deal with these faults if they happen. Link: https://lore.kernel.org/20260630-mark-after-vmemmap-populate-v4-1-febbc15da028@iscas.ac.cn Signed-off-by: Vivian Wang Cc: Alexandre Ghiti Cc: David Hildenbrand Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Palmer Dabbelt Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton

mm/vmalloc: add alignment info in warning print as possible failure reason

2026-07-05T23:23:44+00:00

When running 'fix_align_alloc_test' case of test_vmalloc module with command: insmod ./test_vmalloc.ko run_test_mask=64 It will fail, which is the expected result, as the case increment the alignment parameter gradually to 64bit limit. And the dmesg has warning msg: "vmalloc_test/0: vmalloc error: size 4096, vm_struct allocation failed, mode:0xdc0(GFP_KERNEL|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0" It doesn't give the alignment info, which is the real reason for the failure (not the 'size'). Add alignment info to the warning print to give the necessary hint for possible failure reason, and the message will be: "vmalloc_test/0: vmalloc error: size 4096, align 0x800000000000, vm_struct allocation failed, mode:0xdc0(GFP_KERNEL|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0" Link: https://lore.kernel.org/20260702112610.21589-1-feng.tang@linux.alibaba.com Signed-off-by: Feng Tang Reviewed-by: Uladzislau Rezki (Sony) Signed-off-by: Andrew Morton

memcg-v1: bail out reclaim when memcg is dying

2026-07-05T23:23:44+00:00

The legacy memory.limit_in_bytes and memory.memsw.limit_in_bytes writers retry page_counter_set_max() by reclaiming synchronously in the writer context. memory.force_empty similarly loops in synchronous reclaim until the cgroup is empty or reclaim stops making progress. These writes hold a kernfs active reference on the file. If cgroup removal starts in parallel, the remover sets CSS_DYING and then waits in kernfs_drain() under cgroup_mutex for the active reference to drain. Continuing reclaim after the memcg is dying can therefore delay cgroup removal and keep cgroup_mutex held for a long time. Stop the v1 reclaim loops once the memcg is dying. For limit resizing, keep the existing -EBUSY semantics when the new limit could not be installed. For memory.force_empty, keep the existing best-effort success semantics. Link: https://lore.kernel.org/20260702120235.376752-5-jiayuan.chen@linux.dev Signed-off-by: Jiayuan Chen Reported-by: Zhou Yingfu Acked-by: Johannes Weiner Cc: Jiayuan Chen Cc: Axel Rasmussen Cc: Barry Song Cc: David Hildenbrand Cc: Kairui Song Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Shakeel Butt Cc: Wei Xu Cc: Yuanchu Xie Signed-off-by: Andrew Morton

memcg: bail out proactive reclaim when memcg is dying

2026-07-05T23:23:44+00:00

Proactive reclaim via memory.reclaim can run for a long time - swap I/O or thrashing again dominating the latency - and delays cgroup removal in the same way. Mitigate this by stopping the reclaim once memcg_is_dying(). Link: https://lore.kernel.org/20260702120235.376752-4-jiayuan.chen@linux.dev Signed-off-by: Jiayuan Chen Reported-by: Zhou Yingfu Acked-by: Johannes Weiner Cc: Jiayuan Chen Cc: Axel Rasmussen Cc: Barry Song Cc: David Hildenbrand Cc: Kairui Song Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Shakeel Butt Cc: Wei Xu Cc: Yuanchu Xie Signed-off-by: Andrew Morton