[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190420002009.l65upn2t3qqoj5uy@sghpc.golosunov.pp.ru>
Date: Sat, 20 Apr 2019 04:20:10 +0400
From: Stepan Golosunov <stepan@...osunov.pp.ru>
To: Lukasz Majewski <lukma@...x.de>, Arnd Bergmann <arnd@...db.de>,
Deepa Dinamani <deepa.kernel@...il.com>
Cc: libc-alpha@...rceware.org, Paul Eggert <eggert@...ucla.edu>,
Joseph Myers <joseph@...esourcery.com>,
John Stultz <john.stultz@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/6] y2038: linux: Provide __clock_settime64
implementation
15.04.2019 в 00:08:38 +0200 Lukasz Majewski написал:
> +# if defined __NR_clock_settime64
> + /* Make sure that passed __timespec64 struct pad is 0. */
> + struct __timespec64 ts = *tp;
> + ts.tv_pad = 0;
> + return INLINE_SYSCALL_CALL (clock_settime64, clock_id, &ts);
Isn't kernel supposed to zero out padding on its own?
At least comment in kernel's get_timespec64 says so:
/* Zero out the padding for 32 bit systems or in compat mode */
if (IS_ENABLED(CONFIG_64BIT_TIME) && in_compat_syscall())
kts.tv_nsec &= 0xFFFFFFFFUL;
The code looks buggy though. It fails to zero out the padding in
32-bit kernels. That part is probably broken since
98f76206b3350 ("compat: Cleanup in_compat_syscall() callers").
And, hmm, is CONFIG_64BIT_TIME enabled anywhere?
Powered by blists - more mailing lists