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 97D83C02196 for ; Fri, 7 Feb 2025 18:38:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0F6C4280004; Fri, 7 Feb 2025 13:38:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A744280001; Fri, 7 Feb 2025 13:38:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E8948280004; Fri, 7 Feb 2025 13:38:03 -0500 (EST) 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 CB3B9280001 for ; Fri, 7 Feb 2025 13:38:03 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4926D4C84F for ; Fri, 7 Feb 2025 18:38:03 +0000 (UTC) X-FDA: 83094008046.13.6F91A24 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf16.hostedemail.com (Postfix) with ESMTP id 8D1F118000B for ; Fri, 7 Feb 2025 18:38:01 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=NlQrJCsw; spf=pass (imf16.hostedemail.com: domain of frederic@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=frederic@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738953481; 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=IhwLkh7GJqIxte+/YTH0C2b2Zk0CRP5qBdT1b27Dk7I=; b=sg1Q0akOs7ggatymgiU2M65+SIRprH6uDIXmkax8WFB+T+zgLU+f48Z+l+nHBa5x6ctzWk FfHJA0v/P3H/qv+h8vT24Q1N+vUwv6MJqRBy63e9+eBHbWeGxK+OAjhdrCuj7QGOmm7oRs 2if4uCbWKA69tt6qcCtksNNadLUP0T8= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=NlQrJCsw; spf=pass (imf16.hostedemail.com: domain of frederic@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=frederic@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738953481; a=rsa-sha256; cv=none; b=vCfba35eatSZnd5jPDfoe2/0Yn98sXiCOI7TUl2lBixx8FlKJY4nekNelV2rGd7/EbHhPh dQuBTBDyQusGn7QMVOjXKcWXr0k816xskTHPemTilBpQZ+rkCyBXPX0JNd+5e0lGD/9Gev vP/PBygdR8oMYyOLPrLURf04UXENirE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id BA41AA439E4; Fri, 7 Feb 2025 18:36:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C4FB8C4CED1; Fri, 7 Feb 2025 18:37:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1738953480; bh=nKtIeXe1WybNWDzZwu5Tk8fpz5emsmZs04c0W6ceGA0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NlQrJCswb2tfBHdOL//Nqi1duhWdmo0hhnvyFyfXR+kDIctwxBbNZGMh0uVXpdrpn VtrsS32dlVeABXURIIGFmPTMZ88JEy/aky3D6z70pfkEKIebKtTmA3OIqxmZ3iDcEH trWQP7mjMuGosKO+a09FIi/HB1+rytKm2YepWGLYPhGRvhc49fQbsTVEVzSz1vy8KY 6YWoxRaVR88tPNIw47TXvof69pWZuIN0NCuUntVn/ixzcMSAUzD+pD+us46BW7ocRi X6a7pzBJZI/SEPEJ2Eua3jvdWjb6R21icBFzIt4mEif2XISSYrHb7WAcNTWLbqa0Er f0yIWw7KhrZxA== Date: Fri, 7 Feb 2025 19:37:57 +0100 From: Frederic Weisbecker To: Valentin Schneider 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 , "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 22/30] context_tracking: Exit CT_STATE_IDLE upon irq/nmi entry Message-ID: References: <20250114175143.81438-1-vschneid@redhat.com> <20250114175143.81438-23-vschneid@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Stat-Signature: eash7b1hbyoq8wd36ubz39a7d5bb8dr6 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 8D1F118000B X-HE-Tag: 1738953481-157009 X-HE-Meta: U2FsdGVkX1+Vw44Zoj6GGL4UTHZA53Kh472OAu0aLHYiphGm7EGNr4aUwdh5AgswLEtVduqviMBl18brNnlSQErRUT00hwBDqEqZgsCtBuQY4fzC5zIEwHpZftY3LccQ7EY9kjZWcWOj0aIEp6w8OupuvYNfU2EKy4DRAff3wGAfFAHZyu/ONam8raJYejur/I1yt1u8I/DHSb2GKYlg6cFLaZrtepd36LnoDxBlyNIiM/+LALuq9ECmmFHO4SaFgrWQOp8BC9HIiFXyZUX0v0qsNVloFD6O21Aaerxvvt55HoQsF+s3Ptbf6TFmSzy4Lewmlhzbtyr/ZpwNf48lSK4uzj9FWLRkMslGJneUFG091JrqA8ysLm0FJbDloPuYPGxvfooRSgp3WjkJnn6wEMAtOyN9smv6XY6x9E5jEziloe3j+4vM1RBzKGpCylXsv6NEmJ6n6uO8FYwW5S7Jjx1jbmkuLrltpBTc5QTGCrRJvonNcgp480cfwvcqeNYWFLBJBczCWX9m4ZPAR6ZLP6FHQp57V5hrN/yPwMdWcTTm8m0YqtRoS/zATMojq86/2se9waetKa7JINPf6aI0E4jxFNxRMFb0D4pcN3e5P081Kjc1NYV5LzZDi4PyKkb/oMfM01XLp6XlS5i8+MH125M86pqIXKSQFYvB1i/1bs6qaryCzap+bdxswoGnUNZtQ8+pvBcuoi6FdAWddZ0bKe9ThTrrdPry9yHBJaWxOXFKpMND8VaKCGtvgbHE/dJGh9z3EUEmUmhW/hrtGgCIBcnUh+PNaJYmu6a4JN1j40Et4wHtev9RrlT2lWxd51oAeMOZPiSnlWnhECkO4O8SQ33qL8zTCC6vRg5VsffvLoSudDKx6Myv84B6+k5UJkO6JVEuXo4ZIOcl3ykt2k4aFaNek2VHG6IXdAXdeXXHNj4R6p/emguao/YUYSsc/G82IHo6yNUJJaCYA1mYBTM 7/QzVNsC /r22IEDhRmVngfozTnRkkKIxoN97pm5cXv6KD0plt+KLIqf5WIaMX5P19RjVA/aq9f8WdrznZ6M0uo/58B/IG0TFPqGKyVy/o+/qxBQg9fcDH7FpmMoZtyGjDU7xX6y9+/qbll/oNn+RcTKGfa+pxg6VI4B9glMm4Msk7uQKV2mfnChX9Yt8dMlUz+k052nBLiRz2VdalWjSaEIXgXFvfRSl985ucYbPiuRUvwJ2A3nHEk9hMgm0Iq73bJhK7LCIWrlZAmprrp4WGIh9iUkFWJG0Ok6EKxUCidhO6rHGd183lZOC770oA7gglrX8WvAXdFkBWV196YnZyznSmiGXrWSfjrp5ofNDCn45V 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: Le Fri, Feb 07, 2025 at 06:06:45PM +0100, Valentin Schneider a écrit : > On 27/01/25 12:17, Valentin Schneider wrote: > > On 22/01/25 01:22, Frederic Weisbecker wrote: > >> And NMIs interrupting userspace don't call > >> enter_from_user_mode(). In fact they don't call irqentry_enter_from_user_mode() > >> like regular IRQs but irqentry_nmi_enter() instead. Well that's for archs > >> implementing common entry code, I can't speak for the others. > >> > > > > That I didn't realize, so thank you for pointing it out. Having another > > look now, I mistook DEFINE_IDTENTRY_RAW(exc_int3) for the general case > > when it really isn't :( > > > >> Unifying the behaviour between user and idle such that the IRQs/NMIs exit the > >> CT_STATE can be interesting but I fear this may not come for free. You would > >> need to save the old state on IRQ/NMI entry and restore it on exit. > >> > > > > That's what I tried to avoid, but it sounds like there's no nice way around it. > > > >> Do we really need it? > >> > > > > Well, my problem with not doing IDLE->KERNEL transitions on IRQ/NMI is that > > this leads the IPI deferral logic to observe a technically-out-of-sync sate > > for remote CPUs. Consider: > > > > CPUx CPUy > > state := CT_STATE_IDLE > > ... > > ~>IRQ > > ... > > ct_nmi_enter() > > [in the kernel proper by now] > > > > text_poke_bp_batch() > > ct_set_cpu_work(CPUy, CT_WORK_SYNC) > > READ CPUy ct->state > > `-> CT_IDLE_STATE > > `-> defer IPI > > > > > > I thought this meant I would need to throw out the "defer IPIs if CPU is > > idle" part, but AIUI this also affects CT_STATE_USER and CT_STATE_GUEST, > > which is a bummer :( > > Soooo I've been thinking... > > Isn't > > (context_tracking.state & CT_RCU_WATCHING) > > pretty much a proxy for knowing whether a CPU is executing in kernelspace, > including NMIs? You got it! > > NMI interrupts userspace/VM/idle -> ct_nmi_enter() -> it becomes true > IRQ interrupts idle -> ct_irq_enter() -> it becomes true > IRQ interrupts userspace -> __ct_user_exit() -> it becomes true > IRQ interrupts VM -> __ct_user_exit() -> it becomes true > > IOW, if I gate setting deferred work by checking for this instead of > explicitely CT_STATE_KERNEL, "it should work" and prevent the > aforementioned issue? Or should I be out drinking instead? :-) Exactly it should work! Now that doesn't mean you can't go out for a drink :-) Thanks.