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 7A7B0C021AA for ; Wed, 19 Feb 2025 15:13:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D1CDE440169; Wed, 19 Feb 2025 10:13:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CCC3F440156; Wed, 19 Feb 2025 10:13:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF8B8440169; Wed, 19 Feb 2025 10:13:11 -0500 (EST) 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 93509440156 for ; Wed, 19 Feb 2025 10:13:11 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 6795A442B1 for ; Wed, 19 Feb 2025 15:13:09 +0000 (UTC) X-FDA: 83137037298.05.3226E29 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf22.hostedemail.com (Postfix) with ESMTP id 2BB8CC0019 for ; Wed, 19 Feb 2025 15:13:07 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GW9GPyek; spf=pass (imf22.hostedemail.com: domain of vschneid@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=vschneid@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739977987; 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=YEDFkhBYjRhP5Z93Fy/FXNH8qcO0tYdixMhBiEsACWQ=; b=Soq0j+rGq+hR39faaV7zvID7t7f6jnxoS9Zv2v/N4JsNcsZ1PBeurqvj3s3wpjOQ45vdnG i0BFdByd51LqVWPeJdpi2Q88rJNkWkQ+FtC2BuQra030w9xCGtIjhU4L7VT39NvVqSyKCr 4BUfqdIcs3NX5hPVgfDN0Xwrbt53YDw= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GW9GPyek; spf=pass (imf22.hostedemail.com: domain of vschneid@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=vschneid@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739977987; a=rsa-sha256; cv=none; b=l4M0JLHaWF5uLXujmAgnHZr40KimM2EGltrq4YwhTxZgF4Sidy0I8iybSJ+IKwbNb9rNb3 fXsuyklILPn3FBu8ApjAEO7c/04Pkcqh1TUl/GXYPd29yUR81M6V1olMJ8v0ivP1Ujdp+9 oHPsHAcHwZ1CiIJRZo9KxtV8+yACX5Y= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1739977986; 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=YEDFkhBYjRhP5Z93Fy/FXNH8qcO0tYdixMhBiEsACWQ=; b=GW9GPyekQTHonsiuL57zD47+u+pvv3Zl7lMu41Z4O6mg0ReVmlHevyBl3eQBcru2N3jwZu k9R27JRRiNS53QWSMhSBaGNB9Ms8uh7mZTmLrVdVRZfz0VvxIJoPta3YcWzLr6/O0bp4GK 9E3HzKLwpohKweKhoeD8s1HfvoR3VBA= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-128-txClnr91PZaxBFO1dUr59w-1; Wed, 19 Feb 2025 10:13:05 -0500 X-MC-Unique: txClnr91PZaxBFO1dUr59w-1 X-Mimecast-MFC-AGG-ID: txClnr91PZaxBFO1dUr59w_1739977984 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-4394c747c72so34917535e9.1 for ; Wed, 19 Feb 2025 07:13:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739977984; x=1740582784; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YEDFkhBYjRhP5Z93Fy/FXNH8qcO0tYdixMhBiEsACWQ=; b=tRp0jQGtaFbmwCKlCYptKqPs8pICQ07P2jcvnqXoiUH0aCnuNubPEafuWLvQ9ylF3I uPYqrBjIk/j/SR2FNohg10ca8fYq02jjQ5hDHbD816Xur8HEquqZAMfSlFlak9lcJqek /gA1fqyOKsOYTlYWGDstLWDKrohmVT+dv2N/37AvndbZo6ByzryvfX6bAt75+XK6H7JH CCKXodLZE3+fc72aF+jYpYY8mcs0RxN6fS1ThXZ9BLVZ0a9DMFJ4Vpva2x5QxcGBDaUH nnha4MEPKAW0xE5vTLJtc5Uqn20siWQBTi1lDuiiM7Oo0ml+UNQhU+DhGwu0imWhHCkO ky6g== X-Forwarded-Encrypted: i=1; AJvYcCVnid8OLUfpHgkXMlesEHSKnrHgEv0rrkakKAvc8n1tfOm5acivXc9egr6BMxIySqIcbuKjhQT+eQ==@kvack.org X-Gm-Message-State: AOJu0YznD5Sjg+FWAzqz3u7ZX/knjgLmTyKa0xKYc2Rj97Obz16A/VUt 2XwoULM02gFMPGq+dqGYdoy9CUZifpTHbr0slBIH/vku1xgxd7aYOZ8CdeqEudODyCUGChSgqZw Ws529sg2MQ2T/Zu4bVyBaa8mJ153msVPvIC8y+83DzLj8KExP X-Gm-Gg: ASbGncucKB9ksNYO1NjjjGJ0AVaH7TzssU6po6LL7ExrIYXaTF8bkv9Ajf6VoZqAApj hIl80/f3sxGPbffBH0AkWmpD04vK9Nli/dUcpZ2Wpj1ffCCLz7jG01suTfwrnumONRkRZH9f9KQ S1PV4N29jLVJvoc8DWp+NYhPTFc+gMkGFLrGqQ7pBWrBemECisPLNKp8rhbS6mKpZS2HmvcGUOz DhHFOJ1gnBXsN8uOF8wO2U1exXoGm1b4X4+El3JwGgFnNuXTwLBa3+34jI44X/+AaJSC+hQQrQi EYIdsPURiDldLqvlJrXepNmsYLwTJyJvf+Jwz19aL8ACHYIHQa/KLNC2qMhqPlzv6g== X-Received: by 2002:a05:600c:3d0b:b0:439:88bb:d02d with SMTP id 5b1f17b1804b1-43988bbd322mr97618975e9.2.1739977984073; Wed, 19 Feb 2025 07:13:04 -0800 (PST) X-Google-Smtp-Source: AGHT+IHqXB0SvUjV4zwF8A6smqwc0vRSLTkn6r2mJurV/wBBuDlOIkQeOJi/olfCVvoVfIVGXKI8cw== X-Received: by 2002:a05:600c:3d0b:b0:439:88bb:d02d with SMTP id 5b1f17b1804b1-43988bbd322mr97618455e9.2.1739977983617; Wed, 19 Feb 2025 07:13:03 -0800 (PST) Received: from vschneid-thinkpadt14sgen2i.remote.csb (213-44-141-166.abo.bbox.fr. [213.44.141.166]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-439858ec5fasm88121225e9.29.2025.02.19.07.13.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Feb 2025 07:13:02 -0800 (PST) From: Valentin Schneider To: Dave Hansen , Jann Horn Cc: linux-kernel@vger.kernel.org, x86@kernel.org, virtualization@lists.linux.dev, linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, linux-perf-users@vger.kernel.org, xen-devel@lists.xenproject.org, kvm@vger.kernel.org, linux-arch@vger.kernel.org, rcu@vger.kernel.org, linux-hardening@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, bpf@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com, Juergen Gross , Ajay Kaher , Alexey Makhalov , Russell King , Catalin Marinas , Will Deacon , Huacai Chen , WANG Xuerui , Paul Walmsley , Palmer Dabbelt , Albert Ou , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Peter Zijlstra , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , "Liang, Kan" , Boris Ostrovsky , Josh Poimboeuf , Pawan Gupta , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Arnd Bergmann , Frederic Weisbecker , "Paul E. McKenney" , Jason Baron , Steven Rostedt , Ard Biesheuvel , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , Boqun Feng , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juri Lelli , Clark Williams , Yair Podemsky , Tomas Glozar , Vincent Guittot , Dietmar Eggemann , Ben Segall , Mel Gorman , Kees Cook , Andrew Morton , Christoph Hellwig , Shuah Khan , Sami Tolvanen , Miguel Ojeda , Alice Ryhl , "Mike Rapoport (Microsoft)" , Samuel Holland , Rong Xu , Nicolas Saenz Julienne , Geert Uytterhoeven , Yosry Ahmed , "Kirill A. Shutemov" , "Masami Hiramatsu (Google)" , Jinghao Jia , Luis Chamberlain , Randy Dunlap , Tiezhu Yang Subject: Re: [PATCH v4 29/30] x86/mm, mm/vmalloc: Defer flush_tlb_kernel_range() targeting NOHZ_FULL CPUs In-Reply-To: References: <20250114175143.81438-1-vschneid@redhat.com> <20250114175143.81438-30-vschneid@redhat.com> <352317e3-c7dc-43b4-b4cb-9644489318d0@intel.com> Date: Wed, 19 Feb 2025 16:13:00 +0100 Message-ID: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Mjq3FsuVFnCvPesTKS3wg3_ixSSrGU2M_77lJj0bQNg_1739977984 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 2BB8CC0019 X-Stat-Signature: 1ft3szjt9ofryyaqzbmw89kqwxwu8mqk X-Rspam-User: X-HE-Tag: 1739977987-740433 X-HE-Meta: U2FsdGVkX189zdS3z3X1kBEc9vNx/3X79HfqjCRo0zxEFcOfdUslqafLit1T46hEmbGDnhzLHcPE6Z6+2p5dROZ/jefFbp027Sr1loJyJzK+4mYeD/yo2re50LF8jXMrEady9IruhChiPl27o2Nv49EO4o3+nujPWbDS2T7ozYtVDP/ryGv0ZNtbDHHZOwv51stgBlX7gBCO9TyP95Yudbf7QQ0d9zv2N20nq23O/gUwh+o7VDhYSlX/0xfUmpCtwgGKB+bLeW2RdKeB4iD/feo6vbHOlBZF2jnHzWJECAmvdOcsCa+glwg1QAI8cQiu64OVQNDeUDMQM6bIdSWnR+ppeBTVXp2l4mCJ0x5YS0atXCZAxBzCcDr6c2P6rXSObL7qFOaBVJDZoXdoxHKHpLgIyRcLHbdsaLpygxBiWDzvZjkGZ0IsX+CoGrbDCykXh7dlYNeoYdIVZ4Ds0jltix81m7kW3usJLID3uFmNqGaTwGie/TJVqVADE2hyCQ2LeNY2npJvj1up1HISEZMRQCUyZVWFjVU80N5g50Azl5lvGxaXGEW2lZx2qAwctSLmhBRQwvaXU7KidzOmLEleidGSQXBNVZ2gzuuw2HzqxSudpTnjwz2ffMYWpDBrkQU/7XbFG6TZlWCaH9y87LNgXKAPUHbhZLjYEDgkyrkw1jAaQUxX1dmAQ0JwtPkFbxPcWDKWOieqooTHc4YOiDr+nYysGnzhW6RB4y/hkemghURN/mavE/wccHFgMTiA/DE8cU4sgJnPZ2z62RFkhK8xhw1HRNSnE9ayFfZ2YEyPy7jn0i1HsNkLxiIxp8Ph/A3SA2nXb7QTUpN/VZemep1Cb+j9TNGFb9XIVI5LlUSCY0ec+LmJrhx4WNd4NUhXQSZS1YYqphWSIeabXyI/L2VniodAzTQ+6O4OGQRgfSA4w3UZ1wF09+bOG14u1mzG5DOp4ho88dL6ImgdFsgEddx tQchITAO 4sUu5BC3BJxmWdNigdWtMRGIlkx5P957vCdS/aLL7YtWbm56kj5bN1gorTLPgMmexUvu2YNcZgbChNLDaBss/R8DKn1bVkRzdi2N49I+OKCZy6BW449IEJslKyhpJ8Jhwse0NlbK71OBvNqpi8GT35G//NW3pKpWx9Q0bDY7ORRXGUYIYo+4JqVxm7C6tR/c1Yg2Zu24AXe5knA9eOslhCOkWK5648aZNHyXGVvEYU0E/3pv2OrONqWgkO/3VPFJGw+YOXQ/NQtaYp0q+AaCaPD4LB3etedvUt8FLE70ZRwNc6nRKE1aYS7ZGtV4Y+9CMoYejEwiubn3k+HcYKsnaKedCg/SzBCO4deL1RX6aOTe5jjsSuw07qVwdM+buri4lW2HvH8o6oBAACWr8HvM+WkjF6XohVEsYs11ejBOZ2HUY7uY= 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: List-Subscribe: List-Unsubscribe: On 18/02/25 16:39, Dave Hansen wrote: > On 2/18/25 14:40, Valentin Schneider wrote: >>> In practice, it's mostly limited like that. >>> >>> Architecturally, there are no promises from the CPU. It is within its >>> rights to cache anything from the page tables at any time. If it's in >>> the CR3 tree, it's fair game. >>> >> So what if the VMEMMAP range *isn't* in the CR3 tree when a CPU is >> executing in userspace? >> >> AIUI that's the case with kPTI - the remaining kernel pages should mostly >> be .entry.text and cpu_entry_area, at least for x86. > > Having part of VMEMMAP not in the CR3 tree should be harmless while > running userspace. VMEMMAP is a purely software structure; the hardware > doesn't do implicit supervisor accesses to it. It's also not needed in > super early entry. > > Maybe I missed part of the discussion though. Is VMEMMAP your only > concern? I would have guessed that the more generic vmalloc() > functionality would be harder to pin down. Urgh, that'll teach me to send emails that late - I did indeed mean the vmalloc() range, not at all VMEMMAP. IIUC *neither* are present in the user kPTI page table and AFAICT the page table swap is done before the actual vmap'd stack (CONFIG_VMAP_STACK=y) gets used.