Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
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
(8) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
|
|
|
|
1
|
2
|
3
|
4
|
5
(3) |
6
|
7
|
8
(1) |
9
|
10
(22) |
11
(2) |
12
|
13
|
14
(1) |
15
|
16
|
17
|
18
|
19
|
20
(1) |
21
|
22
|
23
|
24
|
25
(2) |
26
(1) |
27
|
28
|
29
|
30
|
31
|
|
|
|
|
|
From: Maynard Johnson <maynardj@us...> - 2014-03-26 21:17:46
|
On 03/25/2014 01:01 PM, San Martino wrote: > Hello, > > I am trying to get a callgraph from a stripped binary running on my ARM Cortex A8, Linux 2.6.37 (with oprofile 0.9.9 installed). > > Unfortunately when I add --callgraph to operf my system crashes. However, when using the legacy tool, opcontrol --callgraph=5/opcontrol start, then some data seems to be collected (and, yes, opcontrol --status outputs the correct depth). San, I can't remember if I asked you this question when you pinged me in IRC, but have you tried running 'perf record --call-graph' to see if you get the same system crash? I would expect you would. > > With the data collected that way, I can then post-process the informations on my x86-PC, where I have the seperate debugging symbols corresponding to the stripped binary that I profiled above. > > The problem is that now opreport only reports [self] entries when I report via -l -g --callgraph options, that is, I cannot see any callgraphs showing the relationships between calls. > > Do you know why and/or a possible solution? *Will*, can you help with figuring out what kernel versions support ARM callgraph? Thanks. -Maynard |
From: San Martino <sanmrtn96@gm...> - 2014-03-25 18:01:18
|
Hello, I am trying to get a callgraph from a stripped binary running on my ARM Cortex A8, Linux 2.6.37 (with oprofile 0.9.9 installed). Unfortunately when I add --callgraph to operf my system crashes. However, when using the legacy tool, opcontrol --callgraph=5/opcontrol start, then some data seems to be collected (and, yes, opcontrol --status outputs the correct depth). With the data collected that way, I can then post-process the informations on my x86-PC, where I have the seperate debugging symbols corresponding to the stripped binary that I profiled above. The problem is that now opreport only reports [self] entries when I report via -l -g --callgraph options, that is, I cannot see any callgraphs showing the relationships between calls. Do you know why and/or a possible solution? |
From: Maynard Johnson <maynardj@us...> - 2014-03-25 00:20:14
|
I've gotten a report from a user that there's a problem with the mailing list, so this is just a test message. -Maynard |
From: Maynard Johnson <maynardj@us...> - 2014-03-20 22:06:16
|
On 03/14/2014 02:19 PM, William Cohen wrote: > The size of %lx is 32 bits on 32-bit machine and 64-bits on 64-bit > machines. However, bfd_vma is always a 64-bit value regardless > whether the processor is a 32-bit or 64-bit architecture. The > get_kallsym_symbols() used the %lx which only matched up on the 64-bit > machines. This changes the code to always read things into a > "unsigned long long" variable and then copy that value into the > bfd_vma variable to allow the code to compile on both 32-bit and > 64-bit machine Ack. -Maynard > > Signed-off-by: William Cohen <wcohen@...> > --- > libutil++/op_bfd.cpp | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/libutil++/op_bfd.cpp b/libutil++/op_bfd.cpp > index 1d7ea8c..c92d532 100644 > --- a/libutil++/op_bfd.cpp > +++ b/libutil++/op_bfd.cpp > @@ -303,7 +303,7 @@ void op_bfd::get_kallsym_symbols(symbols_found_t & symbols, ifstream& infile) > stringstream iss; > > bfd_vma start = 0, start_prev = 0; > - unsigned long long length; > + unsigned long long length, start_value; > bool ignore_symbol = true; > bfd_vma base_addr = 0; > name_prev = ""; > @@ -319,7 +319,8 @@ void op_bfd::get_kallsym_symbols(symbols_found_t & symbols, ifstream& infile) > iss >> type; > iss >> name; > > - sscanf(address_str.c_str(), "%lx", &start); > + sscanf(address_str.c_str(), "%llx", &start_value); > + start = start_value; > > if (start_prev == start) > length = 0; > |
From: William Cohen <wcohen@re...> - 2014-03-14 20:07:26
|
The size of %lx is 32 bits on 32-bit machine and 64-bits on 64-bit machines. However, bfd_vma is always a 64-bit value regardless whether the processor is a 32-bit or 64-bit architecture. The get_kallsym_symbols() used the %lx which only matched up on the 64-bit machines. This changes the code to always read things into a "unsigned long long" variable and then copy that value into the bfd_vma variable to allow the code to compile on both 32-bit and 64-bit machine Signed-off-by: William Cohen <wcohen@...> --- libutil++/op_bfd.cpp | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/libutil++/op_bfd.cpp b/libutil++/op_bfd.cpp index 1d7ea8c..c92d532 100644 --- a/libutil++/op_bfd.cpp +++ b/libutil++/op_bfd.cpp @@ -303,7 +303,7 @@ void op_bfd::get_kallsym_symbols(symbols_found_t & symbols, ifstream& infile) stringstream iss; bfd_vma start = 0, start_prev = 0; - unsigned long long length; + unsigned long long length, start_value; bool ignore_symbol = true; bfd_vma base_addr = 0; name_prev = ""; @@ -319,7 +319,8 @@ void op_bfd::get_kallsym_symbols(symbols_found_t & symbols, ifstream& infile) iss >> type; iss >> name; - sscanf(address_str.c_str(), "%lx", &start); + sscanf(address_str.c_str(), "%llx", &start_value); + start = start_value; if (start_prev == start) length = 0; -- 1.8.3.1 |
From: Ingo Molnar <mingo@ke...> - 2014-03-11 10:30:30
|
* Oleg Nesterov <oleg@...> wrote: > On 03/10, Ingo Molnar wrote: > > > > So my main problem with those patches was that if HW_BREAKPOINTS is > > disabled then GDB 'hbreak' isn't simply disabled but fails in various > > non-obvious ways, > > but the kernel should return an error. And this can happen anyway, say, > reserve_bp_slot() can fail because all slots are already used by perf. > > And iirc, gdb always switches to the single-stepping if hbreak fails. When the old patches were submitted I tried it with modern GDB and it wasn't a good experience. Thanks, Ingo |
From: Ingo Molnar <mingo@ke...> - 2014-03-11 10:29:21
|
* Josh Triplett <josh@...> wrote: > On Mon, Mar 10, 2014 at 08:43:54AM +0100, Ingo Molnar wrote: > > > > * Josh Triplett <josh@...> wrote: > > > > > This patch series makes it possible to disable HW_BREAKPOINTS, > > > PERF_EVENTS, INSTRUCTION_DECODER, IRQ_WORK, and ANON_INODES. > > > Without this patch series, all of these config options get > > > automatically selected on x86, making them impossible to > > > disable. > > > > > > This is a revival of a previous patch series from Andi Kleen > > > sent in October 2013. [...] > > > > So my main problem with those patches was that if HW_BREAKPOINTS > > is disabled then GDB 'hbreak' isn't simply disabled but fails in > > various non-obvious ways, taking down the rest of GDB with it, so > > it's in essence an ABI and tool breaker which is not very useful. > > It's hidden behind EXPERT for a reason, [...] With many distros enabling CONFIG_EXPERT=y that's a distinction without much meaning. > [...] and non-hardware breakpoints still work just fine. [...] A lot of other stuff will work just fine as well. Yet my point was that 'hbreak' breaks in ugly ways. > [...] This is the kind of thing enabled on an embedded system, where > you're not going to be running GDB at all, let alone using "hbreak". So that is why I suggested making ptrace configurable. Perhaps. > Given that other options depending on EXPERT let you disable things > as critical as futexes or ELF binary support... Both of which will break in pretty clear ways. The granularity of how we can disable ABIs largely depends on how well actual user-space code handles the failures, and what I'm saying here is that the disabling of hardware breakpoints is too finegrained. Disabling ptrace for embedded OTOH makes sense and gives us even more savings and security advantage. Thanks, Ingo |
From: Josh Triplett <josh@jo...> - 2014-03-10 20:50:40
|
On Mon, Mar 10, 2014 at 05:14:11PM +0100, Frederic Weisbecker wrote: > On Sun, Mar 09, 2014 at 08:12:53PM -0700, Josh Triplett wrote: > > --- a/arch/x86/Kconfig > > +++ b/arch/x86/Kconfig > > @@ -70,9 +70,6 @@ config X86 > > select HAVE_KERNEL_XZ > > select HAVE_KERNEL_LZO > > select HAVE_KERNEL_LZ4 > > - select HAVE_HW_BREAKPOINT > > - select HAVE_MIXED_BREAKPOINTS_REGS > > - select PERF_EVENTS > > select HAVE_PERF_EVENTS_NMI > > select HAVE_PERF_REGS > > select HAVE_PERF_USER_STACK_DUMP > > @@ -587,6 +584,15 @@ config SCHED_OMIT_FRAME_POINTER > > > > If in doubt, say "Y". > > > > +config HW_BREAKPOINTS > > + bool "Enable hardware breakpoints support" if EXPERT > > + default y > > + select HAVE_HW_BREAKPOINT > > + select HAVE_MIXED_BREAKPOINTS_REGS > > + ---help--- > > + Enable support for x86 hardware breakpoints for debuggers > > + and perf. This will implicitly enable perf-events. > > + > > HW_BREAKPOINTS must depend on HAVE_HW_BREAKPOINT, not the other way round. > HAVE_* Kconfig symbols must only express constant backend support, not a variable user choice... > > ie, that's what I did in this patchset > https://lkml.org/lkml/2011/7/14/163 So, the converse of that is that makefiles and code should never depend on HAVE_* symbols; they should only be used in Kconfig as dependencies. Right now, piles of things use HAVE_HW_BREAKPOINT to select things to build. So, the biggest chunk of this change is introducing a new dummy symbol HW_BREAKPOINTS depending on HAVE_HW_BREAKPOINT and HAVE_MIXED_BREAKPOINTS_REGS, and changing almost all the references to HAVE_HW_BREAKPOINT to HW_BREAKPOINTS. That's effectively patch 2/6 of your series. Would you consider reviving that patch, or should I pull that patch into this series instead? - Josh Triplett |
From: Andi Kleen <ak@li...> - 2014-03-10 18:18:16
|
On Mon, Mar 10, 2014 at 10:41:06AM -0700, Andi Kleen wrote: > > > And in fact, why do we need ptrace_get/set_debugreg(DR6) without HW_BREAKPOINTS? > > > > Good question. Andi? > > dr6 controls single stepping which is useful even without hw/breakpoints. > > Basically gdb will still work for 95+% of all use cases, everyone > not using watch points. Actually thinking about it more gdb should be using PTRACE_SINGLESTEP, not direct access to DR6. So removing it is likely ok (but should verify) -Andi |
From: Andi Kleen <ak@li...> - 2014-03-10 17:41:34
|
> > And in fact, why do we need ptrace_get/set_debugreg(DR6) without HW_BREAKPOINTS? > > Good question. Andi? dr6 controls single stepping which is useful even without hw/breakpoints. Basically gdb will still work for 95+% of all use cases, everyone not using watch points. -Andi |
From: Josh Triplett <josh@jo...> - 2014-03-10 17:21:02
|
On Mon, Mar 10, 2014 at 05:14:11PM +0100, Frederic Weisbecker wrote: > On Sun, Mar 09, 2014 at 08:12:53PM -0700, Josh Triplett wrote: > > From: Andi Kleen <ak@...> > > > > Make HW_BREAKPOINTS a config option. HW_BREAKPOINTS depends on perf. > > This allows disabling PERF_EVENTS for systems that don't need it (e.g. > > anything not used for development) This then allows disabling IRQ_WORK > > and INSTRUCTION_DECODER. > > > > This change reduces the size of allnoconfig by 161k, a full 7.6% > > reduction: > > text data bss dec hex filename > > 788816 131952 1214432 2135200 2094a0 vmlinux-allnoconfig-with-perf > > 666361 93020 1214368 1973749 1e1df5 vmlinux-allnoconfig-no-perf > > > > bloat-o-meter summary: > > add/remove: 1/1040 grow/shrink: 1/25 up/down: 82/-152214 (-152132) > > My review hasn't changed much since last time (https://lkml.org/lkml/2013/10/4/483), > so I'm mostly copy pasting it here so that we can discuss if you want: > > I'm personally not against the idea of allowing hw breakpoint support > to be disabled but hpa did not like much the idea. I must say he had > valid concerns though, see the thread of this patchset: https://lkml.org/lkml/2011/7/14/163 > > IMHO, a better solution would be to make the hw breakpoint subsystem work > without using perf. It looks like hpa's concern was primarily that it should be possible to have CONFIG_HW_BREAKPOINTS=y without CONFIG_PERF_EVENTS. I agree, but since right now you can't have *either* of them disabled, allowing both to be disabled seems like an improvement. > > +config HW_BREAKPOINTS > > + bool "Enable hardware breakpoints support" if EXPERT > > + default y > > + select HAVE_HW_BREAKPOINT > > + select HAVE_MIXED_BREAKPOINTS_REGS > > + ---help--- > > + Enable support for x86 hardware breakpoints for debuggers > > + and perf. This will implicitly enable perf-events. > > + > > HW_BREAKPOINTS must depend on HAVE_HW_BREAKPOINT, not the other way round. > HAVE_* Kconfig symbols must only express constant backend support, not a variable user choice... > > ie, that's what I did in this patchset > https://lkml.org/lkml/2011/7/14/163 Fair enough. - Josh Triplett |
From: Frederic Weisbecker <fweisbec@gm...> - 2014-03-10 16:14:23
|
On Sun, Mar 09, 2014 at 08:12:53PM -0700, Josh Triplett wrote: > From: Andi Kleen <ak@...> > > Make HW_BREAKPOINTS a config option. HW_BREAKPOINTS depends on perf. > This allows disabling PERF_EVENTS for systems that don't need it (e.g. > anything not used for development) This then allows disabling IRQ_WORK > and INSTRUCTION_DECODER. > > This change reduces the size of allnoconfig by 161k, a full 7.6% > reduction: > text data bss dec hex filename > 788816 131952 1214432 2135200 2094a0 vmlinux-allnoconfig-with-perf > 666361 93020 1214368 1973749 1e1df5 vmlinux-allnoconfig-no-perf > > bloat-o-meter summary: > add/remove: 1/1040 grow/shrink: 1/25 up/down: 82/-152214 (-152132) My review hasn't changed much since last time (https://lkml.org/lkml/2013/10/4/483), so I'm mostly copy pasting it here so that we can discuss if you want: I'm personally not against the idea of allowing hw breakpoint support to be disabled but hpa did not like much the idea. I must say he had valid concerns though, see the thread of this patchset: https://lkml.org/lkml/2011/7/14/163 IMHO, a better solution would be to make the hw breakpoint subsystem work without using perf. I mean, perf should use the hw breakpoint, but hw breakpoint shouldn't use perf, (in fact that's what we agreed on with hpa IIRC). But right now there is a kind of circular dependency between both that makes perf always built-in in x86. I'm all for solving that by making hw breakpoint independant from perf, but I think Ingo had mixed feelings about doing it that way. And he had valid concerns on that as well. So we are a bit stuck :) Also some comments below: > > Suggested-by: Ingo Molnar <mingo@...> > Signed-off-by: Andi Kleen <ak@...> > [josh: Rebased; HW_BREAKPOINTS marked as EXPERT; commit message updated > with new statistics.] > Signed-off-by: Josh Triplett <josh@...> > --- > arch/x86/Kconfig | 12 +++++++++--- > arch/x86/kernel/Makefile | 3 ++- > arch/x86/kvm/Kconfig | 1 + > 3 files changed, 12 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 0af5250..12e3386 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -70,9 +70,6 @@ config X86 > select HAVE_KERNEL_XZ > select HAVE_KERNEL_LZO > select HAVE_KERNEL_LZ4 > - select HAVE_HW_BREAKPOINT > - select HAVE_MIXED_BREAKPOINTS_REGS > - select PERF_EVENTS > select HAVE_PERF_EVENTS_NMI > select HAVE_PERF_REGS > select HAVE_PERF_USER_STACK_DUMP > @@ -587,6 +584,15 @@ config SCHED_OMIT_FRAME_POINTER > > If in doubt, say "Y". > > +config HW_BREAKPOINTS > + bool "Enable hardware breakpoints support" if EXPERT > + default y > + select HAVE_HW_BREAKPOINT > + select HAVE_MIXED_BREAKPOINTS_REGS > + ---help--- > + Enable support for x86 hardware breakpoints for debuggers > + and perf. This will implicitly enable perf-events. > + HW_BREAKPOINTS must depend on HAVE_HW_BREAKPOINT, not the other way round. HAVE_* Kconfig symbols must only express constant backend support, not a variable user choice... ie, that's what I did in this patchset https://lkml.org/lkml/2011/7/14/163 Thanks. |
From: Josh Triplett <josh@jo...> - 2014-03-10 15:15:51
|
On Mon, Mar 10, 2014 at 03:42:55PM +0100, Oleg Nesterov wrote: > On 03/10, Oleg Nesterov wrote: > > > > On 03/09, Josh Triplett wrote: > > > > > > +static unsigned long ptrace_get_debugreg(struct task_struct *tsk, int n) > > > +{ > > > + struct thread_struct *thread = &tsk->thread; > > > + > > > + if (n == 6) > > > + return thread->debugreg6; > > > + return 0; > > > +} > > > + > > > +/* Without breakpoints only handle DR6 */ > > > +static int ptrace_set_debugreg(struct task_struct *tsk, int n, > > > + unsigned long val) > > > +{ > > > + struct thread_struct *thread = &tsk->thread; > > > + int rc = -EIO; > > > + > > > + if (n == 6) { > > > + thread->debugreg6 = val; > > > + rc = 0; > > > + } > > > + return rc; > > > +} > > > + > > > +#endif > > > > OK, but then perhaps this patch should also make thread_struct->ptrace_bps[] > > depend on CONFIG_HW_BREAKPOINTS ? > > and ->ptrace_dr7 at least. Those do seem like nice optimizations to reduce the size of thread_struct. > And in fact, why do we need ptrace_get/set_debugreg(DR6) without HW_BREAKPOINTS? Good question. Andi? > Perhaps get/set should just return the error? Perhaps. > > But I won't insist if you prefer to do this later. > > Yes. The optimization of thread_struct I would prefer to defer until after this patch series, yes. But if there's a better way to write ptrace_{g,s}et_debugreg when !CONFIG_HW_BREAKPOINTS, I'll happily change that here. - Josh Triplett |
From: Josh Triplett <josh@jo...> - 2014-03-10 15:03:31
|
On Mon, Mar 10, 2014 at 03:21:29PM +0100, Oleg Nesterov wrote: > On 03/09, Josh Triplett wrote: > > diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig > > index 015f85a..8639819 100644 > > --- a/kernel/trace/Kconfig > > +++ b/kernel/trace/Kconfig > > @@ -424,6 +424,7 @@ config UPROBE_EVENT > > bool "Enable uprobes-based dynamic events" > > depends on ARCH_SUPPORTS_UPROBES > > depends on MMU > > + depends on PERF_EVENTS > > Can't we delay this change? This conflicts with > > [PATCH v7 01/15] uprobes: Kconfig dependency fix > http://marc.info/?l=linux-kernel&m=139422332915701 That doesn't conflict; they both make exactly the same change, and they should trivially merge. - Josh Triplett |
From: Oleg Nesterov <oleg@re...> - 2014-03-10 14:51:27
|
On 03/10, Ingo Molnar wrote: > > So my main problem with those patches was that if HW_BREAKPOINTS is > disabled then GDB 'hbreak' isn't simply disabled but fails in various > non-obvious ways, but the kernel should return an error. And this can happen anyway, say, reserve_bp_slot() can fail because all slots are already used by perf. And iirc, gdb always switches to the single-stepping if hbreak fails. Oleg. |
From: Oleg Nesterov <oleg@re...> - 2014-03-10 14:44:01
|
On 03/10, Oleg Nesterov wrote: > > On 03/09, Josh Triplett wrote: > > > > +static unsigned long ptrace_get_debugreg(struct task_struct *tsk, int n) > > +{ > > + struct thread_struct *thread = &tsk->thread; > > + > > + if (n == 6) > > + return thread->debugreg6; > > + return 0; > > +} > > + > > +/* Without breakpoints only handle DR6 */ > > +static int ptrace_set_debugreg(struct task_struct *tsk, int n, > > + unsigned long val) > > +{ > > + struct thread_struct *thread = &tsk->thread; > > + int rc = -EIO; > > + > > + if (n == 6) { > > + thread->debugreg6 = val; > > + rc = 0; > > + } > > + return rc; > > +} > > + > > +#endif > > OK, but then perhaps this patch should also make thread_struct->ptrace_bps[] > depend on CONFIG_HW_BREAKPOINTS ? and ->ptrace_dr7 at least. And in fact, why do we need ptrace_get/set_debugreg(DR6) without HW_BREAKPOINTS? Perhaps get/set should just return the error? > But I won't insist if you prefer to do this later. Yes. Oleg. |
From: Oleg Nesterov <oleg@re...> - 2014-03-10 14:36:23
|
On 03/09, Josh Triplett wrote: > > +#ifdef CONFIG_HW_BREAKPOINTS > + > static void ptrace_triggered(struct perf_event *bp, > struct perf_sample_data *data, > struct pt_regs *regs) > @@ -778,6 +780,34 @@ static int ptrace_set_debugreg(struct task_struct *tsk, int n, > return rc; > } > > +#else > + > +/* Without breakpoints only handle DR6 */ > +static unsigned long ptrace_get_debugreg(struct task_struct *tsk, int n) > +{ > + struct thread_struct *thread = &tsk->thread; > + > + if (n == 6) > + return thread->debugreg6; > + return 0; > +} > + > +/* Without breakpoints only handle DR6 */ > +static int ptrace_set_debugreg(struct task_struct *tsk, int n, > + unsigned long val) > +{ > + struct thread_struct *thread = &tsk->thread; > + int rc = -EIO; > + > + if (n == 6) { > + thread->debugreg6 = val; > + rc = 0; > + } > + return rc; > +} > + > +#endif OK, but then perhaps this patch should also make thread_struct->ptrace_bps[] depend on CONFIG_HW_BREAKPOINTS ? This needs more changes though. In particular, it seems it makes sense to move flush_ptrace_hw_breakpoint() to x86/kernel/ptrace.c, so that it can live in the same ifdef'ed section. copy_threads() needs a cleanup anyway... But I won't insist if you prefer to do this later. Oleg. |
From: Oleg Nesterov <oleg@re...> - 2014-03-10 14:22:29
|
On 03/09, Josh Triplett wrote: > > UPROBES need the perf events code, Actually it doesn't. But yes, the kernel/events directory is only built if CONFIG_PERF_EVENTS. See http://marc.info/?t=139201796100001 > diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig > index 015f85a..8639819 100644 > --- a/kernel/trace/Kconfig > +++ b/kernel/trace/Kconfig > @@ -424,6 +424,7 @@ config UPROBE_EVENT > bool "Enable uprobes-based dynamic events" > depends on ARCH_SUPPORTS_UPROBES > depends on MMU > + depends on PERF_EVENTS Can't we delay this change? This conflicts with [PATCH v7 01/15] uprobes: Kconfig dependency fix http://marc.info/?l=linux-kernel&m=139422332915701 We need to untangle UPROBES and PERF, we can change the Makefile's or move uprobe.c to kernel/. Oleg. |
From: Josh Triplett <josh@jo...> - 2014-03-10 08:42:45
|
On Mon, Mar 10, 2014 at 08:43:54AM +0100, Ingo Molnar wrote: > > * Josh Triplett <josh@...> wrote: > > > This patch series makes it possible to disable HW_BREAKPOINTS, > > PERF_EVENTS, INSTRUCTION_DECODER, IRQ_WORK, and ANON_INODES. > > Without this patch series, all of these config options get > > automatically selected on x86, making them impossible to disable. > > > > This is a revival of a previous patch series from Andi Kleen sent in > > October 2013. [...] > > So my main problem with those patches was that if HW_BREAKPOINTS is > disabled then GDB 'hbreak' isn't simply disabled but fails in various > non-obvious ways, taking down the rest of GDB with it, so it's in > essence an ABI and tool breaker which is not very useful. It's hidden behind EXPERT for a reason, and non-hardware breakpoints still work just fine. This is the kind of thing enabled on an embedded system, where you're not going to be running GDB at all, let alone using "hbreak". Given that other options depending on EXPERT let you disable things as critical as futexes or ELF binary support... Would it help to have some more detailed help text for HW_BREAKPOINTS, explaining that gdb's "hbreak" and similar will utterly fail if this option is disabled? Alternatively, would it suffice to make ptrace_set_debugreg always return an error when !CONFIG_HW_BREAKPOINTS? Would that produce error behavior you'd prefer? > If all of ptrace is disabled then it perhaps behaves more cleanly, That's on my list for the future. :) - Josh Triplett |
From: Ingo Molnar <mingo@ke...> - 2014-03-10 07:44:05
|
* Josh Triplett <josh@...> wrote: > This patch series makes it possible to disable HW_BREAKPOINTS, > PERF_EVENTS, INSTRUCTION_DECODER, IRQ_WORK, and ANON_INODES. > Without this patch series, all of these config options get > automatically selected on x86, making them impossible to disable. > > This is a revival of a previous patch series from Andi Kleen sent in > October 2013. [...] So my main problem with those patches was that if HW_BREAKPOINTS is disabled then GDB 'hbreak' isn't simply disabled but fails in various non-obvious ways, taking down the rest of GDB with it, so it's in essence an ABI and tool breaker which is not very useful. If all of ptrace is disabled then it perhaps behaves more cleanly, but we didn't allow the disabling of ptrace in the past, and I'm not sure we should start with it today. So it's still a NAK for the time being. Thanks, Ingo |
From: Andi Kleen <ak@li...> - 2014-03-10 04:53:45
|
All changes look good to me. Thanks for picking that up. Reviewed-by: Andi Kleen <ak@...> -- ak@... -- Speaking for myself only |
From: Josh Triplett <josh@jo...> - 2014-03-10 04:25:17
|
From: Andi Kleen <ak@...> UPROBES need the perf events code, so add a dependency from PERF_EVENTS to UPROBES. Cc: rostedt@... Signed-off-by: Andi Kleen <ak@...> --- kernel/trace/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig index 015f85a..8639819 100644 --- a/kernel/trace/Kconfig +++ b/kernel/trace/Kconfig @@ -424,6 +424,7 @@ config UPROBE_EVENT bool "Enable uprobes-based dynamic events" depends on ARCH_SUPPORTS_UPROBES depends on MMU + depends on PERF_EVENTS select UPROBES select PROBE_EVENTS select TRACING -- 1.9.0 |
From: Josh Triplett <josh@jo...> - 2014-03-10 04:25:17
|
From: Andi Kleen <ak@...> Add ifdefs on CONFIG_HW_BREAKPOINTS to the hardware break point code in x86 ptrace.c. This prepares this file for being able to disable HW_BREAKPOINTS. The only debug register that needs to be handled without break points is DR6, so do that in a simple separate function without breakpoints. Cc: fweisbec@... Signed-off-by: Andi Kleen <ak@...> --- arch/x86/kernel/ptrace.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c index 7461f50..dda433f 100644 --- a/arch/x86/kernel/ptrace.c +++ b/arch/x86/kernel/ptrace.c @@ -561,6 +561,8 @@ static int genregs_set(struct task_struct *target, return ret; } +#ifdef CONFIG_HW_BREAKPOINTS + static void ptrace_triggered(struct perf_event *bp, struct perf_sample_data *data, struct pt_regs *regs) @@ -778,6 +780,34 @@ static int ptrace_set_debugreg(struct task_struct *tsk, int n, return rc; } +#else + +/* Without breakpoints only handle DR6 */ +static unsigned long ptrace_get_debugreg(struct task_struct *tsk, int n) +{ + struct thread_struct *thread = &tsk->thread; + + if (n == 6) + return thread->debugreg6; + return 0; +} + +/* Without breakpoints only handle DR6 */ +static int ptrace_set_debugreg(struct task_struct *tsk, int n, + unsigned long val) +{ + struct thread_struct *thread = &tsk->thread; + int rc = -EIO; + + if (n == 6) { + thread->debugreg6 = val; + rc = 0; + } + return rc; +} + +#endif + /* * These access the current or another (stopped) task's io permission * bitmap for debugging or core dump. -- 1.9.0 |
From: Josh Triplett <josh@jo...> - 2014-03-10 04:23:58
|
Now that PERF_EVENTS is no longer mandatory, ANON_INODES need not be either. Everything that needs ANON_INODES selects it. bloat-o-meter summary: add/remove: 0/10 grow/shrink: 0/0 up/down: 0/-613 (-613) function old new delta anon_inode_mnt 4 - -4 anon_inode_inode 4 - -4 __initcall_anon_inode_init5 4 - -4 anon_inode_fs_type 28 - -28 anon_inodefs_dname 40 - -40 anon_inodefs_dentry_operations 64 - -64 anon_inode_init 79 - -79 anon_inode_getfd 91 - -91 anon_inodefs_mount 93 - -93 anon_inode_getfile 206 - -206 Signed-off-by: Josh Triplett <josh@...> --- arch/x86/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 12e3386..10c51ff 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -74,7 +74,6 @@ config X86 select HAVE_PERF_REGS select HAVE_PERF_USER_STACK_DUMP select HAVE_DEBUG_KMEMLEAK - select ANON_INODES select HAVE_ALIGNED_STRUCT_PAGE if SLUB select HAVE_CMPXCHG_LOCAL select HAVE_CMPXCHG_DOUBLE -- 1.9.0 |
From: Josh Triplett <josh@jo...> - 2014-03-10 04:23:52
|
From: Andi Kleen <ak@...> Now that oprofile doesn't need the AMD IBS perf code anymore, we can make that code dependent on PERF_EVENTS and AMD CPU support, instead of unconditionally compiling it in. Cc: bp@... Signed-off-by: Andi Kleen <ak@...> --- arch/x86/kernel/cpu/Makefile | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile index 7fd54f0..df9f9a3 100644 --- a/arch/x86/kernel/cpu/Makefile +++ b/arch/x86/kernel/cpu/Makefile @@ -37,6 +37,9 @@ endif obj-$(CONFIG_CPU_SUP_INTEL) += perf_event_p6.o perf_event_knc.o perf_event_p4.o obj-$(CONFIG_CPU_SUP_INTEL) += perf_event_intel_lbr.o perf_event_intel_ds.o perf_event_intel.o obj-$(CONFIG_CPU_SUP_INTEL) += perf_event_intel_uncore.o perf_event_intel_rapl.o +ifdef CONFIG_X86_LOCAL_APIC +obj-$(CONFIG_CPU_SUP_AMD) += perf_event_amd_ibs.o +endif endif @@ -44,7 +47,7 @@ obj-$(CONFIG_X86_MCE) += mcheck/ obj-$(CONFIG_MTRR) += mtrr/ obj-$(CONFIG_MICROCODE) += microcode/ -obj-$(CONFIG_X86_LOCAL_APIC) += perfctr-watchdog.o perf_event_amd_ibs.o +obj-$(CONFIG_X86_LOCAL_APIC) += perfctr-watchdog.o obj-$(CONFIG_HYPERVISOR_GUEST) += vmware.o hypervisor.o mshyperv.o -- 1.9.0 |