* [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).