From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 4909F1DFF0 for ; Fri, 19 Jun 2026 07:31:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781854308; cv=none; b=fvzbWfESXgpzuuFzm1FIxiESKldyeGsB7P0HTmSLRdUmaoa9EJ1GYsK0UnITie+ll7mkfoEYGcF/P6+tAl0V1DvD6TMBl9zcRYjqJuzCIylsh8j0iSY69sUaeW91k5iQGLjywQQ6HQYEZEvK0IMCF2qain2iYKiBoPZqIhZtWCg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781854308; c=relaxed/simple; bh=zczGAL51RESK9hoE6pPi4iR+PYM9YFKlwbpp6PjUcWY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=r3l6sf6GPEiuRtcGGRe3abRGuWjbaILVAEFnJyR7fYt4+U68lodrg8J002aeIoDJpgqvgr1yyrdv+HrLcbfug382z8KfcEnthqLvdJl6AGqFanNlngx5+xg4vgZRX8r9oFW3mZGegz8u5jOal/OXa/CwGjKLkQGfPrhFBLCiZ+g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=XaM0q3+T; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="XaM0q3+T" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=LrkCma/19ElN/AhAjIDFoMIoztt9MXSbWu2XN4GsYF4=; b=XaM0q3+Tq9hOPg4etf5bPOaiiT bu3NfYW392bSMn3H0qcVpKP2dQT+fHn41DPWpTeo+26QQwERe9ha9exbiURW3OzbCGp4ts6rOTIP/ 0Son6jeKfvrDzuNzHqLqHiDndgEMqnrNh/awTCBiDtv7KF80YEgReoS7A09uW4HxrvZlbg97AE0UY 1a1aGAxB/o1yUz1eL8dWlLposduhP/PHdsnOHQJ+5B4GsaByg0Whs77zvEkUFK1EQCRbiQaaXiR/t VBuza7NED/Y1WrAVDzlAWDFIsewH72c1VVCcDuTnazODRKbFYPIyCKImi8COjIGlkND7WPc8GVRGm xSNTQA9A==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1waThP-0000000FqXJ-121b; Fri, 19 Jun 2026 07:31:35 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 394AA300578; Fri, 19 Jun 2026 09:31:34 +0200 (CEST) Date: Fri, 19 Jun 2026 09:31:34 +0200 From: Peter Zijlstra To: "H. Peter Anvin" Cc: Linus Torvalds , tglx@kernel.org, mingo@redhat.com, bp@alien8.de, Nathan Chancellor , Calvin Owens , Dave Hansen , x86-ML , LKML Subject: Re: 8aeb879baf12 - significant system call latency regression, bisected Message-ID: <20260619073134.GQ49951@noisy.programming.kicks-ass.net> References: <20260613085919.GF42921@noisy.programming.kicks-ass.net> <203E61B7-290F-4F87-860F-B352D0072703@zytor.com> <20260616082814.GQ48970@noisy.programming.kicks-ass.net> <20260617123718.GM49951@noisy.programming.kicks-ass.net> <9ae04c80-d1e2-44f0-bca2-d0889c61b45f@zytor.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ae04c80-d1e2-44f0-bca2-d0889c61b45f@zytor.com> On Thu, Jun 18, 2026 at 03:40:00PM -0700, H. Peter Anvin wrote: > On 2026-06-17 05:37, Peter Zijlstra wrote: > > > > This builds with kcfi on and seems to do more or less do what is expected. > > > > I've not actually tried performance measurements on my IDT based system. > > > > I'm going to run this through its paces. > > I'm still confused, though, by the claim that changing the > patchable_function_entry() breaks the kCFI ABI. When I do a symbol check on my > system, the __pfx symbols are still at an offset of -16, and the additional > NOPs are located *before* them. Isn't this completely consistent with the > existing ABI? What am I missing here? CONFIG_CFI=y is what's missing, I suspect you're building with GCC, and Kees is still trying to get the kCFI patches to land there :/ (assuming debian): $ make O=defconfig-build LLVM=-22 defconfig $ ./scripts/config --file defconfig-build/.config --enable CFI $ make O=defconfig-build LLVM=-22 kernel/sched/core.o $ objdump -wdr defconfig-build/kernel/sched/core.o ... 0000000000005630 <__cfi_resched_curr>: 5630: b9 9c 43 4e 4d mov $0x4d4e439c,%ecx 0000000000005635 <.Ltmp268>: 5635: 90 nop 5636: 90 nop 5637: 90 nop 5638: 90 nop 5639: 90 nop 563a: 90 nop 563b: 90 nop 563c: 90 nop 563d: 90 nop 563e: 90 nop 563f: 90 nop 0000000000005640 : 5640: f3 0f 1e fa endbr64 5644: be 04 00 00 00 mov $0x4,%esi 5649: eb 15 jmp 5660 <__resched_curr> 564b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) 5650: 90 nop 5651: 90 nop 5652: 90 nop 5653: 90 nop 5654: 90 nop ... diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 8b791e9e9f67..32c15ea31c02 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -1228,7 +1228,7 @@ void __trace_set_need_resched(struct task_struct *curr, int tif) } EXPORT_SYMBOL_GPL(__trace_set_need_resched); -void resched_curr(struct rq *rq) +__attribute__((patchable_function_entry(27, 27))) void resched_curr(struct rq *rq) { __resched_curr(rq, TIF_NEED_RESCHED); } ... 0000000000005630 <__cfi_resched_curr>: 5630: b9 9c 43 4e 4d mov $0x4d4e439c,%ecx 0000000000005635 <.Ltmp268>: 5635: 90 nop 5636: 90 nop 5637: 90 nop 5638: 90 nop 5639: 90 nop 563a: 90 nop 563b: 90 nop 563c: 90 nop 563d: 90 nop 563e: 90 nop 563f: 90 nop 5640: 90 nop 5641: 90 nop 5642: 90 nop 5643: 90 nop 5644: 90 nop 5645: 90 nop 5646: 90 nop 5647: 90 nop 5648: 90 nop 5649: 90 nop 564a: 90 nop 564b: 90 nop 564c: 90 nop 564d: 90 nop 564e: 90 nop 564f: 90 nop 0000000000005650 : 5650: f3 0f 1e fa endbr64 5654: be 04 00 00 00 mov $0x4,%esi 5659: eb 15 jmp 5670 <__resched_curr> 565b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) 5660: 90 nop 5661: 90 nop 5662: 90 nop 5663: 90 nop 5664: 90 nop ... Now look at any x86_indirect_thunk site, the first being: 30: 41 ba 5a 69 61 c7 mov $0xc761695a,%r10d 36: 45 03 53 f1 add -0xf(%r11),%r10d 3a: 74 02 je 3e <__traceiter_sched_kthread_stop+0x2e> 3c: 0f 0b ud2 3e: 2e e8 00 00 00 00 cs call 44 <__traceiter_sched_kthread_stop+0x34> 40: R_X86_64_PLT32 __x86_indirect_thunk_r11-0x4 This hard assumes the hash (that mov in the __cfi symbol) sits at -15, and observe how that __attribute__((patchable_function_entry(27,27))) has shifted that for this one function? That is what's broken. It makes it impossible to actually do an indirect call to these functions, which is why if you touch patchable_function_entry, you also need nocf_check.