Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
In-Reply-To: <20180716190337.26133-3-riel@surriel.com>
References: <20180716190337.26133-1-riel@surriel.com> <20180716190337.26133-3-riel@surriel.com>
From:   Andy Lutomirski <luto@kernel.org>
Date:   Wed, 15 Aug 2018 18:54:42 -0700
Message-ID: <CALCETrWhb4CU8BfjdYBe+QJ8CVa4pzAr3ME+HBe4=6y=Pi9pFQ@mail.gmail.com>
Subject: Re: [PATCH 2/7] x86,tlb: leave lazy TLB mode at page table free time
To:     Rik van Riel <riel@surriel.com>
Cc:     LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
        Andrew Lutomirski <luto@kernel.org>,
        Mike Galbraith <efault@gmx.de>,
        kernel-team <kernel-team@fb.com>, Ingo Molnar <mingo@kernel.org>,
        Dave Hansen <dave.hansen@intel.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Jul 16, 2018 at 12:03 PM, Rik van Riel <riel@surriel.com> wrote:
> Andy discovered that speculative memory accesses while in lazy
> TLB mode can crash a system, when a CPU tries to dereference a
> speculative access using memory contents that used to be valid
> page table memory, but have since been reused for something else
> and point into la-la land.

Hi Rik-

I was looking through this, and I see:

> -static void tlb_remove_table_one(void *table)
> +static void tlb_remove_table_one(void *table, struct mmu_gather *tlb)
>  {
>         /*
>          * This isn't an RCU grace period and hence the page-tables cannot be
> @@ -344,7 +348,7 @@ static void tlb_remove_table_one(void *table)
>          * It is however sufficient for software page-table walkers that rely on
>          * IRQ disabling. See the comment near struct mmu_table_batch.
>          */
> -       smp_call_function(tlb_remove_table_smp_sync, NULL, 1);
> +       smp_call_function(tlb_remove_table_smp_sync, tlb->mm, 1);
>         __tlb_remove_table(table);
>  }

But tlb_remove_table() doesn't always call tlb_remove_table_one().  Do
the other paths through tlb_remove_table() do the right thing?

--Andy