[lkml]   [2004]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectcompat syscall args

Arnd asked:

> If sparc64 has this problem only for the fifth syscall argument,
> does that mean that e.g. compat_sys_futex and
> compat_sys_mq_timed{send,receive} have the same bug? If this is
> a more general, i.e. not limited to the last argument, there is a
> potential problem in lots of syscalls.

Here is the issue. In the sparc64 C calling conventions, it is
assumed that 32-bit signed values are sign extended by the

This means that, at syscall invocation time, we have to choose
between either:

1) sign extending all syscall args for the C code, then explicitly
zero-extending all non-signed syscall args. This would require
the most amount of compat layer code help.

2) zero extending all syscall args for the C code, then expliticly
sign-extending all signed syscall args.

3) some mixture of 1 and 2

#3 is what sparc64 does, it hits the highest number of system
call arguments correctly. Specifically we:

arg0: zero-extend
arg1: zero-extend
arg2: zero-extend
arg3: zero-extend
arg4: leave as-is
arg5: leave as-is

I remember discussing this with Andi Kleen before.

Each platform is going to behave differently in this area, so
I suppose the right thing to do really is to have the arch
specific code use little zero/sign extender stubs when necessary
so that the compat layer can assume that the args are properly
sign/zero extended already. I guess this is how I'll fix this
up on sparc64 for now.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:03    [W:0.058 / U:1.096 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site