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 cha
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 with
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
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 per-cpu
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() f
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
> fau
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 sta
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 restori
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
9 matches
Mail list logo
