Hello Arnd, On 6/25/20 3:48 AM, Arnd Bergmann wrote: > On Fri, Jun 12, 2020 at 8:51 PM André Almeida <andrealmeid@xxxxxxxxxxxxx> wrote: > >> - 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. >> - 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
