Re: ftrace does not work on cpus > 999.

[Steven Rostedt]

On Sat, 2010-10-16 at 18:16 +0200, Ingo Molnar wrote:
> * Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> 
> > On Sat, 2010-10-16 at 16:45 +0200, Frederic Weisbecker wrote:
> > 
> > > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> > > index 9ec59f5..3565f9e 100644
> > > --- a/kernel/trace/trace.c
> > > +++ b/kernel/trace/trace.c
> > > @@ -3999,7 +3999,7 @@ static void tracing_init_debugfs_percpu(long cpu)
> > >  	/* strlen(cpu) + MAX(log10(cpu)) + '\0' */
> > >  	char cpu_dir[7];
> > >  
> > > -	if (cpu > 999 || cpu < 0)
> > > +	if (cpu < 0)
> > >  		return;
> > >  
> > >  	sprintf(cpu_dir, "cpu%ld", cpu);
> > 
> > You need to change the size of cpu_dir, otherwise this will overflow.
> 
> If you change it to 30 that ought to be enough, as long as cpu_id's fit 
> into u64. (I think we wont overflow that in my lifetime.)

And might as well make it static then, as we seem to be doing with
sched_param.

> 
> > The other case is to dynamically allocate cpu_dir.
> 
> Please tell me that is a joke ...

Why? It handles all cases and is only executed once at boot up. I'll
admit it was a little over engineered, and setting a new max of 30 chars
should be fine too. But no reason for it to be a joke.

-- Steve


--
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/