[PATCH -rt] fix setting of preempt_max_latency and preempt_thresh on 64 bit systems

[PATCH -rt] fix setting of preempt_max_latency and preempt_thresh on 64 bit systems

[Steven Rostedt]

Ingo,

I wasn't able to turn on latency tracing on a x86_64 box. Using logdev
to see what was happening, I found that echoing 0
into /proc/sys/kernel/preempt_max_latency would only change the max from
-1ULL to 0xffffffff00000000. Which would keep the max pretty high still.

The problem is in sysctl.c where preempt_max_latency can be modified. On
systems where cycle_t is greater than the size of int (x86_64) we only
write to the 4 LSB.

Here's the patch:

-- Steve

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

Index: linux-2.6.21-rc5/kernel/sysctl.c
===================================================================
--- linux-2.6.21-rc5.orig/kernel/sysctl.c
+++ linux-2.6.21-rc5/kernel/sysctl.c
@@ -287,17 +287,17 @@ static ctl_table kern_table[] = {
 		.ctl_name	= CTL_UNNUMBERED,
 		.procname	= "preempt_max_latency",
 		.data		= &preempt_max_latency,
-		.maxlen		= sizeof(int),
+		.maxlen		= sizeof(preempt_max_latency),
 		.mode		= 0644,
-		.proc_handler	= &proc_dointvec,
+		.proc_handler	= &proc_doulongvec_minmax,
 	},
 	{
 		.ctl_name	= CTL_UNNUMBERED,
 		.procname	= "preempt_thresh",
 		.data		= &preempt_thresh,
-		.maxlen		= sizeof(int),
+		.maxlen		= sizeof(preempt_thresh),
 		.mode		= 0644,
-		.proc_handler	= &proc_dointvec,
+		.proc_handler	= &proc_doulongvec_minmax,
 	},
 #endif
 #ifdef CONFIG_EVENT_TRACE

Re: [PATCH -rt] fix setting of preempt_max_latency and preempt_thresh on 64 bit systems

[Andreas Mohr]

Hi,

On Tue, Mar 27, 2007 at 01:19:07PM -0400, Steven Rostedt wrote:
> Ingo,
> 
> I wasn't able to turn on latency tracing on a x86_64 box. Using logdev
> to see what was happening, I found that echoing 0
> into /proc/sys/kernel/preempt_max_latency would only change the max from
> -1ULL to 0xffffffff00000000. Which would keep the max pretty high still.
> 
> The problem is in sysctl.c where preempt_max_latency can be modified. On
> systems where cycle_t is greater than the size of int (x86_64) we only
> write to the 4 LSB.

Maybe fix up all the other myriads of sysctl entries which use a rather
non-precise generic sizeof(int) as well?
Or doesn't that make sense?
Maybe this is because it's security relevant and you'd better make sure
to know *exactly* the number of integers a buffer's length is supposed to be?

Thanks,

Andreas Mohr

Re: [PATCH -rt] fix setting of preempt_max_latency and preempt_thresh on 64 bit systems

[Ingo Molnar]

* Steven Rostedt <rostedt@goodmis.org> wrote:

> Ingo,
> 
> I wasn't able to turn on latency tracing on a x86_64 box. Using logdev 
> to see what was happening, I found that echoing 0 into 
> /proc/sys/kernel/preempt_max_latency would only change the max from 
> -1ULL to 0xffffffff00000000. Which would keep the max pretty high 
> still.

ah! This should explain Roland Dreier's report about tracing not working 
on x86_64.

> The problem is in sysctl.c where preempt_max_latency can be modified. 
> On systems where cycle_t is greater than the size of int (x86_64) we 
> only write to the 4 LSB.
> 
> Here's the patch:

thanks, applied.

	Ingo

Re: [PATCH -rt] fix setting of preempt_max_latency and preempt_thresh on 64 bit systems

[Steven Rostedt]

On Tue, 2007-03-27 at 21:15 +0200, Andreas Mohr wrote:

> Maybe fix up all the other myriads of sysctl entries which use a rather
> non-precise generic sizeof(int) as well?
> Or doesn't that make sense?

No, it does make sense

> Maybe this is because it's security relevant and you'd better make sure
> to know *exactly* the number of integers a buffer's length is supposed to be?

This is the problem. I was going to put some more time and clean up all
the stuff in there, but it will take more time than I currently have.
Since I would need to audit all the variables, and see how they would
interact in every arch.

-- Steve