Re: [PATCH v4 00/24] ILP32 for ARM64

From: Dr. Philipp Tomsich
Date: Wed Apr 15 2015 - 06:32:07 EST


even though this may now be moot, as weâll out a 32bit time_t on ILP32 (making it
very similar to n32 on MIPS), hereâs the the info on what would be affected by
changing timespec.

Below is a (hopefully) full list of system calls, helper functions and exposed data
structures (with some comments on what will need to be done to resolve this change)
that would be affected by introducing an other timespec (letâs call it ilp32_timespec
for the ease of discussion) consisting of a 64bit time_t and a 32bit integer.

> On 14 Apr 2015, at 18:55, Catalin Marinas <catalin.marinas@xxxxxxx> wrote:
> As I mentioned above, timespec and possibly other structures no longer
> like any of the existing ABIs. Do we know how many syscalls are
> affected?

Hereâs everything that affected (details on how to resolve are below) in no particular
> syscall: utimensat
> syscall: io_getevents
> syscall: select
> internal: poll_select_copy_remaining (via select) [+on stack: struct compat_timespec rts;]
> syscall: pselect6
> internal: do_compat_pselect (via pselect6) [+on stack: struct compat_timespec ts;]
> syscall: ppoll [+on stack: struct compat_timespec ts;]
> syscall: nanosleep
> internal: compat_nanosleep_restart (via nanosleep)
> syscall: clock_gettime
> syscall: clock_settime
> syscall: clock_getres
> syscall: clock_nanosleep
> syscall: rt_sigtimedwait
> syscall: sched_rr_get_interval
> internal: compat_get_timespec
> internal: compat_put_timespec
> syscall: futex
> syscall: recvmmsg
> file_operations: compat_sock_ioctl
> internal: do_siocgstampns (via compat_sock_ioctl_trans via compat_sock_ioctl)
> syscall: semtimedop
> syscall: mq_timedsend
> syscall: mq_timedreceive
> internal: compat_convert_timespec
> syscall: timer_settime
> syscall: timer_gettime
> syscall: timerfd_settime
> syscall: timerfd_gettime
> struct: itimerspec
> internal: get_compat_itimerspec
> internal: put_compat_itimerspec
> struct: snd_pcm_status32
> internal: snd_pcm_ioctl_sync_ptr_compat
> struct: snd_pcm_mmap_status32
> internal: snd_pcm_status_user_compat
> struct: v4l2_event32
> internal: put_v4l2_event32 (via do_video_ioctl)
> struct: restart_block [simple change: additional field; for nanosleep]
> internal: put_cmsg_compat [on stack: struct compat_timespec cts[3];]
> struct: snd_rawmidi_status32
> internal: snd_rawmidi_ioctl_status_compat (handles snd_rawmidi_status32)
> struct: snd_timer_status32
> internal: snd_timer_user_status_compat
> struct: struct snd_pcm_mmap_status32
> internal: snd_pcm_ioctl_sync_ptr_compat (handles snd_pcm_mmap_status32)
> struct: snd_pcm_status32
> internal: snd_pcm_status_user_compat (handles snd_pcm_status32)

For dealing with them, we can roughly use the following strategy (I may have lost
1. The timespec/compat_timespec/ilp32_timespec is ever only referenced through
its memory address and used for userspace/kernel-transfers. For these cases
we mere need to extend the compat_get_timespec and compat_put_timespec
functions to recognize the ILP32-caseâ same for compat_convert_timespec

For the affected syscalls, the ILP32 implementation should route through the
compat-layer. This can be done in the following cases (Iâm leaving the compat
off for readability):

One helper called through an ioctl will also need to pick this us:
do_siocgstampns (through compat_sock_ioctl)

A special case is the nanosleep syscall and its restart-helper: even though less
apparent, this would be covered by the changes to compat_get_timespec and
compat_put_timespec also (as thereâs only a pointer to a compat_timespec

2. An similar change will be required for anything that uses itimerspec (as that
structure contains two timespec elements):

3. A compat_timespec is currently created on the stack, even though itâs used
only for a get_user/put_user in a few cases; this can be resolved by changing
to use compat_get_timespec/compat_put_timespec. Once this has been
done, then the changes from step 1 should also extend to these case.

Instances include:
poll_select_copy_remaining (helper function called from âselectâ)
do_compat_pselect (helper function called from âpselect6â)

The syscalls associated with these helper-functions need to be passed
through the compat-layer for ILP32 also (as functions in their call chain
are affected):

4. Thereâs some limited expose in the v4l and snd subsystems, primarily in
ioctl data-structures. For these, thereâs typically already a compat-layer
function and a compat-ioctl. So these will require a few (5 by my count) of
individual fixes.

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