From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (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 B99677082D for ; Thu, 18 Jun 2026 22:56:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781823387; cv=none; b=Nxb10pdc3RxnY2RxhJPlRML32GP6BiJGghPMMnTpwDDwY0Xvs4Fo6PtVHyXqli6T58GH3amkmnVgo7DeSTigFUEYwwd5Is+h0YAU3k+Bd9RDRqb3KirEOmOm6SEYUvJ43QFNk/twJLQwf6f9tuWpxg9Iw3DfjCnakvERw0vvqKE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781823387; c=relaxed/simple; bh=plIoGAx1MRTBYcq6NrgT/ST8trcg/EvKsqa+08KTPqs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=R+6w1HPhFlpQFS4iVjukXm9xCkOtMiiLQ4zb6PbiO5NsUJ1pv5eSEknHzmeWhGh5Avs0hea2HpYFJP2wvjYY+p1rgeuAsQqlN5tZlXllvgdk8VytGJCFfOh8rL7fv/pa3nc24H3Vtm1qA5laCeveMigpdldwnUQfMOUFhPqUqzo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=dlsw9A89; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="dlsw9A89" Received: from [IPV6:2601:646:8081:7da1:99a0:e0da:db53:8fc0] ([IPv6:2601:646:8081:7da1:99a0:e0da:db53:8fc0]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 65IMe5xX3910085 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 18 Jun 2026 15:40:05 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 65IMe5xX3910085 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026052701; t=1781822406; bh=Rac/JZe7jZHcwDtjC3x6xRT5+5hmPUUhvonBm+Uvcpo=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=dlsw9A891nrRXH+eJ2pW0txqmpIeSzRMFz2vIHaba9936b6eNdeg9gicE823I+qaS tdpZmJKGLix6q8rdfLeWROylnXMyP5ZcGNK1AhVU1BvS3ZU+qLMUzs2RJzw1F9f6JW SnkC8rg/eukWMpbY0RpxBIYdM9Pi3W1F3InGNlgDUgqvx03Go+R93QH7Q+0KOLfO1v CCSrFm6BYn4Wl4qerlgBKNct6vk686vZBckYQf0IvtuzTX4F1Z8uKppsyw9KpgnMZO DTvXFIoeBlB+q4C/ous4t5vA3uYQz2M6ucStaw0Fx9Lz9seupIbT3eD7KYFIQecFKW CyOkbbYTGqHVQ== Message-ID: <9ae04c80-d1e2-44f0-bca2-d0889c61b45f@zytor.com> Date: Thu, 18 Jun 2026 15:40:00 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: 8aeb879baf12 - significant system call latency regression, bisected To: Peter Zijlstra , Linus Torvalds Cc: tglx@kernel.org, mingo@redhat.com, bp@alien8.de, Nathan Chancellor , Calvin Owens , Dave Hansen , x86-ML , LKML 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> Content-Language: en-US, sv-SE From: "H. Peter Anvin" In-Reply-To: <20260617123718.GM49951@noisy.programming.kicks-ass.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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? That being said, I like the idea of entry points being noendbr: they are very high value targets and making them even a little bit harder to access I think is a very good thing. As far as getting the compiler people to address this: this very clearly would have to be something explicitly opted in; e.g by adding a third (alignment) argument to the patchable_function_entry attribute and option. > Obviously this would want splitting into a few patches, but it does: > > - makes -fno-jump-tables unconditional > - removes array_index_nospec() from the syscall dispatch > - makes x{32,64}_sys_call() 'static noinstr' Note: I have found that merging x32_sys_call() into x64_sys_call() generates considerably better code, because both gcc and clang will re-use x64 sub-branches for the x32 code. Specifically, the way to make it generate good code is to explicitly remove the x32 bit before a second switch (merging the two switch statements will *not* give good code; neither compiler isn't clever enough to detect the common-but-offset code branches.) > - adds align_entry attribute that aligns on cacheline boundaries > and disallows taking address > - sprinkles align_entry on the noinstr syscall path -hpa