Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp775237img; Wed, 20 Mar 2019 10:34:10 -0700 (PDT) X-Google-Smtp-Source: APXvYqyjPh3/iFqxd3FnFsBXukOXx9+tpYvKcsxUlqxmaktCoE+6yg4qP2KLGueBWam7B7lMmbuV X-Received: by 2002:a62:7049:: with SMTP id l70mr8883869pfc.78.1553103250575; Wed, 20 Mar 2019 10:34:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553103250; cv=none; d=google.com; s=arc-20160816; b=q9gi8bRCGvv8ESoKTJnEmYmbBSqGmPQinKJzs4Gdbj8vz/Eqjth5q5ZiNPPbB4eWsa iQrJOPXP/F0IIaXcnW3nGMgcv9SUJLzHzdd8mYhVDSRVxdu2VvS4UeBtDXeGbA+WsNXs OWE8unfbAw9PUSFRXCNZoAsvjxuvUZ8FDxKunOpGl5uQDE0bZEm4/SrHG3LXd4tmVcI2 iP73lzTP+r4QS1eVpe4i1YgF7+Dhwq5ESDuEy6U/+DjAfGSXyDt21iak2TeInUQnxNsP osHLjfc0/+21gxM8yffIqVQa+gZxgre3yJbthMEPq3IcFEz0i7u7nZFpy9B/lGH+MI0j jq0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=UQHu+FWBbDw0iGlj3adBwTusJuvw4DyPhlwVgfp3e6k=; b=FN5ejgNmSgZtM3BDKEiMuNZY7hzBv3s5DUA7qgkV3R+jnmrP30knFX1k8VebpojwbK rx1Nv0tEnP+78x1vxqOnqxE0Mbd76PTaFRSTH+pbdsjHdGug6qUo035VZa661yEowrdW Zl+aR+Fr2HXNgPKtIpTcwR4bUDhvWmIUQe3EM5qLBltdHboAzfGxA4y2ltdcplg1R5tY JNSPVq3zIXfCNHZGE2Hce5w3xakIX3GO0clneL7EZxn3eefLKblQBFU4jEhZEqy8sUb5 /y9Q8Bew6uZriEnGiikw2CiXdciQXPmHg5e4yCu4w97qvLYw9eD7GwM7e+cqGcP5FEyR Q/kg== 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 t9si2098558pgv.111.2019.03.20.10.33.55; Wed, 20 Mar 2019 10:34:10 -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 S1727054AbfCTRcD (ORCPT + 99 others); Wed, 20 Mar 2019 13:32:03 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:43588 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726448AbfCTRcD (ORCPT ); Wed, 20 Mar 2019 13:32:03 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8AAFDA78; Wed, 20 Mar 2019 10:32:02 -0700 (PDT) Received: from why.wild-wind.fr.eu.org (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5F8BA3F614; Wed, 20 Mar 2019 10:31:59 -0700 (PDT) Date: Wed, 20 Mar 2019 17:31:54 +0000 From: Marc Zyngier To: Suzuki K Poulose Cc: , , , , , , , , , , , , , Christoffer Dall Subject: Re: [PATCH v2] kvm: arm: Fix handling of stage2 huge mappings Message-ID: <20190320173154.6cfc7072@why.wild-wind.fr.eu.org> In-Reply-To: <1553093839-29317-1-git-send-email-suzuki.poulose@arm.com> References: <1553093839-29317-1-git-send-email-suzuki.poulose@arm.com> Organization: ARM Ltd X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 20 Mar 2019 14:57:19 +0000 Suzuki K Poulose wrote: > We rely on the mmu_notifier call backs to handle the split/merge > of huge pages and thus we are guaranteed that, while creating a > block mapping, either the entire block is unmapped at stage2 or it > is missing permission. > > However, we miss a case where the block mapping is split for dirty > logging case and then could later be made block mapping, if we cancel the > dirty logging. This not only creates inconsistent TLB entries for > the pages in the the block, but also leakes the table pages for > PMD level. > > Handle this corner case for the huge mappings at stage2 by > unmapping the non-huge mapping for the block. This could potentially > release the upper level table. So we need to restart the table walk > once we unmap the range. > > Fixes : ad361f093c1e31d ("KVM: ARM: Support hugetlbfs backed huge pages") > Reported-by: Zheng Xiang > Cc: Zheng Xiang > Cc: Zhenghui Yu ^ > Cc: Marc Zyngier > Cc: Christoffer Dall > Signed-off-by: Suzuki K Poulose Applied, with Zenghui's name fixed. Thanks, M. -- Without deviation from the norm, progress is not possible.