From patchwork Fri Dec 25 09:25:27 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nadav Amit X-Patchwork-Id: 11989951 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=-8.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT 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 7C42CC433DB for ; Fri, 25 Dec 2020 09:29:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E6A1F22AAC for ; Fri, 25 Dec 2020 09:29:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E6A1F22AAC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D411F6B00A8; Fri, 25 Dec 2020 04:29:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CF23A8D0080; Fri, 25 Dec 2020 04:29:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE0216B00AA; Fri, 25 Dec 2020 04:29:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0069.hostedemail.com [216.40.44.69]) by kanga.kvack.org (Postfix) with ESMTP id A55366B00A8 for ; Fri, 25 Dec 2020 04:29:38 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 51449E086 for ; Fri, 25 Dec 2020 09:29:38 +0000 (UTC) X-FDA: 77631282036.05.seed64_211598127478 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id 2B3A1180C6F11 for ; Fri, 25 Dec 2020 09:29:38 +0000 (UTC) X-HE-Tag: seed64_211598127478 X-Filterd-Recvd-Size: 5521 Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) by imf13.hostedemail.com (Postfix) with ESMTP for ; Fri, 25 Dec 2020 09:29:37 +0000 (UTC) Received: by mail-pf1-f175.google.com with SMTP id q22so2346287pfk.12 for ; Fri, 25 Dec 2020 01:29:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=RVMAYD4gVjDuu2L1m2emovg27Ao1LXtta+hv61YwtE4=; b=Xqcmvrzjf0v3Om3qY3vkNlJvkYs8uthcOLi/yiwi1S3kLGQ6pAV4LqeFEEy1IZA9CG mNewlnd9/uRZH0kIhcLOFsvUntL+EKsG7b1WlC2vtU09eHH1Lwe6b1V3111ZKCeU+itm 7eZwXpAK9UaajQkU9DtHTOZBLsYSAUClXnEg6o9EJ3V2bryDgZYpU2Kiw3Rl3WRqGLDG RL8qHu52h5JYiOKr7j5RACyyLEC7nEi8LjE18p8ZaDp5qjNCo7AtYu/RPP1aVRqdQ0Y+ 4AqEpCmprMFT4QaRS4zbzXbYd0rkzWRYENoJ8d4fyY//dtujo00UT/LajJ+pe44TMEVx nYsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=RVMAYD4gVjDuu2L1m2emovg27Ao1LXtta+hv61YwtE4=; b=Zm4MKWQs7aaWFg9gQV4nN/6nGoMuYclt3lRGKqubCP8HR7YE9kfCj/a4HbmmApfpCM 0K++VlpLee0rBqjcJwBkLZn6dDObiHJczPUjj207sM9inyYwIkFi5wMk7UUxCajM+DEI e5iFghlXCCzJgmpAC5wHUlP4iQCikyHtG7Bt38NQQbbRchPT6nLXiccqyEdgkOlFd/rE ZWxya2RW53KsJiQ+9WcW/5rvHstoXjwaDFqi9CyR89nqhzXxF2+tBtHmU4+1xFw6MI7P aPeHcGoysxtq/UpBw75jFLXA0tAlq+jdySiPOf5bF+6htKdn4cH1DCdkyZz4tIaemvuz dlQQ== X-Gm-Message-State: AOAM533rrEFp7Tayu7ijJxYOM6ttCb5ZV60brGINYJ3NhBeUkXnNPh/j b5Wl1A+hI0fwSgsTveNhjm4hJYwnvgGc3w== X-Google-Smtp-Source: ABdhPJx9/ExfuFhgPf0/W7sU90LeypmQV2CkuLRYiCOv0K2mDGnExIf8WCm0G/rjjtYOy9sK5dD5UQ== X-Received: by 2002:a62:e818:0:b029:19e:31e6:e639 with SMTP id c24-20020a62e8180000b029019e31e6e639mr30578284pfi.81.1608888576176; Fri, 25 Dec 2020 01:29:36 -0800 (PST) Received: from sc2-haas01-esx0118.eng.vmware.com ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id s13sm28966659pfd.99.2020.12.25.01.29.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Dec 2020 01:29:35 -0800 (PST) From: Nadav Amit X-Google-Original-From: Nadav Amit To: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, Nadav Amit , Andrea Arcangeli , Yu Zhao , Andy Lutomirski , Peter Xu , Pavel Emelyanov , Mike Kravetz , Mike Rapoport , Minchan Kim , Will Deacon , Peter Zijlstra Subject: [RFC PATCH v2 0/2] mm: fix races due to deferred TLB flushes Date: Fri, 25 Dec 2020 01:25:27 -0800 Message-Id: <20201225092529.3228466-1-namit@vmware.com> X-Mailer: git-send-email 2.25.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: From: Nadav Amit This patch-set went from v1 to RFCv2, as there is still an ongoing discussion regarding the way of solving the recently found races due to deferred TLB flushes. These patches are only sent for reference for now, and can be applied later if no better solution is taken. In a nutshell, write-protecting PTEs with deferred TLB flushes was mostly performed while holding mmap_lock for write. This prevented concurrent page-fault handler invocations from mistakenly assuming that a page is write-protected when in fact, due to the deferred TLB flush, other CPU could still write to the page. Such a write can cause a memory corruption if it takes place after the page was copied (in cow_user_page()), and before the PTE was flushed (by wp_page_copy()). However, the userfaultfd and soft-dirty mechanisms did not take mmap_lock for write, but only for read, which made such races possible. Since commit 09854ba94c6a ("mm: do_wp_page() simplification") these races became more likely to take place as non-COW'd pages are more likely to be COW'd instead of being reused. Both of the races that these patches are intended to resolve were produced on v5.10. To avoid the performance overhead some alternative solutions that do not require to acquire mmap_lock for write were proposed, specifically for userfaultfd. So far no better solution that can be backported was proposed for the soft-dirty case. v1->RFCv2: - Better (i.e., correct) description of the userfaultfd buggy case [Yu] - Patch for the soft-dirty case Cc: Andrea Arcangeli Cc: Yu Zhao Cc: Andy Lutomirski Cc: Peter Xu Cc: Pavel Emelyanov Cc: Mike Kravetz Cc: Mike Rapoport Cc: Minchan Kim Cc: Will Deacon Cc: Peter Zijlstra Nadav Amit (2): mm/userfaultfd: fix memory corruption due to writeprotect fs/task_mmu: acquire mmap_lock for write on soft-dirty cleanup fs/proc/task_mmu.c | 27 +++++++++++++-------------- mm/mprotect.c | 3 ++- mm/userfaultfd.c | 15 +++++++++++++-- 3 files changed, 28 insertions(+), 17 deletions(-)