Re: [PATCH 1/1] kernel/rcu/tree.c: remove duplicate extern definition

[Paul E. McKenney]

On Mon, Apr 14, 2014 at 09:53:27AM -0700, Joe Perches wrote:
> On Mon, 2014-04-14 at 09:32 -0700, Paul E. McKenney wrote:
> > On Mon, Apr 14, 2014 at 12:19:31PM -0400, Pranith Kumar wrote:
> > > Hi Paul,
> > > 
> > > On Mon, Apr 14, 2014 at 12:07 PM, Paul E. McKenney
> > > <paulmck@xxxxxxxxxxxxxxxxxx> wrote:
> > > > On Sun, Apr 13, 2014 at 05:53:53PM -0400, Pranith Kumar wrote:
> > > >> remove duplicate definition of extern resched_cpu
> > > >>
> > > >> Signed-off-by: Pranith Kumar <bobby.prani@xxxxxxxxx>
> > > >
> > > > Hello, Pranith,
> > > >
> > > > When I apply this patch I get the following:
> > > >
> > > > /home/paulmck/public_git/linux-rcu/kernel/rcu/tree.c: In function ârcu_implicit_dynticks_qsâ:
> > > > /home/paulmck/public_git/linux-rcu/kernel/rcu/tree.c:895:3: error: implicit declaration of function âresched_cpuâ [-Werror=implicit-function-declaration]
> > > > /home/paulmck/public_git/linux-rcu/kernel/rcu/tree.c: At top level:
> > > > /home/paulmck/public_git/linux-rcu/kernel/rcu/tree.c:1009:13: warning: conflicting types for âresched_cpuâ [enabled by default]
> > > > /home/paulmck/public_git/linux-rcu/kernel/rcu/tree.c:895:3: note: previous implicit declaration of âresched_cpuâ was here
> > > >
> > > > This failed in under number of different Kconfig setups, the .config file
> > > > for one of them is attached.
> > > >
> > > > So this declaration really is needed.  Just out of curiosity, what led
> > > > you to believe that it could be removed?
> > > >
> > > 
> > > That is strange. The patch removes a duplicate declaration of
> > > resched_cpu (on lines 768, 954) of the file kernel/rcu/tree.c of the
> > > latest git.
> > > 
> > > The patch compiles fine here with the latest tip of the git tree.
> > > 
> > >   CC      kernel/rcu/tree.o
> > > 
> > > Can you please check if your tree.c has two declarations for resched_cpu?
> > 
> > Ah, your patch didn't apply, so I hand-applied it, and removed the first
> > declaration rather than the second one.  Trying it again.
> 
> Perhaps this might be better than using the extern.
> 
> This also would allow the resched_cpu call to become
> static inline as it's very small.
> 
> ---
>  kernel/rcu/tree.c | 19 +++++++------------
>  1 file changed, 7 insertions(+), 12 deletions(-)
> 
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 0c47e30..7f2c8c2 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -60,6 +60,13 @@
>  #include "tree.h"
>  #include "rcu.h"
> 
> +/*
> + * This include of sched.h (for resched_cpu) really isn't for public
> + * consumption, but RCU is special in that context switches can allow
> + * the state machine to make progress.
> + */
> +#include "../sched/sched.h"

This sort of thing hasn't been well-received recently.  Plus the call
to resched_cpu() is very infrequent, so hardly worth the optimization.

							Thanx, Paul

> +
>  MODULE_ALIAS("rcutree");
>  #ifdef MODULE_PARAM_PREFIX
>  #undef MODULE_PARAM_PREFIX
> @@ -762,12 +769,6 @@ static int dyntick_save_progress_counter(struct rcu_data *rdp,
>  }
> 
>  /*
> - * This function really isn't for public consumption, but RCU is special in
> - * that context switches can allow the state machine to make progress.
> - */
> -extern void resched_cpu(int cpu);
> -
> -/*
>   * Return true if the specified CPU has passed through a quiescent
>   * state by virtue of being in or having passed through an dynticks
>   * idle state since the last call to dyntick_save_progress_counter()
> @@ -947,12 +948,6 @@ static void print_other_cpu_stall(struct rcu_state *rsp)
>  	force_quiescent_state(rsp);  /* Kick them all. */
>  }
> 
> -/*
> - * This function really isn't for public consumption, but RCU is special in
> - * that context switches can allow the state machine to make progress.
> - */
> -extern void resched_cpu(int cpu);
> -
>  static void print_cpu_stall(struct rcu_state *rsp)
>  {
>  	int cpu;
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/