From: Arnd Bergmann <arnd@arndb.de>
To: Tina Ruchandani <ruchandani.tina@gmail.com>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
y2038 <y2038@lists.linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [RESEND PATCH] USB: usbmon: Use 64bit timestamp for mon_bin_hdr
Date: Thu, 05 Nov 2015 17:18:41 +0100 [thread overview]
Message-ID: <11025195.jAqGPh9YPj@wuerfel> (raw)
In-Reply-To: <20151030054431.GA360@google.com>
On Thursday 29 October 2015 22:44:31 Tina Ruchandani wrote:
> struct mon_bin_hdr allows for a 64-bit seconds timestamp. The code
> currently uses 'struct timeval' to populate the timestamp in mon_bin_hdr,
> which has a 32-bit seconds field and will overflow in year 2038 and beyond.
> This patch replaces 'struct timeval' with 'struct timespec64' which is
> y2038 safe. This patch is part of a larger attempt to remove instances
> of struct timeval and other 32-bit timekeeping (time_t, struct timespec)
> from the kernel.
>
> Signed-off-by: Tina Ruchandani <ruchandani.tina@gmail.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
As the patch is a week old and Greg hasn't picked it up yet, I'm guessing
that he doesn't have it in his queue any more and you should send it once
more with my 'Reviewed-by' tag.
> @@ -494,7 +495,7 @@ static void mon_bin_event(struct mon_reader_bin *rp, struct urb *urb,
> struct mon_bin_hdr *ep;
> char data_tag = 0;
>
> - do_gettimeofday(&ts);
> + getnstimeofday64(&ts);
>
> spin_lock_irqsave(&rp->b_lock, flags);
>
This is a very minor comment I still have, and the patch is fine as it, but
I tend to prefer ktime_get_real_ts64() over getnstimeofday64() these days.
The two functions do the exact same thing, and I hope to remove the latter
eventually.
Arnd
next prev parent reply other threads:[~2015-11-05 16:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-30 5:44 Tina Ruchandani
2015-11-05 16:18 ` Arnd Bergmann [this message]
2015-11-05 16:37 ` Greg Kroah-Hartman
2015-11-05 19:00 ` 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=11025195.jAqGPh9YPj@wuerfel \
--to=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=ruchandani.tina@gmail.com \
--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
all inboxes | Powered by JetHome®