linux-kernel - Re: [GIT PULL] vfs mount api updates

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] [day] [month] [year] [list]

Date: Tue, 9 Jan 2024 15:23:58 +0100
From: Christian Brauner <brauner@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Catalin Marinas <catalin.marinas@....com>, 
	Will Deacon <will@...nel.org>, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] vfs mount api updates

On Mon, Jan 08, 2024 at 05:02:48PM -0800, Linus Torvalds wrote:
> On Fri, 5 Jan 2024 at 04:47, Christian Brauner <brauner@...nel.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.