Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp1400814ybi; Wed, 17 Jul 2019 14:44:36 -0700 (PDT) X-Google-Smtp-Source: APXvYqw7L8wTcV+TvgENenvMU2VUR3Nc5G2S8j0w8Ym9bbXBfnDBLL4XUqPf9o59V19b/hR45BEa X-Received: by 2002:a17:902:6a88:: with SMTP id n8mr45948245plk.70.1563399876046; Wed, 17 Jul 2019 14:44:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563399876; cv=none; d=google.com; s=arc-20160816; b=d3ePxhFgVypzNM2QqfNaPM/ESeH+4cwVsqij1H5jUF84xIIsp7UgD9a+01MSB+ax8Z DDyedwtgdkn6Blv/4rSaEL3ZNkQUdtkjLPIDv6xASbPbXt+Ff0CDM9On9d4ZtWeCczBZ +ZrNycPmWkO/PMG/8YzKRiS7a4kzNo7Om7GKUocHmhQqP5FLXTqRFy1rm4x3oD9DKvsx xuMM84qMwdwbQrVEO/HWyZuCWl5YIS+xr1+Jegq/duWEfht4wJr1Qjw7rCTFXPPR+S82 tYG4h+/P53D0/v4lVSo+1AjUemZsk3GSTXAwxpZIzF+RP4ut+tul5HbB2HtRxKXn3P0I 5hUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=R6yzRFKjLNutBbjBCce/hhZ9RyUPFUpEfUfseQ58zYg=; b=KhBB1PKHoRsukmpdFf15AjY9jkDysbaGy2WJmlQJf/FTpWH9kVGEw/Q5ysSuTD4Ioj 2h2GPPwnHLycuppMxKOZYRdKAbKwwd8kpBpslIM1XSqVBLQs+Kfk5Q2XKnb7HeMvEIL5 ASfst1EGIx8PQ3orFCg4nez6hGRXpRj0gg6D5VB7BHDa4wJhW6AuTl0a7Tm84FBwvEcf r3OoFrYIE8A0sUJ32V/cEf7qopK8K2Gh6/HPX4rUV3vc+W5kBwHVBcccsQzdcNEH+4Rk MM5bikumFlJedkK+0xNEZnudoFcyHxXBMwEAOGyRIS+TuD7p0zf9Pbk/lfKDDM5AqO6y pxkQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 68si568980pgb.104.2019.07.17.14.44.19; Wed, 17 Jul 2019 14:44:36 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729026AbfGQVnx (ORCPT + 99 others); Wed, 17 Jul 2019 17:43:53 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:55411 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727205AbfGQVnx (ORCPT ); Wed, 17 Jul 2019 17:43:53 -0400 Received: from pd9ef1cb8.dip0.t-ipconnect.de ([217.239.28.184] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hnriC-0005hz-EP; Wed, 17 Jul 2019 23:43:44 +0200 Date: Wed, 17 Jul 2019 23:43:43 +0200 (CEST) From: Thomas Gleixner To: Joerg Roedel cc: Dave Hansen , Andy Lutomirski , Peter Zijlstra , Ingo Molnar , Borislav Petkov , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Joerg Roedel Subject: Re: [PATCH 2/3] x86/mm: Sync also unmappings in vmalloc_sync_one() In-Reply-To: <20190717071439.14261-3-joro@8bytes.org> Message-ID: References: <20190717071439.14261-1-joro@8bytes.org> <20190717071439.14261-3-joro@8bytes.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 17 Jul 2019, Joerg Roedel wrote: > From: Joerg Roedel > > With huge-page ioremap areas the unmappings also need to be > synced between all page-tables. Otherwise it can cause data > corruption when a region is unmapped and later re-used. > > Make the vmalloc_sync_one() function ready to sync > unmappings. > > Fixes: 5d72b4fba40ef ('x86, mm: support huge I/O mapping capability I/F') > Signed-off-by: Joerg Roedel > --- > arch/x86/mm/fault.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c > index 4a4049f6d458..d71e167662c3 100644 > --- a/arch/x86/mm/fault.c > +++ b/arch/x86/mm/fault.c > @@ -194,11 +194,12 @@ static inline pmd_t *vmalloc_sync_one(pgd_t *pgd, unsigned long address) > > pmd = pmd_offset(pud, address); > pmd_k = pmd_offset(pud_k, address); > - if (!pmd_present(*pmd_k)) > - return NULL; > > - if (!pmd_present(*pmd)) > + if (pmd_present(*pmd) ^ pmd_present(*pmd_k)) > set_pmd(pmd, *pmd_k); > + > + if (!pmd_present(*pmd_k)) > + return NULL; > else > BUG_ON(pmd_pfn(*pmd) != pmd_pfn(*pmd_k)); So in case of unmap, this updates only the first entry in the pgd_list because vmalloc_sync_all() will break out of the iteration over pgd_list when NULL is returned from vmalloc_sync_one(). I'm surely missing something, but how is that supposed to sync _all_ page tables on unmap as the changelog claims? Thanks, tglx