You can subscribe to this list here.
2001 |
Jan
(1) |
Feb
|
Mar
(7) |
Apr
(3) |
May
(3) |
Jun
(7) |
Jul
(10) |
Aug
(1) |
Sep
(50) |
Oct
(74) |
Nov
(28) |
Dec
(32) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(63) |
Feb
(27) |
Mar
(88) |
Apr
(21) |
May
(59) |
Jun
(41) |
Jul
(61) |
Aug
(89) |
Sep
(179) |
Oct
(152) |
Nov
(190) |
Dec
(92) |
2003 |
Jan
(140) |
Feb
(160) |
Mar
(193) |
Apr
(107) |
May
(84) |
Jun
(60) |
Jul
(97) |
Aug
(97) |
Sep
(42) |
Oct
(105) |
Nov
(99) |
Dec
(52) |
2004 |
Jan
(99) |
Feb
(97) |
Mar
(62) |
Apr
(73) |
May
(94) |
Jun
(37) |
Jul
(32) |
Aug
(89) |
Sep
(87) |
Oct
(72) |
Nov
(114) |
Dec
(35) |
2005 |
Jan
(25) |
Feb
(42) |
Mar
(120) |
Apr
(151) |
May
(71) |
Jun
(36) |
Jul
(35) |
Aug
(92) |
Sep
(19) |
Oct
(57) |
Nov
(77) |
Dec
(61) |
2006 |
Jan
(107) |
Feb
(114) |
Mar
(66) |
Apr
(101) |
May
(74) |
Jun
(64) |
Jul
(42) |
Aug
(51) |
Sep
(106) |
Oct
(118) |
Nov
(138) |
Dec
(162) |
2007 |
Jan
(148) |
Feb
(222) |
Mar
(73) |
Apr
(160) |
May
(166) |
Jun
(125) |
Jul
(184) |
Aug
(58) |
Sep
(41) |
Oct
(102) |
Nov
(111) |
Dec
(52) |
2008 |
Jan
(104) |
Feb
(67) |
Mar
(48) |
Apr
(125) |
May
(114) |
Jun
(98) |
Jul
(206) |
Aug
(89) |
Sep
(88) |
Oct
(163) |
Nov
(115) |
Dec
(113) |
2009 |
Jan
(131) |
Feb
(85) |
Mar
(157) |
Apr
(198) |
May
(202) |
Jun
(154) |
Jul
(156) |
Aug
(75) |
Sep
(80) |
Oct
(148) |
Nov
(88) |
Dec
(83) |
2010 |
Jan
(78) |
Feb
(59) |
Mar
(89) |
Apr
(54) |
May
(92) |
Jun
(66) |
Jul
(38) |
Aug
(73) |
Sep
(84) |
Oct
(91) |
Nov
(52) |
Dec
(62) |
2011 |
Jan
(86) |
Feb
(68) |
Mar
(129) |
Apr
(121) |
May
(154) |
Jun
(81) |
Jul
(55) |
Aug
(55) |
Sep
(58) |
Oct
(115) |
Nov
(88) |
Dec
(95) |
2012 |
Jan
(105) |
Feb
(62) |
Mar
(52) |
Apr
(54) |
May
(103) |
Jun
(89) |
Jul
(152) |
Aug
(73) |
Sep
(58) |
Oct
(60) |
Nov
(52) |
Dec
(90) |
2013 |
Jan
(102) |
Feb
(63) |
Mar
(68) |
Apr
(128) |
May
(82) |
Jun
(94) |
Jul
(87) |
Aug
(29) |
Sep
(24) |
Oct
(25) |
Nov
(40) |
Dec
(51) |
2014 |
Jan
(41) |
Feb
(60) |
Mar
(33) |
Apr
(22) |
May
(38) |
Jun
(23) |
Jul
(86) |
Aug
(113) |
Sep
(23) |
Oct
(22) |
Nov
(18) |
Dec
(13) |
2015 |
Jan
(40) |
Feb
(12) |
Mar
(28) |
Apr
(32) |
May
(53) |
Jun
(65) |
Jul
(27) |
Aug
(6) |
Sep
(13) |
Oct
(25) |
Nov
(48) |
Dec
(19) |
2016 |
Jan
(5) |
Feb
(10) |
Mar
(23) |
Apr
(31) |
May
(19) |
Jun
(28) |
Jul
(19) |
Aug
(2) |
Sep
(9) |
Oct
(18) |
Nov
(10) |
Dec
(4) |
2017 |
Jan
(23) |
Feb
(42) |
Mar
(13) |
Apr
(5) |
May
(7) |
Jun
(26) |
Jul
(13) |
Aug
(8) |
Sep
(1) |
Oct
(3) |
Nov
(27) |
Dec
(4) |
2018 |
Jan
(9) |
Feb
(22) |
Mar
(27) |
Apr
(16) |
May
(7) |
Jun
(5) |
Jul
(7) |
Aug
(1) |
Sep
(36) |
Oct
(17) |
Nov
(1) |
Dec
(5) |
2019 |
Jan
(1) |
Feb
|
Mar
(11) |
Apr
(4) |
May
(7) |
Jun
(6) |
Jul
(9) |
Aug
(4) |
Sep
(6) |
Oct
(4) |
Nov
(5) |
Dec
(13) |
2020 |
Jan
(60) |
Feb
(57) |
Mar
(4) |
Apr
(71) |
May
(1) |
Jun
(1) |
Jul
(7) |
Aug
(11) |
Sep
(6) |
Oct
|
Nov
(2) |
Dec
|
2021 |
Jan
(42) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <no...@so...> - 2002-04-03 17:21:00
|
Bugs item #536954, was opened at 2002-03-29 23:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=116191&aid=536954&group_id=16191 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) >Summary: wrong bash version not handled properly Initial Comment: I started the op_start script (on my athlon) with the following command line (as the docs say): op_start --vmlinux=/usr/src/linux/vmlinux --map-file=/usr/src/linux/System.map --ctr0-event=RETIRED_INSNS --ctr0-count=300000 And I got the following output from it: /usr/local/bin/op_start: 4: No such file or directory /usr/local/bin/op_start: 0: command not found /usr/local/bin/op_start: 0: No such file or directory /usr/local/bin/op_start: CTR_EVENT[0]=RETIRED_INSNS: command not found /usr/local/bin/op_start: 0: command not found /usr/local/bin/op_start: 0: No such file or directory /usr/local/bin/op_start: CTR_COUNT[0]=300000: command not found /usr/local/bin/op_start: 4: No such file or directory /usr/local/bin/op_start: [: ==: binary operator expected /usr/local/bin/op_start: [: ==: binary operator expected Parameters used: /usr/local/bin/op_start: [: ==: binary operator expected CPUTYPE 3 /usr/local/bin/op_start: [: ==: binary operator expected HASH_SIZE default value /usr/local/bin/op_start: [: ==: binary operator expected BUF_SIZE default value /usr/local/bin/op_start: [: ==: binary operator expected NOTE_SIZE default value /usr/local/bin/op_start: 4: No such file or directory /usr/local/bin/op_start: [: ==: binary operator expected IGNORE_MYSELF 0 /usr/local/bin/op_start: [: ==: binary operator expected DIR /var/opd /usr/local/bin/op_start: [: ==: binary operator expected LOG_FILE /var/opd/oprofiled.log /usr/local/bin/op_start: [: ==: binary operator expected SAMPLES_DIR /var/opd/samples/ /usr/local/bin/op_start: [: ==: binary operator expected SEPARATE_SAMPLES 0 /usr/local/bin/op_start: [: ==: binary operator expected DEVICE_FILE /var/opd/opdev /usr/local/bin/op_start: [: ==: binary operator expected NOTE_DEVICE_FILE /var/opd/opnotedev /usr/local/bin/op_start: [: ==: binary operator expected HASH_MAP_DEVICE_FILE /var/opd/ophashmapdev /usr/local/bin/op_start: [: ==: binary operator expected MAP_FILE /usr/src/linux/System.map /usr/local/bin/op_start: [: ==: binary operator expected VMLINUX /usr/src/linux/vmlinux /usr/local/bin/op_start: [: ==: binary operator expected Removing /var/opd/opdev /usr/local/bin/op_start: [: ==: binary operator expected Removing /var/opd/opnotedev /usr/local/bin/op_start: [: ==: binary operator expected Removing /var/opd/ophashmapdev /usr/local/bin/op_start: [: ==: binary operator expected Doing mknod /var/opd/opdev /usr/local/bin/op_start: [: ==: binary operator expected Doing mknod /var/opd/opnotedev /usr/local/bin/op_start: [: ==: binary operator expected Doing mknod /var/opd/ophashmapdev /usr/local/bin/op_start: 4: No such file or directory /usr/local/bin/op_start: 4: No such file or directory /usr/local/bin/op_start: [: ==: binary operator expected cpu speed (estimation) : 1545.984 /usr/local/bin/op_start: [: ==: binary operator expected executing oprofiled --ignore-myself=0 --log-file=/var/opd/oprofiled.log --base-dir=/var/opd --samples-dir=/var/opd/samples/ --device-file=/var/opd/opdev --note-device-file=/var/opd/opnotedev --hash-map-device-file=/var/opd/ophashmapdev --vmlinux=/usr/src/linux/vmlinux --map-file=/usr/src/linux/System.map --separate-samples=0 --cpu-speed=1545.984 Failed to open device. Possibly you have passed incorrect parameters. Check /var/log/messages.Couldn't start oprofiled. Check the log file "/var/opd/oprofiled.log" and /var/log/messages ---------------------------------------------------------------------- >Comment By: John Levon (movement) Date: 2002-04-03 17:20 Message: Logged In: YES user_id=53034 Thanks, 2nd reporter. Can both of you try the untested patch I'm about to attach ? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-04-03 16:32 Message: Logged In: NO I had the same problem, and it turned out that my bash was too old and did not support c-syntax scripts. I replaced the #!/bin/bash at the head of the script with #!/bin/bash2 and the c-syntax parts of the scripts were happy. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=116191&aid=536954&group_id=16191 |
From: <no...@so...> - 2002-04-03 16:33:39
|
Bugs item #536954, was opened at 2002-03-29 15:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=116191&aid=536954&group_id=16191 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: lots of errors in the op_start script Initial Comment: I started the op_start script (on my athlon) with the following command line (as the docs say): op_start --vmlinux=/usr/src/linux/vmlinux --map-file=/usr/src/linux/System.map --ctr0-event=RETIRED_INSNS --ctr0-count=300000 And I got the following output from it: /usr/local/bin/op_start: 4: No such file or directory /usr/local/bin/op_start: 0: command not found /usr/local/bin/op_start: 0: No such file or directory /usr/local/bin/op_start: CTR_EVENT[0]=RETIRED_INSNS: command not found /usr/local/bin/op_start: 0: command not found /usr/local/bin/op_start: 0: No such file or directory /usr/local/bin/op_start: CTR_COUNT[0]=300000: command not found /usr/local/bin/op_start: 4: No such file or directory /usr/local/bin/op_start: [: ==: binary operator expected /usr/local/bin/op_start: [: ==: binary operator expected Parameters used: /usr/local/bin/op_start: [: ==: binary operator expected CPUTYPE 3 /usr/local/bin/op_start: [: ==: binary operator expected HASH_SIZE default value /usr/local/bin/op_start: [: ==: binary operator expected BUF_SIZE default value /usr/local/bin/op_start: [: ==: binary operator expected NOTE_SIZE default value /usr/local/bin/op_start: 4: No such file or directory /usr/local/bin/op_start: [: ==: binary operator expected IGNORE_MYSELF 0 /usr/local/bin/op_start: [: ==: binary operator expected DIR /var/opd /usr/local/bin/op_start: [: ==: binary operator expected LOG_FILE /var/opd/oprofiled.log /usr/local/bin/op_start: [: ==: binary operator expected SAMPLES_DIR /var/opd/samples/ /usr/local/bin/op_start: [: ==: binary operator expected SEPARATE_SAMPLES 0 /usr/local/bin/op_start: [: ==: binary operator expected DEVICE_FILE /var/opd/opdev /usr/local/bin/op_start: [: ==: binary operator expected NOTE_DEVICE_FILE /var/opd/opnotedev /usr/local/bin/op_start: [: ==: binary operator expected HASH_MAP_DEVICE_FILE /var/opd/ophashmapdev /usr/local/bin/op_start: [: ==: binary operator expected MAP_FILE /usr/src/linux/System.map /usr/local/bin/op_start: [: ==: binary operator expected VMLINUX /usr/src/linux/vmlinux /usr/local/bin/op_start: [: ==: binary operator expected Removing /var/opd/opdev /usr/local/bin/op_start: [: ==: binary operator expected Removing /var/opd/opnotedev /usr/local/bin/op_start: [: ==: binary operator expected Removing /var/opd/ophashmapdev /usr/local/bin/op_start: [: ==: binary operator expected Doing mknod /var/opd/opdev /usr/local/bin/op_start: [: ==: binary operator expected Doing mknod /var/opd/opnotedev /usr/local/bin/op_start: [: ==: binary operator expected Doing mknod /var/opd/ophashmapdev /usr/local/bin/op_start: 4: No such file or directory /usr/local/bin/op_start: 4: No such file or directory /usr/local/bin/op_start: [: ==: binary operator expected cpu speed (estimation) : 1545.984 /usr/local/bin/op_start: [: ==: binary operator expected executing oprofiled --ignore-myself=0 --log-file=/var/opd/oprofiled.log --base-dir=/var/opd --samples-dir=/var/opd/samples/ --device-file=/var/opd/opdev --note-device-file=/var/opd/opnotedev --hash-map-device-file=/var/opd/ophashmapdev --vmlinux=/usr/src/linux/vmlinux --map-file=/usr/src/linux/System.map --separate-samples=0 --cpu-speed=1545.984 Failed to open device. Possibly you have passed incorrect parameters. Check /var/log/messages.Couldn't start oprofiled. Check the log file "/var/opd/oprofiled.log" and /var/log/messages ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-04-03 08:32 Message: Logged In: NO I had the same problem, and it turned out that my bash was too old and did not support c-syntax scripts. I replaced the #!/bin/bash at the head of the script with #!/bin/bash2 and the c-syntax parts of the scripts were happy. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=116191&aid=536954&group_id=16191 |
From: John L. <le...@mo...> - 2002-04-02 11:57:02
|
On Mon, Apr 01, 2002 at 01:50:43PM -0800, Ransford, Rusty wrote: > I'm new to using this tool, but need to know if it will properly profile > each active CPU when the sampling interrupt is received. No, each interrupt causes only a local sampling. For RTC mode, this relies on distribution of the RTC interrupt across the CPUs (so e.g. noapic will mean only one CPU gets profiled). For NMI mode, each CPU's counters + APIC is set up identically, so they will each receive and handle their own LVTPC interrupts. > only using RTC sampling and the report shows nothing in regard to the > used CPUs. I'm not sure what you would like reported ? Number of interrupts per CPU ? If you want to investigate this it's probably simplest to add a printk() in module/oprofile.c:get_nr_interrupts() In general the only cases where this would go wrong is badly distributed RTC interrupts, so we haven't gone to the trouble of the necessary sysctl details (instead just giving a global summary). regards john -- "That's just kitten-eating wrong." - Richard Henderson |
From: Ransford, R. <rus...@in...> - 2002-04-01 21:51:28
|
I'm new to using this tool, but need to know if it will properly profile each active CPU when the sampling interrupt is received. Currently, I'm only using RTC sampling and the report shows nothing in regard to the used CPUs. If NMI profiling were enabled for the P4 based platform, would the results be any different? Thanks, Rusty Ransford rus...@in... |
From: <no...@so...> - 2002-03-29 23:46:08
|
Bugs item #536954, was opened at 2002-03-29 15:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=116191&aid=536954&group_id=16191 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: lots of errors in the op_start script Initial Comment: I started the op_start script (on my athlon) with the following command line (as the docs say): op_start --vmlinux=/usr/src/linux/vmlinux --map-file=/usr/src/linux/System.map --ctr0-event=RETIRED_INSNS --ctr0-count=300000 And I got the following output from it: /usr/local/bin/op_start: 4: No such file or directory /usr/local/bin/op_start: 0: command not found /usr/local/bin/op_start: 0: No such file or directory /usr/local/bin/op_start: CTR_EVENT[0]=RETIRED_INSNS: command not found /usr/local/bin/op_start: 0: command not found /usr/local/bin/op_start: 0: No such file or directory /usr/local/bin/op_start: CTR_COUNT[0]=300000: command not found /usr/local/bin/op_start: 4: No such file or directory /usr/local/bin/op_start: [: ==: binary operator expected /usr/local/bin/op_start: [: ==: binary operator expected Parameters used: /usr/local/bin/op_start: [: ==: binary operator expected CPUTYPE 3 /usr/local/bin/op_start: [: ==: binary operator expected HASH_SIZE default value /usr/local/bin/op_start: [: ==: binary operator expected BUF_SIZE default value /usr/local/bin/op_start: [: ==: binary operator expected NOTE_SIZE default value /usr/local/bin/op_start: 4: No such file or directory /usr/local/bin/op_start: [: ==: binary operator expected IGNORE_MYSELF 0 /usr/local/bin/op_start: [: ==: binary operator expected DIR /var/opd /usr/local/bin/op_start: [: ==: binary operator expected LOG_FILE /var/opd/oprofiled.log /usr/local/bin/op_start: [: ==: binary operator expected SAMPLES_DIR /var/opd/samples/ /usr/local/bin/op_start: [: ==: binary operator expected SEPARATE_SAMPLES 0 /usr/local/bin/op_start: [: ==: binary operator expected DEVICE_FILE /var/opd/opdev /usr/local/bin/op_start: [: ==: binary operator expected NOTE_DEVICE_FILE /var/opd/opnotedev /usr/local/bin/op_start: [: ==: binary operator expected HASH_MAP_DEVICE_FILE /var/opd/ophashmapdev /usr/local/bin/op_start: [: ==: binary operator expected MAP_FILE /usr/src/linux/System.map /usr/local/bin/op_start: [: ==: binary operator expected VMLINUX /usr/src/linux/vmlinux /usr/local/bin/op_start: [: ==: binary operator expected Removing /var/opd/opdev /usr/local/bin/op_start: [: ==: binary operator expected Removing /var/opd/opnotedev /usr/local/bin/op_start: [: ==: binary operator expected Removing /var/opd/ophashmapdev /usr/local/bin/op_start: [: ==: binary operator expected Doing mknod /var/opd/opdev /usr/local/bin/op_start: [: ==: binary operator expected Doing mknod /var/opd/opnotedev /usr/local/bin/op_start: [: ==: binary operator expected Doing mknod /var/opd/ophashmapdev /usr/local/bin/op_start: 4: No such file or directory /usr/local/bin/op_start: 4: No such file or directory /usr/local/bin/op_start: [: ==: binary operator expected cpu speed (estimation) : 1545.984 /usr/local/bin/op_start: [: ==: binary operator expected executing oprofiled --ignore-myself=0 --log-file=/var/opd/oprofiled.log --base-dir=/var/opd --samples-dir=/var/opd/samples/ --device-file=/var/opd/opdev --note-device-file=/var/opd/opnotedev --hash-map-device-file=/var/opd/ophashmapdev --vmlinux=/usr/src/linux/vmlinux --map-file=/usr/src/linux/System.map --separate-samples=0 --cpu-speed=1545.984 Failed to open device. Possibly you have passed incorrect parameters. Check /var/log/messages.Couldn't start oprofiled. Check the log file "/var/opd/oprofiled.log" and /var/log/messages ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=116191&aid=536954&group_id=16191 |
From: John L. <le...@mo...> - 2002-03-28 15:32:19
|
On Thu, Mar 28, 2002 at 03:04:00PM +0000, Keith Whitwell wrote: > Seeing as you have a kernel module already, why not add some ioctls there to > do the things that currently require root access? Have the kernel module > verify that the requests are sane & secure. This already happens in fact. See pmc_check_params(). > You could just return a busy error, rather than trying to virtualize the > hardware. I'm not sure how you'd do that, and I'm not sure how many people > would require that... I don't think there's a simple way to prevent one user messing with another user's profile setup (given that they would both have the necessary privileges), but this question is orthogonal to the use of root in oprofile code - this problem exists either way. I'd quite happily have the minimum of code running as root, but we would need to make sure that the admin can still restrict the privilege of messing with profile stuff to users who they allow. Currently this is done via sudo / giving them root. regards john -- "To the untrained eye it might seem as though Quality programs and ISO 9000 are not related. I was confused too until one consultant explained it to me this way : 'ISO 9000 is closely related to Quality because everything you do is Quality and ISO 9000 documents everything you do, therefore give us money.'" - Scott Adams |
From: Keith W. <ke...@tu...> - 2002-03-28 15:06:02
|
William Cohen wrote: > > John Levon wrote: > > > On Wed, Mar 27, 2002 at 11:43:29AM -0500, William Cohen wrote: > > > > > >>I much prefer the possibility of someone slowing down the machine with > >>repeated 'op_dump' than to require giving root access to anyone doing > >> > > > > Actually an admin can currently add oprof_start to sudo list safely (as > > far as I know). We need to be careful not to make security promises we > > can't live up to, and I am not really an expert in this arena... > > > > It would be relatively easy to make a command line version of > > oprof_start that could be sudo'd too - obviously, op_start is too easily > > exploitable to serve for this. > > > > Allowing a normal user to dump isn't particularly useful if they can't > > control counter parameters etc. and that requires what I mention above. > > > > > Having said that, I'm not necessarily averse to it, we just need to be > > sure of what we are doing. In particular: are we sure that all the > > minimum values for every event type is totally DoS-free even on the > > latest processors ?? > > > > Partly this is a documentation issue of course. > > To some extent having op_dump as runnable by a normal user is a stop-gap > measure. It just allows the user to get some profiling information even > if they do not have root. However, the user is at the mercy of root to > set the profiling to things the user is interested in. Hopefully, root > will set the performance monitoring to something of general utility. Seeing as you have a kernel module already, why not add some ioctls there to do the things that currently require root access? Have the kernel module verify that the requests are sane & secure. > Because the profiling hardware is a scarse resource there are going to > be issues with allocating the performance monitoring resources. More > than one user may want to collect data using the performance monitoring > registers. There is needs to be some locking to make sure that one > user's data collection is not terminated by another user changing the > performance monitoring settings. Oprofile will start a new set of > samples any time a change is made in the profiling configuration. There > are some things like where the sample data is stored which would have to > be limited and things like what kernel is being profile would be off > limits to normal user changes. You could just return a busy error, rather than trying to virtualize the hardware. I'm not sure how you'd do that, and I'm not sure how many people would require that... Keith |
From: William C. <wc...@nc...> - 2002-03-28 14:52:18
|
John Levon wrote: > On Wed, Mar 27, 2002 at 11:43:29AM -0500, William Cohen wrote: > > >>I much prefer the possibility of someone slowing down the machine with >>repeated 'op_dump' than to require giving root access to anyone doing >> > > Actually an admin can currently add oprof_start to sudo list safely (as > far as I know). We need to be careful not to make security promises we > can't live up to, and I am not really an expert in this arena... > > It would be relatively easy to make a command line version of > oprof_start that could be sudo'd too - obviously, op_start is too easily > exploitable to serve for this. > > Allowing a normal user to dump isn't particularly useful if they can't > control counter parameters etc. and that requires what I mention above. > > Having said that, I'm not necessarily averse to it, we just need to be > sure of what we are doing. In particular: are we sure that all the > minimum values for every event type is totally DoS-free even on the > latest processors ?? > > Partly this is a documentation issue of course. To some extent having op_dump as runnable by a normal user is a stop-gap measure. It just allows the user to get some profiling information even if they do not have root. However, the user is at the mercy of root to set the profiling to things the user is interested in. Hopefully, root will set the performance monitoring to something of general utility. Because the profiling hardware is a scarse resource there are going to be issues with allocating the performance monitoring resources. More than one user may want to collect data using the performance monitoring registers. There is needs to be some locking to make sure that one user's data collection is not terminated by another user changing the performance monitoring settings. Oprofile will start a new set of samples any time a change is made in the profiling configuration. There are some things like where the sample data is stored which would have to be limited and things like what kernel is being profile would be off limits to normal user changes. I don't know how feasible it would be to have the performance monitoring register allocated individually to allow more than one user to use the hardware at the same time. There would be complications. How to handle changes in performance monitoring setting. Some files would be affected others would not. There wouldn't be the nice property that everything in the directory is from the same sampling epoc. -Will |
From: John L. <le...@mo...> - 2002-03-27 23:27:08
|
On Wed, Mar 27, 2002 at 11:43:29AM -0500, William Cohen wrote: > I much prefer the possibility of someone slowing down the machine with > repeated 'op_dump' than to require giving root access to anyone doing Actually an admin can currently add oprof_start to sudo list safely (as far as I know). We need to be careful not to make security promises we can't live up to, and I am not really an expert in this arena... It would be relatively easy to make a command line version of oprof_start that could be sudo'd too - obviously, op_start is too easily exploitable to serve for this. Allowing a normal user to dump isn't particularly useful if they can't control counter parameters etc. and that requires what I mention above. Having said that, I'm not necessarily averse to it, we just need to be sure of what we are doing. In particular: are we sure that all the minimum values for every event type is totally DoS-free even on the latest processors ?? Partly this is a documentation issue of course. > For many cases it would be pretty simple for the programmer to copy the > file to a unique place and then run the file. However, for program that > do exec or for system wide profiling this might be more of a problem. Well it's reasonable to expect that a user can keep track of the old executables when they change something, and they need a comparison more detailed than op_time's. regards john -- "Q: Name a non-living object with legs A: A plant." - Family Fortunes |
From: William C. <wc...@nc...> - 2002-03-27 22:38:31
|
John Levon wrote: > On Wed, Mar 27, 2002 at 09:15:54AM -0500, William Cohen wrote: > > >>It would be really nice to reduce the need for root access when using >>oprofile. >> > > Yes, this has been on TODO for a while ... > > >>I have made some modifications in my local version of oprofile >> to make the /proc/sys/dev/oprofile readable by users other than root. >>This allows a user run op_help to determine what processor is being used >>and what types of instrumentation it supports. >> > > Looks good, I will review and test it properly later. > > >>/proc/sys/dev/oprofile/dump is world writable to allow normal users to >>initiate a flush of the profiling data (like a sync command), so they >>don't have to wait for a periodic flush of profiling data to occur. >> > > The question is, can a local user cause a mini-DOS by spamming dump ? > > And is it a problem ? I much prefer the possibility of someone slowing down the machine with repeated 'op_dump' than to require giving root access to anyone doing performance monitoring. Doesn't 'sync' have similar issues? I will play around with the multiple op_dump and see whether it is a problem. >>How does oprofile handle a changes in an executable? Does oprofile >>determine executable has changed and the old collected data is deleted >>and a new profiling data file is started? I am thinking of the case >>where a developer changes something in the source code, recompiles, and >>then wants data only related to the new executable (which has the same >>name as the old executable). >> > > The image's mtime is checked every time it is mapped in and the old > sample file is deleted. Great. I haven't looked at that aspect of the oprofile yet. That is one thing I wasn't sure of. This behavior will life easier for developers > In the future it will be made simpler for the user to compare the > profiles of two different compilations (though they will still probably > have to save the old image file themselves) For many cases it would be pretty simple for the programmer to copy the file to a unique place and then run the file. However, for program that do exec or for system wide profiling this might be more of a problem. > regards > john > > p.s. I much prefer diff -u format Okay, will use "diff -u" in the future. -Will |
From: John L. <le...@mo...> - 2002-03-27 16:11:25
|
On Wed, Mar 27, 2002 at 09:15:54AM -0500, William Cohen wrote: > It would be really nice to reduce the need for root access when using > oprofile. Yes, this has been on TODO for a while ... > I have made some modifications in my local version of oprofile > to make the /proc/sys/dev/oprofile readable by users other than root. > This allows a user run op_help to determine what processor is being used > and what types of instrumentation it supports. Looks good, I will review and test it properly later. > /proc/sys/dev/oprofile/dump is world writable to allow normal users to > initiate a flush of the profiling data (like a sync command), so they > don't have to wait for a periodic flush of profiling data to occur. The question is, can a local user cause a mini-DOS by spamming dump ? And is it a problem ? > How does oprofile handle a changes in an executable? Does oprofile > determine executable has changed and the old collected data is deleted > and a new profiling data file is started? I am thinking of the case > where a developer changes something in the source code, recompiles, and > then wants data only related to the new executable (which has the same > name as the old executable). The image's mtime is checked every time it is mapped in and the old sample file is deleted. In the future it will be made simpler for the user to compare the profiles of two different compilations (though they will still probably have to save the old image file themselves) regards john p.s. I much prefer diff -u format -- "Way back at the beginning of time around 1970 the first man page was handed down from on high. Every one since is an edited copy." - John Hasler <jo...@dh...> |
From: William C. <wc...@nc...> - 2002-03-27 15:51:02
|
It would be really nice to reduce the need for root access when using oprofile. I have made some modifications in my local version of oprofile to make the /proc/sys/dev/oprofile readable by users other than root. This allows a user run op_help to determine what processor is being used and what types of instrumentation it supports. /proc/sys/dev/oprofile/dump is world writable to allow normal users to initiate a flush of the profiling data (like a sync command), so they don't have to wait for a periodic flush of profiling data to occur. Change log entries: * module/oprofile.c (oprof_table): Allow non-root examination of /proc/sys/dev/oprofile and non-root initiation of dump. * dae/op_dump: Allow normal user profiling data dump. Does this seems reasonable? How does oprofile handle a changes in an executable? Does oprofile determine executable has changed and the old collected data is deleted and a new profiling data file is started? I am thinking of the case where a developer changes something in the source code, recompiles, and then wants data only related to the new executable (which has the same name as the old executable). -Will |
From: Philippe E. <ph...@cl...> - 2002-03-20 05:45:09
|
From: "William Cohen" <wc...@nc...> Sent: Wednesday, March 20, 2002 12:11 AM > I was playing around with oprof_report looking and a set of samples that > were collected earlier. Unfortunately, some of the executables had been > removed. I was surprised when I attempted to open one of the sample > files for a non-existent executable and oprof_report exited. It looks > like many of the functions in pp/oprofpp_util.cpp just exit if there is > a problem leaving the entire program. That isn't very desirable > behavior. Someone makes a mistake and oprof_report has to be restarted. > Shouldn't the code in pp/oprofpp_util.cpp be throwing exceptions instead > of just deciding to exit? The oprof_report can print an appropriate > error message and the let the user try again. yeps it's planned oprof_report/oprof_report.cpp /* TODO: oprofpp_util.cpp, opf_container.cpp: handle all error * through exception */ actually oprof_report is rather a prototype application than a full featured apps. > Another minor thing is I noticed that "exit(1);" was used in > gui/oprof_start.cpp and gui/oprof_start_util.cpp. These should probably > be "exit(EXIT_FAILURE);". You never know when someone will decide to > port this code to an operating system where "exit(1)" means something > other than a failure. thanks, I'll correct that. regards, Phil |
From: William C. <wc...@nc...> - 2002-03-20 03:42:01
|
I was playing around with oprof_report looking and a set of samples that were collected earlier. Unfortunately, some of the executables had been removed. I was surprised when I attempted to open one of the sample files for a non-existent executable and oprof_report exited. It looks like many of the functions in pp/oprofpp_util.cpp just exit if there is a problem leaving the entire program. That isn't very desirable behavior. Someone makes a mistake and oprof_report has to be restarted. Shouldn't the code in pp/oprofpp_util.cpp be throwing exceptions instead of just deciding to exit? The oprof_report can print an appropriate error message and the let the user try again. Another minor thing is I noticed that "exit(1);" was used in gui/oprof_start.cpp and gui/oprof_start_util.cpp. These should probably be "exit(EXIT_FAILURE);". You never know when someone will decide to port this code to an operating system where "exit(1)" means something other than a failure. -Will |
From: John L. <le...@mo...> - 2002-03-18 14:09:47
|
On Sat, Mar 16, 2002 at 10:50:32PM -0500, Daniel Jacobowitz wrote: > > Is the patch at the end of this message OK? John, does the patch work > > for you? with 2.12, gcc 2.95.3 compiled a.c, -g3 : 080483d8 1744754 45.3498 a /home/moz/a.c:0 080483c0 2102570 54.6502 b /home/moz/a.c:0 2.12 + your second patch : 080483d8 1797859 44.7118 a /home/moz/a.c:67 080483c0 2223136 55.2882 b /home/moz/a.c:50 Thanks for fixing this ! regards john -- I am a complete moron for forgetting about endianness. May I be forever marked as such. |
From: Philippe E. <ph...@cl...> - 2002-03-17 00:39:58
|
From: "Greg Galperin" <gr...@ai...> Sent: Saturday, March 16, 2002 10:48 PM > shlib is 85MB, compresses down to 12MB. sources contain over 100Klines > of source code... I'll spare the list. :) ok > My initial purpose was to check that I wasn't doing anything blatantly > wrong. I have previously successfully oprofiled exes in this > environment; I guess I'll spend some time now to see if I can tear > this down to make a simple reproducer of this problem. really thanks to not follow blindly my advise to send the whole things :) regards, Philippe Elie |
From: Greg G. <gr...@ai...> - 2002-03-16 21:48:06
|
Philippe Elie wrote: > I means objdump -d -S on the shlib itself, not on the object files yes, tons of source code in the shlib too. (e.g. counted 12,600 lines with // commments. saw code from dozens of different files.) > try it, if you see source file can you send the unstripped binary > and the samples files (tgz please) ? Do not send it to the list > if the compressed size is bigger than 200 Ko shlib is 85MB, compresses down to 12MB. sources contain over 100Klines of source code... I'll spare the list. :) My initial purpose was to check that I wasn't doing anything blatantly wrong. I have previously successfully oprofiled exes in this environment; I guess I'll spend some time now to see if I can tear this down to make a simple reproducer of this problem. thanks, grg |
From: Philippe E. <ph...@cl...> - 2002-03-16 21:21:44
|
From: "Greg Galperin" <gr...@ai...> To: <ph...@cl...> > OK, good questions; there are 271 symbols with nonzero counts, some > with many thousands of counts: > > The .o files used to build the shlib were all compiled with "g++ -g3", > i.e., maximal amount of debug info. Yes, "objdump -d -S" on any of > the .o files does show embedded source code (including comments and > preprocessor directives!). I means objdump -d -S on the shlib itself, not on the object files try it, if you see source file can you send the unstripped binary and the samples files (tgz please) ? Do not send it to the list if the compressed size is bigger than 200 Ko > < /* Repository<Data>::Length(int) 1 0.02169% */ > < /* 1914 41.51% */ > > which shows up in the op_to_source'd file (that symbol is defined > somewhere compeletely different). ok, I'll look at this also. > I'm using gcc-2.95.2 for compilation with -g3 (is that a problem?), > kernel 2.4.18. I never tried with 2.95.2 but it would work, and if it don't work perhaps a work-around exists ... regards, Phil |
From: Greg G. <gr...@ai...> - 2002-03-16 18:52:58
|
Philippe Elie wrote: > > Briefly, I'm trying to op_to_source a shlib, and it only annotates 2 files > > of a couple hundred which went into the shlib, dozens of which had funcs > > show up in oprofpp output with hundreds or thousands of samples. > > > > oprofpp sure seems to know a log about the library: > > > > [1895]oprofpp -demangle -l /proj/libzz.so | wc > > 6617 64531 816959 > > this count all symbols even those w/o any samples neither debug info, > op_to_source deals only with symbols wiich receive samples and > have debug information. ... > are you sure all object file used to build the shared libs contains > debug info ? oprofpp -l does not need debugs info but op_to_source > needs them. Try objdump -d -S on the shared libs and look for > imbeded source inside assembly. OK, good questions; there are 271 symbols with nonzero counts, some with many thousands of counts: [2150]oprofpp -demangle -l /prob/libzz.so | awk '$2+0>0' | wc -l 271 [2151]oprofpp -demangle -l /prob/libzz.so | awk '$2+0>100' | wc -l 113 [2152]oprofpp -demangle -l /prob/libzz.so | awk '$2+0>1000' | wc -l 55 [2153]oprofpp -demangle -l /prob/libzz.so | awk '$2+0>10000' | wc -l 14 [2154]oprofpp -demangle -l /prob/libzz.so | awk '$2+0>100000' | wc -l 1 [2155] The .o files used to build the shlib were all compiled with "g++ -g3", i.e., maximal amount of debug info. Yes, "objdump -d -S" on any of the .o files does show embedded source code (including comments and preprocessor directives!). > > Also, that the one symbol op_to_source named in debug.cpp isn't actually > > in that file or referenced by anything anywhere 'below' that file. > > perhaps a corner case like an inline function or a template > instantation invoked through an implicit call to a base class > ctor. What is the symbol name? Probably not. The file debug.ccp literally only has one line of code which defines a global variable. It includes one header file which in turn includes 3 /usr/include files and defines the DebugOstream class. Nowhere does any of this mention the symbol < /* Repository<Data>::Length(int) 1 0.02169% */ < /* 1914 41.51% */ which shows up in the op_to_source'd file (that symbol is defined somewhere compeletely different). > As a last hint, I commited (03-13) a fix against a problem with > gcc-2.95.3 and debug info. OK, I just checked out, recompiled, reinstalled oprofile. Now I get 2 more files copied into the output directory, but those 4 files are still relatively uninteresting files and still none of them really have any useful annotations. I'm using gcc-2.95.2 for compilation with -g3 (is that a problem?), kernel 2.4.18. thanks! --grg |
From: Philippe E. <ph...@cl...> - 2002-03-16 04:48:12
|
From: "Greg Galperin" <gr...@ai...> Sent: Saturday, March 16, 2002 3:25 AM > Hi oprofilers, hi, > I'm having trouble with op_to_source (both 0.0.9 and a current cvs version) > and am looking for help. > > Briefly, I'm trying to op_to_source a shlib, and it only annotates 2 files > of a couple hundred which went into the shlib, dozens of which had funcs > show up in oprofpp output with hundreds or thousands of samples. > > oprofpp sure seems to know a log about the library: > > [1895]oprofpp -demangle -l /proj/libzz.so | wc > 6617 64531 816959 this count all symbols even those w/o any samples neither debug info, op_to_source deals only with symbols wiich receive samples and have debug information. > but when I try to run op_to_source, it only processes two files, and > doesn't really give any useful info. It does seem to recognize those two > files and copies over the source correctly and annotate them slightly, so I > don't suspect a path or lib name problem (plus, the oprofpp output seems > completely reasonable). are you sure all object file used to build the shared libs contains debug info ? oprofpp -l does not need debugs info but op_to_source needs them. Try objdump -d -S on the shared libs and look for imbeded source inside assembly. > [1896]op_to_source -d -i /proj/libzz.so --source-dir > $SOURCEDIR --output-dir /tmp/grg/oprof-annotated-source [snip diff annotated source/source show small difference] > > Also, that the one symbol op_to_source named in debug.cpp isn't actually > in that file or referenced by anything anywhere 'below' that file. perhaps a corner case like an inline function or a template instantation invoked through an implicit call to a base class ctor. What is the symbol name? > Again, oprofpp does seem to correctly show many symbols which are in many > different files in that same source dir. Shouldn't I expect to see many > of them get annotated by op_to_source? only if debug info are present, in this case if op_to_source can't open the source file for any reason it should warn else it fails silently (debug info missing are a quite common case and so on op_to_source does not complain for symbol w/o debug info) > Perhaps I'm just using the wrong command-line features? I have tried to > play with them (e.g. adding "-w 0") with no change, and this general > format does seem to work for me on simple executables. The behavior > is the same for 0.0.9 and the cvs head. nope plain op_to_source w/o any options should shows all source wich contains at least one sample. As a last hint, I commited (03-13) a fix against a problem with gcc-2.95.3 and debug info. regards, Philippe Elie |
From: Greg G. <gr...@ai...> - 2002-03-16 02:25:40
|
Hi oprofilers, I'm having trouble with op_to_source (both 0.0.9 and a current cvs version) and am looking for help. Briefly, I'm trying to op_to_source a shlib, and it only annotates 2 files of a couple hundred which went into the shlib, dozens of which had funcs show up in oprofpp output with hundreds or thousands of samples. oprofpp sure seems to know a log about the library: [1895]oprofpp -demangle -l /proj/libzz.so | wc 6617 64531 816959 but when I try to run op_to_source, it only processes two files, and doesn't really give any useful info. It does seem to recognize those two files and copies over the source correctly and annotate them slightly, so I don't suspect a path or lib name problem (plus, the oprofpp output seems completely reasonable). [1896]op_to_source -d -i /proj/libzz.so --source-dir $SOURCEDIR --output-dir /tmp/grg/oprof-annotated-source [1897]ls /tmp/grg/oprof-annotated-source ./ ../ note.cpp debug.cpp [1898]diff note.cpp $SOURCEDIR | wc 8 22 127 [1899]diff note.cpp $SOURCEDIR 1,5d0 < /* < Total samples for file : "/proj/note.cpp" < 3 0.06506% < */ < 29d23 < /* 3 0.06506% */ [1900]diff debug.cpp $SOURCEDIR | wc 8 27 194 [1901]diff debug.cpp $SOURCEDIR 1,7d0 < /* < Total samples for file : "/proj/debug.cpp" < 1914 41.51% < */ < < /* Repository<Data>::Length(int) 1 0.02169% */ < /* 1914 41.51% */ [1902] Also, that the one symbol op_to_source named in debug.cpp isn't actually in that file or referenced by anything anywhere 'below' that file. Again, oprofpp does seem to correctly show many symbols which are in many different files in that same source dir. Shouldn't I expect to see many of them get annotated by op_to_source? Perhaps I'm just using the wrong command-line features? I have tried to play with them (e.g. adding "-w 0") with no change, and this general format does seem to work for me on simple executables. The behavior is the same for 0.0.9 and the cvs head. thanks for any suggestions and assistance! --grg |
From: Philippe E. <ph...@cl...> - 2002-03-16 00:09:27
|
From: "Osiris Pedroso" <ope...@sw...> Sent: Friday, March 15, 2002 6:13 AM > I tried, (several times) ... > > Messages stop during boot at: > > calibrating APIC timer ... > ..... cpu clock speed is 1296.0977 Mhz > ..... host bus clock speed is 0.0000 Mhz > cpu: 0, clocks: 0, slice: 0 > > There is no output after the last 0 above. The machine hangs until hard > reset (CTRL+ALT+DEL has no effect). the apic is enabled but the timer counter does not decount :/ > Any hints ? ChangeLog-2.4.14 .... pre4: - Mikael Pettersson: fix P4 boot with APIC enabled perhaps upgrading to 2.4.14 will help. regards, Philippe Elie |
From: Osiris P. <ope...@sw...> - 2002-03-15 05:14:39
|
> well it's in RTC mode, so you need to compile out the RTC driver from > your kernel. I tried, (several times) ... Messages stop during boot at: calibrating APIC timer ... ..... cpu clock speed is 1296.0977 Mhz ..... host bus clock speed is 0.0000 Mhz cpu: 0, clocks: 0, slice: 0 There is no output after the last 0 above. The machine hangs until hard reset (CTRL+ALT+DEL has no effect). Any hints ? Osiris |
From: John L. <le...@mo...> - 2002-03-14 21:21:15
|
On Thu, Mar 14, 2002 at 10:46:56AM -0800, MONTGOMERY,BOB (HP-FtCollins,ex1) wrote: > The rtc handler can never interrupt the NMI handler part of oprofile. The > rtc handler can't profile any interesting interrupt handling code in the > kernel. The NMI handler could profile the rtc handler, but ... ? Well exactly. At the least we'd need some check we're not in the rtc handler. It complicates and slows down the most critical path in the profiler ... > Note that the rtc mode works badly on SMP systems. Each interrupt is > processed by only one of the CPUs in a sort of haphazard way (it seems). I This is dependent on your system (in particular using noapic will make all interrupts go to CPU#0). The arbitration is supposed to distribute interrupts evenly across the CPUs, and that's what I found happened in my tests (well it's more complicated than that, but I didn't see your behaviour). > up (it should still be on the same CPU that handled the RTC interrupt), it > uses smp_call_function to run a pseudo-rtc handler function on the other This is really like greasing a tortoise IMHO. regards john -- I am a complete moron for forgetting about endianness. May I be forever marked as such. |
From: Philippe E. <ph...@cl...> - 2002-03-14 21:20:43
|
From: "John Levon" <le...@mo...> Sent: Thursday, March 14, 2002 2:32 PM > On Wed, Mar 13, 2002 at 08:44:08PM -0800, Osiris Pedroso wrote: > > > 1) How can I convert a vmlinuz to a vmlinux (decompress it?) ? This is > > required for the op_start command. > > You really need the vmlinux from your build. Though if you're not doing > kernel profiling you can use any file you like ... and, if you have not make clean or make mrproper after building your kernel, it must be in /usr/src/linux-2.4/ I'm unsure than with RH 7.2 you have qt2 installed and so on you can't use oprof_start rather op_start... > > 2) when insmod oprofile.o, it fails with "init_module: Device or > > resource busy" > > well it's in RTC mode, so you need to compile out the RTC driver from > your kernel. John, we need something like in op_rtc.c #ifndef CONFIG_RTC /* is it the right identifier ? */ printk("No RTC ..."); #endif return EBUSY; Osiris, I details a litlle what more a previous John's mail about what to do. 1) change the op_cpu enum adding a CPU_P4 2) change op_init::get_cpu_type() to return CPU_P4 when detecting a P4 3) look where and how OP_MAX_COUNTERS is defined, change the definition to allow at least the 18 P4 counters. 4) write an module/op_p4.c which must the counter part of op_nmi.c and fill an op_int_operations with empty place holder function. 5) change oprofile.c::oprof_init() to handle CPU_P4 So at this point you must get a non-working P4 module skeleton then post it here. After that I think you must get a more precise idea on how the module work and what work is needed. Most of the functionnality for P4 are identical than for P2/Athlon but IMHO it's preferable, for now, to cut and copy code from op_nmi.c to op_P4.c If you find this information too or not enough detailed, just flame me. regards, Philippe Elie |