Hello Arnd,

On 6/25/20 3:48 AM, Arnd Bergmann wrote:

On Fri, Jun 12, 2020 at 8:51 PM André Almeida [off-list ref] wrote:

quoted

- The proposed interface uses ktime_t type for absolute timeout, and I
  assumed that it should use values in a nsec resolution. If this is true,
  we have some problems with i386 ABI, please check out the
  COMPAT_32BIT_TIME implementation in patch 1 for more details. I
  haven't added a time64 implementation yet, until this is clarified.

ktime_t is not part of the uapi headers, and has always been considered
an implementation detail of the kernel so far. I would argue it should
stay that way. The most sensible alternatives would be to either use
a "__u64 *timeout" argument for a relative timeout, or a
"struct __kernel_timespec *timeout" for an absolute timeout.

old_time32_t also makes no sense for multiple reasons:

- It's another kernel internal type and not part of the uapi headers
- your time32 call has different calling conventions from your time64
  version, not just a different type.
- there should be no need to add syscalls that are known to be buggy
  when there is a replacement type that does not have that bug.

Thanks for the input. As stated by tglx at [1], "supporting relative
timeouts is wrong to begin with", my next patch will use "struct
__kernel_timespec *timeout" for an absolute timeout.

quoted

- Is expected to have a x32 ABI implementation as well? In the case of
  wait and wake, we could use the same as x86_64 ABI. However, for the
  waitv (aka wait on multiple futexes) we would need a proper x32 entry
  since we are dealing with 32bit pointers.

For new syscalls, I'd actually recommend not having a separate
entry point, but just checking 'if (in_compat_syscall())' inside of the
implementation to pick one behavior vs the other when accessing
the user pointers. This keeps the implementation simpler and
avoids assigning a new x32 syscall number that would be different
from all the other architectures.

Cool, this will make the code cleaner.

      Arnd

Thanks,
	André

[1] https://lkml.org/lkml/2019/7/31/1499