On Thu, Jul 02, 2026 at 10:45:54PM +0200, Thomas Gleixner wrote: > On Thu, Jul 02 2026 at 13:45, Michal Suchánek wrote: > > On Thu, Jul 02, 2026 at 01:24:57PM +0200, Thomas Gleixner wrote: > >> On Wed, Jul 01 2026 at 19:42, Michal Suchánek wrote: > >> > The return value of syscall_enter_from_user_mode is used both for the > >> > adjusted syscall number and the indicator that a syscall should be > >> > skipped. > >> > > >> > As seccomp can be invoked on any syscall, including invalid ones this > >> > somewhat undermines seccomp. > >> > > >> > While the seccomp variants that terminate the process do not need to > >> > care about this for the filter that sets the syscall return value this > >> > disctinction is required. > >> > >> You completely fail to explain why and what actual problem you are > >> trying to solve. At least I can't figure it out from the above word > >> salad. > > > > syscall_enter_from_user_mode returns the new syscall number after doing > > something arbitrarry with it, including running seccomp. > > > > Wehn the syscall is already handled, eg. by seccomp filtering it returns > > -1 as the new syscall number. -1 is an invalid syscall number but it can > > still be filtered by seccomp. > > Once syscall_enter_from_user_mode() returns -1 nothing can filter it > anymore. > > > When the syscall number was -1 to start with it's not possible to > > determine if the syscall was fileterd from the return value. s390 > > returns the filtered state in a flag it sets on the regs structure, > > avoiding this problem. > > What needs to determine whether the syscall was filtered or not?
The code that executes syscall_enter_from_user_mode() needs to determine that. After syscall_enter_from_user_mode() returns the syscall needs to be executed or skipped. 'Executing' an invalid syscall boils down to setting the return value to -ENOSYS. But if the syscall number returned is -1 was the syscall filtered and the return value set by syscall_enter_from_user_mode() or should it be set by the caller to -ENOSYS? > > > However, the API should be specified in a way that does not require > > everyone implementing such flag. > > Which exact problem does the flag solve? To be able to tell if the syscall was handled or no, the return value from syscall_enter_from_user_mode() is inconclusive. That's what the flag is for. To be able to tell if the syscall was handled without relying on the ambiguous return value of syscall_enter_from_user_mode(). Thanks Michal
