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