From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 017531E25E4 for ; Mon, 20 Jan 2025 13:53:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737381211; cv=none; b=WAMW5A38S8MUObXsA349jqSyyxy5SYfeUhjIkJX2dL7BaP0W3QSzxJjbXFFP+k4ezKK1aD5xJnu66I/avDOe8/lL7gIjP+23NXRCDYiQu7p89MhUofGrj6A+K5SdMB5zjma34sQ+/xe/BdnFmlfIFjDvxstezSBG0+YB0ADJmco= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737381211; c=relaxed/simple; bh=uxNVkuB1kfPiPhaAvJDAYwdoCzbbN5ig+MfWtinYkGs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=AHU8q7D5cSs2uQvk5YmCjio5PUQn1Cz09fQ2Dck3X7DTCeepjdlCpVtwqzvpe4aBdI+XT4XguNZ//6eYsMWC7Bwv2OCOQTxI7EuS4GbxDcdsZj6FDN/wHAxgau9kUNezG9VaKpCSAxR8XT8aBrCitd4/W3bB/+yLxITiyoMBrTM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=HbMtC92I; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="HbMtC92I" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1737381209; 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=6OUKdt6VXAQzpOTUFB26LmXUDO8O/oST+Zn2uKcAtKs=; b=HbMtC92IGEx8a976wcxW0kDoKugHnljw5CJ/V3bldO3EleSl4f8dkr/UxaQd0pGkdw7Vvs FLaOvwZFsd3RnEuOP3KbFH5VZ/Mo3jfZrt9VEpg7hpZnAL1LxkF1kfKPvTMoqshvadb4YN 4Ooo0u4GxuufcBnly1qGnkquaO6lzww= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-444-BZCAgCPRNSW-SyxfE4cpOw-1; Mon, 20 Jan 2025 08:53:27 -0500 X-MC-Unique: BZCAgCPRNSW-SyxfE4cpOw-1 X-Mimecast-MFC-AGG-ID: BZCAgCPRNSW-SyxfE4cpOw Received: by mail-qt1-f199.google.com with SMTP id d75a77b69052e-467a3c0c8f6so85056121cf.0 for ; Mon, 20 Jan 2025 05:53:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737381207; x=1737986007; 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=6OUKdt6VXAQzpOTUFB26LmXUDO8O/oST+Zn2uKcAtKs=; b=golUMa3fGZe6pITvVRQKxVYU+/vSmzLSROhM/57+YVSxlZ079L20zB8xm1fROqUc3j JQgKzGMR7Rcb/wuZW2HnDuZqqVeeaejbxDV/8Hn3mf6ss+0OPnU70J9RhgMtUozxSfYd 78wtLyHk4rhm16PKb9PuPVWVToRLDOuvAumsrNUTVfbSngxa4M8iMQkIycsMGuU1CxUC jQv5RxvbiGIwLEVWf0zhLQsqPS5bwFF3/GosgT3tjuFtyOH0M81UW5o3CJoZJGfGYIxz T9m4igBGa1cjxmWPlhbS19/Gdc/uVkVD/pvpPIMbFqUEza8TQkkhnTIyzrD7AD7biAX3 1WaQ== X-Forwarded-Encrypted: i=1; AJvYcCXkx+KuFlx34d4EduEmkWMdMB0JnAcOOJyYABvBA0jDpFBup22NRr0EOkgBiiiFICjbjm2Q996G24eL91vN61xB@vger.kernel.org X-Gm-Message-State: AOJu0YwxBh+XZBOstmLRWrWa7C1ad3O7MWAPiPknrTSF481vJf3j1Fmy 7XlQfSzhpPtXIALNV3ddWV0TP7dL5OsZBV/KMEGhA6IU5BDxmcNeLPvzz9Sb7wXmbZehssvgesk k0C4BOx7o3gIMZhaU//0HRp5Z7FKgFz4akLRSqMqSd11CcxlroXLP9s2cu4IAQLxgDBw= X-Gm-Gg: ASbGncvBQEE/yqUMvWf+O9GGb7OX7wTUw/VnltBrumA4z5eDxXPU6rykytnLovZuDRA JsmodjfzS9391KO0dggx+gsymj7BalnJohwZuE/zG+82sxVKPsuDYQgDk1AolQBDYUS3GE5MOrr CnlBHkBrVZcvzvcOI+4+tkB3eFpYbssAarQviQYUQHy2rx015yepWnwhtHBcdLNpfIJFZNWU5pi +/br7jwRO+xNCswcXkYMGTCSC9boAmSRQvNx51Ct95+OBmCrQalrdi8KZUkRpjQq+NgH69pEAhp 2si169LQHmVwamjBiU9dqhmU3iOXVfCdmfN+eOsR6nlc1gl4MDYrsvw= X-Received: by 2002:ac8:7d82:0:b0:467:5e61:c116 with SMTP id d75a77b69052e-46e12a1e36cmr160729061cf.7.1737381207219; Mon, 20 Jan 2025 05:53:27 -0800 (PST) X-Google-Smtp-Source: AGHT+IGCbxGDy6CHUSfOLqTxGL3gA1S6wKRHlUvydXAdXodFBspL8+Pdog+OKdfN6k1jzDkgqmOx+A== X-Received: by 2002:ac8:7d82:0:b0:467:5e61:c116 with SMTP id d75a77b69052e-46e12a1e36cmr160728291cf.7.1737381206799; Mon, 20 Jan 2025 05:53:26 -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-46e1030da00sm42651971cf.33.2025.01.20.05.53.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Jan 2025 05:53:25 -0800 (PST) From: Valentin Schneider To: Sean Christopherson 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, Peter Zijlstra , Nicolas Saenz Julienne , 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" , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , Kan Liang , Boris Ostrovsky , Josh Poimboeuf , Pawan Gupta , 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 , Geert Uytterhoeven , Yosry Ahmed , "Kirill A. Shutemov" , "Masami Hiramatsu (Google)" , Jinghao Jia , Luis Chamberlain , Randy Dunlap , Tiezhu Yang Subject: Re: [PATCH v4 25/30] context_tracking,x86: Defer kernel text patching IPIs In-Reply-To: References: <20250114175143.81438-1-vschneid@redhat.com> <20250114175143.81438-26-vschneid@redhat.com> Date: Mon, 20 Jan 2025 14:53:13 +0100 Message-ID: Precedence: bulk X-Mailing-List: linux-perf-users@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On 17/01/25 09:15, Sean Christopherson wrote: > On Fri, Jan 17, 2025, Valentin Schneider wrote: >> On 14/01/25 13:13, Sean Christopherson wrote: >> > On Tue, Jan 14, 2025, Valentin Schneider wrote: >> >> +/** >> >> + * is_kernel_noinstr_text - checks if the pointer address is located in the >> >> + * .noinstr section >> >> + * >> >> + * @addr: address to check >> >> + * >> >> + * Returns: true if the address is located in .noinstr, false otherwise. >> >> + */ >> >> +static inline bool is_kernel_noinstr_text(unsigned long addr) >> >> +{ >> >> + return addr >= (unsigned long)__noinstr_text_start && >> >> + addr < (unsigned long)__noinstr_text_end; >> >> +} >> > >> > This doesn't do the right thing for modules, which matters because KVM can be >> > built as a module on x86, and because context tracking understands transitions >> > to GUEST mode, i.e. CPUs that are running in a KVM guest will be treated as not >> > being in the kernel, and thus will have IPIs deferred. If KVM uses a static key >> > or branch between guest_state_enter_irqoff() and guest_state_exit_irqoff(), the >> > patching code won't wait for CPUs to exit guest mode, i.e. KVM could theoretically >> > use the wrong static path. >>> >> AFAICT guest_state_{enter,exit}_irqoff() are only used in noinstr functions >> and thus such a static key usage should at the very least be caught and >> warned about by objtool - when this isn't built as a module. > > That doesn't magically do the right thing though. If KVM is built as a module, > is_kernel_noinstr_text() will get false negatives even for static keys/branches > that are annotaed as NOINSTR. Quite so. I've been looking at mod_mem_type & friends, I'm thinking adding a MOD_NOINSTR_TEXT type might be overkill considering modules really shouldn't be involved with early entry, KVM being the one exception. Your suggestion to have a KVM-module-specific noinstr section sounds good to me, I'll have a look at that.