Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables

On Fri, Aug 12, 2016 at 09:03:52AM -0700, Thomas Garnier wrote: > Borislav, let me know once you tested it and I will send a v2 with > acked/tested. Just did 5 s2d runs, back-to-back, with Rafael's linux-next branch. Looks good so far, no hickups. I'll watch it the coming days if there are any

Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables

On Fri, Aug 12, 2016 at 09:03:52AM -0700, Thomas Garnier wrote: > Borislav, let me know once you tested it and I will send a v2 with > acked/tested. Just did 5 s2d runs, back-to-back, with Rafael's linux-next branch. Looks good so far, no hickups. I'll watch it the coming days if there are any

Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables

On Fri, Aug 12, 2016 at 4:14 AM, Rafael J. Wysocki wrote: > On Fri, Aug 12, 2016 at 7:49 AM, Borislav Petkov wrote: >> On Thu, Aug 11, 2016 at 02:49:29PM -0700, Thomas Garnier wrote: >>> Restore the processor state before calling any other function to ensure >>>

Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables

On Fri, Aug 12, 2016 at 4:14 AM, Rafael J. Wysocki wrote: > On Fri, Aug 12, 2016 at 7:49 AM, Borislav Petkov wrote: >> On Thu, Aug 11, 2016 at 02:49:29PM -0700, Thomas Garnier wrote: >>> Restore the processor state before calling any other function to ensure >>> per-cpu variables can be used

Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables

On Fri, Aug 12, 2016 at 2:23 AM, Jiri Kosina wrote: > On Fri, 12 Aug 2016, Jiri Kosina wrote: > > That's pretty nasty, as turning LOCKDEP on has sideffects on the code > that'd normally not be expected to be run at all (tracepoint off). > > Oh well. Thanks for the analysis, I

Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables

On Fri, Aug 12, 2016 at 2:23 AM, Jiri Kosina wrote: > On Fri, 12 Aug 2016, Jiri Kosina wrote: > > That's pretty nasty, as turning LOCKDEP on has sideffects on the code > that'd normally not be expected to be run at all (tracepoint off). > > Oh well. Thanks for the analysis, I didn't got that far

Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables

On Fri, Aug 12, 2016 at 7:49 AM, Borislav Petkov wrote: > On Thu, Aug 11, 2016 at 02:49:29PM -0700, Thomas Garnier wrote: >> Restore the processor state before calling any other function to ensure >> per-cpu variables can be used with KASLR memory randomization. >> >> Tracing

Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables

On Fri, Aug 12, 2016 at 7:49 AM, Borislav Petkov wrote: > On Thu, Aug 11, 2016 at 02:49:29PM -0700, Thomas Garnier wrote: >> Restore the processor state before calling any other function to ensure >> per-cpu variables can be used with KASLR memory randomization. >> >> Tracing functions use

Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables

On Fri, 12 Aug 2016, Jiri Kosina wrote: > One thing is still beyond me though ... how the heck this doesn't happen > without DEBUG_LOCK_ALLOC? The percpu area pointer should be corrupted > nevertheless, shouldn't it? The reason is that turning DEBUG_LOCK_ALLOC changing trace_suspend_resume()

Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables

On Fri, 12 Aug 2016, Jiri Kosina wrote: > One thing is still beyond me though ... how the heck this doesn't happen > without DEBUG_LOCK_ALLOC? The percpu area pointer should be corrupted > nevertheless, shouldn't it? The reason is that turning DEBUG_LOCK_ALLOC changing trace_suspend_resume()

Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables

Hi! > Restore the processor state before calling any other function to ensure > per-cpu variables can be used with KASLR memory randomization. > > Tracing functions use per-cpu variables (gs based) and one was called > just before restoring the processor state fully. It resulted in a double >

Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables

Hi! > Restore the processor state before calling any other function to ensure > per-cpu variables can be used with KASLR memory randomization. > > Tracing functions use per-cpu variables (gs based) and one was called > just before restoring the processor state fully. It resulted in a double >

Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables

On Thu, 11 Aug 2016, Thomas Garnier wrote: > Restore the processor state before calling any other function to ensure > per-cpu variables can be used with KASLR memory randomization. > > Tracing functions use per-cpu variables (gs based) and one was called > just before restoring the processor

Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables

On Thu, 11 Aug 2016, Thomas Garnier wrote: > Restore the processor state before calling any other function to ensure > per-cpu variables can be used with KASLR memory randomization. > > Tracing functions use per-cpu variables (gs based) and one was called > just before restoring the processor

Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables

On Thu, Aug 11, 2016 at 02:49:29PM -0700, Thomas Garnier wrote: > Restore the processor state before calling any other function to ensure > per-cpu variables can be used with KASLR memory randomization. > > Tracing functions use per-cpu variables (gs based) and one was called > just before

Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables

On Thu, Aug 11, 2016 at 02:49:29PM -0700, Thomas Garnier wrote: > Restore the processor state before calling any other function to ensure > per-cpu variables can be used with KASLR memory randomization. > > Tracing functions use per-cpu variables (gs based) and one was called > just before

[PATCH v1] x86/power/64: Restore processor state before using per-cpu variables

Restore the processor state before calling any other function to ensure per-cpu variables can be used with KASLR memory randomization. Tracing functions use per-cpu variables (gs based) and one was called just before restoring the processor state fully. It resulted in a double fault when both the

[PATCH v1] x86/power/64: Restore processor state before using per-cpu variables

Restore the processor state before calling any other function to ensure per-cpu variables can be used with KASLR memory randomization. Tracing functions use per-cpu variables (gs based) and one was called just before restoring the processor state fully. It resulted in a double fault when both the