"H. Peter Anvin" [off-list ref] writes:

On July 3, 2026 4:39:18 AM PDT, Sven Schnelle [off-list ref]
wrote:

quoted

Michal Suchánek [off-list ref] writes:

quoted

The same could be asked of syscall_enter_from_user_mode. I find it

very

quoted

quoted

odd. Why does it conflate the syscall number with its return value?

It never uses the syscall number passed in except when returning it
unchanged. When it pokes the registers it reads the syscall number

from

quoted

quoted

them.

If the caller of syscall_enter_from_user_mode only read the syscall
number from the registers when syscall_enter_from_user_mode returns

and

quoted

quoted

indicates the syscall should be still executed this whole shenigan

would

quoted

I agree. The fact that if (nr < NR_syscall) just works because -1

gets

quoted

casted to 0xffffffff and is therefore out of bounds is very odd.

Not at all strange. It is an *extremely* common construct in C,
especially for range checking values into [0, n).

A clear indication that this is not as common as you think is that
there's an extra comment in arch/x86/entry/syscall_64.c:

       /*
	* Convert negative numbers to very high and thus out of range
	* numbers for comparisons.
	*/

If everyone knows what this is the comment wouldn't be necessary. But
that cast is not the thing i'm really interested in - if it stays
that way, fine with me. But I would like to see the change from Michal
going in which untangles the secure_computing() return value from the
syscall number. Because this behaviour is very subtle and removing that
would make things easier. (And also easier to read/audit, which is
always importand with security related code, which seccomp/syscall
clearly is).

In addition to being idiomatic, keep in mind that this is one of the
absolutely most performance critical paths in the entire kernel. One
of the fundamental cornerstones behind Unix is to keep system calls
cheap so that they can be simple building blocks for more complex
operations. It is not the only possible design philosophy, but it is
the one we chose to adopt, quite successfully.

The downside? Squeezing every possible cycle out of the system call
path becomes one of the most essential tuning tasks. The good part is
that keeping the system call path clean also makes it maintainable,
even when there are quirks.

I haven't measured it, but I doubt that the unsigned vs signed syscall
bounds check makes a difference in real world scenarios. Even for
ni_syscall cases it would be small. With the C entry code we have
nowadays such optimizations should be left to the compiler. I wouldn't
be surprised if the generated code is even the same.

But as written above, I don't really care about this.