All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Waiman Long <longman@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Clark Williams <clrkwllms@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev
Subject: Re: [PATCH v5] debugobjects: Don't call fill_pool() in early boot hardirq context
Date: Sun, 7 Jun 2026 07:15:06 +0200	[thread overview]
Message-ID: <aiT-Wp4rAvJoN6iG@gmail.com> (raw)
In-Reply-To: <20260605173038.495075-1-longman@redhat.com>


* Waiman Long <longman@redhat.com> wrote:

> When booting a debug PREEMPT_RT kernel on an arm64 system with grace
> processor, a "inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage"
> lockdep warning message was reported to the console.
> 
> During early boot, interrupts are getting enabled before the scheduler
> is enabled. In this window (before SYSTEM_SCHEDULING is set) interrupts
> can fire and attempt to fill the pool from within the hardirq. This can
> lead to a deadlock the interrupt occurred while in the memory allocator.
> 
> Add a new can_fill_pool() helper and reorder the exception rule and
> forbid this scenario by excluding allocations from hardirq.
> 
> Fixes: 06e0ae988f6e ("debugobjects: Allow to refill the pool before SYSTEM_SCHEDULING")
> Co-developed-by: Waiman Long <longman@redhat.com>
> Co-developed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Co-developed-by: Thomas Gleixner <tglx@linutronix.de>
> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Signed-off-by: Waiman Long <longman@redhat.com>
> ---
>  lib/debugobjects.c | 46 +++++++++++++++++++++++++++++++++++++---------
>  1 file changed, 37 insertions(+), 9 deletions(-)
> 
> diff --git a/lib/debugobjects.c b/lib/debugobjects.c
> index b18a682fe3da..6fb00e08a4e2 100644
> --- a/lib/debugobjects.c
> +++ b/lib/debugobjects.c
> @@ -720,6 +720,41 @@ static inline bool debug_objects_is_pi_blocked_on(void)
>  #endif
>  }
>  
> +static inline bool can_fill_pool(void)
> +{
> +	/*
> +	 * On !RT enabled kernels there are no restrictions and spinlock_t and
> +	 * raw_spinlock_t are the same types.
> +	 */
> +	if (!IS_ENABLED(CONFIG_PREEMPT_RT))
> +		return true;

> -	if (!IS_ENABLED(CONFIG_PREEMPT_RT) || system_state < SYSTEM_SCHEDULING ||
> -	    (preemptible() && !debug_objects_is_pi_blocked_on())) {
> +	if (can_fill_pool()) {

Would have been nice to have this as two patches: first one
factors out the check into can_fill_pool() without changing the
logic, while the second one applies the fix to can_fill_pool().

Thanks,

	Ingo

  parent reply	other threads:[~2026-06-07  5:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-05 17:30 [PATCH v5] debugobjects: Don't call fill_pool() in early boot hardirq context Waiman Long
2026-06-06 12:38 ` [tip: core/urgent] " tip-bot2 for Waiman Long
2026-06-07  5:15 ` Ingo Molnar [this message]
2026-06-08  2:21   ` [PATCH v5] " Waiman Long

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=aiT-Wp4rAvJoN6iG@gmail.com \
    --to=mingo@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=bigeasy@linutronix.de \
    --cc=clrkwllms@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-devel@lists.linux.dev \
    --cc=longman@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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.