All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gabriele Monaco <gmonaco@redhat.com>
To: wen.yang@linux.dev
Cc: "Nam Cao" <namcao@linutronix.de>,
	linux-trace-kernel@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Thomas Weißschuh" <thomas.weissschuh@linutronix.de>
Subject: Re: [PATCH v3 1/4] rv/reactors: use context-sensitive lockdep wait type in rv_react()
Date: Wed, 12 Aug 2026 14:34:03 +0200	[thread overview]
Message-ID: <38decc4f7ef5b6f03b37705c7e97f22a7e40d7e2.camel@redhat.com> (raw)
In-Reply-To: <26526e555baa5118325b2383e9f7f0f8f9b6a199.1786294920.git.wen.yang@linux.dev>

On Mon, 2026-08-10 at 01:10 +0800, wen.yang@linux.dev wrote:
> From: Wen Yang <wen.yang@linux.dev>
> 
> Reactors must not explicitly take locks, so they should comply with
> LD_WAIT_FREE.  However, reactor callbacks can run with preemption
> enabled on any kernel (not just PREEMPT_RT).  If a timer interrupt
> fires during the callback, the interrupt exit path schedules and
> acquires rq->__lock (LD_WAIT_SPIN) while the lockdep override map that
> declared LD_WAIT_FREE is still held, triggering a spurious
> "Invalid wait context" warning:
> 
>     [ BUG: Invalid wait context ]
>     context-{5:5}
>     1 lock held by kunit_try_catch/209:
>      #0: (rv_react_map-wait-type-override){+.+.}-{1:1}
>     kunit_try_catch/209 is trying to lock:
>     ffff8a743ed3e8a0 (&rq->__lock){-...}-{2:2}
> 
> Fixes: 69d8895cb9a9 ("rv: Add explicit lockdep context for reactors")
> Suggested-by: Gabriele Monaco <gmonaco@redhat.com>

You came up with the idea, I at most suggested how I'd like it worded in the
comment.

Anyway, I'd appreciate comments/acks from the other folks in the loop, but from
my side this looks good.

Reviewed-by: Gabriele Monaco <gmonaco@redhat.com>

Thanks,
Gabriele

> Signed-off-by: Wen Yang <wen.yang@linux.dev>
> Cc: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
>  kernel/trace/rv/rv_reactors.c | 20 +++++++++++++++-----
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/kernel/trace/rv/rv_reactors.c b/kernel/trace/rv/rv_reactors.c
> index 2f5fc8d18dea..5830229210e8 100644
> --- a/kernel/trace/rv/rv_reactors.c
> +++ b/kernel/trace/rv/rv_reactors.c
> @@ -465,18 +465,28 @@ int init_rv_reactors(struct dentry *root_dir)
>  
>  void rv_react(struct rv_monitor *monitor, const char *msg, ...)
>  {
> -	static DEFINE_WAIT_OVERRIDE_MAP(rv_react_map, LD_WAIT_FREE);
> +	/*
> +	 * Reactors must not explicitly take locks, so they should be
> +	 * LD_WAIT_FREE.  However, reactor callbacks can run with preemption
> +	 * enabled, meaning the preempting code (e.g. the scheduler taking
> +	 * rq->__lock at LD_WAIT_SPIN) may violate that constraint.  Use
> +	 * LD_WAIT_SPIN in preemptible contexts to avoid false-positive
> lockdep
> +	 * reports; keep LD_WAIT_FREE in NMI/hardirq where preemption is
> +	 * disabled and the scheduler cannot run.
> +	 */
> +	static DEFINE_WAIT_OVERRIDE_MAP(rv_react_map,        LD_WAIT_SPIN);
> +	static DEFINE_WAIT_OVERRIDE_MAP(rv_react_map_atomic, LD_WAIT_FREE);
> +	struct lockdep_map * __maybe_unused map;
>  	va_list args;
>  
>  	if (!rv_reacting_on() || !monitor->react)
>  		return;
>  
> +	map = (in_nmi() || in_hardirq()) ? &rv_react_map_atomic :
> &rv_react_map;
>  	va_start(args, msg);
> -
> -	lock_map_acquire_try(&rv_react_map);
> +	lock_map_acquire_try(map);
>  	monitor->react(msg, args);
> -	lock_map_release(&rv_react_map);
> -
> +	lock_map_release(map);
>  	va_end(args);
>  }
>  EXPORT_SYMBOL_GPL(rv_react);


  reply	other threads:[~2026-08-12 12:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-09 17:10 [PATCH v3 0/4] rv/reactors: fix lockdep warning and add KUnit tests wen.yang
2026-08-09 17:10 ` [PATCH v3 1/4] rv/reactors: use context-sensitive lockdep wait type in rv_react() wen.yang
2026-08-12 12:34   ` Gabriele Monaco [this message]
2026-08-17  8:18     ` Nam Cao
2026-08-19  7:12       ` Gabriele Monaco
2026-08-19  9:24         ` Thomas Weißschuh
2026-08-19 17:28           ` Wen Yang
2026-08-25 14:43             ` Gabriele Monaco
2026-08-09 17:10 ` [PATCH v3 2/4] rv/reactors: propagate rv_register_reactor() error from reactor init wen.yang
2026-08-17 10:54   ` Nam Cao
2026-08-09 17:10 ` [PATCH v3 3/4] rv/reactors: export rv_register_reactor() and rv_unregister_reactor() wen.yang
2026-08-09 17:10 ` [PATCH v3 4/4] rv/reactors: add KUnit tests for reactor registration and dispatch wen.yang
2026-08-12 12:58   ` Gabriele Monaco
2026-08-17 10:52   ` Nam Cao
2026-08-17 11:05     ` Gabriele Monaco

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=38decc4f7ef5b6f03b37705c7e97f22a7e40d7e2.camel@redhat.com \
    --to=gmonaco@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=namcao@linutronix.de \
    --cc=thomas.weissschuh@linutronix.de \
    --cc=wen.yang@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.