Re: [Y2038] [PATCH 8/8] timekeeping: remove obsolete time accessors

2018-12-07 Thread John Stultz 
On Fri, Dec 7, 2018 at 5:49 AM Arnd Bergmann  wrote:
>
> There are no more remaining users of these deprecated wrappers, so
> let's remove them before new users have a chance to make it in.
>
> See Documentation/core-api/timekeeping.rst for replacements when
> porting old drivers that contain calls to this function.
>
> Signed-off-by: Arnd Bergmann 
> ---
>  include/linux/timekeeping.h   | 14 --
>  include/linux/timekeeping32.h |  9 -
>  2 files changed, 23 deletions(-)

Acked-by: John Stultz 
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH 5/8] timekeeping: remove unused {read, update}_persistent_clock

2018-12-07 Thread John Stultz 
On Fri, Dec 7, 2018 at 5:49 AM Arnd Bergmann  wrote:
>
> After arch/sh has removed the last reference to these functions,
> we can remove them completely and just rely on the 64-bit time_t
> based versions. This cleans up a rather ugly use of __weak
> functions.
>
> Signed-off-by: Arnd Bergmann 
> ---
>  include/linux/timekeeping32.h |  6 --
>  kernel/time/ntp.c | 10 +-
>  kernel/time/timekeeping.c | 12 ++--
>  3 files changed, 3 insertions(+), 25 deletions(-)

Acked-by: John Stultz 

thanks
-john
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH 6/8] timekeeping: remove timespec_add/timespec_del

2018-12-07 Thread John Stultz 
On Fri, Dec 7, 2018 at 5:49 AM Arnd Bergmann  wrote:
>
> The last users were removed a while ago since everyone moved to ktime_t,
> so we can remove the two unused interfaces for old timespec structures.
>
> With those two gone, set_normalized_timespec() is also unused, so
> remove that as well.
>
> Signed-off-by: Arnd Bergmann 
> ---
>  include/linux/time32.h | 25 -
>  kernel/time/time.c | 36 
>  2 files changed, 61 deletions(-)

Acked-by: John Stultz 
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH 6/7] time: move old timekeeping interfaces to timekeeping32.h

2017-10-24 Thread John Stultz 
On Thu, Oct 19, 2017 at 4:14 AM, Arnd Bergmann  wrote:
> The interfaces based on 'struct timespec' and 'unsigned long' seconds
> are no longer recommended for new code, and we are trying to migrate to
> ktime_t based interfaces and other y2038-safe variants.
>
> This moves all the legacy interfaces from linux/timekeeping.h into a
> new timekeeping32.h to better document this.
>
> Signed-off-by: Arnd Bergmann 

Just as a heads up, trying to apply these for testing (initially
against 4.14-rc3, but also -rc6) and I'm running into fuzz issues from
this patch on.

patch seems to resolve it, but not sure exactly what it was based on,
and wanted to make sure I'm not doing something daft.

thanks
-john
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH 04/12] fs: ceph: CURRENT_TIME with ktime_get_real_ts()

2017-06-01 Thread John Stultz 
On Thu, Jun 1, 2017 at 5:26 PM, Yan, Zheng  wrote:
> On Thu, Jun 1, 2017 at 6:22 PM, Arnd Bergmann  wrote:
>> On Thu, Jun 1, 2017 at 11:56 AM, Yan, Zheng  wrote:
>>> On Sat, Apr 8, 2017 at 8:57 AM, Deepa Dinamani  
>>> wrote:
>>
 diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
 index 517838b..77204da 100644
 --- a/drivers/block/rbd.c
 +++ b/drivers/block/rbd.c
 @@ -1922,7 +1922,7 @@ static void rbd_osd_req_format_write(struct 
 rbd_obj_request *obj_request)
  {
 struct ceph_osd_request *osd_req = obj_request->osd_req;

 -   osd_req->r_mtime = CURRENT_TIME;
 +   ktime_get_real_ts(_req->r_mtime);
 osd_req->r_data_offset = obj_request->offset;
  }

 diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c
 index c681762..1d3fa90 100644
 --- a/fs/ceph/mds_client.c
 +++ b/fs/ceph/mds_client.c
 @@ -1666,6 +1666,7 @@ struct ceph_mds_request *
  ceph_mdsc_create_request(struct ceph_mds_client *mdsc, int op, int mode)
  {
 struct ceph_mds_request *req = kzalloc(sizeof(*req), GFP_NOFS);
 +   struct timespec ts;

 if (!req)
 return ERR_PTR(-ENOMEM);
 @@ -1684,7 +1685,8 @@ ceph_mdsc_create_request(struct ceph_mds_client 
 *mdsc, int op, int mode)
 init_completion(>r_safe_completion);
 INIT_LIST_HEAD(>r_unsafe_item);

 -   req->r_stamp = current_fs_time(mdsc->fsc->sb);
 +   ktime_get_real_ts();
 +   req->r_stamp = timespec_trunc(ts, mdsc->fsc->sb->s_time_gran);
>>>
>>> This change causes our kernel_untar_tar test case to fail (inode's
>>> ctime goes back). The reason is that there is time drift between the
>>> time stamps got by  ktime_get_real_ts() and current_time(). We need to
>>> revert this change until current_time() uses ktime_get_real_ts()
>>> internally.
>>
>> Hmm, the change was not supposed to have a user-visible effect, so
>> something has gone wrong, but I don't immediately see how it
>> relates to what you observe.
>>
>> ktime_get_real_ts() and current_time() use the same time base, there
>> is no drift, but there is a difference in resolution, as the latter uses
>> the time stamp of the last jiffies update, which may be up to one jiffy
>> (10ms) behind the exact time we put in the request stamps here.
>>
>> Do you still see problems if you use current_kernel_time() instead of
>> ktime_get_real_ts()?
>
> The problem disappears after using current_kernel_time().
>
> https://github.com/ceph/ceph-client/commit/2e0f648da23167034a3cf1500bc90ec60aef2417

From the commit above:
"It seems there is time drift between ktime_get_real_ts() and
current_kernel_time()"

Its more of a granularity difference. current_kernel_time() returns
the cached time at the last tick, where as ktime_get_real_ts() reads
the clocksource hardware and returns the immediate time.

Filesystems usually use the cached time (similar to
CLOCK_REALTIME_COARSE), for performance reasons, as touching the
clocksource takes time.

thanks
-john
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH v4 25/26] time: Delete current_fs_time() function

2016-08-17 Thread John Stultz 
On Sat, Aug 13, 2016 at 3:48 PM, Deepa Dinamani <deepa.ker...@gmail.com> wrote:
> All uses of the current_fs_time() function have been
> replaced by other time interfaces.
>
> And, its use cases can be fulfilled by current_time()
> or ktime_get_* variants.
>
> Signed-off-by: Deepa Dinamani <deepa.ker...@gmail.com>
> Reviewed-by: Arnd Bergmann <a...@arndb.de>
> Cc: John Stultz <john.stu...@linaro.org>
> Cc: Thomas Gleixner <t...@linutronix.de>

Assuming all the users are gone when this is applied:
Acked-by: John Stultz <john.stu...@linaro.org>

thanks
-john
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH] crypto: Jitter RNG - use ktime_get_raw_ns as fallback

2016-06-21 Thread John Stultz 
On Tue, Jun 21, 2016 at 12:37 PM, Arnd Bergmann <a...@arndb.de> wrote:
> On Tuesday, June 21, 2016 12:05:06 PM CEST John Stultz wrote:
>> On Tue, Jun 21, 2016 at 11:49 AM, Stephan Mueller <smuel...@chronox.de> 
>> wrote:
>> > Am Dienstag, 21. Juni 2016, 11:11:42 schrieb John Stultz:
>> >
>> > Hi John,
>> >
>> >> I don't see in the above an explanation of *why* you're using
>> >> ktime_get_raw_ns() instead of ktime_get_ns().
>> >
>> > Could you help me understand what the difference is or point me to some
>> > documentation? I understood that we only talked about the _raw variant.
>>
>> Using specialized interfaces with subtle semantics w/o understanding
>> them is sort of my concern here.
>>
>> There are reasons why you might want to use the ktime_get_raw_ns()
>> interface over ktime_get_ns(), but they have not been made clear in
>> the comment. Arnd discussed some potential concerns that the freq
>> adjustment done by ntp might be somewhat predictable/controlled by
>> remote parties, which could have some effect in the calculation. That
>> feels a little overly vague to me, but I'm no crypto expert, so if
>> that is a reasonable concern, then it should be a conscious and
>> documented decision.
>
> My original patch changed __getnstimeofday() to __getnstimeofday64(),
> which kept the original semantics of not warning in case the clock
> source is suspended (which is the only different to the normal
> getnstimeofday{,64}().
>
> I did the patch a while time ago along with a number of other patches
> that I never sent out until last week, so I don't remember the
> reasoning for suggesting ktime_get_raw_fast_ns() over ktime_get_raw_ns(),
> but I sure wanted to keep the non-warning behavior, and ktime_get_ns()
> warns on timekeeping_suspended() while the other two don't.

Right. But this code isn't called in late suspend or early resume is it?


> If we don't care about the non-warning aspect, ktime_get_ns() makes
> most sense here, and the original code should probably have used
> getnstimeofday() as well.

This is what I suspect as well.  But again, I don't mind if folks use
the specialized interfaces, as long as they document a clear reason
for it. Especially for things like crypto where intuition isn't always
the best guide.

thanks
-john
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH] crypto: Jitter RNG - use ktime_get_raw_ns as fallback

2016-06-21 Thread John Stultz 
On Tue, Jun 21, 2016 at 11:49 AM, Stephan Mueller <smuel...@chronox.de> wrote:
> Am Dienstag, 21. Juni 2016, 11:11:42 schrieb John Stultz:
>
> Hi John,
>
>> I don't see in the above an explanation of *why* you're using
>> ktime_get_raw_ns() instead of ktime_get_ns().
>
> Could you help me understand what the difference is or point me to some
> documentation? I understood that we only talked about the _raw variant.

Using specialized interfaces with subtle semantics w/o understanding
them is sort of my concern here.

There are reasons why you might want to use the ktime_get_raw_ns()
interface over ktime_get_ns(), but they have not been made clear in
the comment. Arnd discussed some potential concerns that the freq
adjustment done by ntp might be somewhat predictable/controlled by
remote parties, which could have some effect in the calculation. That
feels a little overly vague to me, but I'm no crypto expert, so if
that is a reasonable concern, then it should be a conscious and
documented decision.

thanks
-john
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

2016-06-21 Thread John Stultz 
On Tue, Jun 21, 2016 at 9:51 AM, Stephan Mueller <smuel...@chronox.de> wrote:
> Am Dienstag, 21. Juni 2016, 09:47:23 schrieb John Stultz:
>
> Hi John,
>
>> On Tue, Jun 21, 2016 at 9:34 AM, Stephan Mueller <smuel...@chronox.de>
> wrote:
>> > Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz:
>> >
>> > Hi John,
>> >
>> >> On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann <a...@arndb.de> wrote:
>> >> > On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote:
>> >> >> Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann:
>> >> > Compared to the previous __getnstimeofday(), the difference is
>> >> >
>> >> > - using "monotonic" timebase instead of "real", so the zero time
>> >> >
>> >> >   is when the system booted rather than Jan 1 1970
>> >>
>> >> I haven't looked at the details of the calling code, but I'd worry for
>> >> crypto uses, especially if its being used for entropy collection,
>> >> using the monotonic clock instead of the realtime clock might be
>> >> problematic.
>> >
>> > Funnily it does not seem like that. All tests that I have conducted show
>> > that monotonic clocks behave equally as realtime clocks, because the
>> > uncertainty lies in the execution time of a set of instructions. All we
>> > need to do is to measure it with a timer that has a resolution that
>> > allows detecting these variations.
>>
>> Ok. If you're only using it for interval measurements, then either way
>> shouldn't matter. I just wanted to make sure the entropy wasn't coming
>> from the actual time.
>>
>> >> > - "raw" means we don't honor updates for the rate based on ntp,
>> >> >
>> >> >   which is probably better as the ntp state might be observable
>> >> >   over the net (it probably doesn't matter, but it can't hurt)
>> >>
>> >> So... this feels like a very vague explanation, and the lack of
>> >> frequency correction here probably need a really good comment. Keeping
>> >> multiple time domains is usually asking for trouble, but we added the
>> >> MONOTONIC_RAW clock to address a few cases where people really wanted
>> >> an abstract hardware counter, which was unaffected by frequency
>> >> corrections. I'd really make sure its clear why this is what you want
>> >> vs the standard system time domain so we don't run into problems
>> >> understanding it later.
>> >
>> > Perfect, that is what I would be interested in.
>>
>> But documenting *why* clearly is the thing I'd very strongly suggest.
>> If we need to make some slight semantic change for whatever reason, I
>> don't want folks worried "we can't do that because the crypto code is
>> using it for voodoo".
>
> I hope my explanation is sufficient to not count as voodoo: I only need an
> interval measurement capability which has a sufficient high resolution similar
> or better than RDTSC on x86.

So this is definitely more clear then what was described earlier, and
worries me because on many x86 machines (though fewer I guess these
days then in the past) the clocksource will often not be the TSC (and
have lower resolution).

So you might boot w/ "clocksource=acpi_pm" or "clocksource=hpet" to
test these other possible clocksources.

However, this was always the case, so if if __getnstimeofday64()
worked before (though, its not clear why you were using the __ version
prior, since that's supposed to be an internal function), it uses the
same clocksource, so I suspect there won't be any functional
difference the the pre-existing code.

But please just make sure the reason why you're using that specific
interface is clearly documented in the code so we don't have to later
reverse engineer the intent.

thanks
-john
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

2016-06-21 Thread John Stultz 
On Tue, Jun 21, 2016 at 9:34 AM, Stephan Mueller <smuel...@chronox.de> wrote:
> Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz:
>
> Hi John,
>
>> On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann <a...@arndb.de> wrote:
>> > On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote:
>> >> Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann:
>> > Compared to the previous __getnstimeofday(), the difference is
>> >
>> > - using "monotonic" timebase instead of "real", so the zero time
>> >
>> >   is when the system booted rather than Jan 1 1970
>>
>> I haven't looked at the details of the calling code, but I'd worry for
>> crypto uses, especially if its being used for entropy collection,
>> using the monotonic clock instead of the realtime clock might be
>> problematic.
>
> Funnily it does not seem like that. All tests that I have conducted show that
> monotonic clocks behave equally as realtime clocks, because the uncertainty
> lies in the execution time of a set of instructions. All we need to do is to
> measure it with a timer that has a resolution that allows detecting these
> variations.

Ok. If you're only using it for interval measurements, then either way
shouldn't matter. I just wanted to make sure the entropy wasn't coming
from the actual time.


>> > - "raw" means we don't honor updates for the rate based on ntp,
>> >
>> >   which is probably better as the ntp state might be observable
>> >   over the net (it probably doesn't matter, but it can't hurt)
>>
>> So... this feels like a very vague explanation, and the lack of
>> frequency correction here probably need a really good comment. Keeping
>> multiple time domains is usually asking for trouble, but we added the
>> MONOTONIC_RAW clock to address a few cases where people really wanted
>> an abstract hardware counter, which was unaffected by frequency
>> corrections. I'd really make sure its clear why this is what you want
>> vs the standard system time domain so we don't run into problems
>> understanding it later.
>
> Perfect, that is what I would be interested in.

But documenting *why* clearly is the thing I'd very strongly suggest.
If we need to make some slight semantic change for whatever reason, I
don't want folks worried "we can't do that because the crypto code is
using it for voodoo".


>> > - "fast" means that in very rare cases, the time might appear
>> >
>> >   to go backwards (it probably can't happen here because you are not
>> >   called in an NMI).
>>
>> "fast" really means "safe-for-nmi wrt to locking".  The tradeoff being
>> that when frequency adjustments occur, and if your code is delayed,
>> you might see time go backwards by a small amount. This allows
>
> My code would not see that as an issue.
>
>> tracing/sched code (or other code called from NMI)  to not have to
>> duplicate the timekeeping infrastructure.
>>
>> I think without a much better explanation, using the "fast" method
>> isn't really warranted here.
>
> Thanks a lot. With that, I would think that the proposed ktime_get_raw_fast_ns
> is good for use, which is supported with testing on my system.

So.. again, I'd avoid using the "fast" accessor unless there is a
clear need or obvious benefit. Which should be documented.

thanks
-john
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

2016-06-21 Thread John Stultz 
On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann  wrote:
> On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote:
>> Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann:
>>
> Compared to the previous __getnstimeofday(), the difference is
>
> - using "monotonic" timebase instead of "real", so the zero time
>   is when the system booted rather than Jan 1 1970

I haven't looked at the details of the calling code, but I'd worry for
crypto uses, especially if its being used for entropy collection,
using the monotonic clock instead of the realtime clock might be
problematic.

> - "raw" means we don't honor updates for the rate based on ntp,
>   which is probably better as the ntp state might be observable
>   over the net (it probably doesn't matter, but it can't hurt)

So... this feels like a very vague explanation, and the lack of
frequency correction here probably need a really good comment. Keeping
multiple time domains is usually asking for trouble, but we added the
MONOTONIC_RAW clock to address a few cases where people really wanted
an abstract hardware counter, which was unaffected by frequency
corrections. I'd really make sure its clear why this is what you want
vs the standard system time domain so we don't run into problems
understanding it later.

> - "fast" means that in very rare cases, the time might appear
>   to go backwards (it probably can't happen here because you are not
>   called in an NMI).

"fast" really means "safe-for-nmi wrt to locking".  The tradeoff being
that when frequency adjustments occur, and if your code is delayed,
you might see time go backwards by a small amount. This allows
tracing/sched code (or other code called from NMI)  to not have to
duplicate the timekeeping infrastructure.

I think without a much better explanation, using the "fast" method
isn't really warranted here.

thanks
-john
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH] timer: avoid using timespec

2016-06-17 Thread John Stultz 
On Fri, Jun 17, 2016 at 8:30 AM, Arnd Bergmann  wrote:
> The tstats_show() function prints a ktime_t variable by converting
> it to struct timespec first. The algorithm is ok, but we want to
> stop using timespec in general because of the 32-bit time_t
> overflow problem.
>
> This changes the code to use struct timespec64, without any
> functional change.
>
> Signed-off-by: Arnd Bergmann 

Queued for testing.

thanks
-john
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH 21/21] time: Delete CURRENT_TIME_SEC and CURRENT_TIME macro

2016-06-14 Thread John Stultz 
On Wed, Jun 8, 2016 at 10:05 PM, Deepa Dinamani <deepa.ker...@gmail.com> wrote:
> All uses of these macors have been replaced by other
> time functions.
> These macros are also not y2038 safe.
> And, all its usecases can be fulfilled by y2038
> safe ktime_get_* variants.
>

Assuming the prereqs are in place:

Acked-by: John Stultz <john.stu...@linaro.org>

thanks
-john
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH 15/21] time: Add time64_to_tm()

2016-06-14 Thread John Stultz 
On Wed, Jun 8, 2016 at 10:04 PM, Deepa Dinamani <deepa.ker...@gmail.com> wrote:
> time_to_tm() takes time_t as an argument.
> time_t is not y2038 safe.
> Add time64_to_tm() that takes time64_t as an argument
> which is y2038 safe.
> The plan is to eventually replace all calls to time_to_tm()
> by time64_to_tm().
>
> Signed-off-by: Deepa Dinamani <deepa.ker...@gmail.com>
> Cc: John Stultz <john.stu...@linaro.org>
> Cc: Thomas Gleixner <t...@linutronix.de>

This looks sane to me. Are you hoping for me to queue this, or would
you like i to go though the fsdev maintainers with my ack?

In either case.

Acked-by: John Stultz <john.stu...@linaro.org>

thanks
-john
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH 1/3] time: Add missing implementation for timespec64_add_safe()

2016-05-04 Thread John Stultz 
On Fri, Apr 29, 2016 at 9:39 AM, Deepa Dinamani <deepa.ker...@gmail.com> wrote:
> timespec64_add_safe() has been defined in time64.h for
> 64 bit systems.
> But, 32 bit systems only have an extern function prototype defined.
> Provide a definition for the above function.
>
> The function will be necessary as part of y2038 changes.
> struct timespec is not y2038 safe. All references to timespec will
> be replaced by struct timespec64. The function is meant to be a
> replacement for timespec_add_safe().
>
> The implementation is similar to timespec_add_safe().
>
> Signed-off-by: Deepa Dinamani <deepa.ker...@gmail.com>
> Cc: John Stultz <john.stu...@linaro.org>
> Cc: Thomas Gleixner <t...@linutronix.de>
> ---
>  include/linux/time64.h |  4 +---
>  kernel/time/time.c | 25 +
>  2 files changed, 26 insertions(+), 3 deletions(-)

Looks ok at the first glance. I've queued these up for testing,
however I only got #1 and #3 of the set. Are you hoping these two
patches will go through tip/timers/core or are you looking for acks so
they can go via another tree?

thanks
-john
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [RFC PATCH v2 3/4] ppdev: add compat ioctl

2015-07-08 Thread John Stultz 
On Mon, Jun 29, 2015 at 7:23 AM, Bamvor Zhang Jian
bamvor.zhangj...@linaro.org wrote:
 Add compat ioctl in ppdev in order to solve the y2038 issue in
 later patch.
 This patch simply add pp_do_ioctl to compat_ioctl, because I found
 that all the ioctl access the arg as a pointer.

 Signed-off-by: Bamvor Zhang Jian bamvor.zhangj...@linaro.org
 ---
  drivers/char/ppdev.c | 9 +
  1 file changed, 9 insertions(+)

 diff --git a/drivers/char/ppdev.c b/drivers/char/ppdev.c
 index ae0b42b..9207658 100644
 --- a/drivers/char/ppdev.c
 +++ b/drivers/char/ppdev.c
 @@ -69,6 +69,7 @@
  #include linux/ppdev.h
  #include linux/mutex.h
  #include linux/uaccess.h
 +#include linux/compat.h

  #define PP_VERSION ppdev: user-space parallel port driver
  #define CHRDEV ppdev
 @@ -635,6 +636,11 @@ static long pp_ioctl(struct file *file, unsigned int 
 cmd, unsigned long arg)
 return ret;
  }

 +static long pp_compat_ioctl(struct file *file, unsigned int cmd, unsigned 
 long arg)
 +{
 +   return pp_ioctl(file, cmd, (unsigned long)compat_ptr(arg));
 +}
 +
  static int pp_open (struct inode * inode, struct file * file)
  {
 unsigned int minor = iminor(inode);
 @@ -744,6 +750,9 @@ static const struct file_operations pp_fops = {
 .write  = pp_write,
 .poll   = pp_poll,
 .unlocked_ioctl = pp_ioctl,
 +#ifdef CONFIG_COMPAT
 +   .compat_ioctl   = pp_compat_ioctl,
 +#endif

Does adding this patch w/o the following patch break 32bit apps using
this on 64bit kernels?

thanks
-john
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH v4 00/25] Convert the posix_clock_operations and k_clock structure to ready for 2038

2015-05-29 Thread John Stultz 
On Fri, May 29, 2015 at 5:16 AM, Baolin Wang baolin.w...@linaro.org wrote:
 This patch series changes the 32-bit time types (timespec/itimerspec) to
 the 64-bit types (timespec64/itimerspec64), since 32-bit time types will
 break in the year 2038.

 This patch series introduces new methods with timespec64/itimerspec64 type,
 and removes the old ones with timespec/itimerspec type for 
 posix_clock_operations
 and k_clock structure.

 Baolin Wang (25):

Is there a way to break this patch series up into a smaller number of
patches? I keep on meaning to get through and review these, but the
patch-count (and speed of the iterations) is a bit overwhelming and
has kept me from actually getting to reviewing it. Having the full
series is great to see, but splitting out 4-5 key patches and focusing
on those for review might help get additional feedback.

thanks
-john
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH v4 11/24] posix-timers:Convert to the 64bit methods for the clock_settime syscall function

2015-05-20 Thread John Stultz 
On Tue, May 19, 2015 at 5:49 AM, Baolin Wang baolin.w...@linaro.org wrote:
 This patch introduces the clock_set64 method with timespec64 type for
 k_clock structure, that makes it ready for the 2038 year.

 Convert to the 64bit method with timespec64 type for the
 clock_settime syscall function, and change the clock_settime syscall
 implementation according to the CONFIG_64BIT macro.

 Also add a default 64bit method for the clock_set64 pointer of
 k_clock structure, and it will be removed after all the drivers are
 converted to 64bit methods.

 Signed-off-by: Baolin Wang baolin.w...@linaro.org
 ---
  include/linux/posix-timers.h |2 ++
  kernel/time/posix-timers.c   |   30 +++---
  2 files changed, 29 insertions(+), 3 deletions(-)

 diff --git a/include/linux/posix-timers.h b/include/linux/posix-timers.h
 index 16c3364..2b19ec8 100644
 --- a/include/linux/posix-timers.h
 +++ b/include/linux/posix-timers.h
 @@ -100,6 +100,8 @@ struct k_clock {
 int (*clock_getres) (const clockid_t which_clock, struct timespec 
 *tp);
 int (*clock_set) (const clockid_t which_clock,
   const struct timespec *tp);
 +   int (*clock_set64) (const clockid_t which_clock,
 +   const struct timespec64 *tp);
 int (*clock_get) (const clockid_t which_clock, struct timespec * tp);
 int (*clock_adj) (const clockid_t which_clock, struct timex *tx);
 int (*timer_create) (struct k_itimer *timer);
 diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
 index bfcfc78..3d59efa 100644
 --- a/kernel/time/posix-timers.c
 +++ b/kernel/time/posix-timers.c
 @@ -541,6 +541,18 @@ static int default_timer_set64(struct k_itimer *timr, 
 int flags,
 return ret;
  }

 +static int default_clock_set64(const clockid_t which_clock,
 +  const struct timespec64 *tp64)
 +{
 +   struct k_clock *kc = clockid_to_kclock(which_clock);
 +   struct timespec tp;
 +   int ret;
 +
 +   tp = timespec64_to_timespec(*tp64);
 +   ret = kc-clock_set(which_clock, tp);
 +   return ret;
 +}
 +
  void posix_timers_register_clock(const clockid_t clock_id,
  struct k_clock *new_clock)
  {
 @@ -565,6 +577,8 @@ void posix_timers_register_clock(const clockid_t clock_id,
 new_clock-timer_get64 = default_timer_get64;
 if (new_clock-timer_set  !new_clock-timer_set64)
 new_clock-timer_set64 = default_timer_set64;
 +   if (new_clock-clock_set  !new_clock-clock_set64)
 +   new_clock-clock_set64 = default_clock_set64;

 posix_clocks[clock_id] = *new_clock;
  }
 @@ -1075,25 +1089,35 @@ void exit_itimers(struct signal_struct *sig)
 }
  }

 -static int __clock_settime(clockid_t which_clock, struct timespec *ts)
 +static int __clock_settime(clockid_t which_clock, struct timespec64 *ts)
  {
 struct k_clock *kc = clockid_to_kclock(which_clock);

 -   if (!kc || !kc-clock_set)
 +   if (!kc || !kc-clock_set64)
 return -EINVAL;

 -   return kc-clock_set(which_clock, ts);
 +   return kc-clock_set64(which_clock, ts);
  }

  SYSCALL_DEFINE2(clock_settime, const clockid_t, which_clock,
 const struct timespec __user *, tp)
  {
 +#ifdef CONFIG_64BIT
 +   struct timespec64 new_tp;
 +#else
 struct timespec new_tp;
 +   struct timespec64 new_tp64;
 +#endif

 if (copy_from_user(new_tp, tp, sizeof (*tp)))
 return -EFAULT;

 +#ifdef CONFIG_64BIT
 return __clock_settime(which_clock, new_tp);
 +#else
 +   new_tp64 = timespec_to_timespec64(new_tp);
 +   return __clock_settime(which_clock, new_tp64);
 +#endif
  }

Please just have two clock_settime functions wrapped by the ifdef
conditional. You should always try to avoid ifdefs inside of
functions.

thanks
-john
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038