Messages in this thread | | | From | "Zhang, Qiang1" <> | Subject | RE: [PATCH] rcu: Fix opposite might_sleep() check in rcu_blocking_is_gp() | Date | Sat, 17 Dec 2022 02:44:47 +0000 |
| |
On Thu, Dec 15, 2022 at 11:57:55AM +0800, Zqiang wrote: > Currently, if the system is in the RCU_SCHEDULER_INACTIVE state, invoke > synchronize_rcu_*() will implies a grace period and return directly, > so there is no sleep action due to waiting for a grace period to end, > but this might_sleep() check is the opposite. therefore, this commit > puts might_sleep() check in the correct palce. > > Signed-off-by: Zqiang <qiang1.zhang@intel.com> > >Queued for testing and review, thank you! > >I was under the impression that might_sleep() did some lockdep-based >checking, but I am unable to find it. If there really is such checking, >that would be a potential argument for leaving this code as it is. > > >__might_sleep > __might_resched(file, line, 0) > rcu_sleep_check() > >Does it refer to this rcu_sleep_check() ? > >If so, when in the RCU_SCHEDULER_INACTIVE state, the debug_lockdep_rcu_enabled() is always >return false, so the RCU_LOCKDEP_WARN() also does not produce an actual warning. >
and when the system_state == SYSTEM_BOOTING, we just did rcu_sleep_check() and then return.
Thanks Zqiang
>Thanks >Zqiang >
>But in the meantime, full speed ahead! ;-) > > Thanx, Paul > > --- > kernel/rcu/tree.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > index ee8a6a711719..65f3dd2fd3ae 100644 > --- a/kernel/rcu/tree.c > +++ b/kernel/rcu/tree.c > @@ -3379,9 +3379,10 @@ void __init kfree_rcu_scheduler_running(void) > */ > static int rcu_blocking_is_gp(void) > { > - if (rcu_scheduler_active != RCU_SCHEDULER_INACTIVE) > + if (rcu_scheduler_active != RCU_SCHEDULER_INACTIVE) { > + might_sleep(); > return false; > - might_sleep(); /* Check for RCU read-side critical section. */ > + } > return true; > } > > -- > 2.25.1 >
| |