Message ID | 20241010182427.1434605-56-seanjc@google.com |
---|---|
State | Accepted |
Headers | show
Return-Path: <kvm-riscv-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org> X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; secure) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=p6djS8P4; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20230601 header.b=0NCiVq29; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.infradead.org (client-ip=2607:7c80:54:3::133; helo=bombadil.infradead.org; envelope-from=kvm-riscv-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org; receiver=patchwork.ozlabs.org) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4XPjxy4nMYz1xvf for <incoming@patchwork.ozlabs.org>; Fri, 11 Oct 2024 08:46:28 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:Reply-To:List-Subscribe:List-Help: List-Post:List-Archive:List-Unsubscribe:List-Id:Cc:To:From:Subject:Message-ID :References:Mime-Version:In-Reply-To:Date:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=YvSxWM5gv+knpNmKJL2vF+KED6X1xGMMu11yjd6eDYc=; b=p6djS8P4hAEGIc 4rZH7w/vQXptI3vL64h42epgB4Zfr2W1y4mfqbIU4NpMgRfdhpqJTUq7tp/P8SzgHxuHcfB02TOXQ tv+ASlomTyzBcR4n8NpUsaFj1UgEYbi5QPjOK2FwGW9yv25kE3bADQcbjOBP/BaXUmHShS8B562u5 oTJPHbF69B6eEx+YornXNO3aIlG/iIY5sJAxQ/Qy81sgpJX8o6/wJBkDP2+qIoUsWTOukhSlK2V9O lTpc7hOMYgNn+XAaff521nNbzRKzA4sb2KhVcHx64+hQdauEMw9uaKdv5SBDYhHx2XKrwz1ftu29j Y7BqXuQJ8BEeNXdOnRHg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1sz0zL-0000000ESTO-28DJ; Thu, 10 Oct 2024 21:46:27 +0000 Received: from mail-pf1-x44a.google.com ([2607:f8b0:4864:20::44a]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1syxsB-0000000DrAN-1KPW for kvm-riscv@lists.infradead.org; Thu, 10 Oct 2024 18:26:54 +0000 Received: by mail-pf1-x44a.google.com with SMTP id d2e1a72fcca58-71e019ab268so1589446b3a.2 for <kvm-riscv@lists.infradead.org>; Thu, 10 Oct 2024 11:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1728584810; x=1729189610; darn=lists.infradead.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=K6YUqJX41UvLftiTjNafBx3/10X+6KBTIzQjXduU2xw=; b=0NCiVq29rFGnhx5H88IoL3ATW2C2rUWOjXZSdIu+X2IO47lSMoJniHN5TNSeqAXiCE vdYQvKFrx3oDn1gRyQMyhpHTz+6quCptZkRRo3o7mi+i280e9CsMWrw12MOxLkLf/z0d n9S3M2ueKS5c0w86AOpvJSx6WYvwwYWNDLTNWHkWQHmHyk73I3u+hhvSuESEc9jxPtu9 I8RiTJ2ti60nNLRKX10QJc1F/7mmAIhzBpW5L7gTAasZ32ELbTbyr66jwUWqpuYSli8q TzZYiRXhNgW10vDG12czBFzP40DQAV1W9mSZKLrtG3DwUE5f8tQuEUoHd9oyl6g+1FqZ QTyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728584810; x=1729189610; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=K6YUqJX41UvLftiTjNafBx3/10X+6KBTIzQjXduU2xw=; b=ka5hxa6Qq26JtPabdWRQFtdImOu7J3naUI0jmlkh3oDhM1KRxPGBew9TBCUBcAy8DA PkmW0ARr36elI7UvIIQhMBKbHt+Iwcxd/MbcBztdea0gnskXvbqXtGv7Cd/6OzV/4EKb Ymh0T47xGRhGYPwMchua5LeTE/ZhnhBat3qR7O6oMG4flXPJfFY4eoIZqQLlJzyzBwVr 2Q6vvpavq0GvEalS86zpKedOy/jQeH+slRsSrDdVKRVA+DrorzAca5j35hACJT5lSYHU vxzLZFgZ2Bu5GXUzSKGckSAiyQhUBGRx4Xlk9YgpbC2hy9HwfDIORS202TFHb0CsPdvu Qnqg== X-Forwarded-Encrypted: i=1; AJvYcCUu4MN5xwRAS2f+74qDnDFTpvmX7OqqpVvpFVdCZBguty9jLM3VL4BQ5DHWUBHJrXCQdXAdwqldl10=@lists.infradead.org X-Gm-Message-State: AOJu0YyDQpihTE+r8nIjjbowdsTVvUOBN6ZSWLpKa514A5L9/itduTpK 1YflXGbMY8ySwBQA8pMRHc/jvC6+rpIFVV59K5XXRRHXFoGooWu5owlZS8RvPG4udZ5u5kY9tbz 69g== X-Google-Smtp-Source: AGHT+IEO1ECBC98fGvB+GRqYHAQaBdxJcqvY9DmP3QI4gZm0KdOyij1fLmFl0bPXgfvra8JJdQe8JNFxBHM= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:9d:3983:ac13:c240]) (user=seanjc job=sendgmr) by 2002:a05:6a00:9199:b0:71e:1e8:e337 with SMTP id d2e1a72fcca58-71e1dbe467fmr8496b3a.4.1728584809106; Thu, 10 Oct 2024 11:26:49 -0700 (PDT) Date: Thu, 10 Oct 2024 11:23:57 -0700 In-Reply-To: <20241010182427.1434605-1-seanjc@google.com> Mime-Version: 1.0 References: <20241010182427.1434605-1-seanjc@google.com> X-Mailer: git-send-email 2.47.0.rc1.288.g06298d1525-goog Message-ID: <20241010182427.1434605-56-seanjc@google.com> Subject: [PATCH v13 55/85] KVM: arm64: Mark "struct page" pfns accessed/dirty before dropping mmu_lock From: Sean Christopherson <seanjc@google.com> To: Paolo Bonzini <pbonzini@redhat.com>, Marc Zyngier <maz@kernel.org>, Oliver Upton <oliver.upton@linux.dev>, Tianrui Zhao <zhaotianrui@loongson.cn>, Bibo Mao <maobibo@loongson.cn>, Huacai Chen <chenhuacai@kernel.org>, Michael Ellerman <mpe@ellerman.id.au>, Anup Patel <anup@brainfault.org>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Christian Borntraeger <borntraeger@linux.ibm.com>, Janosch Frank <frankja@linux.ibm.com>, Claudio Imbrenda <imbrenda@linux.ibm.com>, Sean Christopherson <seanjc@google.com> Cc: kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, " =?utf-8?q?Alex_Benn=C3=A9e?= " <alex.bennee@linaro.org>, Yan Zhao <yan.y.zhao@intel.com>, David Matlack <dmatlack@google.com>, David Stevens <stevensd@chromium.org>, Andrew Jones <ajones@ventanamicro.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241010_112651_564774_60E5964F X-CRM114-Status: GOOD ( 10.36 ) X-Spam-Score: -7.0 (-------) X-Spam-Report: Spam detection software, running on the system "bombadil.infradead.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Mark pages/folios accessed+dirty prior to dropping mmu_lock, as marking a page/folio dirty after it has been written back can make some filesystems unhappy (backing KVM guests will such filesystem fil [...] Content analysis details: (-7.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2607:f8b0:4864:20:0:0:0:44a listed in] [list.dnswl.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record -7.5 USER_IN_DEF_DKIM_WL From: address is in the default DKIM welcome-list -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -0.0 DKIMWL_WL_MED DKIMwl.org - Medium trust sender 2.5 RISK_FREE No risk! X-BeenThere: kvm-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: <kvm-riscv.lists.infradead.org> List-Unsubscribe: <http://lists.infradead.org/mailman/options/kvm-riscv>, <mailto:kvm-riscv-request@lists.infradead.org?subject=unsubscribe> List-Archive: <http://lists.infradead.org/pipermail/kvm-riscv/> List-Post: <mailto:kvm-riscv@lists.infradead.org> List-Help: <mailto:kvm-riscv-request@lists.infradead.org?subject=help> List-Subscribe: <http://lists.infradead.org/mailman/listinfo/kvm-riscv>, <mailto:kvm-riscv-request@lists.infradead.org?subject=subscribe> Reply-To: Sean Christopherson <seanjc@google.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kvm-riscv" <kvm-riscv-bounces@lists.infradead.org> Errors-To: kvm-riscv-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org |
Series |
KVM: Stop grabbing references to PFNMAP'd pages
|
expand
|
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c index dd221587fcca..ecc6c2b56c43 100644 --- a/arch/arm64/kvm/mmu.c +++ b/arch/arm64/kvm/mmu.c @@ -1692,15 +1692,17 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, } out_unlock: + if (writable && !ret) + kvm_release_pfn_dirty(pfn); + else + kvm_release_pfn_clean(pfn); + read_unlock(&kvm->mmu_lock); /* Mark the page dirty only if the fault is handled successfully */ - if (writable && !ret) { - kvm_set_pfn_dirty(pfn); + if (writable && !ret) mark_page_dirty_in_slot(kvm, memslot, gfn); - } - kvm_release_pfn_clean(pfn); return ret != -EAGAIN ? ret : 0; }
Mark pages/folios accessed+dirty prior to dropping mmu_lock, as marking a page/folio dirty after it has been written back can make some filesystems unhappy (backing KVM guests will such filesystem files is uncommon, and the race is minuscule, hence the lack of complaints). While scary sounding, practically speaking the worst case scenario is that KVM would trigger this WARN in filemap_unaccount_folio(): /* * At this point folio must be either written or cleaned by * truncate. Dirty folio here signals a bug and loss of * unwritten data - on ordinary filesystems. * * But it's harmless on in-memory filesystems like tmpfs; and can * occur when a driver which did get_user_pages() sets page dirty * before putting it, while the inode is being finally evicted. * * Below fixes dirty accounting after removing the folio entirely * but leaves the dirty flag set: it has no effect for truncated * folio and anyway will be cleared before returning folio to * buddy allocator. */ if (WARN_ON_ONCE(folio_test_dirty(folio) && mapping_can_writeback(mapping))) folio_account_cleaned(folio, inode_to_wb(mapping->host)); KVM won't actually write memory because the stage-2 mappings are protected by the mmu_notifier, i.e. there is no risk of loss of data, even if the VM were backed by memory that needs writeback. See the link below for additional details. This will also allow converting arm64 to kvm_release_faultin_page(), which requires that mmu_lock be held (for the aforementioned reason). Link: https://lore.kernel.org/all/cover.1683044162.git.lstoakes@gmail.com Signed-off-by: Sean Christopherson <seanjc@google.com> --- arch/arm64/kvm/mmu.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)