linux-kernel - Re: [PATCH v3 1/3] tools headers: Go back to include asm-generic/unistd.h for arm64

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <b50402a1-f1e2-46dc-b0f8-a08326b02c96@app.fastmail.com>
Date: Wed, 07 Jan 2026 16:21:28 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Leo Yan" <leo.yan@....com>, "James Clark" <james.clark@...aro.org>
Cc: linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
 "Arnaldo Carvalho de Melo" <acme@...nel.org>,
 "Namhyung Kim" <namhyung@...nel.org>, "Jiri Olsa" <jolsa@...nel.org>,
 "Ian Rogers" <irogers@...gle.com>, "Adrian Hunter" <adrian.hunter@...el.com>
Subject: Re: [PATCH v3 1/3] tools headers: Go back to include asm-generic/unistd.h for
 arm64

On Wed, Jan 7, 2026, at 15:48, Leo Yan wrote:
> On Wed, Dec 24, 2025 at 01:47:51PM +0000, James Clark wrote:
>> > To fix the issue, it restores to include asm-generic/unistd.h.  This is
>> 
>> Would this prevent us from using any Arm64 specific syscalls in the future?
>
> I hope the perf code can be general enough so don't call arch specific
> syscalls.
>
>> I think that's a downside of this approach vs copying the generated output
>> that should be noted here.
>
> From pragmatic view, I don't see any issue with using the
> asm-generic/unistd.h on Arm64 at current stage.
>
> If later we need to support new syscalls, I assume it is very likely not
> an issue for Arm64 specific, we need to resolve common issue either
> updating asm-generic/unistd.h or change to use dynamic generated headers.

Right, the arm64 table is currently shared with arc/hexagon/loongarch/riscv.

There won't be any new arm64 specific syscalls, but the kernel's
own uapi/asm-generic/unistd.h file is going away, so the
tools/include/uapi/asm-generic/unistd.h copy will become harder
to keep in sync with scripts/syscall.tbl in the future.

>> I'm still a bit lost about why Arm64 copying
>> the generated header is considered a special case when we already have these
>> x86 ones.
>
> If arm64 maintains its own unistd.h, there is a concern that other
> architectures will do the same, and we will end up maintaining
> fragmented headers for each architecture.
>
> Later, if we need to support architecture specific syscalls, we should
> explore better approaches, such as using generated headers (e.g.,
> make headers) to provide UAPI headers instead.

I think the more important issue with the current code is that
we don't support the older architectures besides x86: arm32, powerpc,
s390, mips, etc all have a custom syscall.tbl file like x86 but
don't have any asm/unistd.h installed in tools. If we want to
support any of them in the future, we should start generating the
files the same way we do for the kernel. There is already a copy
of the syscall.tbl files in tools/perf/arch/*/entry/syscalls/syscall*.tbl
and the arch/mips/kernel/syscalls/Makefile
just not the corresponding scripts/syscallhdr.sh.

     Arnd