Anatomy of a system call, part 1 [LWN.net]

Anatomy of a system call, part 1

Posted Jul 13, 2014 0:00 UTC (Sun) by gb (subscriber, #58328)
Parent article: Anatomy of a system call, part 1

Why such a strange implementation taken - put values into registers, switch to ring 0, than put this values into stack? Isn't it make more sense to keep values in the registers till real syscall function which may, if it wants, push values to the stack?

to post comments

Anatomy of a system call, part 1

Posted Jul 14, 2014 9:45 UTC (Mon) by drysdale (guest, #95971) [Link] (1 responses)

Having the arguments in registers for the ring transition means that there's no need for fancy footwork to get at the userspace stack memory (compare the innards of copy_from_user()).

Storing the registers on the kernel stack allows the state of the registers to be restored on the return to userspace. But once the parameters are available on the stack, there's no need to preserve them in the registers too – the syscall can get its arguments from the stack (i.e. be asmlinkage) and can immediately use (and clobber) the registers.

Anatomy of a system call, part 1

Posted Jul 16, 2014 17:03 UTC (Wed) by nix (subscriber, #2304) [Link]

Quite. Keeping the args on the stack is a non-starter: userspace stacks are swappable, and you *don't* want to have to go checking to see if the args have been swapped out in the instant of ring transition: it's the sort of terribly narrow race that leads to code that rots and then silently breaks in almost-impossible-to-debug ways, and for almost no gain.

But obviously the args have to end up on the stack -- or, rather, have to end up whereever the C ABI for the platform says they should (possibly optimized by asmlinkage, but still, something the compiler supports).

Thanks for this article: I too have wasted entirely too much time tracking this down in pieces now and then: it's nice to have a reference here for next time. Looking forward to the next one.