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 47970FA3740 for ; Mon, 31 Oct 2022 04:09:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229561AbiJaEJo (ORCPT ); Mon, 31 Oct 2022 00:09:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54848 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229469AbiJaEJm (ORCPT ); Mon, 31 Oct 2022 00:09:42 -0400 Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B67CA7667 for ; Sun, 30 Oct 2022 21:09:41 -0700 (PDT) Received: by mail-pj1-x1035.google.com with SMTP id k5so1798473pjo.5 for ; Sun, 30 Oct 2022 21:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=gWemLfOzUXoCZKBHkTng8WZ7m1m/5k1ivUxEwj3raDw=; b=kvSxwDiwRGtPcK0NvGldR3n/cJLI4rtvSls8Y803ZIffDcgpYmFUOennVFrjSR+u3J uJeN5tgdUCtIIJ11lP3/GP4gRAK4dNRmkdETwsmYn3VoyNW/P7YY0EZPhN5xyVoEjE5t zG6/qbX5r+jcWdOHtC240eNA3eO3L3IU/ZweGSDSOjK2B+caDTZDZ1HQaV51M8A2xmuF d9BLmI776UBq/oRku58KtL+xBAyU2Sa3QSTsRykHT31hPBtEJAgmIWX1wkkh2HJmCNgQ EDLoiKJjrsecu7gchvSewwI8c7Bry14rJGyRyWutxthPncElEUFRse5fSKCQ2zDHHKFz vnrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gWemLfOzUXoCZKBHkTng8WZ7m1m/5k1ivUxEwj3raDw=; b=j48NfvSsTBbSmLE2YOc9EpKtRQGbI13Qh6bTqEahblSGewZOovjUatRkB/lhfTFdsO P0HUAr+9pYkl0Lao2/s0f4w7pai0dt4BJ0Vridx4k9U0eGoA/mYjdZYl5cn7nfZ3FRgM 29rJs3y0hMdTKVYGHDKkGXvZjViike6uI4O/slTCb+2Lk0txxBc2vC+L/UEAU9IRxuzP f7z9RWI4QTB8PwYAFOE2gWRhqNbBfu1jMHpDIAIn0gUAzGTvkbL/E1ulQ/Isty2kzHjM fwpu+DpA0bGZl9VbJIv/8HlgGwsyt8nhqA396L7BzB+WdtYmq+xUlDSwXF16+esgPyIH P0Jg== X-Gm-Message-State: ACrzQf2GsEqp5kU4j0a8yzuG/wHLjgolUOmJFI94N7umrZzCRu9vmhHr RCsumc7cqUg2iCIIVp81pIuS03Mb7tTOiZzAKas= X-Google-Smtp-Source: AMsMyM5jseukbTyVylHrJNbqU0HdAtiHSIZ8m19EEAkcCpum8DbSE3wMN8kEYJ13x8Tpu2js0sjO2Q== X-Received: by 2002:a17:903:11c7:b0:178:af17:e93e with SMTP id q7-20020a17090311c700b00178af17e93emr12238156plh.78.1667189380816; Sun, 30 Oct 2022 21:09:40 -0700 (PDT) Received: from smtpclient.apple (c-24-6-216-183.hsd1.ca.comcast.net. [24.6.216.183]) by smtp.gmail.com with ESMTPSA id n1-20020a170902e54100b00177ff4019d9sm3356279plf.274.2022.10.30.21.09.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Oct 2022 21:09:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [PATCH 01/13] mm: Update ptep_get_lockless()s comment From: Nadav Amit In-Reply-To: Date: Sun, 30 Oct 2022 21:09:37 -0700 Cc: Peter Zijlstra , Jann Horn , John Hubbard , X86 ML , Matthew Wilcox , Andrew Morton , kernel list , Linux-MM , Andrea Arcangeli , "Kirill A . Shutemov" , jroedel@suse.de, ubizjak@gmail.com, Alistair Popple Content-Transfer-Encoding: quoted-printable Message-Id: References: <20221022111403.531902164@infradead.org> <20221022114424.515572025@infradead.org> <2c800ed1-d17a-def4-39e1-09281ee78d05@nvidia.com> <6C548A9A-3AF3-4EC1-B1E5-47A7FFBEB761@gmail.com> <47678198-C502-47E1-B7C8-8A12352CDA95@gmail.com> <140B437E-B994-45B7-8DAC-E9B66885BEEF@gmail.com> To: Linus Torvalds X-Mailer: Apple Mail (2.3696.120.41.1.1) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Oct 30, 2022, at 6:47 PM, Linus Torvalds = wrote: > The reason I haven't actually tested it is partly because I never > recreated the original problem Navav reported, and partly because the > meat of patch 4/4 is just the same "encode an extra flag bit in the > low bit of the page pointer" that I _did_ test, just doing the "remove > rmap" instead of "set dirty". >=20 > In other words, I *think* this should make Nadav's test-case happy, > and avoid the warning he saw. I am sorry for not managing to make it reproducible on your system. The = fact that you did not get the warning that I got means that it is not a hardware-TLB differences issue (at least not only that), but the race = does not happen on your system (assuming you used ext4 on the BRD). Anyhow, I ran the tests with the patches and there are no failures. Thanks for addressing this issue. I understand from the code that you decided to drop the deferring of set_page_dirty(), which could - at least for the munmap case (where mmap_lock is taken for write) - prevent the need for =E2=80=9Cforce_flush=E2= =80=9D and potentially save TLB flushes. I was just wondering whether the reason for that is that you wanted to have small backportable and conservative patches, or whether you changed your mind about it.