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 4CA9AD78782 for ; Thu, 21 Nov 2024 15:51:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8C2D76B0085; Thu, 21 Nov 2024 10:51:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 872456B0088; Thu, 21 Nov 2024 10:51:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 712C16B0089; Thu, 21 Nov 2024 10:51:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 53ED36B0085 for ; Thu, 21 Nov 2024 10:51:24 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E149C14145E for ; Thu, 21 Nov 2024 15:51:23 +0000 (UTC) X-FDA: 82810540092.22.0D59B19 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf11.hostedemail.com (Postfix) with ESMTP id 0CCC540014 for ; Thu, 21 Nov 2024 15:50:15 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=g4SSYZ8R; spf=pass (imf11.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=1732204130; 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=wqwT6sLOKw3cQNoRLXKYtXYhu38OXiMdpn/8NdnhM30=; b=fCu6r1zapMhNFDBeUWGwSwu0KCw+q22Tdoq53SHZ1C6pzxep7abDOTzek3xSqjpdhRBmdO +X3hITaGrOdHYE69at5EkdoAaHkimD+b8m7+NL6rFTvaXLCCyh49+4XZxXtppTD1aVeROA Y5HAKc3vF7Soca/vwqYjsi2a8/TekQ0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732204130; a=rsa-sha256; cv=none; b=TiNA4rvQoO6XLMDZeOgGn1q5/7m8l3JI//ptWLH4VdJ0L6XabzsMn4xEifjIK6eq8rADJL SyueG9XK7p+6WkeDdkPDVudTYMpAnP+gd/Y0Te8Hjw4X0MfBxiFpL/jlLxi2/qM9AZ3YKI 5Rlu0OfljLIfPsEvl7JbtmBeoE+JhZ4= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=g4SSYZ8R; spf=pass (imf11.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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1732204281; 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=wqwT6sLOKw3cQNoRLXKYtXYhu38OXiMdpn/8NdnhM30=; b=g4SSYZ8RPW3XHuknO3Zn3A5mDDKlGH9JTZLz+0TD9XLedn0oySxuE7qrqJxr7Zl0HBzwqJ G9bLz57WgCKOiaiqn38MNqK8DFlRhUnPLbwc0zRlkKlQCr8NEWVAhFwwKTLKSzyrjuXsJB iZ3joCCbETAl44D3ARVsbnFia/IYZFU= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-68-iQw23sY5PBqCLhR74JQTWQ-1; Thu, 21 Nov 2024 10:51:19 -0500 X-MC-Unique: iQw23sY5PBqCLhR74JQTWQ-1 X-Mimecast-MFC-AGG-ID: iQw23sY5PBqCLhR74JQTWQ Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-462e5b8a36cso15398141cf.0 for ; Thu, 21 Nov 2024 07:51:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732204279; x=1732809079; 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=wqwT6sLOKw3cQNoRLXKYtXYhu38OXiMdpn/8NdnhM30=; b=w3ArtyFUsEO3d/jH2ZW9bxsS+FxAnw2Yjjq+Nn+9eVZAkcCB3mW87ILCDMG5yj9Byk j0wq5ViepSSFQaCt7XYFJzLZ1Q4BfsQxi+6RsmeVHEB7zCQbVbZDcf6PWg7X8DkWdN5v C+HIN/5XCghAFHTqzXOIqLNfMxcQgb7aClEOQ8/e6fekbuFhgcSXtn4FbaMRDBMY1TKb uL97EHLyiE7Hdq5sjJLP9JLVreGGyeRLnXAnZTkpALuufmpmxNh3y6aamylO90Jfeytj W249xYFwNKXoAwvW93T9RnFqPvmOOVhzJ4fdlTFvhbi/lzZ3Ak8SWlmVwCHuyg78wOVI vLMw== X-Forwarded-Encrypted: i=1; AJvYcCXm3EG67h98Ot/kHrcJUpYmHE1KFp/IgqRC1tDXGri20cI32h1YhJaZI3KR5sThQSAZd71VeRlGPw==@kvack.org X-Gm-Message-State: AOJu0YyyaHl+yauDszZNd3c28pbNQQUWPMYz4QvO6/s0Z/RGI6/4TUwl +h/fdrt90YTfemErYJH8mfOYg629GORDUuUiQzJqFzlaZdNOAD0sUlYFehQujX41fDluCKPVQN1 hREROcx0aOA/EoFTF+yCs6vpDoosQA8zYklxa7XWPCtGO6yQE X-Gm-Gg: ASbGncswMi/KAkRNt7OB27BOHE6GgGNDp4zt+u/deK/P30PsMoWvAZpVx24KmuB4jiS dm0I+bTmLGV7ZZ8eda2VPSDG0uhr0w/PguMjYEkbglLt9oUGlmJ3VVd16novJRxWfFwZ0tJDNqz dlr9te1GeGljgKOI1CBYiGoYuWeN5mwAi4kO4xuHVE8SXTbCXORc3lMp/aQdoV6RKGqspeYEL4w PgM0g8fOL/kOjR7RUJ/wyvHfGDhIXQcFF5EixpgO6nYqmvIeUAhS4N3ALpjZeBc3a+XmgCp3ywO yOiwmXFvzW0pIQeRJpn8jEaXnxR5y9JN5HE= X-Received: by 2002:ac8:7c4b:0:b0:461:4372:f2b6 with SMTP id d75a77b69052e-4647965fae7mr111015081cf.39.1732204279371; Thu, 21 Nov 2024 07:51:19 -0800 (PST) X-Google-Smtp-Source: AGHT+IFhhGvXxNF9YG7Wn8RkZZVe3HUI8vO3AoWFe5rp5bueN6AbTjXI6+VbxkAuh2ulevplAsAH7Q== X-Received: by 2002:ac8:7c4b:0:b0:461:4372:f2b6 with SMTP id d75a77b69052e-4647965fae7mr111014101cf.39.1732204278637; Thu, 21 Nov 2024 07:51:18 -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 d75a77b69052e-4646ab21371sm23699431cf.76.2024.11.21.07.51.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Nov 2024 07:51:17 -0800 (PST) From: Valentin Schneider To: Peter Zijlstra , Josh Poimboeuf Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, bpf@vger.kernel.org, x86@kernel.org, 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 , 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 , Jason Baron , Kees Cook , Sami Tolvanen , Ard Biesheuvel , Nicholas Piggin , Juerg Haefliger , Nicolas Saenz Julienne , "Kirill A. Shutemov" , Nadav Amit , Dan Carpenter , Chuang Wang , Yang Jihong , Petr Mladek , "Jason A. Donenfeld" , Song Liu , Julian Pidancet , Tom Lendacky , Dionna Glaze , Thomas =?utf-8?Q?Wei=C3=9Fschuh?= , Juri Lelli , Marcelo Tosatti , Yair Podemsky , Daniel Wagner , Petr Tesarik Subject: Re: [RFC PATCH v3 06/15] jump_label: Add forceful jump label type In-Reply-To: <20241121110020.GC24774@noisy.programming.kicks-ass.net> References: <20241119153502.41361-1-vschneid@redhat.com> <20241119153502.41361-7-vschneid@redhat.com> <20241119233902.kierxzg2aywpevqx@jpoimboe> <20241120145649.GJ19989@noisy.programming.kicks-ass.net> <20241120145746.GL38972@noisy.programming.kicks-ass.net> <20241120165515.qx4qyenlb5guvmfe@jpoimboe> <20241121110020.GC24774@noisy.programming.kicks-ass.net> Date: Thu, 21 Nov 2024 16:51:09 +0100 Message-ID: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: QsFymxbtonU99-vIIUBj7hkK1s69W58Hc3O_4rUE4xI_1732204279 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 0CCC540014 X-Stat-Signature: 6th9o7k1i8unn83we74xm5bu3u5ccd16 X-HE-Tag: 1732204215-416785 X-HE-Meta: U2FsdGVkX18LDH9I2zarHX2PkjpJG/40kmiuI0oHENUqXC871mFSupj8C9ttEKu9hJNg/nOAUo3Hcn3fUE9F2dG8+9kmBgpQAWkRtjCINvmE/cnVEROawgH220mu4OhOl+axoeyojKTdKFLBVRgBp1rQ1NYolgzctB7oxCBugaSEodBPVT3Aw0CLK3G5Vdbf96JFuhx7qi9J+87YIyPdrfnxdwHTL4fJoDfvXoLZ77LMk4ybk1iXTIibcNXUdxg7xAixZF0wW36y3V03rEZfK7kW1wnjPPiSokePLyiaSaYEjfpInw7Olyzl4nQIsS5pj421225yvLcI2rp61lnYwfmbb/FQMGLb19bndWmM7D85dld2LKPb8vMrH7h1WqtkeOookfrdX+UkLDVPunIbiB2p3NvEvS43e9qciZfnSCktY68SO9k+ndiVMEXZ43FOIeV2ZATybME91Ivt5y9M7v900tP3zuzte1qAS2H+1m4OSigWSVlU5NujALGJN9SGnhYl6a4HAUjzM/KDm4MYVrYXqvRiwFzrYKGwYAWbSuZ3w+/z3Sq/Ep9w20sGjBG3dAQGro2QvyvF53U4duM530dlsqUBZDogngR5DVDzNHUFyeuVkn3O3yC5ERDbGAjuzXLTTNFSYES4M95+Tz7XbAvoR3vIbxFeasFGAWs7Tgw7yy9dWGGUiHOgToZ+YcvAbp/QxcC6YD597m7lhwiEK5IiipsW1XYZYOZ6JpZcK/hgjQH/ASxrxz4WJZPxs+8v0mnA+NIdOn6mlCZOGd1MmITMfa/Z9MfXLPxVVIlPohtLVjqqJ3oTR1272MEwpFR0uw6wKOfP3D844f81Wci2qrfi2xjDobpYOePA6fbgY8sX3CZhrRzAQmMFs/0s3Eh5ZOcFNVdtVFWaJUeoQzvckd7vZPudl2h8+i0xC4rq88x5+IKGWCVUAxJHI/50HengrM+nRX4X6TxG1yT4M9p HRsBJ4sP hk79NN5Xw6m/eYWIjoKFDbbqrGK8bKeNny3QZy2GkdYaNJPqrN/nLMeF1PlYhz7du18a5INUMchtD3lBiik74Ja3XKKkfVD0VHA7Q5R73LtMzJBLN9ISXDHSGvMBxMKybf1FI+E2krDcpR4jWuQ2D5Roap4sEr2Z2OZh13D2WBqUulxahjwlWpq0ddc9FDd3ac2NOWnKiiBkiTv5Ptqechtc2N4LT1N7iqFyRQ6NGALuDqnSiBoHt9V0PMbrEqzmDIjx4EvNVVsY+KeLwM2knttJcfke8AXy28c7F3WJh/rkq2hy207Np8raSg2zFpf38UEQSxWfBamS2TcSa3Bg92whXfv0Nd9Qao4Vwup50ui1cHqfD9EbSMdBC8kgf/Fzlm2Ijrc//fqC0dzOHvXG8X48m2Iq47AIJWKcDckL3Yk65rJ8= 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 21/11/24 12:00, Peter Zijlstra wrote: > On Wed, Nov 20, 2024 at 08:55:15AM -0800, Josh Poimboeuf wrote: >> On Wed, Nov 20, 2024 at 03:57:46PM +0100, Peter Zijlstra wrote: >> > On Wed, Nov 20, 2024 at 03:56:49PM +0100, Peter Zijlstra wrote: >> > >> > > But I think we can make the fall-back safer, we can simply force the IPI >> > > when we poke at noinstr code -- then NOHZ_FULL gets to keep the pieces, >> > > but at least we don't violate any correctness constraints. >> > >> > I should have read more; that's what is being proposed. >> >> Hm, now I'm wondering what you read, as I only see the text poke IPIs >> being forced when the caller sets force_ipi, rather than the text poke >> code itself detecting a write to .noinstr. > > Right, so I had much confusion and my initial thought was that it would > do something dangerous. Then upon reading more I see it forces the IPI > for these special keys -- with that force_ipi thing. > > Now, there's only two keys marked special, and both have a noinstr > presence -- the entire reason they get marked. > > So effectively we force the IPI when patching noinstr, no? > > But yeah, this is not quite the same as not marking anything and simply > forcing the IPI when the target address is noinstr. > > And having written all that; perhaps that is the better solution, it > sticks the logic in text_poke and ensure it automagically work for all > its users, obviating the need for special marking. > Okay so forcing the IPI for .noinstr patching lets us get rid of all the force_ipi faff; however I would still want the special marking to tell objtool "yep we're okay with this one", and still get warnings when a new .noinstr key gets added so we double think about it.