Path: csiph.com!news.redatomik.org!aioe.org!bofh.it!news.nic.it!robomod
From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: linux.kernel
Subject: Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
Date: Sat, 09 Sep 2017 20:50:01 +0200
Message-ID: <unSZj-R2-7@gated-at.bofh.it>
References: <unOCl-6t7-5@gated-at.bofh.it> <unOVH-6zR-7@gated-at.bofh.it> <unP5n-6DD-11@gated-at.bofh.it> <unPf3-6Js-1@gated-at.bofh.it> <unQXw-81G-11@gated-at.bofh.it> <unRqx-8u8-5@gated-at.bofh.it> <unRJT-8V-1@gated-at.bofh.it> <unRTA-cn-29@gated-at.bofh.it> <unSwh-F4-1@gated-at.bofh.it> <unSFY-IW-21@gated-at.bofh.it> <unSPE-Nx-5@gated-at.bofh.it>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Sender: robomod@news.nic.it
Approved: robomod@news.nic.it
Lines: 26
Organization: linux.* mail to news gateway
Xref: csiph.com linux.kernel:1729513

On Sat, Sep 9, 2017 at 11:29 AM, Borislav Petkov <bp@alien8.de> 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 free'd and been re-allocated to something
>> else (and *then* they may point to garbage).
>
> Cool, I was trying to think of a good use case how we'd hit that. I
> guess you just gave one. :)

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.

But the part in Andy's patch that worries me the most is that

+               cpumask_clear_cpu(cpu, mm_cpumask(mm));

in enter_lazy_tlb(). It means that we won't be notified by peopel
invalidating the page tables, and while we then do re-validate the TLB
when we switch back from lazy mode, I still worry. I'm not entirely
convinced by that tlb_gen logic.

I can't actually see anything *wrong* in the tlb_gen logic, but it worries me.

            Linus