From: sashiko-bot@kernel.org
To: "Zhen Ni" <zhen.ni@easystack.cn>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH 1/6] mm/page_owner: extract page_owner_next_eligible() from read loop
Date: Fri, 09 Oct 2026 11:35:12 +0000 [thread overview]
Message-ID: <sashiko-outbox-165395@kernel.org> (raw)
In-Reply-To: <20261009112308.240769-2-zhen.ni@easystack.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mm: soft lockup in page_owner_next_eligible() due to missing cond_resched()
--
commit 303a10c305ed333982228df86334f12bd6d8a3c2
Author: Zhen Ni <zhen.ni@easystack.cn>
mm/page_owner: extract page_owner_next_eligible() from read loop
This commit extracts the page scanning logic from read_page_owner() into a
dedicated helper, page_owner_next_eligible(). It advances a cursor to the
next eligible page and takes a snapshot of the page_owner record inside the
page_ext RCU window.
> diff --git a/mm/page_owner.c b/mm/page_owner.c
> index fbbda7ba914ba..bafe474f33602 100644
> --- a/mm/page_owner.c
> +++ b/mm/page_owner.c
[ ... ]
> @@ -798,37 +795,67 @@ read_page_owner(struct file *file, char __user *buf, size_t count, loff_t *ppos)
> goto ext_put_continue;
>
> /*
> - * Access to page_ext->handle isn't synchronous so we should
> - * be careful to access it.
> + * Take a snapshot of the page_owner record inside the RCU
> + * window, then validate it, so that print_page_owner()
> + * reads the checked handle from the same snapshot.
> */
> - handle = READ_ONCE(page_owner->handle);
> - if (!handle)
> - goto ext_put_continue;
> + scan->pfn = pfn;
> + scan->page = page;
> + scan->po_snap = *page_owner;
> + page_ext_put(page_ext);
>
> + if (!scan->po_snap.handle)
> + continue;
[Severity: High]
Could this cause a soft lockup? By using a continue statement here in
page_owner_next_eligible(), we jump directly to the next loop iteration
(advancing pfn) without executing cond_resched() at the end of the loop
block.
If a large contiguous sequence of allocated pages lacks stack handles
(e.g., if stack depot is exhausted or during early non-tracked allocations),
the kernel could iterate over millions of pages without yielding.
The original implementation used goto ext_put_continue; which correctly
yielded. Does this need to be updated to explicitly yield or use the
goto instead?
> +
> + return true;
> +
> +ext_put_continue:
> + page_ext_put(page_ext);
> + cond_resched();
> + }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261009112308.240769-1-zhen.ni@easystack.cn?part=1
next prev parent reply other threads:[~2026-10-09 11:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-09 11:23 [PATCH 0/6] mm/page_owner: add bpf_iter and kfuncs Zhen Ni
2026-10-09 11:23 ` [PATCH 1/6] mm/page_owner: extract page_owner_next_eligible() from read loop Zhen Ni
2026-10-09 11:35 ` sashiko-bot [this message]
2026-10-10 9:40 ` zhen.ni
2026-10-09 11:23 ` [PATCH 2/6] mm/page_owner: add bpf_iter target "page_owner" Zhen Ni
2026-10-09 11:50 ` sashiko-bot
2026-10-12 6:28 ` zhen.ni
2026-10-09 11:23 ` [PATCH 3/6] mm/page_owner: add open-coded page_owner iterator Zhen Ni
2026-10-09 12:00 ` sashiko-bot
2026-10-12 6:41 ` zhen.ni
2026-10-09 11:23 ` [PATCH 4/6] mm/page_owner: add bpf_page_owner_get_nid() kfunc Zhen Ni
2026-10-09 12:20 ` sashiko-bot
2026-10-12 7:01 ` zhen.ni
2026-10-09 11:23 ` [PATCH 5/6] mm/page_owner: add bpf_page_owner_get_memcg_info() kfunc Zhen Ni
2026-10-09 12:43 ` sashiko-bot
2026-10-12 7:09 ` zhen.ni
2026-10-09 11:23 ` [PATCH 6/6] selftests/bpf: add tests for the page_owner bpf_iter target Zhen Ni
2026-10-09 12:50 ` sashiko-bot
2026-10-12 7:15 ` zhen.ni
2026-10-09 13:48 ` bot+bpf-ci
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-165395@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=zhen.ni@easystack.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.