syscall_get_nr(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ syscall_get_nr(9) ✨

okay so this is a page from the Kernel API Manual (section 9, kernel-land, very demure very mindful) and it's literally about figuring out which syscall a task is currently vibing in πŸ’…


🌸 NAME 🌸

syscall_get_nr β€” find what system call a task is executing


πŸŽ€ SYNOPSIS πŸŽ€

int syscall_get_nr (struct task_struct *task , struct pt_regs *regs );

πŸ¦‹ ARGUMENTS πŸ¦‹

  • task β€” the task of interest. bestie it must be blocked, no exceptions, that's the whole vibe check 🫢
  • regs β€” this is task_pt_regs of task. like, the registers of that task specifically, not some random other task's, iykyk

πŸ’– DESCRIPTION πŸ’–

so here's the tea β˜• if task is executing a system call, or it's at system call tracing about to attempt one, this returns the system call number. slay, that's it, that's the number πŸ”₯

but if task is not executing a system call β€” meaning it's blocked inside the kernel for a fault or a signal β€” then it returns -1. like, nothing's happening, no syscall, no number, just -1 😭

⚠️ okay important detail: this returns int even on 64-bit machines. only 32 bits of system call number can be meaningful. so if the actual arch value is 64 bits, this truncates to 32 bits, which means 0xffffffff means -1. yes really, that's the whole bit-truncation situation, no cap πŸ’€

and the big one, the rule that matters:

🌟 it's only valid to call this when task is known to be blocked. not guessing. not hoping. known. periodt πŸ‘‘

🌈 SEE ALSO 🌈


that's the whole page bestie, go read the whole syscall family, they're all iconic together πŸ§šπŸ’œ

β€” from ./include/asm-generic, dated October 2026, mwah πŸ’‹

πŸ“¦ where this page comes from