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.129.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 E40D21B85DB for ; Mon, 20 Jan 2025 13:53:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737381211; cv=none; b=PchwjOGvJvWks9Ycs7Novy8HspIIKtAHNMkWBuloxaEylLDbuPY2YqoyywtIJmibIm5/vIwDFQiij9YxHY7VI9x3PdjPmyYL2bunWETJS0sEBr/hf0lBK4AB3SnaqLwJEtiPGJOeQlGpNy9IklYsnZ/0ZkVtrwEUUpkwwemMZvs= 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.129.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-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-303-ZME1cqtAPS-MNFuw2GoM9A-1; Mon, 20 Jan 2025 08:53:27 -0500 X-MC-Unique: ZME1cqtAPS-MNFuw2GoM9A-1 X-Mimecast-MFC-AGG-ID: ZME1cqtAPS-MNFuw2GoM9A Received: by mail-qt1-f200.google.com with SMTP id d75a77b69052e-468f80df8caso85758931cf.2 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=uXHWs0+CkqgSbIO3m4XHuhaBJ0dWzjoHKrmZlpRnDsd76JrEzub3Gw525YFWEzG9Mj +GsTTmx376uXTk1TGPIpeUU0n97gLV43BkJRW50dUdpz1LO+dwbHgWC5hCsOgIrvcLkE Rtr8RcDDR5IOK4/36RnitYNbGiYCZZDZ9KrhaJvuA3wYwqjL3eKAGtbfhejTp4IR+F5u qNXe8effP5bx7y3dRzJq9nss6fzq9Cojqte5SBHFkfInANS6vn8QCaMOnPQ++VUJ+m3U SmMyHVQ5IsO9FP19uC/b7xqmsv80K10MlSrkuz6IqC4iG6/q6VOpVSqiSjj30ZEp0bVr 2bAw== X-Forwarded-Encrypted: i=1; AJvYcCWV/e/wMhT1NVkMd8viid/mHs2nKrHReUTPmJReFutQGes1n2QYYOCkyNknJSwevOeojf8=@vger.kernel.org X-Gm-Message-State: AOJu0YyoMBGu6yVM8ljqdM7wTMdo9fq8haFHeHqEypZ6M6T2bdI0qwgD O6QaauDd9KJcoP6IKdiAhC4EgFgeAOzlxLC9BlTgkoLM103xM9mfLz10iYEsXDsjoVRaH8k/6Cg i2WsuVs/8svyhFD8xHpkrCgwUl9ADw1IHNFrOPTJiHpr2x6unwQ== X-Gm-Gg: ASbGncuuP7q3uVqbc7+OHvoPqUHJ8eviJL1wzHQEeoa+7kFUzrOlzblWik1fbPtYxBa PDrbjooLd1roso1xQ3oyrPUoqry3CtOH6F8V/DKviOozvTMFpxXZhujnutnpTWnj1KpeZo33DKH JX/0/hrQwk+wX7SUFfpDMDFDqH0zXzoZh7e19z7iwsDdPY+IOZ3jScYrd6moWzmdajb3bhAUe7G qYPD+CpRkkORHfqyZfb1DM9zQLUYAOH6vctJbBjHWgSubpwCREWR2W/JIklFRfPrg2tF8MFnUt7 OpnwexkPe+ETpmL8Bk6cFGsyoN9EwX3v883OEjrxlOKGFl3h4Fr77OA= X-Received: by 2002:ac8:7d82:0:b0:467:5e61:c116 with SMTP id d75a77b69052e-46e12a1e36cmr160729041cf.7.1737381207218; 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: bpf@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.