From patchwork Fri Nov 20 14:35:51 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Will Deacon X-Patchwork-Id: 11920405 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=-11.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_GIT 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 52014C56201 for ; Fri, 20 Nov 2020 14:36:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7A6562240B for ; Fri, 20 Nov 2020 14:36:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="pfnWM6mp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7A6562240B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 912AD6B006C; Fri, 20 Nov 2020 09:36:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8C2EA6B0070; Fri, 20 Nov 2020 09:36:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7D8AE6B0071; Fri, 20 Nov 2020 09:36:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0004.hostedemail.com [216.40.44.4]) by kanga.kvack.org (Postfix) with ESMTP id 449CF6B006C for ; Fri, 20 Nov 2020 09:36:06 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id C566A181AEF1F for ; Fri, 20 Nov 2020 14:36:05 +0000 (UTC) X-FDA: 77505046290.08.sleep75_35131d32734c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id A7B401819E621 for ; Fri, 20 Nov 2020 14:36:05 +0000 (UTC) X-HE-Tag: sleep75_35131d32734c X-Filterd-Recvd-Size: 3750 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Fri, 20 Nov 2020 14:36:05 +0000 (UTC) Received: from localhost.localdomain (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id AE6532224C; Fri, 20 Nov 2020 14:36:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605882963; bh=B2tsz1eLDySQbKv3rPA/SjqjJvraB6qR6zYVvcCJO3U=; h=From:To:Cc:Subject:Date:From; b=pfnWM6mpPr4mUovHZOqS0m5JTkFwwrPNej8iWne6LVWh44CuojQDQ2e8GbrwhJgPw E51LRycawzpz8/vnMjAOh4WPU0NY32mcbFTDSF8NEx1XjZfJ/R/DKKZcwRS6Y95e91 ZyahIyR6nxGDdWxMPTqLMh6D0ytvmdQc3mPINgrQ= From: Will Deacon To: linux-kernel@vger.kernel.org Cc: kernel-team@android.com, Will Deacon , Catalin Marinas , Yu Zhao , Minchan Kim , Peter Zijlstra , Linus Torvalds , Anshuman Khandual , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org Subject: [PATCH 0/6] tlb: Fix access and (soft-)dirty bit management Date: Fri, 20 Nov 2020 14:35:51 +0000 Message-Id: <20201120143557.6715-1-will@kernel.org> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 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: Hi all, This series attempts to fix some issues relating to our access and (soft-)dirty bit management relating to TLB invalidation. It's a bit all over the place because I kept running into new issues as I was trying to figure it out. The first patch fixes a crash we've seen in practice. The other patches are all addressing things that I found by code inspection and I would _really_ appreciate others having a look. In particular, what can go wrong in practice if a CPU has a stale, writable entry in the TLB for a pte which is !pte_write()? It feels intuitively bad, but I couldn't find anywhere that would explode (the CoW path looks alright, for example). Cheers, Will Cc: Catalin Marinas Cc: Yu Zhao Cc: Minchan Kim Cc: Peter Zijlstra Cc: Linus Torvalds Cc: Andrew Morton Cc: linux-mm@kvack.org Cc: linux-arm-kernel@lists.infradead.org --->8 Will Deacon (6): arm64: pgtable: Fix pte_accessible() arm64: pgtable: Ensure dirty bit is preserved across pte_wrprotect() tlb: mmu_gather: Remove unused start/end arguments from tlb_finish_mmu() mm: proc: Invalidate TLB after clearing soft-dirty page state tlb: mmu_gather: Introduce tlb_gather_mmu_fullmm() mm: proc: Avoid fullmm flush for young/dirty bit toggling arch/arm64/include/asm/pgtable.h | 31 +++++++++++++++---------------- arch/ia64/include/asm/tlb.h | 2 +- arch/x86/kernel/ldt.c | 2 +- fs/exec.c | 2 +- fs/proc/task_mmu.c | 22 +++++++++++++--------- include/asm-generic/tlb.h | 6 ++++-- include/linux/mm_types.h | 4 ++-- mm/hugetlb.c | 2 +- mm/madvise.c | 6 +++--- mm/memory.c | 4 ++-- mm/mmap.c | 6 +++--- mm/mmu_gather.c | 21 +++++++++++++++------ mm/oom_kill.c | 4 ++-- 13 files changed, 63 insertions(+), 49 deletions(-)