mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Leo Yan" <leo.yan@linaro.org>
Cc: "Vincent Whitchurch" <vincent.whitchurch@axis.com>,
	"Arnaldo Carvalho de Melo" <acme@kernel.org>,
	"Hans-Peter Nilsson" <hp@axis.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	"John Garry" <john.garry@huawei.com>,
	"Will Deacon" <will@kernel.org>,
	"Mathieu Poirier" <mathieu.poirier@linaro.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
	"Jiri Olsa" <jolsa@redhat.com>,
	"Namhyung Kim" <namhyung@kernel.org>,
	"Kim Phillips" <kim.phillips@arm.com>
Subject: Re: [PATCH] perf arm64: Fix mksyscalltbl, don't lose syscalls due to sort -nu
Date: Mon, 12 Dec 2022 14:42:36 +0100	[thread overview]
Message-ID: <8da67034-2073-4dce-8dc5-de5277bdf4b4@app.fastmail.com> (raw)
In-Reply-To: <Y5cH4I8XD8804hqa@leoy-yangtze.lan>

On Mon, Dec 12, 2022, at 11:52, Leo Yan wrote:
> Hi Arnd,
>
> On Fri, Nov 25, 2022 at 02:56:31PM +0100, Arnd Bergmann wrote:
>> On Fri, Nov 25, 2022, at 13:54, Leo Yan wrote:
>> > On Fri, Nov 25, 2022 at 12:53:10PM +0100, Vincent Whitchurch wrote:
>> 
>> >> It looks like this patch was never applied?  AFAICS it is still needed
>> >> on current HEAD and it still applies cleanly.
>> >
>> > Thanks a lot for bringing up this.
>> >
>> > Before there have a discussion [1] for refactoring Arm64 system call
>> > table but it didn't really happen.
>> 
>> I actually worked on this last week and did a new series to convert
>> the old asm-generic/unistd.h header into the syscall.tbl format,
>> and change arm64 to use that.
>> 
>> You can find my work in the 'syscall-tbl' branch of my asm-generic
>> tree [1]. This has only seen light build testing so far, and is
>> probably still buggy, but most of the work is there. The missing
>> bits are the Makefiles for the other seven architectures using
>> asm-generic/unistd.h, and checking the output to ensure the
>> contents are still the same.
>
> Thanks a lot for sharing the patch set.
>
> I went through the whole patch set, below are several things I observed:

Thanks for the review!

> - I did a quick compilation but found building failure, this failure
>   is caused by the first patch "arm64: convert unistd_32.h to
>   syscall.tbl format", it removes the macro __NR_compat_syscalls.
>
>   In file included from ./include/vdso/const.h:5,
>                  from ./include/linux/const.h:4,
>                  from ./arch/arm64/include/asm/alternative-macros.h:5,
>                  from ./arch/arm64/include/asm/alternative.h:5,
>                  from ./arch/arm64/include/asm/lse.h:15,
>                  from ./arch/arm64/include/asm/cmpxchg.h:14,
>                  from ./arch/arm64/include/asm/atomic.h:16,
>                  from ./include/linux/atomic.h:7,
>                  from ./include/linux/refcount.h:95,
>                  from kernel/seccomp.c:18:
>   ./arch/arm64/include/asm/seccomp.h:27:33: error: 
> ‘__NR_compat_syscalls’ undeclared here (not in a function); did you 
> mean ‘in_compat_syscall’?
>      27 | # define SECCOMP_ARCH_COMPAT_NR __NR_compat_syscalls
>         |                                 ^~~~~~~~~~~~~~~~~~~~
>   ./include/uapi/linux/const.h:34:40: note: in definition of macro 
> ‘__KERNEL_DIV_ROUND_UP’
>      34 | #define __KERNEL_DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))
>         |                                        ^
>   ./include/linux/types.h:11:28: note: in expansion of macro 
> ‘BITS_TO_LONGS’
>      11 |         unsigned long name[BITS_TO_LONGS(bits)]
>         |                            ^~~~~~~~~~~~~
>   kernel/seccomp.c:168:9: note: in expansion of macro ‘DECLARE_BITMAP’
>     168 |         DECLARE_BITMAP(allow_compat, SECCOMP_ARCH_COMPAT_NR);
>         |         ^~~~~~~~~~~~~~
>   kernel/seccomp.c:168:38: note: in expansion of macro 
> ‘SECCOMP_ARCH_COMPAT_NR’
>     168 |         DECLARE_BITMAP(allow_compat, SECCOMP_ARCH_COMPAT_NR);
>         |                                      ^~~~~~~~~~~~~~~~~~~~~~

Sorry about that, I thought I had fixed it already. I'll need to
get back to the series and make sure this works.

> - The patch set breaks git bisection, when I use "git bisect" I can
>   find more building failures caused by middle patches.

Ok, I'll check these out as well.

> - The patch "arm64: generate 64-bit syscall.tbl" removes macros:
>
>   __ARCH_WANT_RENAMEAT
>   __ARCH_WANT_NEW_STAT
>   __ARCH_WANT_SET_GET_RLIMIT
>   __ARCH_WANT_TIME32_SYSCALLS
>   __ARCH_WANT_SYS_CLONE3
>   __ARCH_WANT_MEMFD_SECRET
>
>   Seems to me we still need to enable these macros so can enable Arm64
>   specific system calls?

The system call selection is now controlled with the line

ABIS_unistd64.h := common,64,renameat,newstat,rlimit,mmu,clone3,memfd_secret

which picks the types of ABIs that are enabled when converting
the syscall.tbl file into the headers. Removing these was
intentional, but I now see that we still need to define __ARCH_WANT_NEW_STAT
and __ARCH_WANT_SYS_CLONE3 because those two are referenced not
just in unistd.h but also in fs/stat.c and kernel/fork.c.

I'll put this on the list of things to check for the other architectures,
in addition to comparing the resulting syscall table object and the
generated asm/unistd.h.

> - We also need to update the header files:
>   tools/include/uapi/asm-generic/unistd.h
>
> You are welcome to CC me when you send out formal patches to mailing
> list and I can test it (and look if can refine perf code for this).

Ok, thanks again.

    Arnd

  reply	other threads:[~2022-12-12 13:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-28  2:39 Hans-Peter Nilsson
2020-12-29  3:09 ` Leo Yan
2022-11-25 11:53   ` Vincent Whitchurch
2022-11-25 12:54     ` Leo Yan
2022-11-25 13:56       ` Arnd Bergmann
2022-12-02 18:39         ` Arnaldo Carvalho de Melo
2022-12-12 10:52         ` Leo Yan
2022-12-12 13:42           ` Arnd Bergmann [this message]
2022-12-21 20:15         ` Arnaldo Carvalho de Melo
2022-12-21 20:21           ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8da67034-2073-4dce-8dc5-de5277bdf4b4@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=hp@axis.com \
    --cc=john.garry@huawei.com \
    --cc=jolsa@redhat.com \
    --cc=kim.phillips@arm.com \
    --cc=leo.yan@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.poirier@linaro.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=vincent.whitchurch@axis.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®