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 E7EDDFA3740 for ; Thu, 27 Oct 2022 19:43:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 75C786B0071; Thu, 27 Oct 2022 15:43:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 70D416B0073; Thu, 27 Oct 2022 15:43:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D4A36B0074; Thu, 27 Oct 2022 15:43:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4ED216B0071 for ; Thu, 27 Oct 2022 15:43:21 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id DFDDF1207E7 for ; Thu, 27 Oct 2022 19:43:20 +0000 (UTC) X-FDA: 80067753360.25.BF5E940 Received: from mail-qv1-f53.google.com (mail-qv1-f53.google.com [209.85.219.53]) by imf20.hostedemail.com (Postfix) with ESMTP id 7750E1C0013 for ; Thu, 27 Oct 2022 19:43:20 +0000 (UTC) Received: by mail-qv1-f53.google.com with SMTP id ml12so2395711qvb.0 for ; Thu, 27 Oct 2022 12:43:20 -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=u5WV0fN4ArkrzknOWlVXairTOGe+oE0SgEdnrwAT0fQ=; b=PgC9fn7D8Pv3QW3LbTscPthfBT03SvxrZhga/+9qUt92e4hANFEMmShtrwv+hZmOkD c+x6P5DXf49yiOOlImuPHVf51/ucyxNwZcAqMuLweZiWm9eBv566KvERROVEAOknj5uP xWIcpidBKZW02pfeL6mmtPCiWD0jzIW6ZS7ME= 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=u5WV0fN4ArkrzknOWlVXairTOGe+oE0SgEdnrwAT0fQ=; b=1Nn/RC9nRqf2JWuWECvB7Lejt52JGfDOpwWFNFRLSgA3vO3VeQGvi0GMceNcHoSekr 99aa9qKNX3b1o4Ed6goWgf2RCMmt+ITga4+9DP6UCh+cgYVr6IxthksIBNsawTjK2t/U Wk55zo4ksxe/AaA1z2nMC4b4UjHJiC8JlHCXRcyjZhakHoBShQRTAChn7zEYKdueUfBR oCmoukdbYkaW40J5i0FJCEJoWeEP35F2I+MR6D9SGoepgfSQSK4YeFSIvlQ5bQZvrHIW LKGi/yEnaQwS7IGwUrtKN4+zK3/TknbH8KClw9QLZpyGcCMOhG0fFM7q6pAImiwXgSFK GT4Q== X-Gm-Message-State: ACrzQf2OGscV+4re4PUW1d1pwRPEfSBqJd21x+l1uS42JrlKQ95fa1vv y8JXPNuWyh0VJ6eNfTBqOFfbfeJA4XagiA== X-Google-Smtp-Source: AMsMyM6HheZ+M8WJgt2oKqSBZjWdY9Acb5Yy8n9TqK/VqfKJ6gFE9aU/1wI9WPo9eYmW4L2G9J3fvA== X-Received: by 2002:a0c:e2c8:0:b0:4b7:c1bf:784a with SMTP id t8-20020a0ce2c8000000b004b7c1bf784amr35509458qvl.17.1666899799326; Thu, 27 Oct 2022 12:43:19 -0700 (PDT) Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com. [209.85.128.170]) by smtp.gmail.com with ESMTPSA id bs11-20020a05620a470b00b006f84ee3a4f3sm1573170qkb.48.2022.10.27.12.43.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Oct 2022 12:43:17 -0700 (PDT) Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-367cd2807f2so26811517b3.1 for ; Thu, 27 Oct 2022 12:43:17 -0700 (PDT) X-Received: by 2002:a81:11d0:0:b0:35b:dd9f:5358 with SMTP id 199-20020a8111d0000000b0035bdd9f5358mr46239372ywr.401.1666899797074; Thu, 27 Oct 2022 12:43:17 -0700 (PDT) MIME-Version: 1.0 References: <20221022114424.515572025@infradead.org> <2c800ed1-d17a-def4-39e1-09281ee78d05@nvidia.com> In-Reply-To: From: Linus Torvalds Date: Thu, 27 Oct 2022 12:43:01 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 01/13] mm: Update ptep_get_lockless()s comment To: Peter Zijlstra Cc: Jann Horn , John Hubbard , x86@kernel.org, willy@infradead.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, aarcange@redhat.com, kirill.shutemov@linux.intel.com, jroedel@suse.de, ubizjak@gmail.com Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666899800; 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=u5WV0fN4ArkrzknOWlVXairTOGe+oE0SgEdnrwAT0fQ=; b=XE05MDgung8oaBnU4T9/CUeutwyMoia4ra+ythd3vEuD6NvlMVFFPazxfr/qe3ADJ/9ryb kWYwWd1doTVMUoo+FyCt/TkVAx/2eOV4+KfYbFoQK46XfzvmhLeGdOo7jKCt3PbdCxeueK SRcPIHSghSeso6kpVYvEDXYhR8KLAUY= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=PgC9fn7D; spf=pass (imf20.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.219.53 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666899800; a=rsa-sha256; cv=none; b=vzCCHfhCZyvn3eeWxQ+f6SO/E502c1M6Ij3+HES9b0K4Y93uo9oDCEKs0yBF7rUu/VhoQa yZgLa4UUZ1Wiea5IjCh/79cKaDfwwXZqtKCARvkYT01kgEITX+/MMPoieWwh2p35qxnywM 9Z+y+nLjBYtlUM0MPJo0CrqiqO3qAf0= X-Stat-Signature: fqparcsooar9o8gd4aaj3iuftbz8kehr X-Rspamd-Queue-Id: 7750E1C0013 Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=PgC9fn7D; spf=pass (imf20.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.219.53 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1666899800-808768 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 Thu, Oct 27, 2022 at 12:35 PM Peter Zijlstra wrote: > > On Thu, Oct 27, 2022 at 11:13:55AM -0700, Linus Torvalds wrote: > > > But "fullmm" is probably even stronger than "mmap write-lock" in that > > it should also mean "no other CPU can be actively using this" - either > > for hardware page table walking, or for GUP. > > IIRC fullmm is really: this is the last user and we're taking the whole > mm down -- IOW exit(). Yes. But that doesn't mean that it's entirely "just ours" - vmscan can still see the entries due to rmap, I think. So there can still be some concurrency concerns, but it's limited. > Do we worry about CPU errata where things go side-ways if multiple CPUs > have inconsistent TLB state? Yeah, we should definitely worry about those, since I think they have been known to cause machine checks etc, which then crashes the machine because the machine check architecture is broken garbage. "User gets the odd memory ordering they asked for" is different from "user can crash machine because of bad machine check architecture" ;) That said, I don't think this is a real worry here. Because if I recall the errata correctly, they are not about "different TLB contents", but "different cacheability for the same physical page". Because different TLB contents are normal and even expected, I think. Things like kmap_local etc already end up doing some lazy TLB flushing. No? I think it's only "somebody did an UC access to a cacheline I have" that ends up being bad. Note the *WILD HANDWAVING* above - I didn't actually look up the errata. The above is from my dim memories of the issues we had, and I might just be wrong. Linus