From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 43B6CC433E0 for ; Wed, 3 Mar 2021 09:54:38 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 847E764EEC for ; Wed, 3 Mar 2021 09:54:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 847E764EEC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id EC2DC4B79A; Wed, 3 Mar 2021 04:54:36 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liZO3NDSPDEU; Wed, 3 Mar 2021 04:54:35 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id AF8DE4B78F; Wed, 3 Mar 2021 04:54:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 066DA4B77F for ; Wed, 3 Mar 2021 04:54:34 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cgg-YB54gZBF for ; Wed, 3 Mar 2021 04:54:33 -0500 (EST) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id C54C54B784 for ; Wed, 3 Mar 2021 04:54:32 -0500 (EST) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A147B64EE9; Wed, 3 Mar 2021 09:54:29 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lHOD5-00Grus-9a; Wed, 03 Mar 2021 09:54:27 +0000 Date: Wed, 03 Mar 2021 09:54:25 +0000 Message-ID: <87sg5czhny.wl-maz@kernel.org> From: Marc Zyngier To: Jia He Subject: Re: [PATCH] KVM: arm64: Fix unaligned addr case in mmu walking In-Reply-To: <20210303024225.2591-1-justin.he@arm.com> References: <20210303024225.2591-1-justin.he@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: justin.he@arm.com, kvmarm@lists.cs.columbia.edu, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org, gshan@redhat.com, wangyanan55@huawei.com, qperret@google.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: Catalin Marinas , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Will Deacon , kvmarm@lists.cs.columbia.edu X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu Hi Jia, On Wed, 03 Mar 2021 02:42:25 +0000, Jia He wrote: > > If the start addr is not aligned with the granule size of that level. > loop step size should be adjusted to boundary instead of simple > kvm_granual_size(level) increment. Otherwise, some mmu entries might miss > the chance to be walked through. > E.g. Assume the unmap range [data->addr, data->end] is > [0xff00ab2000,0xff00cb2000] in level 2 walking and NOT block mapping. When does this occur? Upgrade from page mappings to block? Swap out? > And the 1st part of that pmd entry is [0xff00ab2000,0xff00c00000]. The > pmd value is 0x83fbd2c1002 (not valid entry). In this case, data->addr > should be adjusted to 0xff00c00000 instead of 0xff00cb2000. Let me see if I understand this. Assuming 4k pages, the region described above spans *two* 2M entries: (a) ff00ab2000-ff00c00000, part of ff00a00000-ff00c00000 (b) ff00c00000-ff00db2000, part of ff00c00000-ff00e00000 (a) has no valid mapping, but (b) does. Because we fail to correctly align on a block boundary when skipping (a), we also skip (b), which is then left mapped. Did I get it right? If so, yes, this is... annoying. Understanding the circumstances this triggers in would be most interesting. This current code seems to assume that we get ranges aligned to mapping boundaries, but I seem to remember that the old code did use the stage2_*_addr_end() helpers to deal with this case. Will: I don't think things have changed in that respect, right? > > Without this fix, userspace "segment fault" error can be easily > triggered by running simple gVisor runsc cases on an Ampere Altra > server: > docker run --runtime=runsc -it --rm ubuntu /bin/bash > > In container: > for i in `seq 1 100`;do ls;done The workload on its own isn't that interesting. What I'd like to understand is what happens on the host during that time. > > Reported-by: Howard Zhang > Signed-off-by: Jia He > --- > arch/arm64/kvm/hyp/pgtable.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c > index bdf8e55ed308..4d99d07c610c 100644 > --- a/arch/arm64/kvm/hyp/pgtable.c > +++ b/arch/arm64/kvm/hyp/pgtable.c > @@ -225,6 +225,7 @@ static inline int __kvm_pgtable_visit(struct kvm_pgtable_walk_data *data, > goto out; > > if (!table) { > + data->addr = ALIGN_DOWN(data->addr, kvm_granule_size(level)); > data->addr += kvm_granule_size(level); > goto out; > } It otherwise looks good to me. Quentin, Will: unless you object to this, I plan to take it in the next round of fixes with Fixes: b1e57de62cfb ("KVM: arm64: Add stand-alone page-table walker infrastructure") Cc: stable@vger.kernel.org Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4FB90C433E0 for ; Wed, 3 Mar 2021 17:45:26 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6478864EEA for ; Wed, 3 Mar 2021 17:45:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6478864EEA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Subject:Cc:To: From:Message-ID:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=M5hD9cAtjvjs/gU0kmIStqh/mp2lexYJ0FRFRNOSQJw=; b=S0SKG+yUoVv6hYugxIW2wC9UT XT/fbgqqpfCWN2jt7900u63L8YZXkkCx2phNTow3mECOMAI/SJwA9pK5VIaqcQzctst0uBy8wtnZL dK63QY2umBv+Op/gxl9caQmDu08a1qSADqpER/pvBiuw31t1QsBoz/nEEXaOnIKbHF9nmFjXZsAnT bbX2pcCJSqZzCyEXKOy0v7dGs/eGBaU9W7Y8MJO4nt3cUugmT4IQK92YYCkuXO7EPWKkiF5765BCi gI0y1nKSpM9fMQ1An0ZQingAsKz+Liv7gxcP0oiPrCnJypqYlHEWAl+ZDgx76pj3WNaUnoxnHtEd/ 4Rd4aEx8Q==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lHVWT-005qz0-GS; Wed, 03 Mar 2021 17:42:57 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lHSw4-005Fiz-AW for linux-arm-kernel@desiato.infradead.org; Wed, 03 Mar 2021 14:57:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Type:MIME-Version:References: In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=vjYum5nqzs+rUR64eJfY5hF/9XkidhNHVb3lnFceZzs=; b=hCRzUfQYLEE69i1LqR8ategC1C S8s+nLzk+4E/MktTsrDNPlw2OcsC0ftlsVcCVPXJWp8K5fnr9+3p4pUzo3kldrExkUN8KH8ZX+lI/ rQK+qPNQ1kShL1Gfwcffo56STuNB5R9JdqtifIP0Uv+LgsEA4zhwaSL06zjyMLEue0fkIRqUteSEo GnnZ6TlW6Da2tOI2Ij+MDC0sBc3nL2OFyV1bTxL1FwISJc6qhU6O80wRsIXpxwtxkjrXXl+oyOLyp sTnCG82FVBR1c1Lrx6MYIEp39QnnnkA/1vi48SSP71SpFsvjlY7krXxJLVu9mo9flL8XnV1Gajxa/ V7ePvcPw==; Received: from mail.kernel.org ([198.145.29.99]) by casper.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lHODB-0025S1-G2 for linux-arm-kernel@lists.infradead.org; Wed, 03 Mar 2021 09:54:40 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A147B64EE9; Wed, 3 Mar 2021 09:54:29 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lHOD5-00Grus-9a; Wed, 03 Mar 2021 09:54:27 +0000 Date: Wed, 03 Mar 2021 09:54:25 +0000 Message-ID: <87sg5czhny.wl-maz@kernel.org> From: Marc Zyngier To: Jia He Cc: kvmarm@lists.cs.columbia.edu, James Morse , Julien Thierry , Suzuki K Poulose , Catalin Marinas , Will Deacon , Gavin Shan , Yanan Wang , Quentin Perret , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] KVM: arm64: Fix unaligned addr case in mmu walking In-Reply-To: <20210303024225.2591-1-justin.he@arm.com> References: <20210303024225.2591-1-justin.he@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: justin.he@arm.com, kvmarm@lists.cs.columbia.edu, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org, gshan@redhat.com, wangyanan55@huawei.com, qperret@google.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210303_095440_807589_EAD96E62 X-CRM114-Status: GOOD ( 27.36 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Jia, On Wed, 03 Mar 2021 02:42:25 +0000, Jia He wrote: > > If the start addr is not aligned with the granule size of that level. > loop step size should be adjusted to boundary instead of simple > kvm_granual_size(level) increment. Otherwise, some mmu entries might miss > the chance to be walked through. > E.g. Assume the unmap range [data->addr, data->end] is > [0xff00ab2000,0xff00cb2000] in level 2 walking and NOT block mapping. When does this occur? Upgrade from page mappings to block? Swap out? > And the 1st part of that pmd entry is [0xff00ab2000,0xff00c00000]. The > pmd value is 0x83fbd2c1002 (not valid entry). In this case, data->addr > should be adjusted to 0xff00c00000 instead of 0xff00cb2000. Let me see if I understand this. Assuming 4k pages, the region described above spans *two* 2M entries: (a) ff00ab2000-ff00c00000, part of ff00a00000-ff00c00000 (b) ff00c00000-ff00db2000, part of ff00c00000-ff00e00000 (a) has no valid mapping, but (b) does. Because we fail to correctly align on a block boundary when skipping (a), we also skip (b), which is then left mapped. Did I get it right? If so, yes, this is... annoying. Understanding the circumstances this triggers in would be most interesting. This current code seems to assume that we get ranges aligned to mapping boundaries, but I seem to remember that the old code did use the stage2_*_addr_end() helpers to deal with this case. Will: I don't think things have changed in that respect, right? > > Without this fix, userspace "segment fault" error can be easily > triggered by running simple gVisor runsc cases on an Ampere Altra > server: > docker run --runtime=runsc -it --rm ubuntu /bin/bash > > In container: > for i in `seq 1 100`;do ls;done The workload on its own isn't that interesting. What I'd like to understand is what happens on the host during that time. > > Reported-by: Howard Zhang > Signed-off-by: Jia He > --- > arch/arm64/kvm/hyp/pgtable.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c > index bdf8e55ed308..4d99d07c610c 100644 > --- a/arch/arm64/kvm/hyp/pgtable.c > +++ b/arch/arm64/kvm/hyp/pgtable.c > @@ -225,6 +225,7 @@ static inline int __kvm_pgtable_visit(struct kvm_pgtable_walk_data *data, > goto out; > > if (!table) { > + data->addr = ALIGN_DOWN(data->addr, kvm_granule_size(level)); > data->addr += kvm_granule_size(level); > goto out; > } It otherwise looks good to me. Quentin, Will: unless you object to this, I plan to take it in the next round of fixes with Fixes: b1e57de62cfb ("KVM: arm64: Add stand-alone page-table walker infrastructure") Cc: stable@vger.kernel.org Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 863B1C43381 for ; Wed, 3 Mar 2021 15:28:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5DD6C64EBD for ; Wed, 3 Mar 2021 15:28:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1448346AbhCCPZA (ORCPT ); Wed, 3 Mar 2021 10:25:00 -0500 Received: from mail.kernel.org ([198.145.29.99]:47470 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241111AbhCCKcX (ORCPT ); Wed, 3 Mar 2021 05:32:23 -0500 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A147B64EE9; Wed, 3 Mar 2021 09:54:29 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lHOD5-00Grus-9a; Wed, 03 Mar 2021 09:54:27 +0000 Date: Wed, 03 Mar 2021 09:54:25 +0000 Message-ID: <87sg5czhny.wl-maz@kernel.org> From: Marc Zyngier To: Jia He Cc: kvmarm@lists.cs.columbia.edu, James Morse , Julien Thierry , Suzuki K Poulose , Catalin Marinas , Will Deacon , Gavin Shan , Yanan Wang , Quentin Perret , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] KVM: arm64: Fix unaligned addr case in mmu walking In-Reply-To: <20210303024225.2591-1-justin.he@arm.com> References: <20210303024225.2591-1-justin.he@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: justin.he@arm.com, kvmarm@lists.cs.columbia.edu, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org, gshan@redhat.com, wangyanan55@huawei.com, qperret@google.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jia, On Wed, 03 Mar 2021 02:42:25 +0000, Jia He wrote: > > If the start addr is not aligned with the granule size of that level. > loop step size should be adjusted to boundary instead of simple > kvm_granual_size(level) increment. Otherwise, some mmu entries might miss > the chance to be walked through. > E.g. Assume the unmap range [data->addr, data->end] is > [0xff00ab2000,0xff00cb2000] in level 2 walking and NOT block mapping. When does this occur? Upgrade from page mappings to block? Swap out? > And the 1st part of that pmd entry is [0xff00ab2000,0xff00c00000]. The > pmd value is 0x83fbd2c1002 (not valid entry). In this case, data->addr > should be adjusted to 0xff00c00000 instead of 0xff00cb2000. Let me see if I understand this. Assuming 4k pages, the region described above spans *two* 2M entries: (a) ff00ab2000-ff00c00000, part of ff00a00000-ff00c00000 (b) ff00c00000-ff00db2000, part of ff00c00000-ff00e00000 (a) has no valid mapping, but (b) does. Because we fail to correctly align on a block boundary when skipping (a), we also skip (b), which is then left mapped. Did I get it right? If so, yes, this is... annoying. Understanding the circumstances this triggers in would be most interesting. This current code seems to assume that we get ranges aligned to mapping boundaries, but I seem to remember that the old code did use the stage2_*_addr_end() helpers to deal with this case. Will: I don't think things have changed in that respect, right? > > Without this fix, userspace "segment fault" error can be easily > triggered by running simple gVisor runsc cases on an Ampere Altra > server: > docker run --runtime=runsc -it --rm ubuntu /bin/bash > > In container: > for i in `seq 1 100`;do ls;done The workload on its own isn't that interesting. What I'd like to understand is what happens on the host during that time. > > Reported-by: Howard Zhang > Signed-off-by: Jia He > --- > arch/arm64/kvm/hyp/pgtable.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c > index bdf8e55ed308..4d99d07c610c 100644 > --- a/arch/arm64/kvm/hyp/pgtable.c > +++ b/arch/arm64/kvm/hyp/pgtable.c > @@ -225,6 +225,7 @@ static inline int __kvm_pgtable_visit(struct kvm_pgtable_walk_data *data, > goto out; > > if (!table) { > + data->addr = ALIGN_DOWN(data->addr, kvm_granule_size(level)); > data->addr += kvm_granule_size(level); > goto out; > } It otherwise looks good to me. Quentin, Will: unless you object to this, I plan to take it in the next round of fixes with Fixes: b1e57de62cfb ("KVM: arm64: Add stand-alone page-table walker infrastructure") Cc: stable@vger.kernel.org Thanks, M. -- Without deviation from the norm, progress is not possible.