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.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 13F2CC433E0 for ; Wed, 23 Dec 2020 00:21:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 82DD02253D for ; Wed, 23 Dec 2020 00:21:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 82DD02253D 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 0328F6B009C; Tue, 22 Dec 2020 19:21:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F23BE8D0001; Tue, 22 Dec 2020 19:21:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E384F6B009F; Tue, 22 Dec 2020 19:21:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0209.hostedemail.com [216.40.44.209]) by kanga.kvack.org (Postfix) with ESMTP id CF7006B009C for ; Tue, 22 Dec 2020 19:21:07 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 8F3AF181AEF3C for ; Wed, 23 Dec 2020 00:21:07 +0000 (UTC) X-FDA: 77622642174.24.chair47_1313c6527464 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin24.hostedemail.com (Postfix) with ESMTP id 68BBA1A4A5 for ; Wed, 23 Dec 2020 00:21:07 +0000 (UTC) X-HE-Tag: chair47_1313c6527464 X-Filterd-Recvd-Size: 5627 Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by imf13.hostedemail.com (Postfix) with ESMTP for ; Wed, 23 Dec 2020 00:21:06 +0000 (UTC) Received: by mail-lf1-f42.google.com with SMTP id s26so36044397lfc.8 for ; Tue, 22 Dec 2020 16:21:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DLFc43+zWZaHz7DJE5w0IA8m/d3/STNRHdNjNBYY/r8=; b=Kv96F1RjqhLKNH4Di/XoAkh4fGcFanJF/35mBeZg8s5yZd6emVuhDTmAbKdCOPjTHy 2Flkg4YAHNfaKVQVpWzaowFcfIsg0qWnCHYScg1wPkWTGMP48AsbRBDUDmFxjUz6rUTh Xoab7E7PwRF0MbFD3jGQK+ux0O7RWJxy/Q1DA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DLFc43+zWZaHz7DJE5w0IA8m/d3/STNRHdNjNBYY/r8=; b=HLX+l0zoDmhBDnK6n+kIV9JevYz3r1WENA1ZibNJNabxoEflySqRRvYVq5Q2g4tKuT Yjh+s9jKIZexZXwt+SWcy+OPypccmjfYGT8Xi/3uCWzbO5//p/050SdJn+QWjdTX6s6a GYcGBpEmIA8aEWR4aDYwqtgj+xhmd4yJZFBOGSpoe8H0Q5e1iwXp2j1vXn4EScs3vh6I iDdie5fMSj3j5ULhWLCdc3XisG4L/PqQITJMe+Zi9VyrIozxL08NjoUI+E5qvwNtXmaO zbWydRcUxlPhBJrXHJ7n5ZY3BTPFdnJAs9MrQb7gDJ84ujHC8ZoeZ0oq59t2STnQuaIL sGHQ== X-Gm-Message-State: AOAM531lgjN1+7DMD52bl0yuXBZ6uCRmzhBbY3Vs/mtsXauBHefD2/RT LtyOolsrSbsn9czKhuB87LKKuNCnFUtxAA== X-Google-Smtp-Source: ABdhPJwK0lQ5x2QQLYfUvAx/mfvnRgT9elFZitTp7+mMmR44vYoZC7xYARPHF1sNXqWtzgt7jS+nfQ== X-Received: by 2002:ac2:5b4f:: with SMTP id i15mr9482476lfp.572.1608682865109; Tue, 22 Dec 2020 16:21:05 -0800 (PST) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com. [209.85.167.48]) by smtp.gmail.com with ESMTPSA id 11sm2419986ljf.53.2020.12.22.16.21.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Dec 2020 16:21:04 -0800 (PST) Received: by mail-lf1-f48.google.com with SMTP id a12so36118844lfl.6 for ; Tue, 22 Dec 2020 16:21:03 -0800 (PST) X-Received: by 2002:a05:6512:338f:: with SMTP id h15mr9238858lfg.40.1608682863624; Tue, 22 Dec 2020 16:21:03 -0800 (PST) MIME-Version: 1.0 References: <9E301C7C-882A-4E0F-8D6D-1170E792065A@gmail.com> <1FCC8F93-FF29-44D3-A73A-DF943D056680@gmail.com> <20201221223041.GL6640@xz-x1> In-Reply-To: From: Linus Torvalds Date: Tue, 22 Dec 2020 16:20:47 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect To: Yu Zhao Cc: Andrea Arcangeli , Andy Lutomirski , Peter Xu , Nadav Amit , linux-mm , lkml , Pavel Emelyanov , Mike Kravetz , Mike Rapoport , stable , Minchan Kim , Will Deacon , Peter Zijlstra Content-Type: text/plain; charset="UTF-8" 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: On Tue, Dec 22, 2020 at 3:50 PM Linus Torvalds wrote: > > The rule is that the TLB flush has to be done before the page table > lock is released. I take that back. I guess it's ok as long as the mmap_sem is held for writing. Then the TLB flush can be delayed until just before releasing the mmap_sem. I think. The stale TLB entries still mean that somebody else can write through them in another thread, but as long as anybody who actually unmaps the page (and frees it - think rmap etc) is being careful, mprotect() itself can probably afford to be a bit laissez-faire. So mprotect() itself should be ok, I think, because it takes things for writing. Even with the mmap_sem held for writing, truncate and friends can see the read-only page table entries (because they can look things up using the file i_mmap thing instead), but then they rely on the page table lock and they'll also be careful if they then change that PTE and will force their own TLB flushes. So I think a pending TLB flush outside the page table lock is fine - but once again only if you hold the mmap_sem for writing. Not for reading, because then the page tables need to be synchronized with the TLB so that other readers don't see the not-yet-synchronized state. It once again looks like it's just userfaultfd that would trigger this due to the read-lock on the mmap_sem. And mprotect() itself is fine. Am I missing something? But apparently Nadav sees problems even with that lock changed to a write lock. Navad? Linus