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 E3A3DC02183 for ; Fri, 17 Jan 2025 16:11:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5747D6B0088; Fri, 17 Jan 2025 11:11:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 500C76B008A; Fri, 17 Jan 2025 11:11:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 32A816B008C; Fri, 17 Jan 2025 11:11:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 11FFB6B0088 for ; Fri, 17 Jan 2025 11:11:42 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8453AA01C7 for ; Fri, 17 Jan 2025 16:11:41 +0000 (UTC) X-FDA: 83017434402.23.6FB650B Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) by imf28.hostedemail.com (Postfix) with ESMTP id 72423C0019 for ; Fri, 17 Jan 2025 16:11:39 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TBmjOSGU; spf=pass (imf28.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.182 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737130299; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Mwf/8xvajfVfuiw0AKepwMJBFKP0lwWuKM/onBPK6d8=; b=dy/FDsHs9bgjgLP8lsEAv4uBWSfqF90jiRg2s0uu+zylwTMlJClytJLMhveU0bdH5bgDh6 HOmwMxvB3ocjOHNmZlbOQn3AvIWdIQ7tnUC1NeJn/6gpBJC1XcSkp73b4CAxFgaR30XaGV XVt3TWC7XsDW1rGaJShSh4W61ekyGzo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737130299; a=rsa-sha256; cv=none; b=mpRThAsl517cHCCbrX867j6wmqQyjeFiDkv5NvSsXZTUSyiz0lQKbYf9TG/IOElVfsQMlU BZP4WaCkwrAcII922l+gK1N4aLtXOYnLDS76VHC3Kz12DH3v52+Rj3TGJYYOwfCnQyJwh0 Z1WHu0vW79DnpPnLl6ecJQMLVU0m4gU= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TBmjOSGU; spf=pass (imf28.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.182 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-30227c56b11so23053041fa.3 for ; Fri, 17 Jan 2025 08:11:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737130297; x=1737735097; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:date:from:from:to :cc:subject:date:message-id:reply-to; bh=Mwf/8xvajfVfuiw0AKepwMJBFKP0lwWuKM/onBPK6d8=; b=TBmjOSGUo40YVDJlKTF0rblJLlBHl+HBBdQlJfU6B0jRz9ACADxQcuYtSAVdIU9Xpy lNmJtmZbNPmD/v6jQmPfUaidkNp/rPU3F8+FPxeKScXHTYn98pexWkmMCbzhVuCFnr8/ PMVyxsIb8X6U0xeakkhxaoDzs6dMEZZdbqkx117qmXM4U/WKa8aewc2LbhaUclxB5GOF UzFwRsg0XY47zfLlYOtvHahG+7dQetLaY3/YUqsIC+XUcWw+YvBJ/R2AqhIjRr0S1pi3 5h2SUquuq2fK3rrUhfLOpgNJijy8N2pFkhnyTy4tyUAxPaHRkjIkOiJj7mNX6yVEDjva SzYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737130297; x=1737735097; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:date:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Mwf/8xvajfVfuiw0AKepwMJBFKP0lwWuKM/onBPK6d8=; b=V1tvE4j245qV+I8DgZ4fUXGXqjkyUUpbA1XPn7oYoK1rAscKVQH/0N489FghR+B2Pr iarMR3dE46B0mMwwWp2DOwyc2dlpv496YhQZpF2BdkX2Jnx0IfvaeH54Is91yrfNq+mr GoICd1tloM6+RwgdBCwq+/0GhIFQvoRv+PgWkLFsCTwugQmQEHFPjj2iuHArU3iBgkBl RpVDzPH1j7FbHjzDhLk5Rogka42jXa/y4Vcp6dj5uUDXfhIu/RVDy1eEfw98C7e70Yoj z2fJGxBGSJynhrzdWP4VlikG1zc9q9yJhtV2g+B0FSyO1UWihCJr+va8E/b68y4bJWU4 nJ/A== X-Forwarded-Encrypted: i=1; AJvYcCWpQLw44pPoSkd8O7UOOOyRjkmq8P3W1CIHVTF8AJLXw/lXYcs0BSq4O1mpmi0aSWWu59b9g4qz5w==@kvack.org X-Gm-Message-State: AOJu0YzS8v/Aq3OaEOfVvq5OrPICANwAq6Tw3qvgVcsvaDNUst2id853 NPRaxw1fpz1g+n7ZE/HQe1TmeRhwdWv9NuYZ4A+/eCPp8kRTg5d7 X-Gm-Gg: ASbGncu9G6P06P/fZjmcOCgWYQJBfU/0u5F52HHQ7XqGOO5tMZjtjKR4NTDZJMg6gcu fKgGJYY1phWo2Qzz6BaD47lsYjv2oIZ8IBustTfoVlKo2Jzzxz24c59YIaC0LCLdCqcEVD0di2N jw6x7GtZoBLflon3sPmDg5ETg01ui3QawMPLNYCsKVYjNg2ijCRYPLYCYADS/qn5arLWnU9Fm5o 4Ya7unHI+L84iMYeF8qdDFzaqP//jB1FElHJRS8zKWl922SiThKsor+ZOWAzKTAeDInwQVr/zOR PByekmLFuKU= X-Google-Smtp-Source: AGHT+IFH9kfhzB42dITXdZg9xXnIuIrCtLCGkWK8kDwmfncKlFAzifmDHoUZVUHtKkW5iC7Zz8oHDA== X-Received: by 2002:a2e:bc27:0:b0:302:40ec:a1b3 with SMTP id 38308e7fff4ca-3072caa166amr12690871fa.21.1737130297134; Fri, 17 Jan 2025 08:11:37 -0800 (PST) Received: from pc636 (host-217-213-93-172.mobileonline.telia.com. [217.213.93.172]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-3072a4ed4bcsm4854351fa.71.2025.01.17.08.11.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Jan 2025 08:11:36 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Fri, 17 Jan 2025 17:11:30 +0100 To: Valentin Schneider Cc: Jann Horn , 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 Message-ID: References: <20250114175143.81438-1-vschneid@redhat.com> <20250114175143.81438-30-vschneid@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 72423C0019 X-Stat-Signature: njwqnz1ka16ntpgci65ebpjodzs5xhep X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1737130299-389714 X-HE-Meta: U2FsdGVkX18w+xnSqouIlL+a1sHOJLxck7Hf517q7kcZSUgXVcEiOhSevoB/UuIo5amUqrwEXXK+BFCMcF53dVjbied3Fk2QFO+CXk5Rb+SsL5asYASSWhZ1K0kRPQLHfUM6U05jI5SWX+Ve+oKB+XefwD8Oh0RGI+OqZr2RV03t8Y/bjGf5HH2JM+ar950Rx0FkmlR/G7UW3Gnrn/rM6dGcDlLj/Ndb3L1nd9oTKi0vFntgXyZtkhzvAM+rvFrUw3QtfvytWsQgQFTLWk8lVsbtpoqTgjNDlbC7ZfpfVJna1nqU3QrVObjjW3S6gYpwBAKzu0H1IRC0WPMTEC0Nt4cTNgwqrmlNO61exeB6xASgCnmmCCvRAhHtRDLm2PF4yrjs6aLUC04K8qVbm3Wg798hUEAWz1HWE7kG1XemHexcZQ5mUWhVuYOz9oWsNKYStj4wAx/ui5mCgScOWOz4dpLIK0E0M4NWiBk8Hzbg7JPmQzwpjrxFxH/w0KGQvg2Hj9vLWcUZIEIn/V/Qc1yPoSNsT/lGXXLpxBpYMje9wrDUoynKmfkIdXV3BZc8dJe+rm6eAyRiyNtfr29sW6OStjnEBDmF11EyYk8ETyrPH9aZDiqe/qQD9of173RdbqbPiMArHCmeY7BlNloxGeJDX+JG52HgxVO/7bt99rMkCQjMsTt4WDE5q5X4Eib9W8Q+dkRM7r1fjdaBrELkdsjj8gOYkTbH8yIVRyrGbwiAHF+7RinJpnT6iLYzWY1a7UmFqr4sH2ThjxgDzC5AqwssBoEPxIOEvXTjnw84jla9lq4QGEw4V1vveCA/+z05dtheAIeMPCRDyXbKSQnVfSk8a+KexN9lLdxTfKQ+M8UcDuz7P+Xhr0Y+92dvrhG/7LLHQl5/XljefnMK+J+psSOKnedB3y2F77rb4xvSAorQuisRjIG24mvfx2yi4FXF41F/LdE/iTCDgKehp/zsc4a W0xjqS7D PJ6ncCMlRggzA36aj5+CF+fwXYvXqcWFxZ71v5E/XidxPNcEJFB6aq2mESSh9wcvW+55nUDWYFHJFrTCwH2Q3EnXJ+RwgKoPWAIDsaqC/8EBZAPiRQrYqqu/cSM7wrUVC+hZulZqPj1knko3bJShQ9O/TQKtZH7Qcp5hmRj6M/mNumAx8kLVkx1D3QFbLIQy0LZmGs6s5d6wAvmXryoa7/Bx0H0mBZtl7kP6Eeo9D+HXQ0+5thb1PKr18d2uORYPljmyL0x7PLLD0pKgoH3jeiFhDFBzOkBZbFysnKVyM0IutW7zK3NvnMg/ZK0UAtrSUwqYP4QmPZedSgI9CjgnsWx7yToTbuBSq0RGGPYPWukgcrRXtAfAfQej1CeJHwejQmkflxSxCQpZErxNj4v3mNWXTbRiVVR8w/ax202qMT1OertPeoeN+HwuYoGsYa8QZYyNb9xUZ6oHzvEbBELrJDR7cmgSWuKp+sDvXTbEjnHmRhms+sAKenDlMZg788TWMOTSEaqqAr5+VjE8z9JGONtz12QanqkcF+dkgPtuqRU5NlTNStXAFiyUisA== 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 Fri, Jan 17, 2025 at 04:25:45PM +0100, Valentin Schneider wrote: > On 14/01/25 19:16, Jann Horn wrote: > > On Tue, Jan 14, 2025 at 6:51 PM Valentin Schneider wrote: > >> vunmap()'s issued from housekeeping CPUs are a relatively common source of > >> interference for isolated NOHZ_FULL CPUs, as they are hit by the > >> flush_tlb_kernel_range() IPIs. > >> > >> Given that CPUs executing in userspace do not access data in the vmalloc > >> range, these IPIs could be deferred until their next kernel entry. > >> > >> Deferral vs early entry danger zone > >> =================================== > >> > >> This requires a guarantee that nothing in the vmalloc range can be vunmap'd > >> and then accessed in early entry code. > > > > In other words, it needs a guarantee that no vmalloc allocations that > > have been created in the vmalloc region while the CPU was idle can > > then be accessed during early entry, right? > > I'm not sure if that would be a problem (not an mm expert, please do > correct me) - looking at vmap_pages_range(), flush_cache_vmap() isn't > deferred anyway. > > So after vmapping something, I wouldn't expect isolated CPUs to have > invalid TLB entries for the newly vmapped page. > > However, upon vunmap'ing something, the TLB flush is deferred, and thus > stale TLB entries can and will remain on isolated CPUs, up until they > execute the deferred flush themselves (IOW for the entire duration of the > "danger zone"). > > Does that make sense? > Probably i am missing something and need to have a look at your patches, but how do you guarantee that no-one map same are that you defer for TLB flushing? As noted by Jann, we already defer a TLB flushing by backing freed areas until certain threshold and just after we cross it we do a flush. -- Uladzislau Rezki