All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Puranjay Mohan" <puranjay@kernel.org>
Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-rt-devel@lists.linux.dev
Subject: Re: [PATCH v2 1/6] rcu: Make call_rcu() safe to call from any context
Date: Mon, 03 Aug 2026 14:18:14 +0000	[thread overview]
Message-ID: <20260803141815.A765F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260803135329.2327280-1-puranjay@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Concurrent `rcu_barrier()` calls can cause missed wakeups and system hangs in `irq_work_sync()` on architectures without IPI-based `irq_work`.
--

--- Patch [1]: [PATCH v2 1/6] rcu: Make call_rcu() safe to call from any context ---
commit f033f4bd0a671eccd668878bff133f083ff63d97
Author: Puranjay Mohan <puranjay@kernel.org>

rcu: Make call_rcu() safe to call from any context

This commit makes call_rcu() safe to call from any context by deferring
the callback on a per-CPU llist when interrupts are disabled, and raising
an irq_work to re-issue it once interrupts are enabled. It introduces
rcu_defer_flush() to flush these deferred callbacks during rcu_barrier().

> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 96848fc1f02b8..31e2d2207ac03 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c

[ ... ]

> @@ -3896,8 +3990,12 @@ void rcu_barrier(void)
>  	unsigned long flags;
>  	unsigned long gseq;
>  	struct rcu_data *rdp;
> -	unsigned long s = rcu_seq_snap(&rcu_state.barrier_sequence);
> +	unsigned long s;
>  
> +	/* Register any deferred callbacks before snapshotting the sequence. */
> +	rcu_defer_flush();
> +

[Severity: High]
Because rcu_defer_flush() is called before taking the rcu_state.barrier_mutex,
can multiple threads execute it concurrently?

If multiple threads call rcu_defer_flush() concurrently, they will both
call irq_work_sync(&rdp->defer_work) on the same per-CPU irq_work:

kernel/rcu/tree.c:rcu_defer_flush() {
...
    if (cpu_online(cpu))
        irq_work_sync(&rdp->defer_work);
...
}

On architectures where arch_irq_work_has_interrupt() is false,
irq_work_sync() waits using rcuwait_wait_event(). Since rcuwait only
supports a single waiter, won't concurrent callers overwrite the internal
task pointer, causing one of the threads to miss the wakeup and hang
indefinitely?

> +	s = rcu_seq_snap(&rcu_state.barrier_sequence);
>  	rcu_barrier_trace(TPS("Begin"), -1, s);
>  
>  	/* Take mutex to serialize concurrent rcu_barrier() requests. */
>  	mutex_lock(&rcu_state.barrier_mutex);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260803134839.2103051-1-puranjay@kernel.org?part=1

  reply	other threads:[~2026-08-03 14:18 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-03 13:48 [PATCH v2 0/6] rcu,srcu: Make call_rcu()/call_srcu() safe from any context Puranjay Mohan
2026-08-03 13:53 ` [PATCH v2 1/6] rcu: Make call_rcu() safe to call " Puranjay Mohan
2026-08-03 14:18   ` sashiko-bot [this message]
2026-08-03 13:53 ` [PATCH v2 2/6] rcu: Make Tiny " Puranjay Mohan
2026-08-03 14:35   ` sashiko-bot
2026-08-03 14:40     ` Puranjay Mohan
2026-08-03 13:53 ` [PATCH v2 3/6] srcu: Make call_srcu() " Puranjay Mohan
2026-08-03 14:49   ` sashiko-bot
2026-08-03 14:52     ` Puranjay Mohan
2026-08-03 13:53 ` [PATCH v2 4/6] srcu: Make Tiny " Puranjay Mohan
2026-08-03 13:53 ` [PATCH v2 5/6] rcutorture: Exercise ->call() from NMI context Puranjay Mohan
2026-08-03 13:53 ` [PATCH v2 6/6] selftests/bpf: Add a call_srcu() re-entry reproducer Puranjay Mohan
2026-08-03 15:15   ` sashiko-bot

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=20260803141815.A765F1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-devel@lists.linux.dev \
    --cc=puranjay@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.