From: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
To: Harry Yoo <harry@kernel.org>, Zhan Xusheng <zhanxusheng1024@gmail.com>
Cc: urezki@gmail.com, paulmck@kernel.org, qiang.zhang@linux.dev,
akpm@linux-foundation.org, hao.li@linux.dev, cl@gentwo.org,
rientjes@google.com, roman.gushchin@linux.dev,
linux-mm@kvack.org, rcu@vger.kernel.org,
linux-kernel@vger.kernel.org, zhanxusheng@xiaomi.com
Subject: Re: [PATCH 2/2] mm/slab: don't queue the page cache work under krcp->lock
Date: Wed, 4 Nov 2026 09:19:10 +0100 [thread overview]
Message-ID: <e4951dae-e010-4d75-a4c1-397e7c5cd05e@kernel.org> (raw)
In-Reply-To: <auifTNDwbBTJeu81@thinkstation>
On 11/2/26 15:35, Harry Yoo wrote:
> Here I added bit more context and adjusted comment. End result:
>
> mm/slab: don't queue the page cache work under krcp->lock
>
> Commit 56292e8609e3 ("rcu/tree: Defer kvfree_rcu() allocation to a
> clean context") deferred page allocations to a workqueue. To avoid
> deadlocks with the scheduler, it used hrtimer to queue the work instead
> of queueing it directly.
>
> Commit d0bfa8b3c411 ("kvfree_rcu: Release a page cache under memory
> pressure") later added a backoff mechanism under memory pressure, but
> did not consider that queue_delayed_work() with delay = 0 immediately
> queues the work and introduced the deadlock commit 56292e8609e3 tried to
> avoid.
>
> run_page_cache_worker() runs under krcp->lock, from kvfree_call_rcu()
> callers that may hold more, such as set_cpus_allowed_force() under
> pi_lock, so it kicks the refill work from an hrtimer. Under memory
> pressure it instead queues the work with a delay of
> rcutree.rcu_delay_page_cache_fill_msec, which may be 0, and a zero delay
> queues it at once, taking pool->lock under krcp->lock.
>
> With the delay set to 0, calling kvfree_rcu() on vmalloc memory under
> pi_lock after a drop_caches makes lockdep report:
>
> Chain exists of:
> &pool->lock --> &p->pi_lock --> krc.lock
>
> Use the hrtimer when the delay is 0.
>
> Fixes: d0bfa8b3c411 ("kvfree_rcu: Release a page cache under memory pressure")
> Cc: stable@vger.kernel.org
> Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
> Link: https://patch.msgid.link/20261028134647.3176080-2-zhanxusheng1024@gmail.com
> [ harry@kernel.org: add more context to changelog and adjust comment ]
> Signed-off-by: Harry Yoo (Meta) <harry@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
> mm/slab_common.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 41dea01a8c1f..051ca63c0b67 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -1987,7 +1987,15 @@ run_page_cache_worker(struct kfree_rcu_cpu *krcp)
>
> if (rcu_scheduler_active == RCU_SCHEDULER_RUNNING &&
> !atomic_xchg(&krcp->work_in_progress, 1)) {
> - if (atomic_read(&krcp->backoff_page_cache_fill)) {
> + /*
> + * Use the hrtimer to avoid a deadlock with the scheduler
> + * by waking up the worker directly. queue_delayed_work()
> + * uses a timer to queue the work, so it's fine.
> + * But with delay = 0 it queues the work immediately.
> + * Fall back to the hrtimer in that case.
> + */
> + if (atomic_read(&krcp->backoff_page_cache_fill) &&
> + rcu_delay_page_cache_fill_msec) {
> queue_delayed_work(rcu_reclaim_wq,
> &krcp->page_cache_work,
> msecs_to_jiffies(rcu_delay_page_cache_fill_msec));
next prev parent reply other threads:[~2026-11-04 8:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-28 13:46 [PATCH 1/2] mm/slab: restore the rcutree. prefix of the kvfree_rcu parameters Zhan Xusheng
2026-10-28 13:46 ` [PATCH 2/2] mm/slab: don't queue the page cache work under krcp->lock Zhan Xusheng
2026-11-02 14:35 ` Harry Yoo
2026-11-04 8:19 ` Vlastimil Babka (SUSE) [this message]
2026-10-28 15:23 ` [PATCH 1/2] mm/slab: restore the rcutree. prefix of the kvfree_rcu parameters Harry Yoo
2026-11-02 14:33 ` Harry Yoo
2026-11-04 8:17 ` Vlastimil Babka (SUSE)
2026-11-02 14:27 ` Harry Yoo (Meta)
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=e4951dae-e010-4d75-a4c1-397e7c5cd05e@kernel.org \
--to=vbabka@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cl@gentwo.org \
--cc=hao.li@linux.dev \
--cc=harry@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=paulmck@kernel.org \
--cc=qiang.zhang@linux.dev \
--cc=rcu@vger.kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=urezki@gmail.com \
--cc=zhanxusheng1024@gmail.com \
--cc=zhanxusheng@xiaomi.com \
/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.