Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Thu, Feb 23, 2017 at 06:28:01PM +0100, Peter Zijlstra wrote: > I think Boris and Thomas were talking about moving the entire c1e > detection out of there. Yeah, see 07c94a381253 ("x86/amd: Simplify AMD E400 aware idle routine") tglx and I got rid of reading that MSR in the idle routine. --

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Thu, Feb 23, 2017 at 06:28:01PM +0100, Peter Zijlstra wrote: > I think Boris and Thomas were talking about moving the entire c1e > detection out of there. Yeah, see 07c94a381253 ("x86/amd: Simplify AMD E400 aware idle routine") tglx and I got rid of reading that MSR in the idle routine. --

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Thu, Feb 23, 2017 at 01:24:34PM +0100, Jiri Olsa wrote: > On Mon, Nov 21, 2016 at 10:28:50AM +0100, Peter Zijlstra wrote: > > > > I think I prefer something like the below, that only annotates the one > > RDMSR in question, instead of all of them. > > > > > > diff --git

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Thu, Feb 23, 2017 at 01:24:34PM +0100, Jiri Olsa wrote: > On Mon, Nov 21, 2016 at 10:28:50AM +0100, Peter Zijlstra wrote: > > > > I think I prefer something like the below, that only annotates the one > > RDMSR in question, instead of all of them. > > > > > > diff --git

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

> > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > > index 0888a879120f..d6c6aa80675f 100644 > > --- a/arch/x86/kernel/process.c > > +++ b/arch/x86/kernel/process.c > > @@ -357,7 +357,7 @@ static void amd_e400_idle(void) > > if (!amd_e400_c1e_detected) { > >

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

> > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > > index 0888a879120f..d6c6aa80675f 100644 > > --- a/arch/x86/kernel/process.c > > +++ b/arch/x86/kernel/process.c > > @@ -357,7 +357,7 @@ static void amd_e400_idle(void) > > if (!amd_e400_c1e_detected) { > >

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 10:28:50AM +0100, Peter Zijlstra wrote: > On Mon, Nov 21, 2016 at 01:53:43AM +0100, Jiri Olsa wrote: > > hi, > > Jan hit following output when msr tracepoints are enabled on amd server: > > > > [ 91.585653] === > > [ 91.589840] [ INFO:

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 10:28:50AM +0100, Peter Zijlstra wrote: > On Mon, Nov 21, 2016 at 01:53:43AM +0100, Jiri Olsa wrote: > > hi, > > Jan hit following output when msr tracepoints are enabled on amd server: > > > > [ 91.585653] === > > [ 91.589840] [ INFO:

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Wed, 30 Nov 2016, Borislav Petkov wrote: > On Wed, Nov 30, 2016 at 09:54:58AM +0100, Thomas Gleixner wrote: > > Right, that's the safe bet. But I'm quite sure that the C1E crap only > > starts to work _after_ ACPI initialization. > > Yap, I think it is an ACPI decision whether to enter C1E or

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Wed, 30 Nov 2016, Borislav Petkov wrote: > On Wed, Nov 30, 2016 at 09:54:58AM +0100, Thomas Gleixner wrote: > > Right, that's the safe bet. But I'm quite sure that the C1E crap only > > starts to work _after_ ACPI initialization. > > Yap, I think it is an ACPI decision whether to enter C1E or

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Wed, Nov 30, 2016 at 09:54:58AM +0100, Thomas Gleixner wrote: > Right, that's the safe bet. But I'm quite sure that the C1E crap only > starts to work _after_ ACPI initialization. Yap, I think it is an ACPI decision whether to enter C1E or not. And all those boxes which are unaffected - they

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Wed, Nov 30, 2016 at 09:54:58AM +0100, Thomas Gleixner wrote: > Right, that's the safe bet. But I'm quite sure that the C1E crap only > starts to work _after_ ACPI initialization. Yap, I think it is an ACPI decision whether to enter C1E or not. And all those boxes which are unaffected - they

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Wed, 30 Nov 2016, Borislav Petkov wrote: > On Tue, Nov 29, 2016 at 02:59:01PM +0100, Thomas Gleixner wrote: > > The issue is that you obvioulsy start with the assumption, that the machine > > has this bug. As a consequence the machine is brute forced into tick > > broadcast mode, which cannot

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Wed, 30 Nov 2016, Borislav Petkov wrote: > On Tue, Nov 29, 2016 at 02:59:01PM +0100, Thomas Gleixner wrote: > > The issue is that you obvioulsy start with the assumption, that the machine > > has this bug. As a consequence the machine is brute forced into tick > > broadcast mode, which cannot

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Tue, Nov 29, 2016 at 02:59:01PM +0100, Thomas Gleixner wrote: > The issue is that you obvioulsy start with the assumption, that the machine > has this bug. As a consequence the machine is brute forced into tick > broadcast mode, which cannot be reverted when you clear that misfeature > after

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Tue, Nov 29, 2016 at 02:59:01PM +0100, Thomas Gleixner wrote: > The issue is that you obvioulsy start with the assumption, that the machine > has this bug. As a consequence the machine is brute forced into tick > broadcast mode, which cannot be reverted when you clear that misfeature > after

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Tue, Nov 29, 2016 at 02:16:49PM +0100, Borislav Petkov wrote: > On Mon, Nov 21, 2016 at 05:06:54PM +0100, Borislav Petkov wrote: > > IOW, what's the worst thing that can happen if we did this below? > > > > We basically get rid of the detection and switch the timer to broadcast > > mode

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Tue, Nov 29, 2016 at 02:16:49PM +0100, Borislav Petkov wrote: > On Mon, Nov 21, 2016 at 05:06:54PM +0100, Borislav Petkov wrote: > > IOW, what's the worst thing that can happen if we did this below? > > > > We basically get rid of the detection and switch the timer to broadcast > > mode

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Tue, 29 Nov 2016, Borislav Petkov wrote: > On Mon, Nov 21, 2016 at 05:06:54PM +0100, Borislav Petkov wrote: > > IOW, what's the worst thing that can happen if we did this below? > > > > We basically get rid of the detection and switch the timer to broadcast > > mode immediately on the halting

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Tue, 29 Nov 2016, Borislav Petkov wrote: > On Mon, Nov 21, 2016 at 05:06:54PM +0100, Borislav Petkov wrote: > > IOW, what's the worst thing that can happen if we did this below? > > > > We basically get rid of the detection and switch the timer to broadcast > > mode immediately on the halting

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 05:06:54PM +0100, Borislav Petkov wrote: > IOW, what's the worst thing that can happen if we did this below? > > We basically get rid of the detection and switch the timer to broadcast > mode immediately on the halting CPU. > > amd_e400_idle() is behind an "if

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 05:06:54PM +0100, Borislav Petkov wrote: > IOW, what's the worst thing that can happen if we did this below? > > We basically get rid of the detection and switch the timer to broadcast > mode immediately on the halting CPU. > > amd_e400_idle() is behind an "if

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

> Well, actually it's been optimized a lot from the first instances. > Note, tracepoints need to be quite generic, so where it can be optimized > is not obvious. There is quite a bit of stuff that doesn't change from trace point to trace point. So you could just cache all these decisions into a

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

> Well, actually it's been optimized a lot from the first instances. > Note, tracepoints need to be quite generic, so where it can be optimized > is not obvious. There is quite a bit of stuff that doesn't change from trace point to trace point. So you could just cache all these decisions into a

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, 28 Nov 2016 13:48:25 -0800 Andi Kleen wrote: > > I took a look at this and forced some more functions to be inlined. I > > did a little tweaking here and there. Could you pull my tree and see if > > things are better? I don't currently have the hardware to run this

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, 28 Nov 2016 13:48:25 -0800 Andi Kleen wrote: > > I took a look at this and forced some more functions to be inlined. I > > did a little tweaking here and there. Could you pull my tree and see if > > things are better? I don't currently have the hardware to run this > > myself. > > > >

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

> I took a look at this and forced some more functions to be inlined. I > did a little tweaking here and there. Could you pull my tree and see if > things are better? I don't currently have the hardware to run this > myself. > >

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

> I took a look at this and forced some more functions to be inlined. I > did a little tweaking here and there. Could you pull my tree and see if > things are better? I don't currently have the hardware to run this > myself. > >

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, 21 Nov 2016 10:37:00 -0800 Andi Kleen wrote: > > It tries to be optimized. I "unoptimized" it a while back to pull out > > all the inlines that were done in the tracepoint itself. That is, the > > trace_() function is inlined in the code itself. By > > breaking that

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, 21 Nov 2016 10:37:00 -0800 Andi Kleen wrote: > > It tries to be optimized. I "unoptimized" it a while back to pull out > > all the inlines that were done in the tracepoint itself. That is, the > > trace_() function is inlined in the code itself. By > > breaking that up a bit, I was able

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Tue, Nov 22, 2016 at 09:39:45AM -0500, Steven Rostedt wrote: > On Mon, 21 Nov 2016 10:37:00 -0800 > Andi Kleen wrote: > > > > Here is it again untruncated: > > > > http://halobates.de/tracepoint-trace > > BTW, what tool did you use to generate this? perf and Intel PT,

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Tue, Nov 22, 2016 at 09:39:45AM -0500, Steven Rostedt wrote: > On Mon, 21 Nov 2016 10:37:00 -0800 > Andi Kleen wrote: > > > > Here is it again untruncated: > > > > http://halobates.de/tracepoint-trace > > BTW, what tool did you use to generate this? perf and Intel PT, with the

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, 21 Nov 2016 10:37:00 -0800 Andi Kleen wrote: > Here is it again untruncated: > > http://halobates.de/tracepoint-trace BTW, what tool did you use to generate this? -- Steve

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, 21 Nov 2016 10:37:00 -0800 Andi Kleen wrote: > Here is it again untruncated: > > http://halobates.de/tracepoint-trace BTW, what tool did you use to generate this? -- Steve

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 12:44:45PM -0800, Andi Kleen wrote: > > > http://halobates.de/tracepoint-trace > > > > There's a lot of push and pop regs due to function calling. There's > > places that inlines can still improve things, and perhaps even some > > likely unlikelys well placed. > >

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 12:44:45PM -0800, Andi Kleen wrote: > > > http://halobates.de/tracepoint-trace > > > > There's a lot of push and pop regs due to function calling. There's > > places that inlines can still improve things, and perhaps even some > > likely unlikelys well placed. > >

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

> > http://halobates.de/tracepoint-trace > > There's a lot of push and pop regs due to function calling. There's > places that inlines can still improve things, and perhaps even some > likely unlikelys well placed. Assuming you avoid all the push/pop and all the call/ret this would only be ~25%

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

> > http://halobates.de/tracepoint-trace > > There's a lot of push and pop regs due to function calling. There's > places that inlines can still improve things, and perhaps even some > likely unlikelys well placed. Assuming you avoid all the push/pop and all the call/ret this would only be ~25%

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 01:24:38PM -0500, Steven Rostedt wrote: > > Paul, > > > On Mon, 21 Nov 2016 12:55:01 -0500 > Steven Rostedt wrote: > > > On Mon, 21 Nov 2016 18:18:53 +0100 > > Peter Zijlstra wrote: > > > > > Its not ftrace as such though,

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 01:24:38PM -0500, Steven Rostedt wrote: > > Paul, > > > On Mon, 21 Nov 2016 12:55:01 -0500 > Steven Rostedt wrote: > > > On Mon, 21 Nov 2016 18:18:53 +0100 > > Peter Zijlstra wrote: > > > > > Its not ftrace as such though, its RCU, ftrace simply uses RCU to avoid > >

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, 21 Nov 2016 10:37:00 -0800 Andi Kleen wrote: > Just adding a few inlines won't fix the gigantic bloat that is currently > there. See the PT trace I posted earlier (it was even truncated, it's > actually worse). Just a single enabled trace point took about a us. If

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, 21 Nov 2016 10:37:00 -0800 Andi Kleen wrote: > Just adding a few inlines won't fix the gigantic bloat that is currently > there. See the PT trace I posted earlier (it was even truncated, it's > actually worse). Just a single enabled trace point took about a us. If you want to play with

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, 21 Nov 2016 10:37:00 -0800 Andi Kleen wrote: > Ok so how should tracing in idle code work then in your opinion? As I suggested already. If we can get a light weight rcu_is_watching() then we can do the rcu_idle work when needed, and not when we don't need it. Sure

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, 21 Nov 2016 10:37:00 -0800 Andi Kleen wrote: > Ok so how should tracing in idle code work then in your opinion? As I suggested already. If we can get a light weight rcu_is_watching() then we can do the rcu_idle work when needed, and not when we don't need it. Sure this will add more

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

> It tries to be optimized. I "unoptimized" it a while back to pull out > all the inlines that were done in the tracepoint itself. That is, the > trace_() function is inlined in the code itself. By > breaking that up a bit, I was able to save a bunch of text because the > tracepoints were bloating

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

> It tries to be optimized. I "unoptimized" it a while back to pull out > all the inlines that were done in the tracepoint itself. That is, the > trace_() function is inlined in the code itself. By > breaking that up a bit, I was able to save a bunch of text because the > tracepoints were bloating

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

Paul, On Mon, 21 Nov 2016 12:55:01 -0500 Steven Rostedt wrote: > On Mon, 21 Nov 2016 18:18:53 +0100 > Peter Zijlstra wrote: > > > Its not ftrace as such though, its RCU, ftrace simply uses RCU to avoid > > locking, as one does. > > Just to be

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

Paul, On Mon, 21 Nov 2016 12:55:01 -0500 Steven Rostedt wrote: > On Mon, 21 Nov 2016 18:18:53 +0100 > Peter Zijlstra wrote: > > > Its not ftrace as such though, its RCU, ftrace simply uses RCU to avoid > > locking, as one does. > > Just to be clear, as ftrace in the kernel mostly

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, 21 Nov 2016 10:06:54 -0800 Andi Kleen wrote: > > And a popf can be much more expensive than any of these. You should > > know, not all instructions are equal. > > > > Using perf, I've seen popf take up almst 30% of a function the size of > > this. > > In any case

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, 21 Nov 2016 10:06:54 -0800 Andi Kleen wrote: > > And a popf can be much more expensive than any of these. You should > > know, not all instructions are equal. > > > > Using perf, I've seen popf take up almst 30% of a function the size of > > this. > > In any case it's a small

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

> And a popf can be much more expensive than any of these. You should > know, not all instructions are equal. > > Using perf, I've seen popf take up almst 30% of a function the size of > this. In any case it's a small fraction of the 600+ instructions which are currently executed for every

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

> And a popf can be much more expensive than any of these. You should > know, not all instructions are equal. > > Using perf, I've seen popf take up almst 30% of a function the size of > this. In any case it's a small fraction of the 600+ instructions which are currently executed for every

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, 21 Nov 2016 09:45:04 -0800 Andi Kleen wrote: > On Mon, Nov 21, 2016 at 06:18:53PM +0100, Peter Zijlstra wrote: > > On Mon, Nov 21, 2016 at 09:06:13AM -0800, Andi Kleen wrote: > > > > > it got away with attached change.. but this rcu logic > > > > > is far beyond

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, 21 Nov 2016 09:45:04 -0800 Andi Kleen wrote: > On Mon, Nov 21, 2016 at 06:18:53PM +0100, Peter Zijlstra wrote: > > On Mon, Nov 21, 2016 at 09:06:13AM -0800, Andi Kleen wrote: > > > > > it got away with attached change.. but this rcu logic > > > > > is far beyond me, so it's just wild

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, 21 Nov 2016 18:18:53 +0100 Peter Zijlstra wrote: > Its not ftrace as such though, its RCU, ftrace simply uses RCU to avoid > locking, as one does. Just to be clear, as ftrace in the kernel mostly represents function tracing, which doesn't use RCU. This is a

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, 21 Nov 2016 18:18:53 +0100 Peter Zijlstra wrote: > Its not ftrace as such though, its RCU, ftrace simply uses RCU to avoid > locking, as one does. Just to be clear, as ftrace in the kernel mostly represents function tracing, which doesn't use RCU. This is a tracepoint feature. > >

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 06:18:53PM +0100, Peter Zijlstra wrote: > On Mon, Nov 21, 2016 at 09:06:13AM -0800, Andi Kleen wrote: > > > > it got away with attached change.. but this rcu logic > > > > is far beyond me, so it's just wild guess.. ;-) > > > > > > I think I prefer something like the

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 06:18:53PM +0100, Peter Zijlstra wrote: > On Mon, Nov 21, 2016 at 09:06:13AM -0800, Andi Kleen wrote: > > > > it got away with attached change.. but this rcu logic > > > > is far beyond me, so it's just wild guess.. ;-) > > > > > > I think I prefer something like the

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 09:06:13AM -0800, Andi Kleen wrote: > > > it got away with attached change.. but this rcu logic > > > is far beyond me, so it's just wild guess.. ;-) > > > > I think I prefer something like the below, that only annotates the one > > RDMSR in question, instead of all of

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 09:06:13AM -0800, Andi Kleen wrote: > > > it got away with attached change.. but this rcu logic > > > is far beyond me, so it's just wild guess.. ;-) > > > > I think I prefer something like the below, that only annotates the one > > RDMSR in question, instead of all of

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

> > it got away with attached change.. but this rcu logic > > is far beyond me, so it's just wild guess.. ;-) > > I think I prefer something like the below, that only annotates the one > RDMSR in question, instead of all of them. It would be far better to just fix trace points that they always

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

> > it got away with attached change.. but this rcu logic > > is far beyond me, so it's just wild guess.. ;-) > > I think I prefer something like the below, that only annotates the one > RDMSR in question, instead of all of them. It would be far better to just fix trace points that they always

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

+ tglx. On Mon, Nov 21, 2016 at 04:41:04PM +0100, Peter Zijlstra wrote: > Right, I just wondered about the !c1e present case. In that case we'll > forever read the msr in the hope of finding that bit set, and we never > will. Well, erratum 400 flag is set on everything F10h from model 0x2

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

+ tglx. On Mon, Nov 21, 2016 at 04:41:04PM +0100, Peter Zijlstra wrote: > Right, I just wondered about the !c1e present case. In that case we'll > forever read the msr in the hope of finding that bit set, and we never > will. Well, erratum 400 flag is set on everything F10h from model 0x2

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 04:35:38PM +0100, Borislav Petkov wrote: > On Mon, Nov 21, 2016 at 03:37:16PM +0100, Peter Zijlstra wrote: > > Yeah, but this one does a printk() when it hits the contidion it checks > > for, so not tracing it would be fine I think. > > FWIW, there's already: > > static

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 04:35:38PM +0100, Borislav Petkov wrote: > On Mon, Nov 21, 2016 at 03:37:16PM +0100, Peter Zijlstra wrote: > > Yeah, but this one does a printk() when it hits the contidion it checks > > for, so not tracing it would be fine I think. > > FWIW, there's already: > > static

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 03:37:16PM +0100, Peter Zijlstra wrote: > Yeah, but this one does a printk() when it hits the contidion it checks > for, so not tracing it would be fine I think. FWIW, there's already: static inline void notrace native_write_msr(unsigned int msr, u32 low, u32 high) {

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 03:37:16PM +0100, Peter Zijlstra wrote: > Yeah, but this one does a printk() when it hits the contidion it checks > for, so not tracing it would be fine I think. FWIW, there's already: static inline void notrace native_write_msr(unsigned int msr, u32 low, u32 high) {

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 09:15:43AM -0500, Steven Rostedt wrote: > On Mon, 21 Nov 2016 13:58:30 +0100 > Peter Zijlstra wrote: > > > On Mon, Nov 21, 2016 at 10:34:25AM +0100, Jiri Olsa wrote: > > > > > > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > >

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 09:15:43AM -0500, Steven Rostedt wrote: > On Mon, 21 Nov 2016 13:58:30 +0100 > Peter Zijlstra wrote: > > > On Mon, Nov 21, 2016 at 10:34:25AM +0100, Jiri Olsa wrote: > > > > > > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > > > > index

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, 21 Nov 2016 13:58:30 +0100 Peter Zijlstra wrote: > On Mon, Nov 21, 2016 at 10:34:25AM +0100, Jiri Olsa wrote: > > > > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > > > index 0888a879120f..d6c6aa80675f 100644 > > > ---

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, 21 Nov 2016 13:58:30 +0100 Peter Zijlstra wrote: > On Mon, Nov 21, 2016 at 10:34:25AM +0100, Jiri Olsa wrote: > > > > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > > > index 0888a879120f..d6c6aa80675f 100644 > > > --- a/arch/x86/kernel/process.c > > > +++

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, 21 Nov 2016 13:58:30 +0100 Peter Zijlstra wrote: > On Mon, Nov 21, 2016 at 10:34:25AM +0100, Jiri Olsa wrote: > > > > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > > > index 0888a879120f..d6c6aa80675f 100644 > > > ---

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, 21 Nov 2016 13:58:30 +0100 Peter Zijlstra wrote: > On Mon, Nov 21, 2016 at 10:34:25AM +0100, Jiri Olsa wrote: > > > > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > > > index 0888a879120f..d6c6aa80675f 100644 > > > --- a/arch/x86/kernel/process.c > > > +++

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 10:34:25AM +0100, Jiri Olsa wrote: > > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > > index 0888a879120f..d6c6aa80675f 100644 > > --- a/arch/x86/kernel/process.c > > +++ b/arch/x86/kernel/process.c > > @@ -357,7 +357,7 @@ static void

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 10:34:25AM +0100, Jiri Olsa wrote: > > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > > index 0888a879120f..d6c6aa80675f 100644 > > --- a/arch/x86/kernel/process.c > > +++ b/arch/x86/kernel/process.c > > @@ -357,7 +357,7 @@ static void

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 12:31:31PM +0100, Peter Zijlstra wrote: > On Mon, Nov 21, 2016 at 12:22:29PM +0100, Jiri Olsa wrote: > > On Mon, Nov 21, 2016 at 10:42:27AM +0100, Peter Zijlstra wrote: > > > On Mon, Nov 21, 2016 at 10:34:25AM +0100, Jiri Olsa wrote: > > > > On Mon, Nov 21, 2016 at

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 12:31:31PM +0100, Peter Zijlstra wrote: > On Mon, Nov 21, 2016 at 12:22:29PM +0100, Jiri Olsa wrote: > > On Mon, Nov 21, 2016 at 10:42:27AM +0100, Peter Zijlstra wrote: > > > On Mon, Nov 21, 2016 at 10:34:25AM +0100, Jiri Olsa wrote: > > > > On Mon, Nov 21, 2016 at

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 12:22:29PM +0100, Jiri Olsa wrote: > On Mon, Nov 21, 2016 at 10:42:27AM +0100, Peter Zijlstra wrote: > > On Mon, Nov 21, 2016 at 10:34:25AM +0100, Jiri Olsa wrote: > > > On Mon, Nov 21, 2016 at 10:28:50AM +0100, Peter Zijlstra wrote: > > > > > > I think I prefer something

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 12:22:29PM +0100, Jiri Olsa wrote: > On Mon, Nov 21, 2016 at 10:42:27AM +0100, Peter Zijlstra wrote: > > On Mon, Nov 21, 2016 at 10:34:25AM +0100, Jiri Olsa wrote: > > > On Mon, Nov 21, 2016 at 10:28:50AM +0100, Peter Zijlstra wrote: > > > > > > I think I prefer something

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 10:42:27AM +0100, Peter Zijlstra wrote: > On Mon, Nov 21, 2016 at 10:34:25AM +0100, Jiri Olsa wrote: > > On Mon, Nov 21, 2016 at 10:28:50AM +0100, Peter Zijlstra wrote: > > > > I think I prefer something like the below, that only annotates the one > > > RDMSR in question,

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 10:42:27AM +0100, Peter Zijlstra wrote: > On Mon, Nov 21, 2016 at 10:34:25AM +0100, Jiri Olsa wrote: > > On Mon, Nov 21, 2016 at 10:28:50AM +0100, Peter Zijlstra wrote: > > > > I think I prefer something like the below, that only annotates the one > > > RDMSR in question,

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 10:43:21AM +0100, Peter Zijlstra wrote: > On Mon, Nov 21, 2016 at 01:02:25AM -0800, Paul E. McKenney wrote: > > On Mon, Nov 21, 2016 at 01:53:43AM +0100, Jiri Olsa wrote: > > > > > > it got away with attached change.. but this rcu logic > > > is far beyond me, so it's just

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 10:43:21AM +0100, Peter Zijlstra wrote: > On Mon, Nov 21, 2016 at 01:02:25AM -0800, Paul E. McKenney wrote: > > On Mon, Nov 21, 2016 at 01:53:43AM +0100, Jiri Olsa wrote: > > > > > > it got away with attached change.. but this rcu logic > > > is far beyond me, so it's just

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 01:02:25AM -0800, Paul E. McKenney wrote: > On Mon, Nov 21, 2016 at 01:53:43AM +0100, Jiri Olsa wrote: > > > > it got away with attached change.. but this rcu logic > > is far beyond me, so it's just wild guess.. ;-) > > If in idle, the _rcuidle() is needed, so: Well,

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 01:02:25AM -0800, Paul E. McKenney wrote: > On Mon, Nov 21, 2016 at 01:53:43AM +0100, Jiri Olsa wrote: > > > > it got away with attached change.. but this rcu logic > > is far beyond me, so it's just wild guess.. ;-) > > If in idle, the _rcuidle() is needed, so: Well,

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 10:34:25AM +0100, Jiri Olsa wrote: > On Mon, Nov 21, 2016 at 10:28:50AM +0100, Peter Zijlstra wrote: > > I think I prefer something like the below, that only annotates the one > > RDMSR in question, instead of all of them. > > I was wondering about that, but haven't found

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 10:34:25AM +0100, Jiri Olsa wrote: > On Mon, Nov 21, 2016 at 10:28:50AM +0100, Peter Zijlstra wrote: > > I think I prefer something like the below, that only annotates the one > > RDMSR in question, instead of all of them. > > I was wondering about that, but haven't found

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 10:28:50AM +0100, Peter Zijlstra wrote: > On Mon, Nov 21, 2016 at 01:53:43AM +0100, Jiri Olsa wrote: > > hi, > > Jan hit following output when msr tracepoints are enabled on amd server: > > > > [ 91.585653] === > > [ 91.589840] [ INFO:

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 10:28:50AM +0100, Peter Zijlstra wrote: > On Mon, Nov 21, 2016 at 01:53:43AM +0100, Jiri Olsa wrote: > > hi, > > Jan hit following output when msr tracepoints are enabled on amd server: > > > > [ 91.585653] === > > [ 91.589840] [ INFO:

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 01:53:43AM +0100, Jiri Olsa wrote: > hi, > Jan hit following output when msr tracepoints are enabled on amd server: > > [ 91.585653] === > [ 91.589840] [ INFO: suspicious RCU usage. ] > [ 91.594025] 4.9.0-rc1+ #1 Not tainted > [

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 01:53:43AM +0100, Jiri Olsa wrote: > hi, > Jan hit following output when msr tracepoints are enabled on amd server: > > [ 91.585653] === > [ 91.589840] [ INFO: suspicious RCU usage. ] > [ 91.594025] 4.9.0-rc1+ #1 Not tainted > [

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 01:53:43AM +0100, Jiri Olsa wrote: > hi, > Jan hit following output when msr tracepoints are enabled on amd server: > > [ 91.585653] === > [ 91.589840] [ INFO: suspicious RCU usage. ] > [ 91.594025] 4.9.0-rc1+ #1 Not tainted > [

Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

On Mon, Nov 21, 2016 at 01:53:43AM +0100, Jiri Olsa wrote: > hi, > Jan hit following output when msr tracepoints are enabled on amd server: > > [ 91.585653] === > [ 91.589840] [ INFO: suspicious RCU usage. ] > [ 91.594025] 4.9.0-rc1+ #1 Not tainted > [

[BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

hi, Jan hit following output when msr tracepoints are enabled on amd server: [ 91.585653] === [ 91.589840] [ INFO: suspicious RCU usage. ] [ 91.594025] 4.9.0-rc1+ #1 Not tainted [ 91.597691] --- [ 91.601877]

[BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

hi, Jan hit following output when msr tracepoints are enabled on amd server: [ 91.585653] === [ 91.589840] [ INFO: suspicious RCU usage. ] [ 91.594025] 4.9.0-rc1+ #1 Not tainted [ 91.597691] --- [ 91.601877]