Re: [PATCH -rt] fix setting of preempt_max_latency and preempt_thresh on 64 bit systems
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -rt] fix setting of preempt_max_latency and preempt_thresh on 64 bit systems
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 0x. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -rt] fix setting of preempt_max_latency and preempt_thresh on 64 bit systems
* Steven Rostedt <[EMAIL PROTECTED]> 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 0x. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -rt] 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 0x. 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]>
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 = _max_latency,
- .maxlen = sizeof(int),
+ .maxlen = sizeof(preempt_max_latency),
.mode = 0644,
- .proc_handler = _dointvec,
+ .proc_handler = _doulongvec_minmax,
},
{
.ctl_name = CTL_UNNUMBERED,
.procname = "preempt_thresh",
.data = _thresh,
- .maxlen = sizeof(int),
+ .maxlen = sizeof(preempt_thresh),
.mode = 0644,
- .proc_handler = _dointvec,
+ .proc_handler = _doulongvec_minmax,
},
#endif
#ifdef CONFIG_EVENT_TRACE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -rt] 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 0x. 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]
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -rt] fix setting of preempt_max_latency and preempt_thresh on 64 bit systems
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 0x. 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -rt] fix setting of preempt_max_latency and preempt_thresh on 64 bit systems
* Steven Rostedt [EMAIL PROTECTED] 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 0x. 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -rt] fix setting of preempt_max_latency and preempt_thresh on 64 bit systems
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
