linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Arnd Bergmann <arnd@arndb.de>
Cc: pang.xunlei@linaro.org, peterz@infradead.org,
	heiko.carstens@de.ibm.com, paulus@samba.org, cl@linux.com,
	heenasirwani@gmail.com, linux-arch@vger.kernel.org,
	linux-s390@vger.kernel.org, y2038@lists.linaro.org,
	rafael.j.wysocki@intel.com, ahh@google.com, fweisbec@gmail.com,
	pjt@google.com, riel@redhat.com, richardcochran@gmail.com,
	tj@kernel.org, john.stultz@linaro.org, rth@twiddle.net,
	Baolin Wang <baolin.wang@linaro.org>,
	gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org, schwidefsky@de.ibm.com,
	linux390@de.ibm.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: [Y2038] [PATCH 04/11] posix timers:Introduce the 64bit methods with timespec64 type for k_clock structure
Date: Tue, 21 Apr 2015 16:14:26 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.11.1504211528040.13914@nanos> (raw)
In-Reply-To: <3755355.Xf0HbltZXg@wuerfel>

On Tue, 21 Apr 2015, Arnd Bergmann wrote:
> > COMPAT_SYSCALL_DEFINE2(timer_gettime, timer_t, timer_id,
> >                        struct compat_itimerspec __user *, setting)
> 
> As a side note, I want to kill off the get_fs()/set_fs() calls in
> the process. These always make me dizzy when I try to work out whether
> there is a potential security hole (there is not in this case), and
> they can be slow on some architectures.

Yeah. I have to take a deep breath every time I look at those :)
 
> My preferred solution is one where we end up with the same syscalls
> for both 32-bit and 64-bit, and basically use the
> compat_sys_timer_gettime() implementation (or a simplified version)
> for the existing , something like this:

No objections from my side. I was not looking into the syscall magic
yet. I just wanted to avoid the code churn and have the guts of the
syscalls factored out for simple reusage.

....
 
> Note the use of a separate __kernel_itimerspec64 for the user interface
> here, which I think will be needed to hide the differences between the
> normal itimerspec on 64-bit machines, and the new itimerspec on 32-bit
> platforms that will be defined differently (using 'long long').

Confused.

timespec64 / itimerspec64 should be the same independent of 64bit and
32bit. So why do we need another variant ?

> I would also prefer not too many people to work on the syscalls, and
> would rather have Baolin not touch any of the syscall prototypes for
> the moment.

I did not ask him to change any of the syscall prototypes. I just
wanted him to split out the guts of the syscall into a seperate static
function to avoid all that code churn.

Thanks,

	tglx

  reply	other threads:[~2015-04-21 14:15 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-20  5:57 [PATCH 00/11] Convert the posix_clock_operations and k_clock structure to ready for 2038 Baolin Wang
2015-04-20  5:57 ` [PATCH 01/11] linux/time64.h:Introduce the 'struct itimerspec64' for 64bit Baolin Wang
2015-04-20  9:49   ` Sergei Shtylyov
2015-04-20 10:55     ` Baolin Wang
2015-04-20 19:14   ` Thomas Gleixner
2015-04-20 19:59     ` Thomas Gleixner
2015-04-21  8:19     ` Baolin Wang
2015-04-20  5:57 ` [PATCH 02/11] timekeeping:Introduce the current_kernel_time64() function with timespec64 type Baolin Wang
2015-04-20  5:57 ` [PATCH 03/11] time/hrtimer:Introduce hrtimer_get_res64() with timespec64 type for getting the timer resolution Baolin Wang
2015-04-20 19:15   ` Thomas Gleixner
2015-04-20  5:57 ` [PATCH 04/11] posix timers:Introduce the 64bit methods with timespec64 type for k_clock structure Baolin Wang
2015-04-20 20:40   ` Thomas Gleixner
2015-04-21  8:59     ` [Y2038] " Arnd Bergmann
2015-04-21 14:14       ` Thomas Gleixner [this message]
2015-04-21 14:57         ` Arnd Bergmann
2015-04-21 15:13           ` Thomas Gleixner
2015-04-21 15:40             ` Arnd Bergmann
2015-04-21 20:13               ` Thomas Gleixner
2015-04-22  8:45                 ` Thomas Gleixner
2015-04-22 10:11                   ` Richard Cochran
2015-04-22 10:44                   ` David Laight
2015-04-22 11:07                   ` Arnd Bergmann
2015-04-22 13:37                     ` Thomas Gleixner
2015-04-22 13:50                     ` Arnd Bergmann
2015-04-22 14:54                       ` Richard Cochran
2015-04-22 15:37                         ` Arnd Bergmann
2015-04-22 15:14                       ` Luc Van Oostenryck
2015-04-22 15:38                         ` Arnd Bergmann
2015-04-20  5:57 ` [PATCH 05/11] time/posix-timers:Convert to the 64bit methods for k_clock callback functions Baolin Wang
2015-04-20 20:48   ` Thomas Gleixner
2015-04-21  8:36     ` Baolin Wang
2015-04-21  8:45       ` [Y2038] " Arnd Bergmann
2015-04-21  8:55         ` Baolin Wang
2015-04-20  5:57 ` [PATCH 06/11] char/mmtimer:Convert to the 64bit methods for k_clock callback function Baolin Wang
2015-04-20  5:57 ` [PATCH 07/11] time/alarmtimer:Convert to the new methods for k_clock structure Baolin Wang
2015-04-20  5:57 ` [PATCH 08/11] time/posix-clock:Convert to the 64bit methods for k_clock and posix_clock_operations structure Baolin Wang
2015-04-20  5:57 ` [PATCH 09/11] cputime:Introduce the cputime_to_timespec64/timespec64_to_cputime function Baolin Wang
2015-04-20 21:09   ` Thomas Gleixner
2015-04-20  5:57 ` [PATCH 10/11] time/posix-cpu-timers:Convert to the 64bit methods for k_clock structure Baolin Wang
2015-04-20  5:57 ` [PATCH 11/11] k_clock:Remove the 32bit methods with timespec type Baolin Wang
2015-04-20  8:42   ` Richard Cochran
2015-04-20  9:00     ` Baolin Wang

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=alpine.DEB.2.11.1504211528040.13914@nanos \
    --to=tglx@linutronix.de \
    --cc=ahh@google.com \
    --cc=arnd@arndb.de \
    --cc=baolin.wang@linaro.org \
    --cc=cl@linux.com \
    --cc=fweisbec@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heenasirwani@gmail.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=john.stultz@linaro.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux390@de.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=netdev@vger.kernel.org \
    --cc=pang.xunlei@linaro.org \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=richardcochran@gmail.com \
    --cc=riel@redhat.com \
    --cc=rth@twiddle.net \
    --cc=schwidefsky@de.ibm.com \
    --cc=tj@kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).