From: Arnd Bergmann <arnd@arndb.de>
To: Bamvor Zhang Jian <bamvor.zhangjian@linaro.org>
Cc: John Stultz <john.stultz@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>,
y2038@lists.linaro.org, lkml <linux-kernel@vger.kernel.org>,
Baolin Wang <baolin.wang@linaro.org>
Subject: Re: [RFC PATCH v2 1/4] y2038: add 64bit time_t support in timeval for 32bit architecture
Date: Thu, 09 Jul 2015 12:26:16 +0200 [thread overview]
Message-ID: <1819798.ecaiCVEJzg@wuerfel> (raw)
In-Reply-To: <559E38B7.2030201@linaro.org>
On Thursday 09 July 2015 17:02:47 Bamvor Zhang Jian wrote:
> On 07/09/2015 04:09 AM, John Stultz wrote:
> > On Mon, Jun 29, 2015 at 7:23 AM, Bamvor Zhang Jian
> > <bamvor.zhangjian@linaro.org> wrote:
> >> +int get_timeval64(struct timeval64 *tv,
> >> + const struct __kernel_timeval __user *utv)
> >> +{
> >> + struct __kernel_timeval ktv;
> >> + int ret;
> >> +
> >> + ret = copy_from_user(&ktv, utv, sizeof(ktv));
> >> + if (ret)
> >> + return -EFAULT;
> >> +
> >> + tv->tv_sec = ktv.tv_sec;
> >> + if (!IS_ENABLED(CONFIG_64BIT)
> >> +#ifdef CONFIG_COMPAT
> >> + || is_compat_task()
> >> +#endif
> >
> > These sorts of ifdefs are to be avoided inside of functions.
>
> > Instead, it seems is_compat_task() should be defined to 0 in the
> > !CONFIG_COMPAT case, so you can avoid the ifdefs and the compiler can
> > still optimize it out.
> I add this ifdef because I got compile failure on arm platform. This
> file do not include the <linux/compat.h> directly. And in arm64,
> compat.h is included implicitily.
> So, I am not sure what I should do here. Include <linux/compat.h> in
> this file directly or add a this check at the beginning of this file?
>
> #ifndef is_compat_task
> #define is_compat_task() (0)
> #endif
>
Actually I think we can completely skip this test here: Unlike
timespec, timeval is defined in a way that always lets user space
use a 64-bit type for the microsecond portion (suseconds_t tv_usec).
I think we should simplify this case and just assume that user space
does exactly that, and treat a tv_usec value with a nonzero upper
half as an error.
I would also keep this function local to the ppdev driver, in order
to not proliferate this to generic kernel code, but that is something
we can debate, based on what other drivers need. For core kernel
code, we should not need a get_timeval64 function because all system
calls that pass a timeval structure are obsolete and we don't need
to provide 64-bit time_t variants of them.
Arnd
next prev parent reply other threads:[~2015-07-09 10:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-29 14:23 [RFC PATCH v2 0/4] Convert ppdev to y2038 safe Bamvor Zhang Jian
2015-06-29 14:23 ` [RFC PATCH v2 1/4] y2038: add 64bit time_t support in timeval for 32bit architecture Bamvor Zhang Jian
2015-07-08 20:09 ` John Stultz
2015-07-09 9:02 ` Bamvor Zhang Jian
2015-07-09 10:26 ` Arnd Bergmann [this message]
2015-07-15 3:18 ` Bamvor Zhang Jian
2015-07-15 9:33 ` Arnd Bergmann
2015-06-29 14:23 ` [RFC PATCH v2 2/4] time64: add timeval64 helper for compat syscalls Bamvor Zhang Jian
2015-06-29 14:23 ` [RFC PATCH v2 3/4] ppdev: add compat ioctl Bamvor Zhang Jian
2015-07-08 20:17 ` John Stultz
2015-07-08 21:28 ` [Y2038] " Arnd Bergmann
2015-06-29 14:23 ` [RFC PATCH v2 4/4] y2038: convert ppdev to 2038 safe Bamvor Zhang Jian
2015-07-08 21:34 ` Arnd Bergmann
2015-07-08 21:36 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1819798.ecaiCVEJzg@wuerfel \
--to=arnd@arndb.de \
--cc=bamvor.zhangjian@linaro.org \
--cc=baolin.wang@linaro.org \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=y2038@lists.linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox