Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752614AbdFVOsp (ORCPT ); Thu, 22 Jun 2017 10:48:45 -0400 Received: from mail.kernel.org ([198.145.29.99]:41336 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751795AbdFVOso (ORCPT ); Thu, 22 Jun 2017 10:48:44 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8EFD222B6A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org MIME-Version: 1.0 In-Reply-To: <20170622072449.4rc4bnvucn7usuak@pd.tnic> References: <91f24a6145b2077f992902891f8fa59abe5c8696.1498022414.git.luto@kernel.org> <20170621184424.eixb2jdyy66xq4hg@pd.tnic> <20170622072449.4rc4bnvucn7usuak@pd.tnic> From: Andy Lutomirski Date: Thu, 22 Jun 2017 07:48:21 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 05/11] x86/mm: Track the TLB's tlb_gen and update the flushing algorithm To: Borislav Petkov Cc: Andy Lutomirski , X86 ML , "linux-kernel@vger.kernel.org" , Linus Torvalds , Andrew Morton , Mel Gorman , "linux-mm@kvack.org" , Nadav Amit , Rik van Riel , Dave Hansen , Arjan van de Ven , Peter Zijlstra Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1236 Lines: 34 On Thu, Jun 22, 2017 at 12:24 AM, Borislav Petkov wrote: > On Wed, Jun 21, 2017 at 07:46:05PM -0700, Andy Lutomirski wrote: >> > I'm certainly still missing something here: >> > >> > We have f->new_tlb_gen and mm_tlb_gen to control the flushing, i.e., we >> > do once >> > >> > bump_mm_tlb_gen(mm); >> > >> > and once >> > >> > info.new_tlb_gen = bump_mm_tlb_gen(mm); >> > >> > and in both cases, the bumping is done on mm->context.tlb_gen. >> > >> > So why isn't that enough to do the flushing and we have to consult >> > info.new_tlb_gen too? >> >> The issue is a possible race. Suppose we start at tlb_gen == 1 and >> then two concurrent flushes happen. The first flush is a full flush >> and sets tlb_gen to 2. The second is a partial flush and sets tlb_gen >> to 3. If the second flush gets propagated to a given CPU first and it > > Maybe I'm still missing something, which is likely... > > but if the second flush gets propagated to the CPU first, the CPU will > have local tlb_gen 1 and thus enforce a full flush anyway because we > will go 1 -> 3 on that particular CPU. Or? > Yes, exactly. Which means I'm probably just misunderstanding your original question. Can you re-ask it? --Andy