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 6C5C2C001DF for ; Tue, 25 Jul 2023 16:38:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C32296B0071; Tue, 25 Jul 2023 12:38:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BBBD66B0074; Tue, 25 Jul 2023 12:38:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A0EF06B0075; Tue, 25 Jul 2023 12:38:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8FCDC6B0071 for ; Tue, 25 Jul 2023 12:38:12 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 5D986160DF6 for ; Tue, 25 Jul 2023 16:38:12 +0000 (UTC) X-FDA: 81050691624.12.9E20C73 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf16.hostedemail.com (Postfix) with ESMTP id EAF66180008 for ; Tue, 25 Jul 2023 16:38:09 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="U/fqcDuO"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf16.hostedemail.com: domain of mtosatti@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=mtosatti@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690303090; 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=jLj18oLOp3KH/CAHpxuqfsfjyo2yWkCl10MaSaKRkoU=; b=kRFAZnSxKo07a2mGMbEuxe27BjVrgoWMztVSggf/x9OS1YfKJYNq/W6JVFG/xHnopIyfvU gsaEnhNm9zOganCfpgLvk6tpl3izTfNkaEVXRIXeZod+yFQNjr9aJ+qSjBH5L6lnhzQS+5 duQ0c4zEhzvUxpDye18eH12wYqnJOFg= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="U/fqcDuO"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf16.hostedemail.com: domain of mtosatti@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=mtosatti@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690303090; a=rsa-sha256; cv=none; b=xsfD4RZuOyJHyacywscSKjShY8ZtzSpG2/sM3Sh2r4J+dk0+xogLXxzgCfPAnpP4Aq9faG gFg3kTewXxkqNAxHnxSqJTajEmG4lKxCCEjrtJWhKHjIkwIBNbXH4KO1hq74GQ4w+WG/Ii tEX838LtsnmU8dCrlLIIg9Sr8OHRyS8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1690303089; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jLj18oLOp3KH/CAHpxuqfsfjyo2yWkCl10MaSaKRkoU=; b=U/fqcDuO8lxg2fkfbn2c1J5k9PiQxScWbcW/dVQmBVDEToJ7JHCiHdkyt/QkkB90Hh8J+z L6F3F52tDyP/kPEnewgaKp0WKVZvMFxsWqbYpmtMiH01HGYAEtORTgjxdCJSzm1N2HDugf tPKxcohKbeEqs6KHITwY4ctFohuTK3U= Received: from mimecast-mx02.redhat.com (66.187.233.73 [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-500-LzR5megnNuaWxeZbStK90g-1; Tue, 25 Jul 2023 12:38:04 -0400 X-MC-Unique: LzR5megnNuaWxeZbStK90g-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 20F571C07542; Tue, 25 Jul 2023 16:38:02 +0000 (UTC) Received: from tpad.localdomain (ovpn-112-3.gru2.redhat.com [10.97.112.3]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5D55E1121330; Tue, 25 Jul 2023 16:37:59 +0000 (UTC) Received: by tpad.localdomain (Postfix, from userid 1000) id B479B4018E672; Tue, 25 Jul 2023 13:37:32 -0300 (-03) Date: Tue, 25 Jul 2023 13:37:32 -0300 From: Marcelo Tosatti To: Dave Hansen Cc: Valentin Schneider , Nadav Amit , Linux Kernel Mailing List , "linux-trace-kernel@vger.kernel.org" , "linux-doc@vger.kernel.org" , "kvm@vger.kernel.org" , linux-mm , bpf , the arch/x86 maintainers , "rcu@vger.kernel.org" , "linux-kselftest@vger.kernel.org" , Steven Rostedt , Masami Hiramatsu , Jonathan Corbet , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Paolo Bonzini , Wanpeng Li , Vitaly Kuznetsov , Andy Lutomirski , Peter Zijlstra , Frederic Weisbecker , "Paul E. McKenney" , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , Boqun Feng , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , Josh Poimboeuf , Jason Baron , Kees Cook , Sami Tolvanen , Ard Biesheuvel , Nicholas Piggin , Juerg Haefliger , Nicolas Saenz Julienne , "Kirill A. Shutemov" , Dan Carpenter , Chuang Wang , Yang Jihong , Petr Mladek , "Jason A. Donenfeld" , Song Liu , Julian Pidancet , Tom Lendacky , Dionna Glaze , Thomas =?iso-8859-1?Q?Wei=DFschuh?= , Juri Lelli , Daniel Bristot de Oliveira , Yair Podemsky Subject: Re: [RFC PATCH v2 20/20] x86/mm, mm/vmalloc: Defer flush_tlb_kernel_range() targeting NOHZ_FULL CPUs Message-ID: References: <20230720163056.2564824-1-vschneid@redhat.com> <20230720163056.2564824-21-vschneid@redhat.com> <188AEA79-10E6-4DFF-86F4-FE624FD1880F@vmware.com> <2284d0db-f94a-e059-7bd0-bab4f112ed35@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2284d0db-f94a-e059-7bd0-bab4f112ed35@intel.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: EAF66180008 X-Stat-Signature: 9fguwezihftbqz87tfjesonsczpffczo X-Rspam-User: X-HE-Tag: 1690303089-924002 X-HE-Meta: U2FsdGVkX1+WjchFrpcD/Q09pn0+da3Ac4B4zoj4WiVFGCQMQic4jOwcJSwur4hf6+ITGMYpGABxYLjeQUQCyVlbMjhLnTQ/mc3q4mDGIcUv96kP5HkwefajfiJtWyQuv7Jsz/reX3sgsFCBGWQFs5QSOagfOzBM+5PrrMxMjnXkvUjIt5OoS7RnLHt7RswLXOtmCj5Jw5RoULOVWjczmGpAsxGxhjz76UjpN5tWGPq9/08vWu8Jrb7m4VNPmanTL9xMN/BKlsUw8T+RYzTeOmA1ZLNYBu2SDiXV4A1uRZ8eJY4mCmcy8OEftQ2zpj0s/NkdZ29LFeMJLRdTS1N+lPqKLZMnYcH6s1Ll4Q58//mOjKSazr4YPZt9rQvXURF/1VRTV7qD0jQ0Uks4KdWCwwowD2seEXtszLLS0j1GBlVvfyAolPs/fWwPDRrSfiuaUYFe9g5vCrT0jY+tz9y38KjwTbpaPoXFRPuKbEu8CQQAtXTdc5y16jvV7V+pAtY28tkj+dL+lLs48zMnMfIcE6rq0Vh5zxN3XRJCrXTugM5roG+nBZXXTtxJWpVt1HT/W7dB557hc/ejI9E5qOBYh1N1Rf/0wFTPQrCsv9fTqE12836SFXXEK/yWCJcXQWPMZOjn67fc1svtVb4tPccQxtFFuEKN5GmCK3R+x0fkxMw/n0YpkKa4Z3zndV2F4f57XiKzLfQrLw+Yv1FU92veXSLK/5ln1YQ3fRunOKXiJMdyon6TgSP+UQB6fKT7EjjLZMvDgvZzcnawT1N80XGaSkvBMCVoajTGP0yjr3kMHIfbwfHvqwtyfnNAJistkPIqzEY9G1ygj0t+qvxewIUYOsLl0yjMkanPaOBXeau48sdpeJiJeS16bA/YdIm4a6EeMIec1Er5YZ8WBP/VEpUTqdRY+wAJ2eRGB/VKAguGuNJuD5LWJY6HoYJidxwYwoy138oYGzpZHnpkeoYSVuq Cfgwmubd I9vfDQGomug1bTNtPfCnidNb0pg78UmgxYXL+u6aIBbH1WbWvdWGrBZojwT6Cky25D+HMk2SFwiZ0/vVclnqpgx+AIdlryCrcDJVDKZNgaasYC9M2sh7OLY+Yxo5OCU/7Eg1xsNXPcVonQefNI1PnzfDC3riR2Zem2ybZ3zllxhFiZmiLMxUZ2dEJxRnNJmxHNlC/KAFAFnTsKFZc7vK/7gkrXDJdzIaSyjKQgrJucgGRGcmX9GTQ5GWRMH4LjxtowctBAnIKKw9yX9njZzj1QvmcjQPdquM+Bt72jtxucgUfVehrpDSm7UsD1y49wl2XilMw 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 Mon, Jul 24, 2023 at 10:40:04AM -0700, Dave Hansen wrote: > On 7/24/23 04:32, Valentin Schneider wrote: > > AFAICT the only reasonable way to go about the deferral is to prove that no > > such access happens before the deferred @operation is done. We got to prove > > that for sync_core() deferral, cf. PATCH 18. > > > > I'd like to reason about it for deferring vunmap TLB flushes: > > > > What addresses in VMAP range, other than the stack, can early entry code > > access? Yes, the ranges can be checked at runtime, but is there any chance > > of figuring this out e.g. at build-time? > > Nadav was touching on a very important point: TLB flushes for addresses > are relatively easy to defer. You just need to ensure that the CPU > deferring the flush does an actual flush before it might architecturally > consume the contents of the flushed entry. > > TLB flushes for freed page tables are another game entirely. The CPU is > free to cache any part of the paging hierarchy it wants at any time. Depend on CONFIG_PAGE_TABLE_ISOLATION=y, which flushes TLB (and page table caches) on user->kernel and kernel->user context switches ? So freeing a kernel pagetable page does not require interrupting a CPU which is in userspace (therefore does not have visibility into kernel pagetables). > It's also free to set accessed and dirty bits at any time, even for > instructions that may never execute architecturally. > > That basically means that if you have *ANY* freed page table page > *ANYWHERE* in the page table hierarchy of any CPU at any time ... you're > screwed. > > There's no reasoning about accesses or ordering. As soon as the CPU > does *anything*, it's out to get you. > > You're going to need to do something a lot more radical to deal with > free page table pages.