[PATCH] arm64: perf: fix syscalltbl path base

[James Clark]

On 21/12/2025 9:48 pm, Joel May wrote:
> On Mon, Dec 15, 2025, at 03:28, Leo Yan wrote:
>> On Mon, Dec 15, 2025 at 12:52:24PM +0200, James Clark wrote:
>>> On 15/12/2025 11:33, Arnd Bergmann wrote:
>>>> On Mon, Dec 15, 2025, at 09:47, James Clark wrote:
>>>>> On 15/12/2025 00:12, Joel May wrote:
>>>>>
>>>>> Hi Joel,
>>>>>
>>>>> There is a similar fix on the list here:
>>>>>
>>>>> https://lore.kernel.org/linux-perf-users/20251204-perf_fix_syscall_header-v1-1-b8e27f74ed6a@arm.com/
>>>>>
>>>>> I'm not sure if commit 1 alone will also fix your issue, or we'd need to
>>>>> collapse both of the commits in that set.
>>
>> We need to apply both patches in the share link - we need to apply the
>> second patch to revert generating unistd_64.h in libperf.
> 
> Yes, applying both of those patches will mitigate my problem.
> 
> Neither of those patches update syscalltbl in
> arm/arm64/kernel/Makefile.syscalls though.  Based on the context in
> scripts/Makefile.asm-headers, it looks like syscalltbl is always intended
> to be relative to srctree.  So, my patch increases consistency, even if
> it's not fixing any known problem (after the other patches are applied).
> 
> Whether headers are dynamically generated or not, it seems like this is
> something that can be improved anyway.
> 
> This is my first time contributing to the Linux kernel, so please bare with
> my ignorance.  I don't know whether it's acceptable to consider patches
> that conceptually improve something without an actual problem they're
> solving.
> 

No worries, thanks for sending the fix. Yes I think it could be ok to 
apply your patch anyway. I just wanted to make sure we were all on the 
same page with both fixes fixing the same thing.

You might want to drop the fixes tag though to avoid confusion if Leo's 
one gets accepted, because then technically it doesn't fix anything any 
more. Keeping Leo's fixes: tag is a bit better because it fixes 
additional things and targets an older commit.

James

> Thanks,
> --Joel