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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id F2FF6C38A02 for ; Sat, 29 Oct 2022 21:12:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6A05D6B0075; Sat, 29 Oct 2022 17:12:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 650386B0078; Sat, 29 Oct 2022 17:12:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5185E8E0002; Sat, 29 Oct 2022 17:12:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 440306B0075 for ; Sat, 29 Oct 2022 17:12:36 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 18723C068F for ; Sat, 29 Oct 2022 21:12:36 +0000 (UTC) X-FDA: 80075235912.16.63D2691 Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by imf30.hostedemail.com (Postfix) with ESMTP id BE5068000B for ; Sat, 29 Oct 2022 21:12:35 +0000 (UTC) Received: by mail-qt1-f179.google.com with SMTP id c23so5489226qtw.8 for ; Sat, 29 Oct 2022 14:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ETLKPxqsaGal116jans0YIcCD8eWvXgEySs7gsIGlTM=; b=b5x6oR4FXTWYPUc99zNzOcMHWWo3ItbOwAwf5GbuPqbyB1Eqo7uDya7OFTrl2yOVqJ +lmCdLemihCs18tijDGR3C4GbKAsmQe+VZrVW21/hfaBLzgFm3ux7f5Z/+CBvC5Yt/EN /tOuOnWSkaTKDnGdFqcTNc7EHxP5eGtM3HIPM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ETLKPxqsaGal116jans0YIcCD8eWvXgEySs7gsIGlTM=; b=HWVV0niMjunTUhOLUE3sVl5QIxB1RLetFUCYz1Hg7wSEMsNh9HeO1cyUA4FBmyq9mZ Go+5ugWtMKhJTYFu6kopWY+k2wLU9cEiJFvmwPQDza6Rtqf6j8KWVh3XhHWCH73R/h7R Tgr4xLtqeW9G1eRe3K+0nTkwG7mCrD2a/ECnZ/go8jwPlkMqsGi22308qCztq2r1/Xlk TWApas+uO9kX1XLac4Po32sb/7p1Z9qCb7TGt3eHHodWzmihIYMgcfXMO1aHs62A+OZY euwPjjqOM3BK/MOCLzyRJ+bFokYNeRXLP02mqzObAs+Iv2gvbvOH8poN0FGHz1sQy+5t dDug== X-Gm-Message-State: ACrzQf28mzUUqAH1/jsAwcLPzM1RrriBUTJ9kVke2/m/Qgg0nCbOsAet D9IEWtbzEbC0jmg18gkQ6wSypw2GmqrkEw== X-Google-Smtp-Source: AMsMyM4WbVFR1Ie5DLPONtGD4rOI1zWiOxBCWhqpbe1DwEwSi+zeKa8cQJmAipSd5A/npjlpnQV2Sg== X-Received: by 2002:ac8:58d2:0:b0:39d:ac0:b5da with SMTP id u18-20020ac858d2000000b0039d0ac0b5damr4805712qta.631.1667077954726; Sat, 29 Oct 2022 14:12:34 -0700 (PDT) Received: from mail-yw1-f174.google.com (mail-yw1-f174.google.com. [209.85.128.174]) by smtp.gmail.com with ESMTPSA id s13-20020a05620a254d00b006cf8fc6e922sm1688338qko.119.2022.10.29.14.12.32 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 29 Oct 2022 14:12:32 -0700 (PDT) Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-36cbcda2157so76457797b3.11 for ; Sat, 29 Oct 2022 14:12:32 -0700 (PDT) X-Received: by 2002:a0d:fe07:0:b0:360:c3e9:fc8a with SMTP id o7-20020a0dfe07000000b00360c3e9fc8amr5619835ywf.441.1667077952153; Sat, 29 Oct 2022 14:12:32 -0700 (PDT) MIME-Version: 1.0 References: <20221022111403.531902164@infradead.org> <2c800ed1-d17a-def4-39e1-09281ee78d05@nvidia.com> <6C548A9A-3AF3-4EC1-B1E5-47A7FFBEB761@gmail.com> <47678198-C502-47E1-B7C8-8A12352CDA95@gmail.com> <3a57cfc5-5db4-bdc9-1ddf-5305a37ffa62@nvidia.com> In-Reply-To: From: Linus Torvalds Date: Sat, 29 Oct 2022 14:12:15 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 01/13] mm: Update ptep_get_lockless()s comment To: Nadav Amit Cc: John Hubbard , Peter Zijlstra , Jann Horn , X86 ML , Matthew Wilcox , Andrew Morton , kernel list , Linux-MM , Andrea Arcangeli , "Kirill A . Shutemov" , jroedel@suse.de, ubizjak@gmail.com, Alistair Popple Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=b5x6oR4F; spf=pass (imf30.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.160.179 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667077955; a=rsa-sha256; cv=none; b=YDY+JqvtyW+hZORkMLf8bDCWqdOCfhPTplK9duM1+SO7tcCmfvhEySS1bk+RpQlGIVDA0R c6AKQybKvwryj6k8tOMCHSwL/RYhAzDz/a9AZ1qAj10T+6uD80jh30F87fj72dEb3888D6 Wqz4pETxTc3zj6kIsjWV1Wp03l1/y8c= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667077955; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ETLKPxqsaGal116jans0YIcCD8eWvXgEySs7gsIGlTM=; b=HAJAaEgQK77hpQd+RnrT9dIox/FZV+3i7ZXoC9yM0TEAVbfAuTCW0L46Di6R894o6vzRUP LaPx9dYjkxFLEpyqbe6+TRuXgIJv2RGc6OAkSZI5/jpmBtDWqwBlQqDV0A0SRSzw04EMbO 6Uyc0D5/BfSVYxU6B7PKWe9JlgCs1IY= X-Rspam-User: X-Rspamd-Queue-Id: BE5068000B Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=b5x6oR4F; spf=pass (imf30.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.160.179 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Stat-Signature: wbsf365orzaqsofbb5bu3f4nm7j4bnay X-Rspamd-Server: rspam10 X-HE-Tag: 1667077955-175319 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 Sat, Oct 29, 2022 at 1:56 PM Nadav Amit wrote: > > On Oct 29, 2022, at 1:15 PM, Linus Torvalds wrote: > > > (b) we could move the "page_remove_rmap()" into the "flush-and-free" pa= th too > > > > And (b) would be fairly easy - same model as that dirty bit patch, > > just a 'do page_remove_rmap too' - except page_remove_rmap() wants the > > vma as well (and we delay the TLB flush over multiple vma's, so it's > > not just a "save vma in mmu_gather=E2=80=9D). > > (b) sounds reasonable and may potentially allow future performance > improvements (batching, doing stuff without locks). So the thing is, I think (b) makes sense from a TLB flush standpoint, but as mentioned, if filesystems _really_ want to feel in control, none of these locks fundamentally help, because the whole "gup + set_page_dirty()" situation still exists. And that fundamentally does not hold any locks between the lookup and the set_page_dirty(), and fundamentally doesn't stop an rmap from happening in between, so while the zap_page_range() and dirty TLB case case be dealt with that way, you don't actually fix any fundamental issues. Now, neither does my (c) case on its own, but as John Hubbard alluded to, *if* we had some sane serialization for a struct page, maybe that could then be used to at least avoid the issue with "rmap no longer exists", and make the filesystem handling case a bit better. IOW, I really do think that not only is (a) the current solution, it's the *correct* solution. But it is possible that (c) could then be used as a way to make (a) more palatable to filesystems, in that at least then there would be some way to serialize with "set_page_dirty()". But (b) cannot be used for that - because GUP fundamentally breaks that rmap association. It's all nasty. Linus