* [PATCH] mm: bail out when the PMD has been set in bloom filter
@ 2026-02-27 7:52 zhaoyang.huang
2026-02-27 11:42 ` kernel test robot
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: zhaoyang.huang @ 2026-02-27 7:52 UTC (permalink / raw)
To: Andrew Morton, Yu Zhao, linux-mm, linux-kernel, Zhaoyang Huang,
steve.kang
From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
There are two reasons to have the recorded PMD bail out from doing
the following iteration
1. It is worth of doing such a trade off thing in terms of reclaiming
efficiency as test_bloom_filter only consume 20~30 instructions in modern
processors(25 instructions in ARM64).
2. The PMD needs to accumulate young pages until aging happens while the
new arrived folio reference checking under current max_seq refuse to do so
which will affect carrying hot PMDs to new generation.
Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
---
mm/vmscan.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 9d900be478ea..e50e98291d0d 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -4227,6 +4227,10 @@ bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw)
/* avoid taking the LRU lock under the PTL when possible */
walk = current->reclaim_state ? current->reclaim_state->mm_walk : NULL;
+ /* may the pmd has been set in bloom filter */
+ if (test_bloom_filter(mm_state, max_seq, pvmw->pmd))
+ return true;
+
start = max(addr & PMD_MASK, vma->vm_start);
end = min(addr | ~PMD_MASK, vma->vm_end - 1) + 1;
--
2.25.1
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] mm: bail out when the PMD has been set in bloom filter
2026-02-27 7:52 [PATCH] mm: bail out when the PMD has been set in bloom filter zhaoyang.huang
@ 2026-02-27 11:42 ` kernel test robot
2026-02-28 0:50 ` Zhaoyang Huang
2026-02-28 11:20 ` [syzbot ci] " syzbot ci
2026-03-01 6:14 ` [PATCH] " Gregory Price
2 siblings, 1 reply; 5+ messages in thread
From: kernel test robot @ 2026-02-27 11:42 UTC (permalink / raw)
To: zhaoyang.huang, Andrew Morton, Yu Zhao, linux-kernel,
Zhaoyang Huang, steve.kang
Cc: llvm, oe-kbuild-all, Linux Memory Management List
Hi zhaoyang.huang,
kernel test robot noticed the following build warnings:
[auto build test WARNING on akpm-mm/mm-everything]
url: https://github.com/intel-lab-lkp/linux/commits/zhaoyang-huang/mm-bail-out-when-the-PMD-has-been-set-in-bloom-filter/20260227-155729
base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link: https://lore.kernel.org/r/20260227075250.1128175-1-zhaoyang.huang%40unisoc.com
patch subject: [PATCH] mm: bail out when the PMD has been set in bloom filter
config: sparc64-randconfig-002-20260227 (https://download.01.org/0day-ci/archive/20260227/202602271916.OBNa34QU-lkp@intel.com/config)
compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project 9a109fbb6e184ec9bcce10615949f598f4c974a9)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260227/202602271916.OBNa34QU-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202602271916.OBNa34QU-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> mm/vmscan.c:4206:24: warning: variable 'mm_state' is uninitialized when used here [-Wuninitialized]
4206 | if (test_bloom_filter(mm_state, max_seq, pvmw->pmd))
| ^~~~~~~~
mm/vmscan.c:4185:35: note: initialize the variable 'mm_state' to silence this warning
4185 | struct lru_gen_mm_state *mm_state;
| ^
| = NULL
>> mm/vmscan.c:4206:34: warning: variable 'max_seq' is uninitialized when used here [-Wuninitialized]
4206 | if (test_bloom_filter(mm_state, max_seq, pvmw->pmd))
| ^~~~~~~
mm/vmscan.c:4186:23: note: initialize the variable 'max_seq' to silence this warning
4186 | unsigned long max_seq;
| ^
| = 0
2 warnings generated.
vim +/mm_state +4206 mm/vmscan.c
4157
4158 /******************************************************************************
4159 * rmap/PT walk feedback
4160 ******************************************************************************/
4161
4162 /*
4163 * This function exploits spatial locality when shrink_folio_list() walks the
4164 * rmap. It scans the adjacent PTEs of a young PTE and promotes hot pages. If
4165 * the scan was done cacheline efficiently, it adds the PMD entry pointing to
4166 * the PTE table to the Bloom filter. This forms a feedback loop between the
4167 * eviction and the aging.
4168 */
4169 bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw)
4170 {
4171 int i;
4172 bool dirty;
4173 unsigned long start;
4174 unsigned long end;
4175 struct lru_gen_mm_walk *walk;
4176 struct folio *last = NULL;
4177 int young = 1;
4178 pte_t *pte = pvmw->pte;
4179 unsigned long addr = pvmw->address;
4180 struct vm_area_struct *vma = pvmw->vma;
4181 struct folio *folio = pfn_folio(pvmw->pfn);
4182 struct mem_cgroup *memcg;
4183 struct pglist_data *pgdat = folio_pgdat(folio);
4184 struct lruvec *lruvec;
4185 struct lru_gen_mm_state *mm_state;
4186 unsigned long max_seq;
4187 int gen;
4188
4189 lockdep_assert_held(pvmw->ptl);
4190 VM_WARN_ON_ONCE_FOLIO(folio_test_lru(folio), folio);
4191
4192 if (!ptep_clear_young_notify(vma, addr, pte))
4193 return false;
4194
4195 if (spin_is_contended(pvmw->ptl))
4196 return true;
4197
4198 /* exclude special VMAs containing anon pages from COW */
4199 if (vma->vm_flags & VM_SPECIAL)
4200 return true;
4201
4202 /* avoid taking the LRU lock under the PTL when possible */
4203 walk = current->reclaim_state ? current->reclaim_state->mm_walk : NULL;
4204
4205 /* may the pmd has been set in bloom filter */
> 4206 if (test_bloom_filter(mm_state, max_seq, pvmw->pmd))
4207 return true;
4208
4209 start = max(addr & PMD_MASK, vma->vm_start);
4210 end = min(addr | ~PMD_MASK, vma->vm_end - 1) + 1;
4211
4212 if (end - start == PAGE_SIZE)
4213 return true;
4214
4215 if (end - start > MIN_LRU_BATCH * PAGE_SIZE) {
4216 if (addr - start < MIN_LRU_BATCH * PAGE_SIZE / 2)
4217 end = start + MIN_LRU_BATCH * PAGE_SIZE;
4218 else if (end - addr < MIN_LRU_BATCH * PAGE_SIZE / 2)
4219 start = end - MIN_LRU_BATCH * PAGE_SIZE;
4220 else {
4221 start = addr - MIN_LRU_BATCH * PAGE_SIZE / 2;
4222 end = addr + MIN_LRU_BATCH * PAGE_SIZE / 2;
4223 }
4224 }
4225
4226 memcg = get_mem_cgroup_from_folio(folio);
4227 lruvec = mem_cgroup_lruvec(memcg, pgdat);
4228 max_seq = READ_ONCE((lruvec)->lrugen.max_seq);
4229 gen = lru_gen_from_seq(max_seq);
4230 mm_state = get_mm_state(lruvec);
4231
4232 lazy_mmu_mode_enable();
4233
4234 pte -= (addr - start) / PAGE_SIZE;
4235
4236 for (i = 0, addr = start; addr != end; i++, addr += PAGE_SIZE) {
4237 unsigned long pfn;
4238 pte_t ptent = ptep_get(pte + i);
4239
4240 pfn = get_pte_pfn(ptent, vma, addr, pgdat);
4241 if (pfn == -1)
4242 continue;
4243
4244 folio = get_pfn_folio(pfn, memcg, pgdat);
4245 if (!folio)
4246 continue;
4247
4248 if (!ptep_clear_young_notify(vma, addr, pte + i))
4249 continue;
4250
4251 if (last != folio) {
4252 walk_update_folio(walk, last, gen, dirty);
4253
4254 last = folio;
4255 dirty = false;
4256 }
4257
4258 if (pte_dirty(ptent))
4259 dirty = true;
4260
4261 young++;
4262 }
4263
4264 walk_update_folio(walk, last, gen, dirty);
4265
4266 lazy_mmu_mode_disable();
4267
4268 /* feedback from rmap walkers to page table walkers */
4269 if (mm_state && suitable_to_scan(i, young))
4270 update_bloom_filter(mm_state, max_seq, pvmw->pmd);
4271
4272 mem_cgroup_put(memcg);
4273
4274 return true;
4275 }
4276
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] mm: bail out when the PMD has been set in bloom filter
2026-02-27 11:42 ` kernel test robot
@ 2026-02-28 0:50 ` Zhaoyang Huang
0 siblings, 0 replies; 5+ messages in thread
From: Zhaoyang Huang @ 2026-02-28 0:50 UTC (permalink / raw)
To: kernel test robot
Cc: zhaoyang.huang, Andrew Morton, Yu Zhao, linux-kernel, steve.kang,
llvm, oe-kbuild-all, Linux Memory Management List
On Fri, Feb 27, 2026 at 7:43 PM kernel test robot <lkp@intel.com> wrote:
>
> Hi zhaoyang.huang,
>
> kernel test robot noticed the following build warnings:
>
> [auto build test WARNING on akpm-mm/mm-everything]
>
> url: https://github.com/intel-lab-lkp/linux/commits/zhaoyang-huang/mm-bail-out-when-the-PMD-has-been-set-in-bloom-filter/20260227-155729
> base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
> patch link: https://lore.kernel.org/r/20260227075250.1128175-1-zhaoyang.huang%40unisoc.com
> patch subject: [PATCH] mm: bail out when the PMD has been set in bloom filter
> config: sparc64-randconfig-002-20260227 (https://download.01.org/0day-ci/archive/20260227/202602271916.OBNa34QU-lkp@intel.com/config)
> compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project 9a109fbb6e184ec9bcce10615949f598f4c974a9)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260227/202602271916.OBNa34QU-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202602271916.OBNa34QU-lkp@intel.com/
>
> All warnings (new ones prefixed by >>):
>
> >> mm/vmscan.c:4206:24: warning: variable 'mm_state' is uninitialized when used here [-Wuninitialized]
> 4206 | if (test_bloom_filter(mm_state, max_seq, pvmw->pmd))
> | ^~~~~~~~
> mm/vmscan.c:4185:35: note: initialize the variable 'mm_state' to silence this warning
> 4185 | struct lru_gen_mm_state *mm_state;
> | ^
> | = NULL
> >> mm/vmscan.c:4206:34: warning: variable 'max_seq' is uninitialized when used here [-Wuninitialized]
> 4206 | if (test_bloom_filter(mm_state, max_seq, pvmw->pmd))
> | ^~~~~~~
> mm/vmscan.c:4186:23: note: initialize the variable 'max_seq' to silence this warning
> 4186 | unsigned long max_seq;
> | ^
> | = 0
> 2 warnings generated.
>
>
> vim +/mm_state +4206 mm/vmscan.c
>
> 4157
> 4158 /******************************************************************************
> 4159 * rmap/PT walk feedback
> 4160 ******************************************************************************/
> 4161
> 4162 /*
> 4163 * This function exploits spatial locality when shrink_folio_list() walks the
> 4164 * rmap. It scans the adjacent PTEs of a young PTE and promotes hot pages. If
> 4165 * the scan was done cacheline efficiently, it adds the PMD entry pointing to
> 4166 * the PTE table to the Bloom filter. This forms a feedback loop between the
> 4167 * eviction and the aging.
> 4168 */
> 4169 bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw)
> 4170 {
> 4171 int i;
> 4172 bool dirty;
> 4173 unsigned long start;
> 4174 unsigned long end;
> 4175 struct lru_gen_mm_walk *walk;
> 4176 struct folio *last = NULL;
> 4177 int young = 1;
> 4178 pte_t *pte = pvmw->pte;
> 4179 unsigned long addr = pvmw->address;
> 4180 struct vm_area_struct *vma = pvmw->vma;
> 4181 struct folio *folio = pfn_folio(pvmw->pfn);
> 4182 struct mem_cgroup *memcg;
> 4183 struct pglist_data *pgdat = folio_pgdat(folio);
> 4184 struct lruvec *lruvec;
> 4185 struct lru_gen_mm_state *mm_state;
> 4186 unsigned long max_seq;
> 4187 int gen;
> 4188
> 4189 lockdep_assert_held(pvmw->ptl);
> 4190 VM_WARN_ON_ONCE_FOLIO(folio_test_lru(folio), folio);
> 4191
> 4192 if (!ptep_clear_young_notify(vma, addr, pte))
> 4193 return false;
> 4194
> 4195 if (spin_is_contended(pvmw->ptl))
> 4196 return true;
> 4197
> 4198 /* exclude special VMAs containing anon pages from COW */
> 4199 if (vma->vm_flags & VM_SPECIAL)
> 4200 return true;
> 4201
> 4202 /* avoid taking the LRU lock under the PTL when possible */
> 4203 walk = current->reclaim_state ? current->reclaim_state->mm_walk : NULL;
> 4204
> 4205 /* may the pmd has been set in bloom filter */
> > 4206 if (test_bloom_filter(mm_state, max_seq, pvmw->pmd))
> 4207 return true;
> 4208
> 4209 start = max(addr & PMD_MASK, vma->vm_start);
> 4210 end = min(addr | ~PMD_MASK, vma->vm_end - 1) + 1;
> 4211
> 4212 if (end - start == PAGE_SIZE)
> 4213 return true;
> 4214
> 4215 if (end - start > MIN_LRU_BATCH * PAGE_SIZE) {
> 4216 if (addr - start < MIN_LRU_BATCH * PAGE_SIZE / 2)
> 4217 end = start + MIN_LRU_BATCH * PAGE_SIZE;
> 4218 else if (end - addr < MIN_LRU_BATCH * PAGE_SIZE / 2)
> 4219 start = end - MIN_LRU_BATCH * PAGE_SIZE;
> 4220 else {
> 4221 start = addr - MIN_LRU_BATCH * PAGE_SIZE / 2;
> 4222 end = addr + MIN_LRU_BATCH * PAGE_SIZE / 2;
> 4223 }
> 4224 }
> 4225
> 4226 memcg = get_mem_cgroup_from_folio(folio);
> 4227 lruvec = mem_cgroup_lruvec(memcg, pgdat);
> 4228 max_seq = READ_ONCE((lruvec)->lrugen.max_seq);
> 4229 gen = lru_gen_from_seq(max_seq);
> 4230 mm_state = get_mm_state(lruvec);
I am confused about the code base which this test is based on. By
checking the base that listed above and linux-next and 7.1-rc1, I
can't find above merged result or I miss anything?
> 4231
> 4232 lazy_mmu_mode_enable();
> 4233
> 4234 pte -= (addr - start) / PAGE_SIZE;
> 4235
> 4236 for (i = 0, addr = start; addr != end; i++, addr += PAGE_SIZE) {
> 4237 unsigned long pfn;
> 4238 pte_t ptent = ptep_get(pte + i);
> 4239
> 4240 pfn = get_pte_pfn(ptent, vma, addr, pgdat);
> 4241 if (pfn == -1)
> 4242 continue;
> 4243
> 4244 folio = get_pfn_folio(pfn, memcg, pgdat);
> 4245 if (!folio)
> 4246 continue;
> 4247
> 4248 if (!ptep_clear_young_notify(vma, addr, pte + i))
> 4249 continue;
> 4250
> 4251 if (last != folio) {
> 4252 walk_update_folio(walk, last, gen, dirty);
> 4253
> 4254 last = folio;
> 4255 dirty = false;
> 4256 }
> 4257
> 4258 if (pte_dirty(ptent))
> 4259 dirty = true;
> 4260
> 4261 young++;
> 4262 }
> 4263
> 4264 walk_update_folio(walk, last, gen, dirty);
> 4265
> 4266 lazy_mmu_mode_disable();
> 4267
> 4268 /* feedback from rmap walkers to page table walkers */
> 4269 if (mm_state && suitable_to_scan(i, young))
> 4270 update_bloom_filter(mm_state, max_seq, pvmw->pmd);
> 4271
> 4272 mem_cgroup_put(memcg);
> 4273
> 4274 return true;
> 4275 }
> 4276
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 5+ messages in thread
* [syzbot ci] Re: mm: bail out when the PMD has been set in bloom filter
2026-02-27 7:52 [PATCH] mm: bail out when the PMD has been set in bloom filter zhaoyang.huang
2026-02-27 11:42 ` kernel test robot
@ 2026-02-28 11:20 ` syzbot ci
2026-03-01 6:14 ` [PATCH] " Gregory Price
2 siblings, 0 replies; 5+ messages in thread
From: syzbot ci @ 2026-02-28 11:20 UTC (permalink / raw)
To: akpm, huangzhaoyang, linux-kernel, linux-mm, steve.kang, yuzhao,
zhaoyang.huang
Cc: syzbot, syzkaller-bugs
syzbot ci has tested the following series
[v1] mm: bail out when the PMD has been set in bloom filter
https://lore.kernel.org/all/20260227075250.1128175-1-zhaoyang.huang@unisoc.com
* [PATCH] mm: bail out when the PMD has been set in bloom filter
and found the following issue:
general protection fault in lru_gen_look_around
Full report is available here:
https://ci.syzbot.org/series/78ce04ff-c36e-4bcc-a097-f457e3ed9e5e
***
general protection fault in lru_gen_look_around
tree: mm-new
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/akpm/mm.git
base: 8982358e1c87e3e1dc0aad37f4f93efe9c1cfe03
arch: amd64
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config: https://ci.syzbot.org/builds/e976d408-587c-416f-85ab-a60940674f35/config
C repro: https://ci.syzbot.org/findings/ea92e1a7-69bd-4608-bc2c-2ff4ca118f9c/c_repro
syz repro: https://ci.syzbot.org/findings/ea92e1a7-69bd-4608-bc2c-2ff4ca118f9c/syz_repro
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
CPU: 1 UID: 0 PID: 5967 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:test_bloom_filter mm/vmscan.c:2785 [inline]
RIP: 0010:lru_gen_look_around+0x45c/0xd20 mm/vmscan.c:4206
Code: 22 be ff 48 c7 44 24 48 00 00 00 00 48 83 c3 28 48 89 dd 48 c1 ed 03 42 80 7c 25 00 00 74 08 48 89 df e8 97 b5 28 00 4c 8b 3b <41> 80 7c 24 03 00 74 0a bf 18 00 00 00 e8 82 b5 28 00 4c 8b 24 25
RSP: 0018:ffffc900046e5c90 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffc900046e5e68 RCX: ffff8881100b1d00
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 1ffff920008dcbcd R08: ffff88811008fcc3 R09: 1ffff11022011f98
R10: dffffc0000000000 R11: ffffed1022011f99 R12: dffffc0000000000
R13: 0000555585af4000 R14: ffffea0006a69fc0 R15: ffff888114457168
FS: 0000555585ad9500(0000) GS:ffff8882a9461000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4753817dac CR3: 00000001b9a5e000 CR4: 00000000000006f0
Call Trace:
<TASK>
folio_referenced_one+0x724/0x1360 mm/rmap.c:962
rmap_walk_anon+0x5cb/0x7c0 mm/rmap.c:2973
rmap_walk mm/rmap.c:3078 [inline]
folio_referenced+0x3c0/0x5f0 mm/rmap.c:1081
folio_check_references mm/vmscan.c:870 [inline]
shrink_folio_list+0x1008/0x5240 mm/vmscan.c:1237
evict_folios+0x3f82/0x5090 mm/vmscan.c:4853
try_to_shrink_lruvec+0xb62/0xfa0 mm/vmscan.c:5008
lru_gen_shrink_lruvec mm/vmscan.c:5157 [inline]
shrink_lruvec+0x54e/0x2b30 mm/vmscan.c:5911
shrink_node_memcgs mm/vmscan.c:6147 [inline]
shrink_node+0xa41/0x3a90 mm/vmscan.c:6188
shrink_zones mm/vmscan.c:6427 [inline]
do_try_to_free_pages+0x6a2/0x1980 mm/vmscan.c:6489
try_to_free_mem_cgroup_pages+0x2ff/0x870 mm/vmscan.c:6811
try_charge_memcg+0x827/0x1560 mm/memcontrol.c:2642
obj_cgroup_charge_pages mm/memcontrol.c:3084 [inline]
__memcg_kmem_charge_page+0x32a/0x530 mm/memcontrol.c:3128
__alloc_frozen_pages_noprof+0x1c1/0x380 mm/page_alloc.c:5271
__alloc_pages_noprof mm/page_alloc.c:5288 [inline]
alloc_pages_bulk_noprof+0x569/0x710 mm/page_alloc.c:5208
alloc_pages_bulk_mempolicy_noprof+0x34e/0x1680 mm/mempolicy.c:2792
vm_area_alloc_pages mm/vmalloc.c:3700 [inline]
__vmalloc_area_node mm/vmalloc.c:3875 [inline]
__vmalloc_node_range_noprof+0xbd9/0x1a80 mm/vmalloc.c:4058
__bpf_map_area_alloc kernel/bpf/syscall.c:404 [inline]
bpf_map_area_alloc+0x12d/0x170 kernel/bpf/syscall.c:411
bloom_map_alloc+0x22f/0x470 kernel/bpf/bloom_filter.c:146
map_create+0xafd/0x16a0 kernel/bpf/syscall.c:1507
__sys_bpf+0x6e1/0x950 kernel/bpf/syscall.c:6210
__do_sys_bpf kernel/bpf/syscall.c:6341 [inline]
__se_sys_bpf kernel/bpf/syscall.c:6339 [inline]
__x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6339
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f475359c799
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fff2e480d98 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 00007f4753815fa0 RCX: 00007f475359c799
RDX: 0000000000000050 RSI: 0000200000000dc0 RDI: 0000000000000000
RBP: 00007f4753632bd9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f4753815fac R14: 00007f4753815fa0 R15: 00007f4753815fa0
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:test_bloom_filter mm/vmscan.c:2785 [inline]
RIP: 0010:lru_gen_look_around+0x45c/0xd20 mm/vmscan.c:4206
Code: 22 be ff 48 c7 44 24 48 00 00 00 00 48 83 c3 28 48 89 dd 48 c1 ed 03 42 80 7c 25 00 00 74 08 48 89 df e8 97 b5 28 00 4c 8b 3b <41> 80 7c 24 03 00 74 0a bf 18 00 00 00 e8 82 b5 28 00 4c 8b 24 25
RSP: 0018:ffffc900046e5c90 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffc900046e5e68 RCX: ffff8881100b1d00
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 1ffff920008dcbcd R08: ffff88811008fcc3 R09: 1ffff11022011f98
R10: dffffc0000000000 R11: ffffed1022011f99 R12: dffffc0000000000
R13: 0000555585af4000 R14: ffffea0006a69fc0 R15: ffff888114457168
FS: 0000555585ad9500(0000) GS:ffff8882a9461000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4753817dac CR3: 00000001b9a5e000 CR4: 00000000000006f0
----------------
Code disassembly (best guess):
0: 22 be ff 48 c7 44 and 0x44c748ff(%rsi),%bh
6: 24 48 and $0x48,%al
8: 00 00 add %al,(%rax)
a: 00 00 add %al,(%rax)
c: 48 83 c3 28 add $0x28,%rbx
10: 48 89 dd mov %rbx,%rbp
13: 48 c1 ed 03 shr $0x3,%rbp
17: 42 80 7c 25 00 00 cmpb $0x0,0x0(%rbp,%r12,1)
1d: 74 08 je 0x27
1f: 48 89 df mov %rbx,%rdi
22: e8 97 b5 28 00 call 0x28b5be
27: 4c 8b 3b mov (%rbx),%r15
* 2a: 41 80 7c 24 03 00 cmpb $0x0,0x3(%r12) <-- trapping instruction
30: 74 0a je 0x3c
32: bf 18 00 00 00 mov $0x18,%edi
37: e8 82 b5 28 00 call 0x28b5be
3c: 4c rex.WR
3d: 8b .byte 0x8b
3e: 24 25 and $0x25,%al
***
If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
Tested-by: syzbot@syzkaller.appspotmail.com
---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] mm: bail out when the PMD has been set in bloom filter
2026-02-27 7:52 [PATCH] mm: bail out when the PMD has been set in bloom filter zhaoyang.huang
2026-02-27 11:42 ` kernel test robot
2026-02-28 11:20 ` [syzbot ci] " syzbot ci
@ 2026-03-01 6:14 ` Gregory Price
2 siblings, 0 replies; 5+ messages in thread
From: Gregory Price @ 2026-03-01 6:14 UTC (permalink / raw)
To: zhaoyang.huang
Cc: Andrew Morton, Yu Zhao, linux-mm, linux-kernel, Zhaoyang Huang,
steve.kang
On Fri, Feb 27, 2026 at 03:52:50PM +0800, zhaoyang.huang wrote:
> From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
>
> There are two reasons to have the recorded PMD bail out from doing
> the following iteration
> 1. It is worth of doing such a trade off thing in terms of reclaiming
> efficiency as test_bloom_filter only consume 20~30 instructions in modern
> processors(25 instructions in ARM64).
> 2. The PMD needs to accumulate young pages until aging happens while the
> new arrived folio reference checking under current max_seq refuse to do so
> which will affect carrying hot PMDs to new generation.
>
Can you explain what the intended *effect* of this patch is?
Why does the PMD need to accumulate young pages?
Why does this patch help that?
How does this affect carrying hot PMDs to the new generation?
What concrete behavior did you see before this patch, and how does
this patch change that behavior?
What is the user-facing effects before / after this patch?
Is this fixing a bug or a tweak to the MGLRU heuristics?
~Gregory
> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> ---
> mm/vmscan.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 9d900be478ea..e50e98291d0d 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -4227,6 +4227,10 @@ bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw)
> /* avoid taking the LRU lock under the PTL when possible */
> walk = current->reclaim_state ? current->reclaim_state->mm_walk : NULL;
>
> + /* may the pmd has been set in bloom filter */
> + if (test_bloom_filter(mm_state, max_seq, pvmw->pmd))
> + return true;
> +
> start = max(addr & PMD_MASK, vma->vm_start);
> end = min(addr | ~PMD_MASK, vma->vm_end - 1) + 1;
>
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-03-01 6:14 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-02-27 7:52 [PATCH] mm: bail out when the PMD has been set in bloom filter zhaoyang.huang
2026-02-27 11:42 ` kernel test robot
2026-02-28 0:50 ` Zhaoyang Huang
2026-02-28 11:20 ` [syzbot ci] " syzbot ci
2026-03-01 6:14 ` [PATCH] " Gregory Price
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox