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=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 CCD71C433DB for ; Thu, 24 Dec 2020 05:18:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 47680229CA for ; Thu, 24 Dec 2020 05:18:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 47680229CA 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 501A86B00A0; Thu, 24 Dec 2020 00:18:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4B21D8D0072; Thu, 24 Dec 2020 00:18:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 379B48D0063; Thu, 24 Dec 2020 00:18:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0165.hostedemail.com [216.40.44.165]) by kanga.kvack.org (Postfix) with ESMTP id 1D5E76B00A0 for ; Thu, 24 Dec 2020 00:18:16 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id D0FC98249980 for ; Thu, 24 Dec 2020 05:18:15 +0000 (UTC) X-FDA: 77627019750.18.goose47_151023e2746e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin18.hostedemail.com (Postfix) with ESMTP id B008F100ED3B4 for ; Thu, 24 Dec 2020 05:18:15 +0000 (UTC) X-HE-Tag: goose47_151023e2746e X-Filterd-Recvd-Size: 5708 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Thu, 24 Dec 2020 05:18:15 +0000 (UTC) Received: by mail-pl1-f182.google.com with SMTP id y8so775206plp.8 for ; Wed, 23 Dec 2020 21:18:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LA2q2PwXp/daJxufMhCIRE8CL74yxjBvwbFCk0LzEik=; b=S27vCWUkNpeATmyIFjHiO2b6j/+sG4TMwFeBMjcE80wcYzHObbBZgKSD1wz5PCyGDw Wq2chyAEB2LUQnPJ//ywxSkp2Zs2+K+iMV+bITtcIN7VWGvoZqI/H9vhwz8mftkAwV+p MgqCmclPKFTpiwAmulbFLyuQoQKBWXjfGcIEg8jribkP701dcl22GvorZVI8CCg8ZR6d EZAxrbyzqHDNiOr2qUKcm3vixuXYwSdMyeD0J3xADLfyHz6e+SzTi+47TpsW6gffkhe8 pltYbe/+d1KMfvxRbwExfXTL+lwFXSVAeT3+ed9G+NBsR2GZXGJDl5m8COV/9bsHBM37 SzrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LA2q2PwXp/daJxufMhCIRE8CL74yxjBvwbFCk0LzEik=; b=BHx93eC3cP1/rp1y0oo6h2fK7l4/F5RRoAEUkquxfqkCdtWUiWvNdGLz9HPhAfLiwr gdT+bERFm8RALoOfyB8jDKqVfsDXY3mjRcAHQdeolrRxQBYU6vIZb9p83eyzEiwy8TlI mTNTRPohvf4tX0KCH7dhLmalGH7gbpflnzUiU9xNYpaezOx6LTomaD1CBXN4ubftimjM 8d+q4g4UN9eK2wdsuJCnQ441y/2cDvV/PbBUa3TRy7zABPER/lC5RgAhDcmZa+nsIh2q xroky0nbAUhnp1nv7zXVBLh+IkVuABOWpJnfK8rh+0z+LsyamWzNRkzwrgmWzPPqydFG O+jw== X-Gm-Message-State: AOAM531Pz4Uz8wqJ/L7YrEJBMEe2ELsUL3WZYWvyfak3Z0GUP4oggWj/ ZbM82Hk+OxW+2CHM4PBhv7E= X-Google-Smtp-Source: ABdhPJx0VPOZ8gOLOrRuzvAcM5UsMBs0uA932mNpmABuZLTTP4XEpc68Z0U/b5FQeqTIFskS0rMKFQ== X-Received: by 2002:a17:90a:708b:: with SMTP id g11mr2750334pjk.23.1608787094272; Wed, 23 Dec 2020 21:18:14 -0800 (PST) Received: from ?IPv6:2601:647:4700:9b2:50a2:5929:401b:705e? ([2601:647:4700:9b2:50a2:5929:401b:705e]) by smtp.gmail.com with ESMTPSA id 14sm1215361pjm.21.2020.12.23.21.18.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Dec 2020 21:18:12 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect From: Nadav Amit In-Reply-To: Date: Wed, 23 Dec 2020 21:18:09 -0800 Cc: Yu Zhao , Andy Lutomirski , Andy Lutomirski , Linus Torvalds , Peter Xu , linux-mm , lkml , Pavel Emelyanov , Mike Kravetz , Mike Rapoport , stable , Minchan Kim , Will Deacon , Peter Zijlstra Content-Transfer-Encoding: 7bit Message-Id: <06DF7858-1447-4531-9B5C-E20C44F0AF54@gmail.com> References: <3A6A1049-24C6-4B2D-8C59-21B549F742B4@gmail.com> To: Andrea Arcangeli X-Mailer: Apple Mail (2.3608.120.23.2.4) 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 Dec 23, 2020, at 8:01 PM, Andrea Arcangeli wrote: > >> On Wed, Dec 23, 2020 at 07:09:10PM -0800, Nadav Amit wrote: >>> Perhaps holding some small bitmap based on part of the deferred flushed >>> pages (e.g., bits 12-17 of the address or some other kind of a single >>> hash-function bloom-filter) would be more performant to avoid (most) > > The concern here aren't only the page faults having to run the bloom > filter, but how to manage the RAM storage pointed by the bloomfilter > or whatever index into the storage, which would slowdown mprotect. > > Granted that mprotect is slow to begin with, but the idea we can't make > it any slower to make MADV_PAGEOUT or uffd-wp or clear_refs run > faster since it's too important and too frequent in comparison. > > Just to restrict the potential false positive IPI caused by page_count > inevitable inaccuracies to uffd-wp and softdirty runtimes, a simple > check on vm_flags should be enough. Andrea, I am not trying to be argumentative, and I did not think through about an alternative solution. It sounds to me that your proposed solution is correct and would probably be eventually (slightly) more efficient than anything that I can propose. Yet, I do want to explain my position. Reasoning on TLB flushes is hard, as this long thread shows. The question is whether it has to be so hard. In theory, we can only think about architectural considerations - whether a PTE permissions are promoted/demoted and whether the PTE was changed/cleared. Obviously, it is more complex than that. Yet, once you add into the equation various parameters such as the VMA flags or whether a page is locked (which Mel told me was once a consideration), things become much more complicated. If all the logic of TLB flushes had been concentrated in a single point and maintenance of this code did not require thought about users and use-cases, I think things would have been much simpler, at least for me. Regards, Nadav