On Sun, Apr 8, 2018 at 11:39 PM, Ingo Molnar <mi...@kernel.org> wrote: > > I see - so it's _not_ the same function call signature, but a wrapper with a > sign-extended version, which is fair and useful. So on architectures where > this > matters there's type conversion and active code generated.
Exactly. Some architectures have that as part of their ABI. On Powerpc, for example, when you pass an "int" argument, the ABI specifies that you have to sign-extend the register in the caller to 64 bits. And the generated code actually depends on that behavior, in that maybe it first tests the 32 bit value, but then _uses_ the full 64 bits, knowing that the caller sign-extended it properly. This is a problem with the system call interface, since the caller isn't a trusted entity, and user space could pass an "int" value with the high bits set to something that _isn't_ the sign-extended thing, so then the compiler generates unsafe code. On x86, this never happens, since x86 doesn't have that "hidden higher bits matter" ABI model. So that part of the wrapper will be a complete no-op. But some other architectures depend on it. Linus