* Andy Lutomirski wrote:
> PeterZ and Ingo, would you be okay with adding a define so arches can
> opt out of the task_struct::active_mm field entirely? That is, with
> the option set, task_struct wouldn't have an active_mm field, the core
> wouldn't call mmgrab and mmdrop, and the arch would b
On 2017.09.09 at 11:26 -0700, Linus Torvalds wrote:
> On Sat, Sep 9, 2017 at 11:14 AM, Markus Trippelsdorf
> wrote:
> >
> > I think the issue gets fixed by:
> >
> > # wrmsr -a 0xc0010015 0x118
> >
> > Setting bit 3 of the Hardware Configuration Register to 1.
> >
> > Quote from the docs:
> >
On Sun, 2017-09-10 at 18:46 -0700, Andy Lutomirski wrote:
>
> No, nothing stops the problematic speculative load. Here's the
> issue.
> One CPU removes a reference to a page table from a higher-level page
> table, flushes, and then frees the page table. Then it re-allocates
> it and writes somet
On Sun, Sep 10, 2017 at 6:12 PM, Rik van Riel wrote:
> On Sat, 2017-09-09 at 12:28 -0700, Andy Lutomirski wrote:
>> -
>> I propose the following fix. If PCID is on, then, in
>> enter_lazy_tlb(), we switch to init_mm with the no-flush flag set.
>> (And we give init_mm its own dedicated ASID to kee
On Sat, 2017-09-09 at 12:28 -0700, Andy Lutomirski wrote:
> -
> I propose the following fix. If PCID is on, then, in
> enter_lazy_tlb(), we switch to init_mm with the no-flush flag set.
> (And we give init_mm its own dedicated ASID to keep it simple and
> fast
> -- no need to use the LRU ASID mapp
> On Sep 10, 2017, at 1:22 PM, Peter Zijlstra wrote:
>
>> On Sat, Sep 09, 2017 at 09:42:12PM -0700, Andy Lutomirski wrote:
>> PeterZ and Ingo, would you be okay with adding a define so arches can
>> opt out of the task_struct::active_mm field entirely? That is, with
>> the option set, task_str
On Sat, Sep 09, 2017 at 09:42:12PM -0700, Andy Lutomirski wrote:
> PeterZ and Ingo, would you be okay with adding a define so arches can
> opt out of the task_struct::active_mm field entirely? That is, with
> the option set, task_struct wouldn't have an active_mm field, the core
> wouldn't call mm
On Sat, Sep 9, 2017 at 12:37 PM, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 12:28:30PM -0700, Andy Lutomirski wrote:
>> I propose the following fix. If PCID is on, then, in
>> enter_lazy_tlb(), we switch to init_mm with the no-flush flag set.
>> (And we give init_mm its own dedicated ASID t
On Sat, Sep 09, 2017 at 12:28:30PM -0700, Andy Lutomirski wrote:
> I propose the following fix. If PCID is on, then, in
> enter_lazy_tlb(), we switch to init_mm with the no-flush flag set.
> (And we give init_mm its own dedicated ASID to keep it simple and fast
> -- no need to use the LRU ASID map
On Sat, Sep 9, 2017 at 12:09 PM, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 11:47:33AM -0700, Linus Torvalds wrote:
>> The thing is, even with the delayed TLB flushing, I don't think it
>> should be *so* delayed that we should be seeing a TLB fill from
>> garbage page tables.
>
> Yeah, but w
On Sat, Sep 9, 2017 at 12:09 PM, Borislav Petkov wrote:
>
> Yeah, but we can't know what kind of speculative accesses happen between
> the removal from the mask and the actual flushing.
Indeed. The speculative kernel thread accesses while lazy could easily
trigger this.
And I guess those are pre
On Sat, Sep 09, 2017 at 09:11:33PM +0200, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 08:46:38PM +0200, Markus Trippelsdorf wrote:
> > OK. ADDR is 12. The rest is the same (modulo time).
>
> I'm assuming that's 12 hex... yeah, "ADDR %llx ".
>
> Dammit, that should have "0x" prepended. Grrr,
On Sat, Sep 09, 2017 at 08:46:38PM +0200, Markus Trippelsdorf wrote:
> OK. ADDR is 12. The rest is the same (modulo time).
I'm assuming that's 12 hex... yeah, "ADDR %llx ".
Dammit, that should have "0x" prepended. Grrr, I'll fix all that next
week.
--
Regards/Gruss,
Boris.
Good mailing pra
On Sat, Sep 09, 2017 at 11:47:33AM -0700, Linus Torvalds wrote:
> The thing is, even with the delayed TLB flushing, I don't think it
> should be *so* delayed that we should be seeing a TLB fill from
> garbage page tables.
Yeah, but we can't know what kind of speculative accesses happen between
the
On Sat, Sep 9, 2017 at 11:29 AM, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 11:26:27AM -0700, Linus Torvalds wrote:
>> But the fact that that fixes it for you does indicate that it's not
>> just a stale TLB entry or something, it really is some CPU using page
>> tables after they have been f
On 2017.09.09 at 20:26 +0200, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 08:14:45PM +0200, Markus Trippelsdorf wrote:
> > # wrmsr -a 0xc0010015 0x118
>
> I know but I'd still like to see the exact error signature.
>
> So please clear that bit 3 and try to catch that MCE together with t
On Sat, Sep 09, 2017 at 11:26:27AM -0700, Linus Torvalds wrote:
> But the fact that that fixes it for you does indicate that it's not
> just a stale TLB entry or something, it really is some CPU using page
> tables after they have been free'd and been re-allocated to something
> else (and *then* th
On Sat, Sep 9, 2017 at 11:14 AM, Markus Trippelsdorf
wrote:
>
> I think the issue gets fixed by:
>
> # wrmsr -a 0xc0010015 0x118
>
> Setting bit 3 of the Hardware Configuration Register to 1.
>
> Quote for the docs:
> »TlbCacheDis: cacheable memory disable. Read-write. 0=Enables performance
On Sat, Sep 09, 2017 at 08:14:45PM +0200, Markus Trippelsdorf wrote:
> # wrmsr -a 0xc0010015 0x118
I know but I'd still like to see the exact error signature.
So please clear that bit 3 and try to catch that MCE together with the
ADDR.
Thanks.
--
Regards/Gruss,
Boris.
Good mailing p
On 2017.09.09 at 19:36 +0200, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 07:23:52PM +0200, Markus Trippelsdorf wrote:
> > Hmm, the output is exactly the same as before your patch.
>
> Bah, that patch doesn't account for the fact that we're rereading the
> status field again in do_machine_che
On Sat, Sep 9, 2017 at 10:49 AM, Andy Lutomirski wrote:
>
> Anyway, if I need change the behavior back, I can do it in one of two
> ways. I can just switch to init_mm instead of going lazy, which is
> expensive, but not *that* expensive on CPUs with PCID. Or I can do it
> the way we used to do i
On Fri, Sep 8, 2017 at 6:39 PM, Andy Lutomirski wrote:
>
>
>> On Sep 8, 2017, at 6:05 PM, Linus Torvalds
>> wrote:
>>
>>> On Fri, Sep 8, 2017 at 5:00 PM, Andy Lutomirski wrote:
>>>
>>> I'm not convinced. The SDM says (Vol 3, 11.3, under WC):
>>>
>>> If the WC buffer is partially filled, the wr
On Sat, Sep 09, 2017 at 07:23:52PM +0200, Markus Trippelsdorf wrote:
> Hmm, the output is exactly the same as before your patch.
Bah, that patch doesn't account for the fact that we're rereading the
status field again in do_machine_check().
Ok, let's force MCi_ADDR out. Ontop:
---
diff --git a/a
On 2017.09.09 at 19:05 +0200, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 06:32:25PM +0200, Markus Trippelsdorf wrote:
> > Also tried the following patch. It does not help.
>
> Ok, another theory. This one still needs to be fixed properly but that
> for later.
>
> For some reason (insufficie
On Sat, Sep 09, 2017 at 06:32:25PM +0200, Markus Trippelsdorf wrote:
> Also tried the following patch. It does not help.
Ok, another theory. This one still needs to be fixed properly but that
for later.
For some reason (insufficient coffee maybe), I have mistyped your
MCi_STATUS value earlier. Yo
On 2017.09.09 at 16:43 +0200, Markus Trippelsdorf wrote:
> On 2017.09.09 at 16:33 +0200, Borislav Petkov wrote:
> > On Sat, Sep 09, 2017 at 04:20:14PM +0200, Markus Trippelsdorf wrote:
> > > > # rdmsr -a 0x0410
> > >
> > > 3fff
> > > 0
> > > 0
> > > 0
> >
> > WTF?! Those should be equal o
On 2017.09.09 at 16:33 +0200, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 04:20:14PM +0200, Markus Trippelsdorf wrote:
> > > # rdmsr -a 0x0410
> >
> > 3fff
> > 0
> > 0
> > 0
>
> WTF?! Those should be equal on every CPU. Yikes, we need to pay
> attention to those... Grrr.
>
> # wrmsr
On Sat, Sep 09, 2017 at 04:20:14PM +0200, Markus Trippelsdorf wrote:
> > # rdmsr -a 0x0410
>
> 3fff
> 0
> 0
> 0
WTF?! Those should be equal on every CPU. Yikes, we need to pay
attention to those... Grrr.
# wrmsr -a 0x0410 0x3bff
should fix your issue.
--
Regards/Gruss,
Bor
On 2017.09.09 at 16:07 +0200, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 03:39:54PM +0200, Markus Trippelsdorf wrote:
> > > mce: [Hardware Error]: CPU: 0 Machine Check Exception: 4 Bank 4:
> > > fa1b0c0f
> > > mce: [Hardware Error]: TSC b75d6ef4ad MISC c00a100
> > > mce: [Har
On Sat, Sep 09, 2017 at 03:39:54PM +0200, Markus Trippelsdorf wrote:
> > mce: [Hardware Error]: CPU: 0 Machine Check Exception: 4 Bank 4:
> > fa1b0c0f
> > mce: [Hardware Error]: TSC b75d6ef4ad MISC c00a100
> > mce: [Hardware Error]: PROCESSOR 2:100f42 TIME 1504963036 SOCKET 0 APIC
On 2017.09.09 at 15:37 +0200, Markus Trippelsdorf wrote:
> On 2017.09.09 at 15:07 +0200, Borislav Petkov wrote:
> > On Sat, Sep 09, 2017 at 01:07:49PM +0200, Markus Trippelsdorf wrote:
> > > It doesn't work. Compiling in a text console just freezes the machine
> > > before any MCE gets printed.
> >
On 2017.09.09 at 15:07 +0200, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 01:07:49PM +0200, Markus Trippelsdorf wrote:
> > It doesn't work. Compiling in a text console just freezes the machine
> > before any MCE gets printed.
>
> Ok, let's turn off all syncflood bits. Hunk below. Do a
>
> $
On Sat, Sep 09, 2017 at 01:07:49PM +0200, Markus Trippelsdorf wrote:
> It doesn't work. Compiling in a text console just freezes the machine
> before any MCE gets printed.
Ok, let's turn off all syncflood bits. Hunk below. Do a
$ dmesg | grep syncflood
to check it worked. It says
[1.557017]
On 2017.09.09 at 12:18 +0200, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 08:39:08AM +0200, Markus Trippelsdorf wrote:
> > Unfortunately the machine hangs in the BIOS after the first warm-reset.
> > Probably when it encounters an MCE it doesn't expect. I have to
> > warm-reset a second time to
On Sat, Sep 09, 2017 at 08:39:08AM +0200, Markus Trippelsdorf wrote:
> Unfortunately the machine hangs in the BIOS after the first warm-reset.
> Probably when it encounters an MCE it doesn't expect. I have to
> warm-reset a second time to get to the boot-loader. So it is impossible
> for me to see
On 2017.09.08 at 14:47 -0700, Andy Lutomirski wrote:
> On Fri, Sep 8, 2017 at 10:16 AM, Markus Trippelsdorf
> wrote:
> > On 2017.09.08 at 09:12 -0700, Andy Lutomirski wrote:
> >> On Fri, Sep 8, 2017 at 4:30 AM, Markus Trippelsdorf
> >> wrote:
> >> > On 2017.09.08 at 12:39 +0200, Markus Trippelsdo
On 2017.09.08 at 23:56 +0200, Borislav Petkov wrote:
> On Fri, Sep 08, 2017 at 02:47:00PM -0700, Andy Lutomirski wrote:
> > Any chance you could test with CONFIG_DEBUG_VM=y? There are lots of
> > potentially useful assertions in that code.
> >
> > Can you also post your /proc/cpuinfo? And can yo
> On Sep 8, 2017, at 6:05 PM, Linus Torvalds
> wrote:
>
>> On Fri, Sep 8, 2017 at 5:00 PM, Andy Lutomirski wrote:
>>
>> I'm not convinced. The SDM says (Vol 3, 11.3, under WC):
>>
>> If the WC buffer is partially filled, the writes may be delayed until
>> the next occurrence of a serializi
On Fri, Sep 8, 2017 at 5:00 PM, Andy Lutomirski wrote:
>
> I'm not convinced. The SDM says (Vol 3, 11.3, under WC):
>
> If the WC buffer is partially filled, the writes may be delayed until
> the next occurrence of a serializing event; such as, an SFENCE or
> MFENCE instruction, CPUID execution,
On Fri, Sep 8, 2017 at 4:23 PM, Linus Torvalds
wrote:
> On Fri, Sep 8, 2017 at 4:07 PM, Andy Lutomirski wrote:
>>
>> I *think* this is impossible because CPU A's mm_cpumask manipulations
>> are atomic and should therefore force out the streaming write buffers,
>> but maybe there's some other scen
On Fri, Sep 8, 2017 at 4:07 PM, Andy Lutomirski wrote:
>
> I *think* this is impossible because CPU A's mm_cpumask manipulations
> are atomic and should therefore force out the streaming write buffers,
> but maybe there's some other scenario where this matters.
I don't think atomic memops do that
[Linus, I added you to get your opinion on whether the last bit here
is a problem.]
On Fri, Sep 8, 2017 at 2:56 PM, Borislav Petkov wrote:
> On Fri, Sep 08, 2017 at 02:47:00PM -0700, Andy Lutomirski wrote:
>> Any chance you could test with CONFIG_DEBUG_VM=y? There are lots of
>> potentially usef
On Fri, Sep 08, 2017 at 02:47:00PM -0700, Andy Lutomirski wrote:
> Any chance you could test with CONFIG_DEBUG_VM=y? There are lots of
> potentially useful assertions in that code.
>
> Can you also post your /proc/cpuinfo? And can you re-confirm that a
> problematic guest kernel is causing probl
On Fri, Sep 8, 2017 at 10:16 AM, Markus Trippelsdorf
wrote:
> On 2017.09.08 at 09:12 -0700, Andy Lutomirski wrote:
>> On Fri, Sep 8, 2017 at 4:30 AM, Markus Trippelsdorf
>> wrote:
>> > On 2017.09.08 at 12:39 +0200, Markus Trippelsdorf wrote:
>> >> On 2017.09.08 at 12:35 +0200, Ingo Molnar wrote:
On 2017.09.08 at 09:12 -0700, Andy Lutomirski wrote:
> On Fri, Sep 8, 2017 at 4:30 AM, Markus Trippelsdorf
> wrote:
> > On 2017.09.08 at 12:39 +0200, Markus Trippelsdorf wrote:
> >> On 2017.09.08 at 12:35 +0200, Ingo Molnar wrote:
> >> >
> >> > * Markus Trippelsdorf wrote:
> >> >
> >> > > On 2017
On Fri, Sep 8, 2017 at 4:30 AM, Markus Trippelsdorf
wrote:
> On 2017.09.08 at 12:39 +0200, Markus Trippelsdorf wrote:
>> On 2017.09.08 at 12:35 +0200, Ingo Molnar wrote:
>> >
>> > * Markus Trippelsdorf wrote:
>> >
>> > > On 2017.09.08 at 11:16 +0200, Borislav Petkov wrote:
>> > > > On Fri, Sep 08
On Fri, Sep 08, 2017 at 11:16:14AM +0200, Borislav Petkov wrote:
...
> +blkid[1020]: segfault at 8 ip 7fec7760c3fd sp 7ffc9dd05890 error 4
> in ld-linux-x86-64.so.2[7fec775fc000+22000]
> +blkid[1026]: segfault at 8 ip 7f5a31ecc3fd sp 7fffaf3604b0 error 4
> in ld-linux-x86-64.so.2[
On 2017.09.08 at 12:39 +0200, Markus Trippelsdorf wrote:
> On 2017.09.08 at 12:35 +0200, Ingo Molnar wrote:
> >
> > * Markus Trippelsdorf wrote:
> >
> > > On 2017.09.08 at 11:16 +0200, Borislav Petkov wrote:
> > > > On Fri, Sep 08, 2017 at 10:05:36AM +0200, Borislav Petkov wrote:
> > > > > On Fr
On 2017.09.08 at 12:35 +0200, Ingo Molnar wrote:
>
> * Markus Trippelsdorf wrote:
>
> > On 2017.09.08 at 11:16 +0200, Borislav Petkov wrote:
> > > On Fri, Sep 08, 2017 at 10:05:36AM +0200, Borislav Petkov wrote:
> > > > On Fri, Sep 08, 2017 at 08:26:44AM +0200, Thomas Gleixner wrote:
> > > > > O
* Markus Trippelsdorf wrote:
> On 2017.09.08 at 11:16 +0200, Borislav Petkov wrote:
> > On Fri, Sep 08, 2017 at 10:05:36AM +0200, Borislav Petkov wrote:
> > > On Fri, Sep 08, 2017 at 08:26:44AM +0200, Thomas Gleixner wrote:
> > > > On Fri, 8 Sep 2017, Markus Trippelsdorf wrote:
> > > >
> > > >
On 2017.09.08 at 11:16 +0200, Borislav Petkov wrote:
> On Fri, Sep 08, 2017 at 10:05:36AM +0200, Borislav Petkov wrote:
> > On Fri, Sep 08, 2017 at 08:26:44AM +0200, Thomas Gleixner wrote:
> > > On Fri, 8 Sep 2017, Markus Trippelsdorf wrote:
> > >
> > > CC+ Borislav. He might have access to such a
On Fri, Sep 08, 2017 at 10:05:36AM +0200, Borislav Petkov wrote:
> On Fri, Sep 08, 2017 at 08:26:44AM +0200, Thomas Gleixner wrote:
> > On Fri, 8 Sep 2017, Markus Trippelsdorf wrote:
> >
> > CC+ Borislav. He might have access to such a beast
>
> Can I have /proc/cpuinfo and dmesg pls, in order to
On Fri, Sep 08, 2017 at 08:26:44AM +0200, Thomas Gleixner wrote:
> On Fri, 8 Sep 2017, Markus Trippelsdorf wrote:
>
> CC+ Borislav. He might have access to such a beast
Can I have /proc/cpuinfo and dmesg pls, in order to see whether I have
something similar?
Private mail's fine too.
Thx.
--
R
On Fri, 8 Sep 2017, Markus Trippelsdorf wrote:
CC+ Borislav. He might have access to such a beast
> On 2017.09.07 at 08:28 +0200, Markus Trippelsdorf wrote:
> > On 2017.09.06 at 15:15 +0200, Markus Trippelsdorf wrote:
> > > On 2017.09.06 at 14:52 +0200, Thomas Gleixner wrote:
> > > > On Tue, 5 Se
On 2017.09.07 at 08:28 +0200, Markus Trippelsdorf wrote:
> On 2017.09.06 at 15:15 +0200, Markus Trippelsdorf wrote:
> > On 2017.09.06 at 14:52 +0200, Thomas Gleixner wrote:
> > > On Tue, 5 Sep 2017, Markus Trippelsdorf wrote:
> > > > On 2017.09.05 at 10:53 +0200, Peter Zijlstra wrote:
> > > > > > A
On 2017.09.06 at 15:15 +0200, Markus Trippelsdorf wrote:
> On 2017.09.06 at 14:52 +0200, Thomas Gleixner wrote:
> > On Tue, 5 Sep 2017, Markus Trippelsdorf wrote:
> > > On 2017.09.05 at 10:53 +0200, Peter Zijlstra wrote:
> > > > > Any ideas on how to debug this further?
> > > >
> > > > So you have
On 2017.09.06 at 14:52 +0200, Thomas Gleixner wrote:
> On Tue, 5 Sep 2017, Markus Trippelsdorf wrote:
> > On 2017.09.05 at 10:53 +0200, Peter Zijlstra wrote:
> > > > Any ideas on how to debug this further?
> > >
> > > So you have a (real) serial line on that box?
> >
> > Sadly, no. But hopefully
On Tue, 5 Sep 2017, Markus Trippelsdorf wrote:
> On 2017.09.05 at 10:53 +0200, Peter Zijlstra wrote:
> > > Any ideas on how to debug this further?
> >
> > So you have a (real) serial line on that box?
>
> Sadly, no. But hopefully somebody else (with a proper kernel debugging
> setup) will reprodu
On 2017.09.05 at 10:53 +0200, Peter Zijlstra wrote:
> On Tue, Sep 05, 2017 at 09:27:38AM +0200, Markus Trippelsdorf wrote:
> > Current mainline git (24e700e291d52bd2) hangs when building software
> > concurrently (for example perf).
> > The issue is not 100% reproducible (sometimes building perf su
On Tue, Sep 05, 2017 at 09:27:38AM +0200, Markus Trippelsdorf wrote:
> Current mainline git (24e700e291d52bd2) hangs when building software
> concurrently (for example perf).
> The issue is not 100% reproducible (sometimes building perf succeeds),
> so bisecting will not work.
Sadly I cannot repro
60 matches
Mail list logo
