From: Christian Brauner <brauner@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] vfs mount api updates
Date: Tue, 9 Jan 2024 15:23:58 +0100 [thread overview]
Message-ID: <20240109-bitten-anzetteln-af76df71c9b3@brauner> (raw)
In-Reply-To: <CAHk-=wjfbjuNxx7jWa144qVb5ykwPCwVWa26tcFMvE-Cr6=vMg@mail.gmail.com>
On Mon, Jan 08, 2024 at 05:02:48PM -0800, Linus Torvalds wrote:
> On Fri, 5 Jan 2024 at 04:47, Christian Brauner <brauner@kernel.org> wrote:
> >
> > This contains the work to retrieve detailed information about mounts via two
> > new system calls.
>
> Gaah. While I have an arm64 laptop now, I don't do arm64 builds in
> between each pull like I do x86 ones.
>
> I *did* just start one, because I got the arm64 pull request.
>
> And this fails the arm64 build, because __NR_statmount and
> __NR_listmount (457 and 458 respectively) exceed the compat system
> call array size, which is
>
> arch/arm64/include/asm/unistd.h:
> #define __NR_compat_syscalls 457
>
> I don't think this is a merge error, I think the error is there in the
> original, but I'm about to go off and have dinner, so I'm just sending
> this out for now.
>
> How was this not noted in linux-next? Am I missing something?
>
> Now, admittedly this looks like an easy mistake to make due to that
> whole odd situation where the compat system calls are listed in
> unistd32.h, but then the max number is in unistd.h, but I would still
> have expected this to have raised flags before it hit my tree..
Bah.
I think Will already provided a good explantion for how this came to be.
But for full transparency: I've ran into this exact issue before with
other system calls we added and I've been notified/saved by Arnd who
pointed out that this file needs to be updated.
32 bit arm has this annoying extra file where you need to bump that
single line. But it'd be nice if we finally had some:
./add-new-syscall
script that could automate adding a new system call number into all
relevant architectures.
Sorry for the breakage. I see that it's already fixed. I'll make a note
to reactivate my cross-compilation toolsuite.
prev parent reply other threads:[~2024-01-09 14:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-05 12:46 [GIT PULL] vfs mount api updates Christian Brauner
2024-01-08 20:00 ` pr-tracker-bot
2024-01-09 1:02 ` Linus Torvalds
2024-01-09 9:52 ` Will Deacon
2024-01-09 10:45 ` Sedat Dilek
2024-01-09 11:56 ` Stephen Rothwell
2024-01-09 14:23 ` Christian Brauner [this message]
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=20240109-bitten-anzetteln-af76df71c9b3@brauner \
--to=brauner@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--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