fix setting of preempt_max_latency and preempt_thresh on 64 bit systems

PATCH Applied Steven Rostedt 3 participants 4 messages Mar 27, 2007 Proc sysctl

lore

Share & tools

lore

Steven Rostedt

author

2007-03-27 17:19 UTC #0 lore raw

PATCH 1/1 fix setting of preempt_max_latency and preempt_thresh on 64 bit systems

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 <[email protected]>

kernel/sysctl.c +4 -4

Index: 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

Andreas Mohr

2007-03-27 19:15 UTC #1 lore raw

Hi,

Quoted 10 lines · 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.

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

Steven Rostedt

author

2007-03-27 19:40 UTC #2 lore raw

Quoted 3 lines · Andreas Mohr

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

Quoted 2 lines

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

Ingo Molnar

Applied

2007-03-27 19:16 UTC #3 lore raw

In reply to Steven Rostedt

Quoted 7 lines · 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.

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

Quoted 5 lines

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