Re: [PATCH v2 3/6] mm/page_owner: add open-coded page_owner iterator

["zhen.ni" <zhen.ni@easystack.cn>]

在 2026/10/13 20:49, sashiko-bot@kernel.org 写道:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] mm: soft lockup in page_owner_next_eligible via BPF iter
> --
> 
> commit b7f01516d35223b7a6800ce695c29a9203809699
> Author: Zhen Ni <zhen.ni@easystack.cn>
> 
> mm/page_owner: add open-coded page_owner iterator
> 
> This patch adds an open-coded bpf_iter over the pages eligible for
> page_owner output, reusing page_owner_next_eligible(). It also provides a
> sleepable BPF program to drive the iterator and retrieve stack traces.
> 
>> diff --git a/mm/page_owner_iter.c b/mm/page_owner_iter.c
>> index 938cb42ab7d79..ac7e69ba0cef3 100644
>> --- a/mm/page_owner_iter.c
>> +++ b/mm/page_owner_iter.c
> [ ... ]
>> @@ -122,3 +123,55 @@ int page_owner_iter_register(void)
>>   
>>   	return bpf_iter_reg_target(&page_owner_iter_reg_info);
>>   }
>> +
>> +/* opaque to BPF programs */
>> +struct bpf_iter_page_owner {
>> +	__u64 __opaque[16];
>> +} __attribute__((aligned(8)));
>> +
>> +struct bpf_iter_page_owner_kern {
>> +	struct page_owner_scan scan;
>> +} __attribute__((aligned(8)));
>> +
>> +__bpf_kfunc_start_defs();
> [ ... ]
>> +__bpf_kfunc struct page_owner_scan *
>> +bpf_iter_page_owner_next(struct bpf_iter_page_owner *it)
>> +{
>> +	struct bpf_iter_page_owner_kern *kit = (void *)it;
>> +
>> +	cond_resched();
>> +
>> +	if (kit->scan.page)
>> +		kit->scan.pfn++;
>> +
>> +	if (!page_owner_next_eligible(&kit->scan))
>> +		return NULL;
> 
> [Severity: High]
> Can this iterator cause a soft lockup or RCU stall?
> 
> If page_owner is disabled, page_ext_get() inside page_owner_next_eligible()
> constantly returns NULL, triggering a continue on every single page up to
> max_pfn:
> 
> mm/page_owner.c:page_owner_next_eligible() {
> 	...
> 	for (; pfn < max_pfn; pfn++) {
> 		...
> 		page_ext = page_ext_get(page);
> 		if (unlikely(!page_ext))
> 			continue;
> 		...
> ext_put_continue:
> 		page_ext_put(page_ext);
> 		cond_resched();
> 	}
> 	...
> }
> 
> Because the continue statement skips the ext_put_continue block, the loop
> never calls cond_resched(). When called from this new sleepable BPF
> iterator, won't it spin over the entire physical memory space in a tight
> loop without yielding?
> 
>> +
>> +	return &kit->scan;
>> +}
> 

The soft lockup / RCU stall doesn't seem critical, since the debugfs
path behaves the same way, but I think it's worth disabling these kfuncs
when page_owner is not enabled. I'll guard them with
static_branch_unlikely(&page_owner_inited).


Thanks,
Zhen