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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1BB08C433FE for ; Sat, 29 Oct 2022 20:31:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229565AbiJ2Ua4 (ORCPT ); Sat, 29 Oct 2022 16:30:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38664 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229456AbiJ2Uav (ORCPT ); Sat, 29 Oct 2022 16:30:51 -0400 Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3E2E464D9 for ; Sat, 29 Oct 2022 13:30:51 -0700 (PDT) Received: by mail-qv1-xf36.google.com with SMTP id j6so6180437qvn.12 for ; Sat, 29 Oct 2022 13:30:51 -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=duX91RyKYbSYTphTC90ZB9IcFhpolz+VyfU076/AESL9jbKZfKxhXYHyeM0EU5WMg5 xQeZ8mjwKWaMUKBPuHGERg0dWCsBmDeemWsKlfyC4TGKW8ZWZhCUoufJGvuZX4bgA3pK ZYsfXvvN8s3r0VApUs722GBgCHsHkG1UnVqH6hKQ8P/3AdsPBEpcQ8cE/BkXxIMn89Z8 SJv5iNywJA7SwzpRr0sVFfQ1ZOD8ETOZC8qxtyHYGNa+2RfX1vpy6hCrWUzyErb98Mah 45/xO37GqjhZ0o6AzgbSIHgdTZVb4U4MvwnEo5lFMw1I8bPSZe2ean7nom1PuBO9sgeb 30tg== X-Gm-Message-State: ACrzQf2m5PJKt5hSebiXzi69AY7tUE+59iskNt8tIgV0xQcsNfd3BYU+ aT5DRK5VJeQSvQRbN0fozdveIFnUZ0o5zw== X-Google-Smtp-Source: AMsMyM5ZgZH/aZSno7RcVEc+6F8WZSn3n+MBugT0Gljj+6VlZUcYhZpxWxSx7cjYoyLLSffRz2uuqQ== X-Received: by 2002:a0c:dd13:0:b0:4bb:664c:5aaa with SMTP id u19-20020a0cdd13000000b004bb664c5aaamr5008842qvk.121.1667075444827; Sat, 29 Oct 2022 13:30:44 -0700 (PDT) Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com. [209.85.219.171]) by smtp.gmail.com with ESMTPSA id z16-20020ac87cb0000000b0039a372fbaa5sm1258033qtv.69.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-f171.google.com with SMTP id o70so9708798yba.7 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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