summaryrefslogtreecommitdiff
path: root/arch/arm/common/it8152.c
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2012-02-21 17:24:20 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2012-02-21 17:24:20 -0800
commitfaf309009e2e18d30c032b7d9479f29b91677c37 (patch)
tree09a22833eaf02886cc1de6ac513aad1143dcf822 /arch/arm/common/it8152.c
parent797a796a13df6b84a4791e57306737059b5b2384 (diff)
sys_poll: fix incorrect type for 'timeout' parameter
The 'poll()' system call timeout parameter is supposed to be 'int', not 'long'. Now, the reason this matters is that right now 32-bit compat mode is broken on at least x86-64, because the 32-bit code just calls 'sys_poll()' directly on x86-64, and the 32-bit argument will have been zero-extended, turning a signed 'int' into a large unsigned 'long' value. We could just introduce a 'compat_sys_poll()' function for this, and that may eventually be what we have to do, but since the actual standard poll() semantics is *supposed* to be 'int', and since at least on x86-64 glibc sign-extends the argument before invocing the system call (so nobody can actually use a 64-bit timeout value in user space _anyway_, even in 64-bit binaries), the simpler solution would seem to be to just fix the definition of the system call to match what it should have been from the very start. If it turns out that somebody somehow circumvents the user-level libc 64-bit sign extension and actually uses a large unsigned 64-bit timeout despite that not being how poll() is supposed to work, we will need to do the compat_sys_poll() approach. Reported-by: Thomas Meyer <thomas@m3y3r.de> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'arch/arm/common/it8152.c')
0 files changed, 0 insertions, 0 deletions