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=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 D3B05C433E0 for ; Tue, 29 Dec 2020 23:14:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8C64022262 for ; Tue, 29 Dec 2020 23:14:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8C64022262 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 338E08D0076; Tue, 29 Dec 2020 18:14:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2E7068D006A; Tue, 29 Dec 2020 18:14:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D6B38D0076; Tue, 29 Dec 2020 18:14:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0023.hostedemail.com [216.40.44.23]) by kanga.kvack.org (Postfix) with ESMTP id 042958D006A for ; Tue, 29 Dec 2020 18:14:46 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id CA8028249980 for ; Tue, 29 Dec 2020 23:14:45 +0000 (UTC) X-FDA: 77647876530.08.queen96_5512502274a0 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id AD9B51819E76C for ; Tue, 29 Dec 2020 23:14:45 +0000 (UTC) X-HE-Tag: queen96_5512502274a0 X-Filterd-Recvd-Size: 3608 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Tue, 29 Dec 2020 23:14:45 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 0F99C22227; Tue, 29 Dec 2020 23:14:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1609283684; bh=pGk9J4rCy7GP3M8Z2VVdPhrK1//OAap2SW0trSWHEig=; h=Date:From:To:Subject:In-Reply-To:From; b=i8EVdVcyTBS1W7pHpVuzGFHTDIgj1oh1R52kMGq0RAx6v48AXf5jZOppPCmBWmhY/ Ca9t7tispxkkw7PA+hm4znbEklObbW843XeIUk7f6I/jXZjpzFBEf7UgbFsOkhjN7L ssTGvrMs15MLLc0g4Gryi2knmjA0TRmHp0zxZa1c= Date: Tue, 29 Dec 2020 15:14:43 -0800 From: Andrew Morton To: akpm@linux-foundation.org, davem@davemloft.net, hughd@google.com, linux-mm@kvack.org, mm-commits@vger.kernel.org, npiggin@gmail.com, peterz@infradead.org, sbsiddha@gmail.com, suresh.b.siddha@intel.com, torvalds@linux-foundation.org, willy@infradead.org Subject: [patch 08/16] mm: generalise COW SMC TLB flushing race comment Message-ID: <20201229231443.n5HPa3y-B%akpm@linux-foundation.org> In-Reply-To: <20201229151349.3285926ec0d1f65a27ac8534@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Nicholas Piggin Subject: mm: generalise COW SMC TLB flushing race comment I'm not sure if I'm completely missing something here, but AFAIKS the reference to the mysterious "COW SMC race" confuses the issue. The original changelog and mailing list thread didn't help me either. This SMC race is where the problem was detected, but isn't the general problem bigger and more obvious: that the new PTE could be picked up at any time by any TLB while entries for the old PTE exist in other TLBs before the TLB flush takes effect? The case where the iTLB and dTLB of a CPU are pointing at different pages is an interesting one but follows from the general problem. The other (minor) thing with the comment I think it makes it a bit clearer to say what the old code was doing (i.e., it avoids the race as opposed to what?). References: 4ce072f1faf29 ("mm: fix a race condition under SMC + COW") Link: https://lkml.kernel.org/r/20201215121119.351650-1-npiggin@gmail.com Reviewed-by: Matthew Wilcox (Oracle) Cc: Suresh Siddha Cc: "David S. Miller" Cc: Hugh Dickins Cc: Peter Zijlstra Cc: Suresh Siddha Signed-off-by: Andrew Morton --- mm/memory.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/mm/memory.c~mm-generalise-cow-smc-tlb-flushing-race-comment +++ a/mm/memory.c @@ -2892,11 +2892,13 @@ static vm_fault_t wp_page_copy(struct vm entry = mk_pte(new_page, vma->vm_page_prot); entry = pte_sw_mkyoung(entry); entry = maybe_mkwrite(pte_mkdirty(entry), vma); + /* * Clear the pte entry and flush it first, before updating the - * pte with the new entry. This will avoid a race condition - * seen in the presence of one thread doing SMC and another - * thread doing COW. + * pte with the new entry, to keep TLBs on different CPUs in + * sync. This code used to set the new PTE then flush TLBs, but + * that left a window where the new PTE could be loaded into + * some TLBs while the old PTE remains in others. */ ptep_clear_flush_notify(vma, vmf->address, vmf->pte); page_add_new_anon_rmap(new_page, vma, vmf->address, false); _