All of lore.kernel.org
 help / color / mirror / Atom feed
From: Neeraj Upadhyay <Neeraj.Upadhyay@kernel.org>
To: Frederic Weisbecker <frederic@kernel.org>,
	kernel test robot <oliver.sang@intel.com>
Cc: Joel Fernandes <joelagnelf@nvidia.com>,
	oe-lkp@lists.linux.dev, lkp@intel.com,
	linux-kernel@vger.kernel.org,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Xiongfeng Wang <wangxiongfeng2@huawei.com>,
	Qi Xi <xiqi2@huawei.com>, "Paul E. McKenney" <paulmck@kernel.org>,
	Linux Kernel Functional Testing <lkft@linaro.org>,
	rcu@vger.kernel.org
Subject: Re: [linus:master] [rcu]  b41642c877: BUG:kernel_hang_in_boot_stage
Date: Wed, 13 Aug 2025 10:10:24 +0530	[thread overview]
Message-ID: <20250813044024.GA2872@neeraj.linux> (raw)
In-Reply-To: <aJY1DsIUQxzq1U1Q@localhost.localdomain>

Hi kernel test robot,

> #syz test
> 
> >From a3cc7624264743996d2ad1295741933103a8d63b Mon Sep 17 00:00:00 2001
> From: Frederic Weisbecker <frederic@kernel.org>
> Date: Fri, 8 Aug 2025 19:03:22 +0200
> Subject: [PATCH] rcu: Fix racy re-initialization of irq_work causing hangs
> 
> RCU re-initializes the deferred QS irq work everytime before attempting
> to queue it. However there are situations where the irq work is
> attempted to be queued even though it is already queued. In that case
> re-initializing messes-up with the irq work queue that is about to be
> handled.
> 
> The chances for that to happen are higher when the architecture doesn't
> support self-IPIs and irq work are then all lazy, such as with the
> following sequence:
> 
> 1) rcu_read_unlock() is called when IRQs are disabled and there is a
>    grace period involving blocked tasks on the node. The irq work
>    is then initialized and queued.
> 
> 2) The related tasks are unblocked and the CPU quiescent state
>    is reported. rdp->defer_qs_iw_pending is reset to DEFER_QS_IDLE,
>    allowing the irq work to be requeued in the future (note the previous
>    one hasn't fired yet).
> 
> 3) A new grace period starts and the node has blocked tasks.
> 
> 4) rcu_read_unlock() is called when IRQs are disabled again. The irq work
>    is re-initialized (but it's queued! and its node is cleared) and
>    requeued. Which means it's requeued to itself.
> 
> 5) The irq work finally fires with the tick. But since it was requeued
>    to itself, it loops and hangs.
> 
> Fix this with initializing the irq work only once before the CPU boots.
> 
> Fixes: b41642c87716 ("rcu: Fix rcu_read_unlock() deadloop due to IRQ work")
> Reported-by: kernel test robot <oliver.sang@intel.com>
> Closes: https://lore.kernel.org/oe-lkp/202508071303.c1134cce-lkp@intel.com
> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
> ---

Can you please update testing results with the proposed fix?


- Neeraj


  parent reply	other threads:[~2025-08-13  4:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-07  5:39 [linus:master] [rcu] b41642c877: BUG:kernel_hang_in_boot_stage kernel test robot
2025-08-08 17:34 ` Frederic Weisbecker
2025-08-09 19:02   ` Joel Fernandes
2025-08-13  4:40   ` Neeraj Upadhyay [this message]
2025-08-13 13:43     ` Oliver Sang
2025-08-13 13:55       ` Neeraj Upadhyay

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=20250813044024.GA2872@neeraj.linux \
    --to=neeraj.upadhyay@kernel.org \
    --cc=frederic@kernel.org \
    --cc=joelagnelf@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkft@linaro.org \
    --cc=lkp@intel.com \
    --cc=oe-lkp@lists.linux.dev \
    --cc=oliver.sang@intel.com \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    --cc=wangxiongfeng2@huawei.com \
    --cc=xiqi2@huawei.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.