rcu.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/3] srcu: A few NMI-safe debugging updates
@ 2022-10-13 17:22 Frederic Weisbecker
  2022-10-13 17:22 ` [PATCH 1/3] srcu: Warn when NMI-unsafe API is used in NMI Frederic Weisbecker
                   ` (3 more replies)
  0 siblings, 4 replies; 7+ messages in thread
From: Frederic Weisbecker @ 2022-10-13 17:22 UTC (permalink / raw)
  To: Paul E . McKenney
  Cc: LKML, Frederic Weisbecker, quic_neeraju, joel, rcu, Lai Jiangshan

Hi,

This has passed SRCU-N, SRCU-P and SRCU-T so far.

git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
	srcu/nmisafe

HEAD: 3cfdc2c6b8e89ca3c33954ea9b0d69e8cd141412

Thanks,
	Frederic
---

Frederic Weisbecker (3):
      srcu: Warn when NMI-unsafe API is used in NMI
      srcu: Explain the reason behind the read side critical section on GP start
      srcu: Debug NMI safety even on archs that don't require it


 include/linux/srcu.h     | 44 ++++++++++++++++++++++++++++++++++----------
 include/linux/srcutiny.h | 12 ------------
 include/linux/srcutree.h |  7 -------
 kernel/rcu/srcutree.c    | 31 ++++++++++++++++---------------
 4 files changed, 50 insertions(+), 44 deletions(-)

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH 1/3] srcu: Warn when NMI-unsafe API is used in NMI
  2022-10-13 17:22 [PATCH 0/3] srcu: A few NMI-safe debugging updates Frederic Weisbecker
@ 2022-10-13 17:22 ` Frederic Weisbecker
  2022-10-14 22:45   ` Joel Fernandes
  2022-10-13 17:22 ` [PATCH 2/3] srcu: Explain the reason behind the read side critical section on GP start Frederic Weisbecker
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 7+ messages in thread
From: Frederic Weisbecker @ 2022-10-13 17:22 UTC (permalink / raw)
  To: Paul E . McKenney
  Cc: LKML, Frederic Weisbecker, quic_neeraju, joel, rcu, Lai Jiangshan

Using the NMI-unsafe reader API from within NMIs is very likely to be
buggy for three reasons:

1) NMIs aren't strictly re-entrant (a pending nested NMI will execute
   at the end of the current one) so it should be fine to use a
   non-atomic increment here. However breakpoints can still interrupt
   NMIs and if a breakpoint callback has a reader on that same ssp, a
   racy increment can happen.

2) If the only reader site for a given ssp is in an NMI, RCU is definetly
   a better choice over SRCU.

3) Because of the previous reason (2), an ssp having an SRCU read side
   critical section in an NMI is likely to have another one from a task
   context.

For all these reasons, warn if an nmi unsafe reader API is used from an
NMI.

Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
---
 kernel/rcu/srcutree.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
index c54142374793..8b7ef1031d89 100644
--- a/kernel/rcu/srcutree.c
+++ b/kernel/rcu/srcutree.c
@@ -642,6 +642,8 @@ static void srcu_check_nmi_safety(struct srcu_struct *ssp, bool nmi_safe)
 
 	if (!IS_ENABLED(CONFIG_PROVE_RCU))
 		return;
+	/* NMI-unsafe use in NMI is a bad sign */
+	WARN_ON_ONCE(!nmi_safe && in_nmi());
 	sdp = raw_cpu_ptr(ssp->sda);
 	old_nmi_safe_mask = READ_ONCE(sdp->srcu_nmi_safety);
 	if (!old_nmi_safe_mask) {
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [PATCH 2/3] srcu: Explain the reason behind the read side critical section on GP start
  2022-10-13 17:22 [PATCH 0/3] srcu: A few NMI-safe debugging updates Frederic Weisbecker
  2022-10-13 17:22 ` [PATCH 1/3] srcu: Warn when NMI-unsafe API is used in NMI Frederic Weisbecker
@ 2022-10-13 17:22 ` Frederic Weisbecker
  2022-10-13 17:22 ` [PATCH 3/3] srcu: Debug NMI safety even on archs that don't require it Frederic Weisbecker
  2022-10-14 18:35 ` [PATCH 0/3] srcu: A few NMI-safe debugging updates Paul E. McKenney
  3 siblings, 0 replies; 7+ messages in thread
From: Frederic Weisbecker @ 2022-10-13 17:22 UTC (permalink / raw)
  To: Paul E . McKenney
  Cc: LKML, Frederic Weisbecker, quic_neeraju, joel, rcu, Lai Jiangshan

Tell about the need to protect against concurrent updaters who may
overflow the GP counter behind the current update.

Reported-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
---
 kernel/rcu/srcutree.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
index 8b7ef1031d89..5bf67d997796 100644
--- a/kernel/rcu/srcutree.c
+++ b/kernel/rcu/srcutree.c
@@ -1154,6 +1154,11 @@ static unsigned long srcu_gp_start_if_needed(struct srcu_struct *ssp,
 	int ss_state;
 
 	check_init_srcu_struct(ssp);
+	/*
+	 * While starting the new gp if needed, make sure we are in an SRCU read
+	 * side critical section so that the gp sequence can't wrap around in
+	 * the middle.
+	 */
 	idx = __srcu_read_lock_nmisafe(ssp, false);
 	ss_state = smp_load_acquire(&ssp->srcu_size_state);
 	if (ss_state < SRCU_SIZE_WAIT_CALL)
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [PATCH 3/3] srcu: Debug NMI safety even on archs that don't require it
  2022-10-13 17:22 [PATCH 0/3] srcu: A few NMI-safe debugging updates Frederic Weisbecker
  2022-10-13 17:22 ` [PATCH 1/3] srcu: Warn when NMI-unsafe API is used in NMI Frederic Weisbecker
  2022-10-13 17:22 ` [PATCH 2/3] srcu: Explain the reason behind the read side critical section on GP start Frederic Weisbecker
@ 2022-10-13 17:22 ` Frederic Weisbecker
  2022-10-14 18:35 ` [PATCH 0/3] srcu: A few NMI-safe debugging updates Paul E. McKenney
  3 siblings, 0 replies; 7+ messages in thread
From: Frederic Weisbecker @ 2022-10-13 17:22 UTC (permalink / raw)
  To: Paul E . McKenney
  Cc: LKML, Frederic Weisbecker, quic_neeraju, joel, rcu, Lai Jiangshan

Currently the NMI safety debugging is only performed on architectures
that don't support NMI-safe this_cpu_inc().

Reorder the code so that other architectures like x86 also detect bad
uses.

Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
---
 include/linux/srcu.h     | 44 +++++++++++++++++++++++++++++++---------
 include/linux/srcutiny.h | 12 -----------
 include/linux/srcutree.h |  7 -------
 kernel/rcu/srcutree.c    | 24 ++++++++--------------
 4 files changed, 43 insertions(+), 44 deletions(-)

diff --git a/include/linux/srcu.h b/include/linux/srcu.h
index 565f60d57484..f0814ffca34b 100644
--- a/include/linux/srcu.h
+++ b/include/linux/srcu.h
@@ -52,8 +52,6 @@ int init_srcu_struct(struct srcu_struct *ssp);
 #else
 /* Dummy definition for things like notifiers.  Actual use gets link error. */
 struct srcu_struct { };
-int __srcu_read_lock_nmisafe(struct srcu_struct *ssp, bool chknmisafe) __acquires(ssp);
-void __srcu_read_unlock_nmisafe(struct srcu_struct *ssp, int idx, bool chknmisafe) __releases(ssp);
 #endif
 
 void call_srcu(struct srcu_struct *ssp, struct rcu_head *head,
@@ -66,6 +64,20 @@ unsigned long get_state_synchronize_srcu(struct srcu_struct *ssp);
 unsigned long start_poll_synchronize_srcu(struct srcu_struct *ssp);
 bool poll_state_synchronize_srcu(struct srcu_struct *ssp, unsigned long cookie);
 
+#ifdef CONFIG_NEED_SRCU_NMI_SAFE
+int __srcu_read_lock_nmisafe(struct srcu_struct *ssp) __acquires(ssp);
+void __srcu_read_unlock_nmisafe(struct srcu_struct *ssp, int idx) __releases(ssp);
+#else
+static inline int __srcu_read_lock_nmisafe(struct srcu_struct *ssp)
+{
+	return __srcu_read_lock(ssp);
+}
+static inline void __srcu_read_unlock_nmisafe(struct srcu_struct *ssp, int idx)
+{
+	__srcu_read_unlock(ssp, idx);
+}
+#endif /* CONFIG_NEED_SRCU_NMI_SAFE */
+
 #ifdef CONFIG_SRCU
 void srcu_init(void);
 #else /* #ifdef CONFIG_SRCU */
@@ -106,6 +118,18 @@ static inline int srcu_read_lock_held(const struct srcu_struct *ssp)
 
 #endif /* #else #ifdef CONFIG_DEBUG_LOCK_ALLOC */
 
+#define SRCU_NMI_UNKNOWN	0x0
+#define SRCU_NMI_UNSAFE		0x1
+#define SRCU_NMI_SAFE		0x2
+
+#if defined(CONFIG_PROVE_RCU) && defined(CONFIG_TREE_SRCU)
+void srcu_check_nmi_safety(struct srcu_struct *ssp, bool nmi_safe);
+#else
+static inline void srcu_check_nmi_safety(struct srcu_struct *ssp,
+					 bool nmi_safe) { }
+#endif
+
+
 /**
  * srcu_dereference_check - fetch SRCU-protected pointer for later dereferencing
  * @p: the pointer to fetch and protect for later dereferencing
@@ -163,6 +187,7 @@ static inline int srcu_read_lock(struct srcu_struct *ssp) __acquires(ssp)
 {
 	int retval;
 
+	srcu_check_nmi_safety(ssp, false);
 	retval = __srcu_read_lock(ssp);
 	rcu_lock_acquire(&(ssp)->dep_map);
 	return retval;
@@ -179,10 +204,8 @@ static inline int srcu_read_lock_nmisafe(struct srcu_struct *ssp) __acquires(ssp
 {
 	int retval;
 
-	if (IS_ENABLED(CONFIG_NEED_SRCU_NMI_SAFE))
-		retval = __srcu_read_lock_nmisafe(ssp, true);
-	else
-		retval = __srcu_read_lock(ssp);
+	srcu_check_nmi_safety(ssp, true);
+	retval = __srcu_read_lock_nmisafe(ssp);
 	rcu_lock_acquire(&(ssp)->dep_map);
 	return retval;
 }
@@ -193,6 +216,7 @@ srcu_read_lock_notrace(struct srcu_struct *ssp) __acquires(ssp)
 {
 	int retval;
 
+	srcu_check_nmi_safety(ssp, false);
 	retval = __srcu_read_lock(ssp);
 	return retval;
 }
@@ -208,6 +232,7 @@ static inline void srcu_read_unlock(struct srcu_struct *ssp, int idx)
 	__releases(ssp)
 {
 	WARN_ON_ONCE(idx & ~0x1);
+	srcu_check_nmi_safety(ssp, false);
 	rcu_lock_release(&(ssp)->dep_map);
 	__srcu_read_unlock(ssp, idx);
 }
@@ -223,17 +248,16 @@ static inline void srcu_read_unlock_nmisafe(struct srcu_struct *ssp, int idx)
 	__releases(ssp)
 {
 	WARN_ON_ONCE(idx & ~0x1);
+	srcu_check_nmi_safety(ssp, true);
 	rcu_lock_release(&(ssp)->dep_map);
-	if (IS_ENABLED(CONFIG_NEED_SRCU_NMI_SAFE))
-		__srcu_read_unlock_nmisafe(ssp, idx, true);
-	else
-		__srcu_read_unlock(ssp, idx);
+	__srcu_read_unlock_nmisafe(ssp, idx);
 }
 
 /* Used by tracing, cannot be traced and cannot call lockdep. */
 static inline notrace void
 srcu_read_unlock_notrace(struct srcu_struct *ssp, int idx) __releases(ssp)
 {
+	srcu_check_nmi_safety(ssp, false);
 	__srcu_read_unlock(ssp, idx);
 }
 
diff --git a/include/linux/srcutiny.h b/include/linux/srcutiny.h
index efd808a23f8d..a2f620f8c559 100644
--- a/include/linux/srcutiny.h
+++ b/include/linux/srcutiny.h
@@ -87,16 +87,4 @@ static inline void srcu_torture_stats_print(struct srcu_struct *ssp,
 		 data_race(READ_ONCE(ssp->srcu_lock_nesting[!idx])),
 		 data_race(READ_ONCE(ssp->srcu_lock_nesting[idx])));
 }
-
-static inline int __srcu_read_lock_nmisafe(struct srcu_struct *ssp, bool chknmisafe)
-{
-	BUG();
-	return 0;
-}
-
-static inline void __srcu_read_unlock_nmisafe(struct srcu_struct *ssp, int idx, bool chknmisafe)
-{
-	BUG();
-}
-
 #endif
diff --git a/include/linux/srcutree.h b/include/linux/srcutree.h
index 35ffdedf86cc..c689a81752c9 100644
--- a/include/linux/srcutree.h
+++ b/include/linux/srcutree.h
@@ -43,10 +43,6 @@ struct srcu_data {
 	struct srcu_struct *ssp;
 };
 
-#define SRCU_NMI_UNKNOWN	0x0
-#define SRCU_NMI_NMI_UNSAFE	0x1
-#define SRCU_NMI_NMI_SAFE	0x2
-
 /*
  * Node in SRCU combining tree, similar in function to rcu_data.
  */
@@ -159,7 +155,4 @@ void synchronize_srcu_expedited(struct srcu_struct *ssp);
 void srcu_barrier(struct srcu_struct *ssp);
 void srcu_torture_stats_print(struct srcu_struct *ssp, char *tt, char *tf);
 
-int __srcu_read_lock_nmisafe(struct srcu_struct *ssp, bool chknmisafe) __acquires(ssp);
-void __srcu_read_unlock_nmisafe(struct srcu_struct *ssp, int idx, bool chknmisafe) __releases(ssp);
-
 #endif
diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
index 5bf67d997796..f6425076779c 100644
--- a/kernel/rcu/srcutree.c
+++ b/kernel/rcu/srcutree.c
@@ -631,17 +631,16 @@ void cleanup_srcu_struct(struct srcu_struct *ssp)
 }
 EXPORT_SYMBOL_GPL(cleanup_srcu_struct);
 
+#ifdef CONFIG_PROVE_RCU
 /*
  * Check for consistent NMI safety.
  */
-static void srcu_check_nmi_safety(struct srcu_struct *ssp, bool nmi_safe)
+void srcu_check_nmi_safety(struct srcu_struct *ssp, bool nmi_safe)
 {
 	int nmi_safe_mask = 1 << nmi_safe;
 	int old_nmi_safe_mask;
 	struct srcu_data *sdp;
 
-	if (!IS_ENABLED(CONFIG_PROVE_RCU))
-		return;
 	/* NMI-unsafe use in NMI is a bad sign */
 	WARN_ON_ONCE(!nmi_safe && in_nmi());
 	sdp = raw_cpu_ptr(ssp->sda);
@@ -652,6 +651,7 @@ static void srcu_check_nmi_safety(struct srcu_struct *ssp, bool nmi_safe)
 	}
 	WARN_ONCE(old_nmi_safe_mask != nmi_safe_mask, "CPU %d old state %d new state %d\n", sdp->cpu, old_nmi_safe_mask, nmi_safe_mask);
 }
+#endif /* CONFIG_PROVE_RCU */
 
 /*
  * Counts the new reader in the appropriate per-CPU element of the
@@ -665,7 +665,6 @@ int __srcu_read_lock(struct srcu_struct *ssp)
 	idx = READ_ONCE(ssp->srcu_idx) & 0x1;
 	this_cpu_inc(ssp->sda->srcu_lock_count[idx].counter);
 	smp_mb(); /* B */  /* Avoid leaking the critical section. */
-	srcu_check_nmi_safety(ssp, false);
 	return idx;
 }
 EXPORT_SYMBOL_GPL(__srcu_read_lock);
@@ -679,7 +678,6 @@ void __srcu_read_unlock(struct srcu_struct *ssp, int idx)
 {
 	smp_mb(); /* C */  /* Avoid leaking the critical section. */
 	this_cpu_inc(ssp->sda->srcu_unlock_count[idx].counter);
-	srcu_check_nmi_safety(ssp, false);
 }
 EXPORT_SYMBOL_GPL(__srcu_read_unlock);
 
@@ -688,7 +686,7 @@ EXPORT_SYMBOL_GPL(__srcu_read_unlock);
  * srcu_struct, but in an NMI-safe manner using RMW atomics.
  * Returns an index that must be passed to the matching srcu_read_unlock().
  */
-int __srcu_read_lock_nmisafe(struct srcu_struct *ssp, bool chknmisafe)
+int __srcu_read_lock_nmisafe(struct srcu_struct *ssp)
 {
 	int idx;
 	struct srcu_data *sdp = raw_cpu_ptr(ssp->sda);
@@ -696,8 +694,6 @@ int __srcu_read_lock_nmisafe(struct srcu_struct *ssp, bool chknmisafe)
 	idx = READ_ONCE(ssp->srcu_idx) & 0x1;
 	atomic_long_inc(&sdp->srcu_lock_count[idx]);
 	smp_mb__after_atomic(); /* B */  /* Avoid leaking the critical section. */
-	if (chknmisafe)
-		srcu_check_nmi_safety(ssp, true);
 	return idx;
 }
 EXPORT_SYMBOL_GPL(__srcu_read_lock_nmisafe);
@@ -707,14 +703,12 @@ EXPORT_SYMBOL_GPL(__srcu_read_lock_nmisafe);
  * element of the srcu_struct.  Note that this may well be a different
  * CPU than that which was incremented by the corresponding srcu_read_lock().
  */
-void __srcu_read_unlock_nmisafe(struct srcu_struct *ssp, int idx, bool chknmisafe)
+void __srcu_read_unlock_nmisafe(struct srcu_struct *ssp, int idx)
 {
 	struct srcu_data *sdp = raw_cpu_ptr(ssp->sda);
 
 	smp_mb__before_atomic(); /* C */  /* Avoid leaking the critical section. */
 	atomic_long_inc(&sdp->srcu_unlock_count[idx]);
-	if (chknmisafe)
-		srcu_check_nmi_safety(ssp, true);
 }
 EXPORT_SYMBOL_GPL(__srcu_read_unlock_nmisafe);
 
@@ -1159,7 +1153,7 @@ static unsigned long srcu_gp_start_if_needed(struct srcu_struct *ssp,
 	 * side critical section so that the gp sequence can't wrap around in
 	 * the middle.
 	 */
-	idx = __srcu_read_lock_nmisafe(ssp, false);
+	idx = __srcu_read_lock_nmisafe(ssp);
 	ss_state = smp_load_acquire(&ssp->srcu_size_state);
 	if (ss_state < SRCU_SIZE_WAIT_CALL)
 		sdp = per_cpu_ptr(ssp->sda, 0);
@@ -1192,7 +1186,7 @@ static unsigned long srcu_gp_start_if_needed(struct srcu_struct *ssp,
 		srcu_funnel_gp_start(ssp, sdp, s, do_norm);
 	else if (needexp)
 		srcu_funnel_exp_start(ssp, sdp_mynode, s);
-	__srcu_read_unlock_nmisafe(ssp, idx, false);
+	__srcu_read_unlock_nmisafe(ssp, idx);
 	return s;
 }
 
@@ -1496,13 +1490,13 @@ void srcu_barrier(struct srcu_struct *ssp)
 	/* Initial count prevents reaching zero until all CBs are posted. */
 	atomic_set(&ssp->srcu_barrier_cpu_cnt, 1);
 
-	idx = __srcu_read_lock_nmisafe(ssp, false);
+	idx = __srcu_read_lock_nmisafe(ssp);
 	if (smp_load_acquire(&ssp->srcu_size_state) < SRCU_SIZE_WAIT_BARRIER)
 		srcu_barrier_one_cpu(ssp, per_cpu_ptr(ssp->sda, 0));
 	else
 		for_each_possible_cpu(cpu)
 			srcu_barrier_one_cpu(ssp, per_cpu_ptr(ssp->sda, cpu));
-	__srcu_read_unlock_nmisafe(ssp, idx, false);
+	__srcu_read_unlock_nmisafe(ssp, idx);
 
 	/* Remove the initial count, at which point reaching zero can happen. */
 	if (atomic_dec_and_test(&ssp->srcu_barrier_cpu_cnt))
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH 0/3] srcu: A few NMI-safe debugging updates
  2022-10-13 17:22 [PATCH 0/3] srcu: A few NMI-safe debugging updates Frederic Weisbecker
                   ` (2 preceding siblings ...)
  2022-10-13 17:22 ` [PATCH 3/3] srcu: Debug NMI safety even on archs that don't require it Frederic Weisbecker
@ 2022-10-14 18:35 ` Paul E. McKenney
  3 siblings, 0 replies; 7+ messages in thread
From: Paul E. McKenney @ 2022-10-14 18:35 UTC (permalink / raw)
  To: Frederic Weisbecker; +Cc: LKML, quic_neeraju, joel, rcu, Lai Jiangshan

On Thu, Oct 13, 2022 at 07:22:41PM +0200, Frederic Weisbecker wrote:
> Hi,
> 
> This has passed SRCU-N, SRCU-P and SRCU-T so far.
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
> 	srcu/nmisafe
> 
> HEAD: 3cfdc2c6b8e89ca3c33954ea9b0d69e8cd141412

Thank you, Frederic!

I have pulled this is for review and testing.

							Thanx, Paul

> Thanks,
> 	Frederic
> ---
> 
> Frederic Weisbecker (3):
>       srcu: Warn when NMI-unsafe API is used in NMI
>       srcu: Explain the reason behind the read side critical section on GP start
>       srcu: Debug NMI safety even on archs that don't require it
> 
> 
>  include/linux/srcu.h     | 44 ++++++++++++++++++++++++++++++++++----------
>  include/linux/srcutiny.h | 12 ------------
>  include/linux/srcutree.h |  7 -------
>  kernel/rcu/srcutree.c    | 31 ++++++++++++++++---------------
>  4 files changed, 50 insertions(+), 44 deletions(-)

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH 1/3] srcu: Warn when NMI-unsafe API is used in NMI
  2022-10-13 17:22 ` [PATCH 1/3] srcu: Warn when NMI-unsafe API is used in NMI Frederic Weisbecker
@ 2022-10-14 22:45   ` Joel Fernandes
  2022-10-20 22:16     ` Paul E. McKenney
  0 siblings, 1 reply; 7+ messages in thread
From: Joel Fernandes @ 2022-10-14 22:45 UTC (permalink / raw)
  To: Frederic Weisbecker
  Cc: Paul E . McKenney, LKML, quic_neeraju, rcu, Lai Jiangshan

On Thu, Oct 13, 2022 at 07:22:42PM +0200, Frederic Weisbecker wrote:
> Using the NMI-unsafe reader API from within NMIs is very likely to be
> buggy for three reasons:
> 
> 1) NMIs aren't strictly re-entrant (a pending nested NMI will execute
>    at the end of the current one) so it should be fine to use a
>    non-atomic increment here. However breakpoints can still interrupt
>    NMIs and if a breakpoint callback has a reader on that same ssp, a
>    racy increment can happen.
> 
> 2) If the only reader site for a given ssp is in an NMI, RCU is definetly
								  definitely
>    a better choice over SRCU.

Just checking - because NMI are by definition not-preemptibe, so SRCU over
RCU doesn't make much sense right?

Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>

thanks,

 - Joel

> 
> 3) Because of the previous reason (2), an ssp having an SRCU read side
>    critical section in an NMI is likely to have another one from a task
>    context.
> 
> For all these reasons, warn if an nmi unsafe reader API is used from an
> NMI.
> 
> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
> ---
>  kernel/rcu/srcutree.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> index c54142374793..8b7ef1031d89 100644
> --- a/kernel/rcu/srcutree.c
> +++ b/kernel/rcu/srcutree.c
> @@ -642,6 +642,8 @@ static void srcu_check_nmi_safety(struct srcu_struct *ssp, bool nmi_safe)
>  
>  	if (!IS_ENABLED(CONFIG_PROVE_RCU))
>  		return;
> +	/* NMI-unsafe use in NMI is a bad sign */
> +	WARN_ON_ONCE(!nmi_safe && in_nmi());
>  	sdp = raw_cpu_ptr(ssp->sda);
>  	old_nmi_safe_mask = READ_ONCE(sdp->srcu_nmi_safety);
>  	if (!old_nmi_safe_mask) {
> -- 
> 2.25.1
> 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH 1/3] srcu: Warn when NMI-unsafe API is used in NMI
  2022-10-14 22:45   ` Joel Fernandes
@ 2022-10-20 22:16     ` Paul E. McKenney
  0 siblings, 0 replies; 7+ messages in thread
From: Paul E. McKenney @ 2022-10-20 22:16 UTC (permalink / raw)
  To: Joel Fernandes
  Cc: Frederic Weisbecker, LKML, quic_neeraju, rcu, Lai Jiangshan

On Fri, Oct 14, 2022 at 10:45:04PM +0000, Joel Fernandes wrote:
> On Thu, Oct 13, 2022 at 07:22:42PM +0200, Frederic Weisbecker wrote:
> > Using the NMI-unsafe reader API from within NMIs is very likely to be
> > buggy for three reasons:
> > 
> > 1) NMIs aren't strictly re-entrant (a pending nested NMI will execute
> >    at the end of the current one) so it should be fine to use a
> >    non-atomic increment here. However breakpoints can still interrupt
> >    NMIs and if a breakpoint callback has a reader on that same ssp, a
> >    racy increment can happen.
> > 
> > 2) If the only reader site for a given ssp is in an NMI, RCU is definetly
> 								  definitely
> >    a better choice over SRCU.
> 
> Just checking - because NMI are by definition not-preemptibe, so SRCU over
> RCU doesn't make much sense right?

Agreed.  But you never know...

> Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>

I will apply on the next rebase (after today's rebase), thank you!

							Thanx, Paul

> thanks,
> 
>  - Joel
> 
> > 
> > 3) Because of the previous reason (2), an ssp having an SRCU read side
> >    critical section in an NMI is likely to have another one from a task
> >    context.
> > 
> > For all these reasons, warn if an nmi unsafe reader API is used from an
> > NMI.
> > 
> > Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
> > ---
> >  kernel/rcu/srcutree.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> > index c54142374793..8b7ef1031d89 100644
> > --- a/kernel/rcu/srcutree.c
> > +++ b/kernel/rcu/srcutree.c
> > @@ -642,6 +642,8 @@ static void srcu_check_nmi_safety(struct srcu_struct *ssp, bool nmi_safe)
> >  
> >  	if (!IS_ENABLED(CONFIG_PROVE_RCU))
> >  		return;
> > +	/* NMI-unsafe use in NMI is a bad sign */
> > +	WARN_ON_ONCE(!nmi_safe && in_nmi());
> >  	sdp = raw_cpu_ptr(ssp->sda);
> >  	old_nmi_safe_mask = READ_ONCE(sdp->srcu_nmi_safety);
> >  	if (!old_nmi_safe_mask) {
> > -- 
> > 2.25.1
> > 

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-10-20 22:16 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-13 17:22 [PATCH 0/3] srcu: A few NMI-safe debugging updates Frederic Weisbecker
2022-10-13 17:22 ` [PATCH 1/3] srcu: Warn when NMI-unsafe API is used in NMI Frederic Weisbecker
2022-10-14 22:45   ` Joel Fernandes
2022-10-20 22:16     ` Paul E. McKenney
2022-10-13 17:22 ` [PATCH 2/3] srcu: Explain the reason behind the read side critical section on GP start Frederic Weisbecker
2022-10-13 17:22 ` [PATCH 3/3] srcu: Debug NMI safety even on archs that don't require it Frederic Weisbecker
2022-10-14 18:35 ` [PATCH 0/3] srcu: A few NMI-safe debugging updates Paul E. McKenney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).