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=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 9EB3DC2D0E4 for ; Mon, 23 Nov 2020 22:06:09 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 0F7152065E for ; Mon, 23 Nov 2020 22:06:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="0bbJst4A"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="deUS5+Vx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0F7152065E 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=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=R6jpnfQq7uCRbZRI46/r4yD5PiD/diqwGZqENzosptU=; b=0bbJst4ASLRcAjeu5SW6BbXv8 agBkotgsfwKKiP2yo/SutbM87Xe9WRZplnFeyIuZxdPc5HKzKXlk7g9ZKS01guXbooxMVk474A2VH C5MHrK/KLmciPL27OZTRnEL1qoV1ZfDXJy2KWmO2lJoD1QZrisrdmNZjxvoVfbwjPQwYnuqUZd49N vlDyba27RasDcDCO9EGQp4d6+VSHiwfhZBkB8KPd9TPjhKsyP+zcwWun22hFVAYZ2dTxjw5/sRW3R icPAZw90BM5gvb9C7G4xr6uFlZ0Qrir06ZL0jwQ4tqkkDvHBOJTIM1kvFaEQTYGLWMcMvDJjFD8vd 2dCarPMAA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1khJxK-0000h1-T8; Mon, 23 Nov 2020 22:05:06 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1khJxI-0000g2-0e for linux-arm-kernel@lists.infradead.org; Mon, 23 Nov 2020 22:05:05 +0000 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (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 740072065E; Mon, 23 Nov 2020 22:05:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1606169103; bh=8QnfruGejTRH7nfsdvCBeNb2gG3IvvOWgour8c1dXr4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=deUS5+Vx3/ztra+NR51IRW3qxLRl5qvD5WjmIkfuSVBWe9GGetwCg9ahlhhkXiK7S VfcP0iwXuWE1It6EuQnVIOu4Atuv7HEopSvXMho1AknqlXXt+Q2Hv8bJgHpB5BwVAQ HLhCsJpAGMErHaGQGzWXlJun8YIYHmsjPWJi5j7c= Date: Mon, 23 Nov 2020 22:04:57 +0000 From: Will Deacon To: Yu Zhao Subject: Re: [PATCH 4/6] mm: proc: Invalidate TLB after clearing soft-dirty page state Message-ID: <20201123220457.GB12069@willie-the-truck> References: <20201120143557.6715-1-will@kernel.org> <20201120143557.6715-5-will@kernel.org> <20201120202253.GB1303870@google.com> <20201121024922.GA1363491@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201121024922.GA1363491@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201123_170504_275661_9FE54DF3 X-CRM114-Status: GOOD ( 23.02 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kernel-team@android.com, Anshuman Khandual , Peter Zijlstra , Catalin Marinas , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Minchan Kim , Linus Torvalds , linux-arm-kernel@lists.infradead.org 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 On Fri, Nov 20, 2020 at 07:49:22PM -0700, Yu Zhao wrote: > On Fri, Nov 20, 2020 at 01:22:53PM -0700, Yu Zhao wrote: > > On Fri, Nov 20, 2020 at 02:35:55PM +0000, Will Deacon wrote: > > > Since commit 0758cd830494 ("asm-generic/tlb: avoid potential double flush"), > > > TLB invalidation is elided in tlb_finish_mmu() if no entries were batched > > > via the tlb_remove_*() functions. Consequently, the page-table modifications > > > performed by clear_refs_write() in response to a write to > > > /proc//clear_refs do not perform TLB invalidation. Although this is > > > fine when simply aging the ptes, in the case of clearing the "soft-dirty" > > > state we can end up with entries where pte_write() is false, yet a > > > writable mapping remains in the TLB. > > > > I don't think we need a TLB flush in this context, same reason as we > > don't have one in copy_present_pte() which uses ptep_set_wrprotect() > > to write-protect a src PTE. Hmm. Afaict, copy_present_pte() is only called on the fork() path when VM_WIPEONFORK is set. I think that's a bit different to the fault case, and even then, there is a fullmm flush after the copy. > > ptep_modify_prot_start/commit() and ptep_set_wrprotect() guarantee > > either the dirty bit is set (when a PTE is still writable) or a PF > > happens (when a PTE has become r/o) when h/w page table walker races > > with kernel that modifies a PTE using the two APIs. > > After we remove the writable bit, if we end up with a clean PTE, any > subsequent write will trigger a page fault. We can't have a stale > writable tlb entry. The architecture-specific APIs guarantee this. > > If we end up with a dirty PTE, then yes, there will be a stale > writable tlb entry. But this won't be a problem because when we > write-protect a page (not PTE), we always check both pte_dirty() > and pte_write(), i.e., write_protect_page() and page_mkclean_one(). > When they see this dirty PTE, they will flush. And generally, only > callers of pte_mkclean() should flush tlb; otherwise we end up one > extra if callers of pte_mkclean() and pte_wrprotect() both flush. I just find this sort of analysis incredibly fragile: we're justifying the lack of TLB invalidation on a case-by-case basis rather than some general rules that mean it is not required by construction. Even if all current users don't need it, what means that will still be true in six months time? It's not like this stuff is easy to trigger in practice if we get it wrong. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel