On July 3, 2026 4:39:18 AM PDT, Sven Schnelle <[email protected]> wrote: >Michal Suchánek <[email protected]> writes: > >> The same could be asked of syscall_enter_from_user_mode. I find it very >> 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 >> 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 >> indicates the syscall should be still executed this whole shenigan would > >I agree. The fact that if (nr < NR_syscall) just works because -1 gets >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). 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.
