On Wed, Jul 10, 2019 at 04:27:09PM -0400, Steven Rostedt wrote:
> But isn't it easier for them to just pull the quick fix in, if it is in
Steve, I've not yet seen a quick fix that actually fixes all the
problems.
Your initial one only fixes the IRQ tracing one, but leaves the context
tracking on
On Wed, Jul 10, 2019 at 04:27:09PM -0400, Steven Rostedt wrote:
[ added stable folks ]
On Sun, 7 Jul 2019 11:17:09 -0700
Linus Torvalds wrote:
On Sun, Jul 7, 2019 at 8:11 AM Andy Lutomirski wrote:
>
> FWIW, I'm leaning toward suggesting that we apply the trivial tracing
> fix and backport *
On Wed, Jul 10, 2019 at 04:27:09PM -0400, Steven Rostedt wrote:
>
> [ added stable folks ]
>
> On Sun, 7 Jul 2019 11:17:09 -0700
> Linus Torvalds wrote:
>
> > On Sun, Jul 7, 2019 at 8:11 AM Andy Lutomirski wrote:
> > >
> > > FWIW, I'm leaning toward suggesting that we apply the trivial tracing
[ added stable folks ]
On Sun, 7 Jul 2019 11:17:09 -0700
Linus Torvalds wrote:
> On Sun, Jul 7, 2019 at 8:11 AM Andy Lutomirski wrote:
> >
> > FWIW, I'm leaning toward suggesting that we apply the trivial tracing
> > fix and backport *that*. Then, in -tip, we could revert it and apply
> > th
On 2019/07/08 18:42, Eiichi Tsukata wrote:
>
>
> On 2019/07/08 17:58, Eiichi Tsukata wrote:
>
>>
>> By the way, is there possibility that the WARNING(#GP in execve(2)) which
>> Steven
>> previously hit? :
>> https://lore.kernel.org/lkml/20190321095502.47b51...@gandalf.local.home/
>>
>> Even
On 2019/07/08 17:58, Eiichi Tsukata wrote:
>
> By the way, is there possibility that the WARNING(#GP in execve(2)) which
> Steven
> previously hit? :
> https://lore.kernel.org/lkml/20190321095502.47b51...@gandalf.local.home/
>
> Even if there were, it will *Not* be the bug introduced by thi
On 2019/07/08 16:48, Peter Zijlstra wrote:
...
>
> Or are we going to put the CR2 save/restore on every single tracepoint?
> But then we also need it on the mcount/fentry stubs and we again have
> multiple places.
>
> Whereas if we stick it in the entry path, like I proposed, we fix it in
> o
On Sat, Jul 06, 2019 at 08:07:22PM +0900, Eiichi Tsukata wrote:
>
>
> On 2019/07/05 11:18, Linus Torvalds wrote:
> > On Fri, Jul 5, 2019 at 5:03 AM Peter Zijlstra wrote:
> >>
> >> Despire the current efforts to read CR2 before tracing happens there
> >> still exist a number of possible holes:
>
On Sun, Jul 7, 2019 at 8:11 AM Andy Lutomirski wrote:
>
> FWIW, I'm leaning toward suggesting that we apply the trivial tracing
> fix and backport *that*. Then, in -tip, we could revert it and apply
> this patch instead.
You don't have to have the same fix in stable as in -tip.
It's fine to sen
On Sun, Jul 7, 2019 at 8:10 AM Andy Lutomirski wrote:
>
> On Thu, Jul 4, 2019 at 1:03 PM Peter Zijlstra wrote:
> >
> > Despire the current efforts to read CR2 before tracing happens there
> > still exist a number of possible holes:
> >
> > idtentry page_fault do_page_fault
On Thu, Jul 4, 2019 at 1:03 PM Peter Zijlstra wrote:
>
> Despire the current efforts to read CR2 before tracing happens there
> still exist a number of possible holes:
>
> idtentry page_fault do_page_fault has_error_code=1
> call error_entry
> TRACE_IRQS_OFF
>
On 2019/07/07 7:27, Steven Rostedt wrote:
>
> We also have to deal with reading vmalloc'd data as that can fault too.
> The perf ring buffer IIUC is vmalloc, so if perf records in one of
> these locations, then the reading of the vmalloc area has a potential
> to fault corrupting the CR2 regis
> On Jul 6, 2019, at 6:08 PM, Linus Torvalds
> wrote:
>
> On Sat, Jul 6, 2019 at 3:41 PM Linus Torvalds
> wrote:
>>
>>> On Sat, Jul 6, 2019 at 3:27 PM Steven Rostedt wrote:
>>>
>>> We also have to deal with reading vmalloc'd data as that can fault too.
>>
>> Ahh, that may be a better rea
On Sat, Jul 6, 2019 at 3:41 PM Linus Torvalds
wrote:
>
> On Sat, Jul 6, 2019 at 3:27 PM Steven Rostedt wrote:
> >
> > We also have to deal with reading vmalloc'd data as that can fault too.
>
> Ahh, that may be a better reason for PeterZ's patches and reading cr2
> very early from asm code than t
On Sat, Jul 6, 2019 at 3:27 PM Steven Rostedt wrote:
>
> On Sat, 6 Jul 2019 14:41:22 -0700
> Linus Torvalds wrote:
>
> > On Fri, Jul 5, 2019 at 6:50 AM Peter Zijlstra wrote:
> > >
> > > Also; all previous attempts at fixing this have been about pushing the
> > > read_cr2() earlier; notably:
> >
On Sat, Jul 6, 2019 at 3:27 PM Steven Rostedt wrote:
>
> We also have to deal with reading vmalloc'd data as that can fault too.
Ahh, that may be a better reason for PeterZ's patches and reading cr2
very early from asm code than the stack trace case. It's why the page
fault handler delayed enabli
On Sat, 6 Jul 2019 14:41:22 -0700
Linus Torvalds wrote:
> On Fri, Jul 5, 2019 at 6:50 AM Peter Zijlstra wrote:
> >
> > Also; all previous attempts at fixing this have been about pushing the
> > read_cr2() earlier; notably:
> >
> > 0ac09f9f8cd1 ("x86, trace: Fix CR2 corruption when tracing page
On Fri, Jul 5, 2019 at 6:50 AM Peter Zijlstra wrote:
>
> Also; all previous attempts at fixing this have been about pushing the
> read_cr2() earlier; notably:
>
> 0ac09f9f8cd1 ("x86, trace: Fix CR2 corruption when tracing page faults")
> d4078e232267 ("x86, trace: Further robustify CR2 handlin
On 2019/07/05 11:18, Linus Torvalds wrote:
> On Fri, Jul 5, 2019 at 5:03 AM Peter Zijlstra wrote:
>>
>> Despire the current efforts to read CR2 before tracing happens there
>> still exist a number of possible holes:
>
> So this whole series disturbs me for the simple reason that I thought
> tr
On Fri, Jul 05, 2019 at 11:18:51AM +0900, Linus Torvalds wrote:
> On Fri, Jul 5, 2019 at 5:03 AM Peter Zijlstra wrote:
> >
> > Despire the current efforts to read CR2 before tracing happens there
> > still exist a number of possible holes:
>
> So this whole series disturbs me for the simple reaso
On Fri, Jul 5, 2019 at 12:16 PM Andy Lutomirski wrote:
>
> If nothing else, MOV to CR2 is architecturally serializing, so, unless
> there’s some fancy unwinding involved, this will be quite slow.
That's why the NMI code does this:
if (unlikely(this_cpu_read(nmi_cr2) != read_cr2()))
> On Jul 4, 2019, at 7:18 PM, Linus Torvalds
> wrote:
>
>> On Fri, Jul 5, 2019 at 5:03 AM Peter Zijlstra wrote:
>>
>> Despire the current efforts to read CR2 before tracing happens there
>> still exist a number of possible holes:
>
> So this whole series disturbs me for the simple reason t
On Fri, Jul 5, 2019 at 5:03 AM Peter Zijlstra wrote:
>
> Despire the current efforts to read CR2 before tracing happens there
> still exist a number of possible holes:
So this whole series disturbs me for the simple reason that I thought
tracing was supposed to save/restore cr2 and make it unnece
23 matches
Mail list logo
