On Fri, Jan 18, 2019 at 8:53 PM Andy Lutomirski luto@kernel.org wrote:
I think we have two issues if we reuse those numbers for new syscalls. First, I'd really like to see new syscalls be numbered consistently everywhere, or at least on all x86 variants, and we can't on x32 because they mean something else. Perhaps more importantly, due to what is arguably a rather severe bug, issuing a native x86_64 syscall (x32 bit clear) with nr in the range 512..547 does *not* return -ENOSYS on a kernel with x32 enabled. Instead it does something that is somewhat arbitrary. With my patch applied, it will return -ENOSYS, but old kernels will still exist, and this will break syscall probing.
Can we perhaps just start the consistent numbers above 547 or maybe block out 512..547 in the new regime?
I'm definitely fine with not reusing them ever, and jumping from 511 to 548 when we get there on all architectures, if you think that helps.
While we could also jump to 548 *now*, I think that would be a bit wasteful. Syscall numbers are fairly cheap, but not entirely free, especially when you consider architectures like mips that have an upper bound of 1000 syscalls before they have to get inventive.
Arnd