[PATCH v2 2/7] y2038: Introduce __ASSUME_64BIT_TIME define

[Lukasz Majewski]

Hi Joseph,

> On Mon, 6 May 2019, Lukasz Majewski wrote:
> 
> > > So, which is (or will be) the case in 5.1 release?  Padding
> > > ignored or not?  
> > 
> > As confirmed in the other mail - the padding is ignored in Linux
> > kernel (and the fix patch for x32 is up its way to be pulled).  
> 
> Did the patch to ignore padding (for compat syscalls under 64-bit
> kernels, non-x32) make it into the final 5.1 release?

As fair as I can tell, it was not pulled to 5.1.

> 
> > > It's possible it's __SYSCALL_WORDSIZE, except that's only defined
> > > for x86_64, so would need to be made more generally available if
> > > it's to be used here.  And if made more generally available, it
> > > would need a careful comment explaining exactly what it means.  
> > 
> > Cannot we just use __WORDSIZE != 64  as proposed by Stepan?
> > (for x32 we would have it defined by default)
> > 
> > #if __WORDSIZE != 64
> > # if __LINUX_KERNEL_VERSION >= 0x050100
> > #  define __ASSUME_TIME64_SYSCALLS 1
> > # endif
> > #endif  
> > 
> > Such approach would allow us to avoid introducing new abstraction
> > (__SYSCALL_WORDSIZE).  
> 
> There are lots of implementation possibilities, including using 
> __WORDSIZE and undefining for x32, or using __WORDSIZE and defining
> the __NR_* macros locally for x32.
> 
> At the present stage of review, I'm not really concerned with such 
> implementation details.  Rather, I'm reviewing things at the level of 
> concepts and abstractions, and how we document those concepts and 
> abstractions.  The things we need to define here are:
> 
> * What are the sets of syscalls related to 64-bit time, with the
> property that, in any given kernel, either all the syscalls in such a
> set are present, or all the syscalls in such a set are absent?

The 64 bit versions of syscalls (like clock_settime64 or
clock_gettime64) are available since 5.1 kernel (as you posted already
the following patch: "Update syscall-names.list for Linux 5.1" .

I've now only focused on clock_settime(64) to make the discussion more
concrete.

> 
> Right now, maybe there's only one such set, and the subset of it
> being used in glibc can be defined by listing the syscalls.  In
> future, there may well be more than one such set - for example, if
> syscalls that currently only have versions using timeval get new
> versions using timespec that are added even on architectures where
> the pre-5.1 kernel syscall interface already uses 64-bit time.

This may also happen, yes.

> 
> * For each set of syscalls, what is the *best* logical description of
> the set of kernel configurations that has those syscalls? 

IMHO, the description is as follows:

"Time related syscalls with explicit 64 bit time support to be run on
archs with 32 bit pointer/long (__WORDSIZE==32)"

Hence the __ASSUME_TIME64_SYSCALLS seems to be a descriptive name (as
even in the kernel some syscalls end with _time64 suffix - i.e.
sched_rr_get_interval_time64) .

> There may
> be many equivalent descriptions of the current set of such
> configurations; we need to find one that is correct, unambiguous,
> succinct, close to the actual logic in the kernel that determines
> whether those syscalls are present, and has the least chance of being
> inaccurate for future kernel configurations.
> 

As stated above - those syscalls are supposed to be used on systems
with __WORDSIZE==32 [*] to provide support for 64 bit time (Y2038 safe).

> Once we have those concepts clearly defined, we can then look at how
> to translate them into code.
> 
> Since (a) future architectures all use asm-generic and (b) the
> asm-generic code uses __BITS_PER_LONG == 32, that suggests something
> in terms of the size of "long" is the right way to describe the
> condition for the presence of the syscalls - at which point you then
> need to discuss how the size of "long" can vary between ABIs, and how
> in the x32 case the size of "long" in the syscall interface is not
> the same as the normal size of that C type.
> 
> Within glibc, __WORDSIZE corresponds to the size of "long", so that
> in turn suggests an implementation approach based on __WORDSIZE in
> some way,

That was the approach took in v3 of the patch set [1] (I do send patches
to show the big picture about the idea and most of all - IMHO it is
easier to discuss the concept with some code available)

>  if you have an exception for x32.
> 

Yes, x32 is special :-) (I'm wondering though what is the percentage of
glibc users, who use this particular ABI...)

Note:

[*] - x32 is a special case and (as proposed in the v3 patch set) shall
#undef the __ASSUME_TIME64_SYSCALLS as it uses syscalls from x86_64

[1] - https://patchwork.ozlabs.org/patch/1096343/

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20190508/e403ecbe/attachment.sig>