Re: 8aeb879baf12 - significant system call latency regression, bisected

[H. Peter Anvin]

On June 19, 2026 12:50:27 AM PDT, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>On Thu, Jun 18, 2026 at 04:05:37PM -0700, H. Peter Anvin wrote:
>> 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
>
>For GCC you also need these unmerged patches: 
>
>  https://lore.kernel.org/r/20260618204530.work.910-kees@xxxxxxxxxx
>
>And you seem to have forgotten about llvm/clang.

I haven't, but I generally have found it easier to push the gcc folks first.