Patches 1-6 fix a number of races when the traced task is currently running.
In the worst case, the kernel may crash since the cpu may continue
tracing after the trace buffer has already been freed.
This may happen when the tracing or traced task are killed.
The first 5 patches apply to .29 with the small preparation patch below.
Patches 7-11 fix problems with the hw-branch-tracer. It performs DS
operations in an on_each_cpu() context, which has interrupts disabled.
Patch 7 adds a _noirq version for most ds_ functions and separates
cpu and task tracing. It allows cpu tracing to be configured from any cpu.
This allows the hw-branch-tracer in patch 8 to remove the bad spinlock
and use simple for_each_online_cpu loops.
The remaining patches change the other DS users to use the new interface.
Patches 12-15 add more selftests, defer selftesting, and fix a bad check.
Patches 16-19 do some cleanups that have been requested from reviewers.
Patch 20 fixes a bug where the wrong qualifier was passed to a shared function
resulting in the bts configuration to be reset when a reset of the pebs
configuration had been requested.
Patch 21 adds support for Core i7.
Thanks to Oleg Nesterov for reviewing the first round of patches and
for pointing out several races!
Signed-off-by: Markus Metzger <[email protected]>
---
Index: linux-2.6.29/arch/x86/kernel/ds.c
===================================================================
--- linux-2.6.29.orig/arch/x86/kernel/ds.c 2009-03-31 11:56:21.000000000 +0200
+++ linux-2.6.29/arch/x86/kernel/ds.c 2009-03-31 11:57:38.000000000 +0200
@@ -78,8 +78,8 @@ struct bts_tracer {
struct ds_tracer ds;
/* the trace including the DS configuration */
struct bts_trace trace;
- /* buffer overflow notification function */
- bts_ovfl_callback_t ovfl;
+ /* Buffer overflow notification function: */
+ bts_ovfl_callback_t ovfl;
};
struct pebs_tracer {
Index: linux-2.6.29/arch/x86/kernel/ptrace.c
===================================================================
--- linux-2.6.29.orig/arch/x86/kernel/ptrace.c 2009-03-31 11:56:21.000000000 +0200
+++ linux-2.6.29/arch/x86/kernel/ptrace.c 2009-03-31 11:56:24.000000000 +0200
@@ -21,6 +21,7 @@
#include <linux/audit.h>
#include <linux/seccomp.h>
#include <linux/signal.h>
+#include <linux/ftrace.h>
#include <asm/uaccess.h>
#include <asm/pgtable.h>
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
On 03/31, Markus Metzger wrote:
>
> The first 5 patches apply to .29 with the small preparation patch below.
Tried to review these patches.
As I said, I don't understand ds.c, but I _think_ these changes are good.
I only have a couple of really minor nitpicks...
Oleg.
>-----Original Message-----
>From: Oleg Nesterov [mailto:[email protected]]
>Sent: Wednesday, April 01, 2009 1:40 AM
>To: Metzger, Markus T
>> The first 5 patches apply to .29 with the small preparation patch below.
>
>Tried to review these patches.
>
>As I said, I don't understand ds.c, but I _think_ these changes are good.
>
>I only have a couple of really minor nitpicks...
Thanks for your review!
I will address the nitpicks in separate patches, if that's OK with everyone.
Regarding bisecting, I split the patches to attract reviewers to the smaller
parts rather than scare them off with one big patch.
I hope that the bisecting tool can cope with broken builds between patches.
regards,
markus.
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
* Metzger, Markus T <[email protected]> wrote:
> >-----Original Message-----
> >From: Oleg Nesterov [mailto:[email protected]]
> >Sent: Wednesday, April 01, 2009 1:40 AM
> >To: Metzger, Markus T
>
>
> >> The first 5 patches apply to .29 with the small preparation patch below.
> >
> >Tried to review these patches.
> >
> >As I said, I don't understand ds.c, but I _think_ these changes are good.
> >
> >I only have a couple of really minor nitpicks...
>
> Thanks for your review!
> I will address the nitpicks in separate patches, if that's OK with everyone.
Please dont forget to propagate Oleg's Reviewed-by (or Acked-by)
tags into the commits.
> Regarding bisecting, I split the patches to attract reviewers to
> the smaller parts rather than scare them off with one big patch.
>
> I hope that the bisecting tool can cope with broken builds between
> patches.
It cannot, and even if it did we dont want a single intentionally
broken bisection point in the kernel. Please do small patches that
build fine at each step. We've got more than 100,000 bisectable
commits in the kernel to look at. If you think it's not possible in
a specific case then please describe the situation to us so that we
can suggest a solution.
Ingo
>-----Original Message-----
>From: Ingo Molnar [mailto:[email protected]]
>Sent: Wednesday, April 01, 2009 1:46 PM
>To: Metzger, Markus T
>> >> The first 5 patches apply to .29 with the small preparation patch below.
>> >
>> >Tried to review these patches.
>> >
>> >As I said, I don't understand ds.c, but I _think_ these changes are good.
>> >
>> >I only have a couple of really minor nitpicks...
>>
>> Thanks for your review!
>> I will address the nitpicks in separate patches, if that's OK with everyone.
>
>Please dont forget to propagate Oleg's Reviewed-by (or Acked-by)
>tags into the commits.
>
>> Regarding bisecting, I split the patches to attract reviewers to
>> the smaller parts rather than scare them off with one big patch.
>>
>> I hope that the bisecting tool can cope with broken builds between
>> patches.
>
>It cannot, and even if it did we dont want a single intentionally
>broken bisection point in the kernel. Please do small patches that
>build fine at each step. We've got more than 100,000 bisectable
>commits in the kernel to look at. If you think it's not possible in
>a specific case then please describe the situation to us so that we
>can suggest a solution.
I can resend the series with fewer but bigger patches that compile OK.
I'm currently using quilt to manage patches.
I use git to get the sources, but that's it. I send all the patches manually.
You mentioned in another email that I should use "git format-patch" and
"git send-email" and that I should propagate Oleg's acks into the commit
logs.
Is there a way to do this with quilt, as well?
Could you point me to some getting-started documentation?
thanks and regards,
markus.
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
* Metzger, Markus T <[email protected]> wrote:
> >-----Original Message-----
> >From: Ingo Molnar [mailto:[email protected]]
> >Sent: Wednesday, April 01, 2009 1:46 PM
> >To: Metzger, Markus T
>
>
> >> >> The first 5 patches apply to .29 with the small preparation patch below.
> >> >
> >> >Tried to review these patches.
> >> >
> >> >As I said, I don't understand ds.c, but I _think_ these changes are good.
> >> >
> >> >I only have a couple of really minor nitpicks...
> >>
> >> Thanks for your review!
> >> I will address the nitpicks in separate patches, if that's OK with everyone.
> >
> >Please dont forget to propagate Oleg's Reviewed-by (or Acked-by)
> >tags into the commits.
> >
> >> Regarding bisecting, I split the patches to attract reviewers to
> >> the smaller parts rather than scare them off with one big patch.
> >>
> >> I hope that the bisecting tool can cope with broken builds between
> >> patches.
> >
> >It cannot, and even if it did we dont want a single intentionally
> >broken bisection point in the kernel. Please do small patches that
> >build fine at each step. We've got more than 100,000 bisectable
> >commits in the kernel to look at. If you think it's not possible in
> >a specific case then please describe the situation to us so that we
> >can suggest a solution.
>
> I can resend the series with fewer but bigger patches that compile
> OK.
>
> I'm currently using quilt to manage patches. I use git to get the
> sources, but that's it. I send all the patches manually.
>
> You mentioned in another email that I should use "git
> format-patch" and "git send-email" and that I should propagate
> Oleg's acks into the commit logs.
>
> Is there a way to do this with quilt, as well? Could you point me
> to some getting-started documentation?
Maybe "quilt mail" does it correctly but i have not checked.
Ingo