Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752489AbdFVCeb (ORCPT ); Wed, 21 Jun 2017 22:34:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:58092 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752105AbdFVCea (ORCPT ); Wed, 21 Jun 2017 22:34:30 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 913B722B42 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: <20170621174320.gouuexwzoau6pjnj@pd.tnic> References: <20170621174320.gouuexwzoau6pjnj@pd.tnic> From: Andy Lutomirski Date: Wed, 21 Jun 2017 19:34:08 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 04/11] x86/mm: Give each mm TLB flush generation a unique ID 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: 1383 Lines: 40 On Wed, Jun 21, 2017 at 10:43 AM, Borislav Petkov wrote: > On Tue, Jun 20, 2017 at 10:22:10PM -0700, Andy Lutomirski wrote: >> - * The x86 doesn't have a mmu context, but >> - * we put the segment information here. >> + * x86 has arch-specific MMU state beyond what lives in mm_struct. >> */ >> typedef struct { >> + /* >> + * ctx_id uniquely identifies this mm_struct. A ctx_id will never >> + * be reused, and zero is not a valid ctx_id. >> + */ >> + u64 ctx_id; >> + >> + /* >> + * Any code that needs to do any sort of TLB flushing for this >> + * mm will first make its changes to the page tables, then >> + * increment tlb_gen, then flush. This lets the low-level >> + * flushing code keep track of what needs flushing. >> + * >> + * This is not used on Xen PV. >> + */ >> + atomic64_t tlb_gen; > > Btw, can this just be a 4-byte int instead? I.e., simply atomic_t. I > mean, it should be enough for all the TLB generations in flight, no? There can only be NR_CPUS generations that actually mean anything at any given time, but I think they can be arbitrarily discontinuous. Imagine a malicious program that does: set affiinitiy to CPU 1 mmap() set affinity to CPU 0 for (i = 0; i < (1ULL<<32); i++) { munmap(); mmap(); } set affinity to CPU 1 With just atomic_t, this could blow up.