Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp3666220ybi; Fri, 19 Jul 2019 07:03:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqw9rRFtkU//7q4PYMkibZOKlExzSbUauLU+mL5pW+HPvEPe/GiFfW8G8HYlRDy2+FJJ2H3j X-Received: by 2002:a17:90a:d343:: with SMTP id i3mr60466514pjx.15.1563544998548; Fri, 19 Jul 2019 07:03:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563544998; cv=none; d=google.com; s=arc-20160816; b=dLQrbGy7RMADPyek/QPeJ8ch/JVNW1gYUluKJjVdWDPK/GGTJ+DP5YBKOrmv6KLK6M ZHi+u67JWZOZH5OQ49opnJ4dGRxbD9aDi+1NfG8JhXgsa3Q5PBkI/vZldu6P9oDOl7iw 3eHs5y00a8bVl6nzLft6vMG0Tu7pLfA4yfBKY+dNuiw6Lvsskwl+3EojqIP3+X58EIjn keh/Rgst3oyVWRjidLBpeFm5vg6gUic2g1LGn4y1CgMMB3nRu6D3j9LLvbsuurR+XkW+ NGoboOPdzCJJ8X1uWhkKB7IfYbbI4XJ+ZHIBWmtCxWWOLeLiPp0tAgMrMkrq5n4H33aH makA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Re9XNDBGaEOf1drjRYRw2FyiATnegfB3VIFvqkNcyd4=; b=f9UuQ+ex6kznXKs/Jo93WmoCQdkJW92CvF0k9ctJbtGfunZi+kxLXFWhLt9OZu8P0W FJ5Cv5nNM3eF2o7k3ynN4lvLHHYDCLfVpoxfEjSXDeV7KV9Q6XP0qO0i3Rz9dAo/yybQ 9ZD2dYtv7wqMeFK81hIhpix20TtSjXaGwUIEfCGkEXd3QLKbW2aq7ha4dZru1hvD1+Ry 1zm81yI/3aARyosHx3TPdTZ8I9poIxlPE8hdRXowd4fP7mSsTXG/5Y7+5zlJM+eDj2KP zaC5Jlo1ONbgnvuAmpWkCgW7BXC7z7TSIMCYfUlROedTTZn7I47BFu8+f/wbRKFp1dL9 BA/w== 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 u186si1499979pgd.532.2019.07.19.07.03.02; Fri, 19 Jul 2019 07:03:18 -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 S1729294AbfGSOB0 (ORCPT + 99 others); Fri, 19 Jul 2019 10:01:26 -0400 Received: from mx2.suse.de ([195.135.220.15]:57178 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726239AbfGSOBZ (ORCPT ); Fri, 19 Jul 2019 10:01:25 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 77F1CAE86; Fri, 19 Jul 2019 14:01:24 +0000 (UTC) Date: Fri, 19 Jul 2019 16:01:22 +0200 From: Joerg Roedel To: Thomas Gleixner Cc: Joerg Roedel , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Ingo Molnar , Borislav Petkov , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 2/3] x86/mm: Sync also unmappings in vmalloc_sync_one() Message-ID: <20190719140122.GF19068@suse.de> References: <20190717071439.14261-1-joro@8bytes.org> <20190717071439.14261-3-joro@8bytes.org> <20190718084654.GF13091@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 18, 2019 at 11:04:57AM +0200, Thomas Gleixner wrote: > Joerg, > > On Thu, 18 Jul 2019, Joerg Roedel wrote: > > On Wed, Jul 17, 2019 at 11:43:43PM +0200, Thomas Gleixner wrote: > > > On Wed, 17 Jul 2019, Joerg Roedel wrote: > > > > + > > > > + 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? > > > > No, you are right, I missed that. It is a bug in this patch, the code > > that breaks out of the loop in vmalloc_sync_all() needs to be removed as > > well. Will do that in the next version. > > I assume that p4d/pud do not need the pmd treatment, but a comment > explaining why would be appreciated. Actually there is already a comment in this function explaining why p4d and pud don't need any treatment: /* * set_pgd(pgd, *pgd_k); here would be useless on PAE * and redundant with the set_pmd() on non-PAE. As would * set_p4d/set_pud. */ I couldn't say it with less words :) Regards, Joerg