[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20191017030000.GB2588@paulmck-ThinkPad-P72>
Date: Wed, 16 Oct 2019 20:00:00 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Lai Jiangshan <laijs@...ux.alibaba.com>
Cc: 20191015102402.1978-1-laijs@...ux.alibaba.com,
linux-kernel@...r.kernel.org,
Lai Jiangshan <jiangshanlai@...il.com>,
Josh Triplett <josh@...htriplett.org>,
Steven Rostedt <rostedt@...dmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Joel Fernandes <joel@...lfernandes.org>, rcu@...r.kernel.org
Subject: Re: [PATCH 6/7] rcu: rename some CONFIG_PREEMPTION to
CONFIG_PREEMPT_RCU
On Wed, Oct 16, 2019 at 11:26:23PM +0800, Lai Jiangshan wrote:
>
>
> On 2019/10/16 11:54 上午, Paul E. McKenney wrote:
> > On Tue, Oct 15, 2019 at 10:28:48AM +0000, Lai Jiangshan wrote:
> > > CONFIG_PREEMPTION and CONFIG_PREEMPT_RCU are always identical,
> > > but some code depends on CONFIG_PREEMPTION to access to
> > > rcu_preempt functionalitis. This patch changes CONFIG_PREEMPTION
> > > to CONFIG_PREEMPT_RCU in these cases.
> > >
> > > Signed-off-by: Lai Jiangshan <jiangshanlai@...il.com>
> > > Signed-off-by: Lai Jiangshan <laijs@...ux.alibaba.com>
> >
> > I believe that this does not cause problems with Sebastian's patch
> > "[PATCH 27/34] rcu: Use CONFIG_PREEMPTION where appropriate", but could
> > you please check?
>
> I don't know for which commit the patch "[PATCH 27/34] rcu: Use
> CONFIG_PREEMPTION where appropriate" should be applied against
> after several tries. But I don't think there will be any conflicts
> which this patch by "eye" applying.
Well, git didn't see any either, so it is now applied for review and
testing. Thank you!
Thanx, Paul
> Thanks,
> Lai
>
>
>
> >
> > Thanx, Paul
> >
> > > ---
> > > kernel/rcu/tree.c | 4 ++--
> > > kernel/rcu/tree_stall.h | 6 +++---
> > > 2 files changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > index 7db5ea06a9ed..81eb64fcf5ab 100644
> > > --- a/kernel/rcu/tree.c
> > > +++ b/kernel/rcu/tree.c
> > > @@ -1926,7 +1926,7 @@ rcu_report_unblock_qs_rnp(struct rcu_node *rnp, unsigned long flags)
> > > struct rcu_node *rnp_p;
> > > raw_lockdep_assert_held_rcu_node(rnp);
> > > - if (WARN_ON_ONCE(!IS_ENABLED(CONFIG_PREEMPTION)) ||
> > > + if (WARN_ON_ONCE(!IS_ENABLED(CONFIG_PREEMPT_RCU)) ||
> > > WARN_ON_ONCE(rcu_preempt_blocked_readers_cgp(rnp)) ||
> > > rnp->qsmask != 0) {
> > > raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
> > > @@ -2294,7 +2294,7 @@ static void force_qs_rnp(int (*f)(struct rcu_data *rdp))
> > > mask = 0;
> > > raw_spin_lock_irqsave_rcu_node(rnp, flags);
> > > if (rnp->qsmask == 0) {
> > > - if (!IS_ENABLED(CONFIG_PREEMPTION) ||
> > > + if (!IS_ENABLED(CONFIG_PREEMPT_RCU) ||
> > > rcu_preempt_blocked_readers_cgp(rnp)) {
> > > /*
> > > * No point in scanning bits because they
> > > diff --git a/kernel/rcu/tree_stall.h b/kernel/rcu/tree_stall.h
> > > index 0b75426ebb3e..55f9b84790d3 100644
> > > --- a/kernel/rcu/tree_stall.h
> > > +++ b/kernel/rcu/tree_stall.h
> > > @@ -163,7 +163,7 @@ static void rcu_iw_handler(struct irq_work *iwp)
> > > //
> > > // Printing RCU CPU stall warnings
> > > -#ifdef CONFIG_PREEMPTION
> > > +#ifdef CONFIG_PREEMPT_RCU
> > > /*
> > > * Dump detailed information for all tasks blocking the current RCU
> > > @@ -215,7 +215,7 @@ static int rcu_print_task_stall(struct rcu_node *rnp)
> > > return ndetected;
> > > }
> > > -#else /* #ifdef CONFIG_PREEMPTION */
> > > +#else /* #ifdef CONFIG_PREEMPT_RCU */
> > > /*
> > > * Because preemptible RCU does not exist, we never have to check for
> > > @@ -233,7 +233,7 @@ static int rcu_print_task_stall(struct rcu_node *rnp)
> > > {
> > > return 0;
> > > }
> > > -#endif /* #else #ifdef CONFIG_PREEMPTION */
> > > +#endif /* #else #ifdef CONFIG_PREEMPT_RCU */
> > > /*
> > > * Dump stacks of all tasks running on stalled CPUs. First try using
> > > --
> > > 2.20.1
> > >
Powered by blists - more mailing lists