Re: [PATCH v10] y2038: Provide conversion helpers for struct __timespec64

["Dmitry V. Levin" <ldv at altlinux dot org>]

On Wed, Dec 04, 2019 at 12:04:32PM +0100, Lukasz Majewski wrote:
> Hi Florian,
> 
> > * Dmitry V. Levin:
> > 
> > > Unfortunately, this didn't work out as intended because Linux
> > > kernel prior to commit 7b8474466ed97be458c825f34a85f2c2b84c3f95
> > > (including released version v5.4) did not zero the upper 32-bits of
> > > tv_nsec on 32-bit architectures, which means that we have to do it
> > > in valid_timeval_to_timespec64 and valid_timespec_to_timespec64
> > > instead.  
> > 
> > Can't we treat this as a critical kernel bug that needs fixing before
> > the kernels become usable?
> > 
> > I'm concern that this will make initializers for struct timespec64
> > invalid.  glibc can't intercept everything that goes into the kernel.
> > 
> 
> There was a discussion regarding explicit clearing of data passed /
> read from the kernel during development of this patch.
> 
> The agreement was that we rely on the kernel in this matter and no
> explicit clearing is necessary in glibc.

So the agreement was to push the garbage to the kernel assuming it will
handle the matter?

Has anybody considered what it will look like in a tracer's output?

clock_nanosleep_time64(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=13185818429535213454}, {tv_sec=0, tv_nsec=111245472}) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)

Confusing, isn't it?

This happens because the type of syscall argument on the kernel side is a
pointer to struct __kernel_timespec where the type of tv_nsec is long long.


-- 
ldv

Attachment: signature.asc
Description: PGP signature