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 45E1EC433FE for ; Sat, 29 Oct 2022 20:30:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 847A16B0071; Sat, 29 Oct 2022 16:30:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D0DD6B0073; Sat, 29 Oct 2022 16:30:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 671978E0001; Sat, 29 Oct 2022 16:30:47 -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 54A186B0071 for ; Sat, 29 Oct 2022 16:30:47 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 0ADF1AAFDD for ; Sat, 29 Oct 2022 20:30:47 +0000 (UTC) X-FDA: 80075130534.10.DEC0CA4 Received: from mail-qv1-f47.google.com (mail-qv1-f47.google.com [209.85.219.47]) by imf27.hostedemail.com (Postfix) with ESMTP id AD50540012 for ; Sat, 29 Oct 2022 20:30:46 +0000 (UTC) Received: by mail-qv1-f47.google.com with SMTP id n18so6191985qvt.11 for ; Sat, 29 Oct 2022 13:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=AmPkk/DwkArLkWG5uoQkbZX2DU9/t0yTo8MPrUCBXeE=; b=DTMdWthi0PzdcOxcA7HO6DkSTx4W8h7SUpNTilK0z2bhHHDm5W40mC8SedyFcIZa0m EWBya40YPPeIKchNdZ/NIjMjaH3d41HJTYxR9a0ReYdjqKJoxJsrOGHgbmBt1XgmrbAy D5vqQwwujljecpRMD04eiq0r/eTLg+xfKLqK4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=AmPkk/DwkArLkWG5uoQkbZX2DU9/t0yTo8MPrUCBXeE=; b=R/VN7sv12hD3MVprOdSNghcdfQIZa8yO0asFANRX57/xJUPjIlSYfZ0+jZVLex11d6 DDdivOEuyyxGDVsT1bhsgVTEb+z6gRCU/2ElrrfveIzEvY/huKw2G6IKG3kvanohgaVR F5/lvVTdEOBbxmapIXd6PZfWVJwD3QNzrPiS72klf30bO/64H74px2a9tUcGX+ApoKOp hjXKb+IVrGNMpHU7TqciJ0z4GxBbgwjSAMeaacEtrzC9G/WT3KEDq3SBu2BPKBpfCT/q Iz2014tdWweShE2uz75yyPwKdZj2WlGUZTTWuJfIY4wQt+anoT3iDVZQsesqZkXt7d4d vULA== X-Gm-Message-State: ACrzQf37pKqpDUvQpuEpatzEh/MEX/z0UlGLrswpRKccq2u4NgzM1xVj Gr0ffafl4pT6p5u0F7urh3NC8AmAjdq0zA== X-Google-Smtp-Source: AMsMyM5ZjC716kdSXIsl2cDWUikxFvSNfuLKpQZt+vVJcFfYoMB6i0wxQB+P3/DWJzM6R6bYi39JcQ== X-Received: by 2002:ad4:5bc1:0:b0:4ad:34b2:d29c with SMTP id t1-20020ad45bc1000000b004ad34b2d29cmr4940980qvt.21.1667075445721; Sat, 29 Oct 2022 13:30:45 -0700 (PDT) Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com. [209.85.219.182]) by smtp.gmail.com with ESMTPSA id m22-20020a05620a291600b006f926a0572asm1688428qkp.27.2022.10.29.13.30.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 29 Oct 2022 13:30:43 -0700 (PDT) Received: by mail-yb1-f182.google.com with SMTP id 187so9741985ybe.1 for ; Sat, 29 Oct 2022 13:30:43 -0700 (PDT) X-Received: by 2002:a05:6902:124f:b0:66e:e3da:487e with SMTP id t15-20020a056902124f00b0066ee3da487emr5680132ybu.310.1667075442955; Sat, 29 Oct 2022 13:30:42 -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 13:30:26 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 01/13] mm: Update ptep_get_lockless()s comment To: John Hubbard Cc: Nadav Amit , 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" ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=DTMdWthi; spf=pass (imf27.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.219.47 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667075446; a=rsa-sha256; cv=none; b=Kyok8LvnvjsiFiB6QHbPGSYrhoo+rVzrD8OmlQPXSy+TS6y1V+LHFT20X1fB8inLgVfGlV o5bPkr+sDMjs/uog24z8islDkyvfSSQpe3OREijOkCk6G3erRmUgh9VtarpC4KKmXBm6WW x2y0L+5TOhXM9D9KtEDHUgLYaMFKkeg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667075446; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=AmPkk/DwkArLkWG5uoQkbZX2DU9/t0yTo8MPrUCBXeE=; b=p4R9awhUErRdML+OB8DK8d9x+hi6Kfhx3TluUmotjDbKcZzsEy/z4DalrNe163BiTAWYGc QhyKKDnqn2BM4TWKd17N1uwq6dEwr907Nuyjz1fRNzPg7WzPystOjfgZ04YSkL/Fzd+gw8 PFuCYZXlXZ5mk9H6NuxlGMq5LYdQK/4= X-Rspam-User: X-Rspamd-Queue-Id: AD50540012 Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=DTMdWthi; spf=pass (imf27.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.219.47 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Stat-Signature: 6mjjihepcyrq8e61r4e3jsbuczct4e7f X-Rspamd-Server: rspam10 X-HE-Tag: 1667075446-415694 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:15 PM Linus Torvalds wrote: > > I can think of three options: > > (a) filesystems just deal with it > > (b) we could move the "page_remove_rmap()" into the "flush-and-free" path too > > (c) we could actually add a spinlock (hashed on the page?) for this > > I think (a) is basically our current expectation. Side note: anybody doing gup + set_page_dirty() won't be fixed by b/c anyway, so I think (a) is basically the only thing. And that's true even if you do a page pinning gup, since the source of the gup may be actively unmapped after the gup. So a filesystem that thinks that only write, or a rmap-accessible mmap can turn the page dirty really seems to be fundamentally broken. And I think that has always been the case, it's just that filesystem writers may not have been happy with it, and may not have had test-cases for it. It's not surprising that the filesystem people then try to blame users. Linus