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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E0302C52D71 for ; Tue, 6 Aug 2024 15:20:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:Cc:To:From: Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=zfDlFqosrXLKfrNosA2JBe6CUch6c/VqYqOk4CYX594=; b=lkay3LBYmKFoTVso2iwqLXoSnX oWNPwNrbsXIQQoE3Qzcb5qC3HNKICBSy0kX2ahziCU0lZwakHx6cpT38JFqJXwmgui8TyPeA2Zuqu mpYf8wTCAAvq74Y9ow5xFYbOO7TgNaca7pZW2wMPDS0udTinL5+poyG34lOQ4URdZUmugEPmRF23A jsavLzIB/FMMMkmPQ0Px+xVw5Z10s7RZEpW+gWR6O/4o17WjpEYFIk1XCGpEuu27rvfZmFmxy2Jhf 6koJMAC2VbbB+83j3Mi4JhH+AWuseUh9Lf/+5nXp8Nx5KpVhgneGV+MQITKaG0mgyhHMzdSdbffjF EANB9mJA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sbLyo-000000029at-42kz; Tue, 06 Aug 2024 15:20:06 +0000 Received: from mail-pl1-x649.google.com ([2607:f8b0:4864:20::649]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sbLyH-000000029RX-3ykW for linux-arm-kernel@lists.infradead.org; Tue, 06 Aug 2024 15:19:35 +0000 Received: by mail-pl1-x649.google.com with SMTP id d9443c01a7336-1fc4e03a885so6795965ad.2 for ; Tue, 06 Aug 2024 08:19:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722957572; x=1723562372; darn=lists.infradead.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=zfDlFqosrXLKfrNosA2JBe6CUch6c/VqYqOk4CYX594=; b=xRECPBMMUt+KgLhGLCCSLfa9dN7SXMDc9zuVxplv2HXfJrkH01HGjqrQ9kiSg34Jks x1CaZ4PWlpD46Jt9rCZ4sj6vx/vGk4a8nMlEd+SHWGz6An8mPH2CMQYKqVuCTPx0gRd+ Os9l3Ci7SpIYN2MWi+FhYAAvkMA/yEmGLRR4gkJjQqbVo6xUFdW3/D0VAew78F4aDSIf RgaEibjpIxxdcdzraQue1/TlyAozjPEbIoRZZjA7PDocZxP/unPW3vRXekj29XW6dPSz wwX3XdmhzD9MMyZ6CY2cjuLSKPi89nMZBeYW+fiEesZ+euSyTWQeCXwsl/I99Dy8PEUH bzVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722957572; x=1723562372; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=zfDlFqosrXLKfrNosA2JBe6CUch6c/VqYqOk4CYX594=; b=db0MuwVB32CGmJtfuJCRrzas+fFUzvgCBZ9haNg3dMrPn/fjvh2W2WkkrD2N37w586 SEqpJ5PSY//tIK7XVptmCg1nWkEq6o35EId9+kEhYoZk0mftUznefHxJsgHy7IGAQHav /nZ/sgmIB7SDKBjyoMTf3JeaUC+a3cciU90UGqp7ZcqSv2ss9mx7cQUalTTCMYWZJ+jR afNzgpAYxudE5O6+mglaoyAymnk1EgPTydyfOIxIiyPKMCFkh69qwO3KO5hrMncPouCD PsdfPYxwbsI/fQS7bt15iCQLmV2UcDu+pFg7QPCsvBYQTgZL+4K0rQCA7qK1k9sbNgtS PfCQ== X-Forwarded-Encrypted: i=1; AJvYcCVeLNHhyRYTN411UxMOcRXGGZxM7pQ1qIjOxUcoV30zeQmIhRyWSTftqVU9Wytxb3v56nFwB5P0xzRW/MwpOHkrMOOVSjwOZSpirWWuvOaSyetuE7Y= X-Gm-Message-State: AOJu0YwkgRDEA5TZkZkKRCVzNno9hZRm1szD0/bSASnmsw65pSeXEoPL y0AdChJH0FQ8zxaspWntu2ftuIDBWQiu4PJAvzznC/iVcRxuApUbPzPFAjUKIpU3JDyfAKplTQX VZA== X-Google-Smtp-Source: AGHT+IG+kq4xSCmsszhC87T6ezpGfclhL8SLo9v6dzemvAwTfI9EBqVt37Vs+G2GK8dBxj5hzSimY+F6XI8= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:e743:b0:1fb:54d9:ebb3 with SMTP id d9443c01a7336-1ff57309939mr9499665ad.6.1722957571476; Tue, 06 Aug 2024 08:19:31 -0700 (PDT) Date: Tue, 6 Aug 2024 08:19:29 -0700 In-Reply-To: <86ikwe2fph.wl-maz@kernel.org> Mime-Version: 1.0 References: <20240726235234.228822-1-seanjc@google.com> <20240726235234.228822-55-seanjc@google.com> <86ikwe2fph.wl-maz@kernel.org> Message-ID: Subject: Re: [PATCH v12 54/84] KVM: arm64: Mark "struct page" pfns accessed/dirty before dropping mmu_lock From: Sean Christopherson To: Marc Zyngier Cc: Oliver Upton , Paolo Bonzini , Tianrui Zhao , Bibo Mao , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , 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, David Matlack , David Stevens , Fuad Tabba Content-Type: text/plain; charset="us-ascii" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240806_081934_015992_7FAEBF18 X-CRM114-Status: GOOD ( 16.60 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Aug 06, 2024, Marc Zyngier wrote: > On Tue, 06 Aug 2024 00:26:54 +0100, > Oliver Upton wrote: > > > > On Mon, Aug 05, 2024 at 11:26:03PM +0000, Oliver Upton wrote: > > > [+cc Fuad] > > > > Take 2! > > > > > Fuad, you mentioned in commit 9c30fc615daa ("KVM: arm64: Move setting > > > the page as dirty out of the critical section") that restructuring > > > around the MMU lock was helpful for reuse (presumably for pKVM), but I > > > lack the context there. > > > > > > On Fri, Jul 26, 2024 at 04:52:03PM -0700, Sean Christopherson wrote: > > > > 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 > > > > > > typo: s/will/with/ > > > > > > > the race is minuscule, hence the lack of complaints). See the link below > > > > for details. > > Should we consider reverting 9c30fc615daa then? Aha! After thinking through things more, I don't think a revert is necessary. I _think_ 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. And FWIW, given that multiple other KVM architectures mark folios dirty outside of mmu_notifier protection and have never tripped over this, I think it's highly unlikely the WARN will ever be triggered by a sane virtualization setup. I can add something to that effect to the changelog, e.g. to document that this isn't super urgent.