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 54B0A266B72 for ; Thu, 18 Jun 2026 23:22:00 +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=1781824921; cv=none; b=FSrwol79hHvmM9rXcMew2iMNFkBVl+RF9bNsKwnnTl5gsq2Okl4keHimtS99hwxOCh/37tkcztrcNPx8HkkYO2dHjGqDS/OIeowFmm3FIGjpRomwT8qBK/m+v1BrGCJn+qCfhEgdmpmPX/QQTYwju86eVfjRjmAuYlGdT0rsZ4I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781824921; c=relaxed/simple; bh=GMc7qMkt1ytSTtVtJWhLHe2JDzMc99uwqepHVM9MBxE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=LoYezZ0XuxnmUPbEDUgwQa02MJPPJ1lHQCItpgHTLkGdeMR6qed5zeQT+OyGbtDPOMQWSxnVdAlvgxOfKlkOB2nDjxES4+EVU9UJPaC5TVlqNzj0Ytp8U68uBifqIJoVcOMErAnmfARmaiai4yopRWJK+MTmRVcm4ouve817K78= 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=bENQYHf6; 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="bENQYHf6" 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 65IN5g5h3951908 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 18 Jun 2026 16:05:42 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 65IN5g5h3951908 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026052701; t=1781823943; bh=w2gRfB+dAefs5szXx/q8XIHZ8zanfIbkEHSc1y17U2Y=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=bENQYHf6WUHdiAvjGl3m1/J6Acf7t6SYhE3YxzhQ0nE1izop5cRDkzR203UqZbH6L JQIX6KfSbX9AnTeqB6nAp34ZCRwJ7ZmriCmc7TxHy7U3UynzGgjx60q9n6/r5C4uyf 4HCJUfU1aPron9fvJS9nq32Z6n41QJHCEEnlUXAPIHK06pFN79jv8gBJtf1Fgzbbxq MZyLsEcfPcriGCB8yQ5zkDJPw3DnZwBKZOc5+O7URuLbILCA/cdnmur2U7CRzZNb49 VZzg+oNXYCYPYsVvbxr4zFJ+ZToiQvu9TpeHdX2R4kZXh3vkOnY+cpnysIFKPWhHIB ziJrxaJDfEG8A== Message-ID: <2a4212f2-86ec-4ad9-a1c5-1e3b572fc887@zytor.com> Date: Thu, 18 Jun 2026 16:05:37 -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 Cc: tglx@kernel.org, mingo@redhat.com, bp@alien8.de, Nathan Chancellor , Calvin Owens , Dave Hansen , torvalds@linux-foundation.org, x86-ML , LKML References: <20260613085919.GF42921@noisy.programming.kicks-ass.net> <203E61B7-290F-4F87-860F-B352D0072703@zytor.com> <338ead9a-91f4-4579-9954-e18911fa3f68@zytor.com> <01ac45a8-b558-4d4d-9f8f-e7a4e725d5d2@zytor.com> <20260616075331.GP48970@noisy.programming.kicks-ass.net> Content-Language: en-US, sv-SE From: "H. Peter Anvin" In-Reply-To: <20260616075331.GP48970@noisy.programming.kicks-ass.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2026-06-16 00:53, Peter Zijlstra wrote: > On Sun, Jun 14, 2026 at 07:07:50PM -0700, H. Peter Anvin wrote: > >> It uses the same hack as the Makefile to deal with function alignment with a >> prefix: it adds unnecessary NOPs so that the pre-alignment and >> post-alignment are the same. At the end of the day this really ought to be >> fixed in gcc. > > And clang, but I don't think they can, it wrecks the 'ABI' they have in > place with the current set of arguments. Which I agree is somewhat > unfortunate, but it is what it is. > > > This more or less works by accident, in general your align_func() macro > is horrendously broken when you consider kCFI. By changing the > patchable_function_entry attribute like this, the kCFI hash ends up at a > different location and things go side-ways really really fast. > OK, I guess I'm still wondering about this. Is there a difference between the kCFI hash and the __pfx symbol? > The only reason it works here is that this function is never indirectly > called and so the kCFI ABI violation is immaterial. Ironically, as you post in your later patch, it is arguably better to have it always fail if it never should be called that way ;) That being said, I have filed a gcc bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125892 -hpa