USB: usbmon: Use 64bit timestamp for mon_bin_hdr
PATCH RESEND 1/1 USB: usbmon: Use 64bit timestamp for mon_bin_hdr
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.
--- drivers/usb/mon/mon_bin.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-)
drivers/usb/mon/mon_bin.c +9 -8
@@ -18,6 +18,7 @@#include <linux/mm.h> #include <linux/scatterlist.h> #include <linux/slab.h> +#include <linux/time64.h> #include <asm/uaccess.h>
@@ -92,8 +93,8 @@ struct mon_bin_hdr {unsigned short busnum;/* Bus number */ char flag_setup;char flag_data; -s64 ts_sec;/* gettimeofday */ -s32 ts_usec;/* gettimeofday */ +s64 ts_sec;/* getnstimeofday64 */ +s32 ts_usec;/* getnstimeofday64 */ int status;unsigned int len_urb;/* Length of data (submitted or actual) */ unsigned int len_cap;/* Delivered length */
@@ -483,7 +484,7 @@ static void mon_bin_event(struct mon_reader_bin *rp, struct urb *urb, char ev_type, int status) {const struct usb_endpoint_descriptor *epd = &urb->ep->desc; -struct timeval ts; +struct timespec64 ts;unsigned long flags;unsigned int urb_length;unsigned int offset;
@@ -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);
@@ -568,7 +569,7 @@ static void mon_bin_event(struct mon_reader_bin *rp, struct urb *urb, ep->busnum = urb->dev->bus->busnum; ep->id = (unsigned long ) urb; ep->ts_sec = ts.tv_sec; - ep->ts_usec = ts.tv_usec; + ep->ts_usec = ts.tv_nsec /NSEC_PER_USEC ; ep->status = status; ep->len_urb = urb_length; ep->len_cap = length + lendesc;
@@ -629,12 +630,12 @@ static void mon_bin_complete(void *data, struct urb *urb, int status)static void mon_bin_error (void *data,struct urb *urb,int error) {struct mon_reader_bin *rp = data; -struct timeval ts; +struct timespec64 ts;unsigned long flags;unsigned int offset;struct mon_bin_hdr *ep; -do_gettimeofday (&ts); +getnstimeofday64 (&ts);spin_lock_irqsave (&rp->b_lock, flags);
@@ -656,7 +657,7 @@ static void mon_bin_error(void *data, struct urb *urb, int error) ep->busnum = urb->dev->bus->busnum; ep->id = (unsigned long ) urb; ep->ts_sec = ts.tv_sec; - ep->ts_usec = ts.tv_usec; + ep->ts_usec = ts.tv_nsec /NSEC_PER_USEC ; ep->status = error; ep->flag_setup ='-' ;
Signature · 1 line
2.6.0.rc2.230.g3dd15c0
Quoted 9 lines · On Thursday 29 October 2015 22:44:31 Tina Ruchandani wrote:
struct
mon_bin_hdrallows for a 64-bit seconds timestamp. The code currently uses 'struct timeval' to populate the timestamp inmon_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 <[email protected]>
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.
drivers/usb/mon/mon_bin.c static void mon_bin_event(struct mon_reader_bin *rp, struct urb *urb, · line 501
Quoted 9 lines
drivers/usb/mon/mon_bin.c +1
-1@@ -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
Greg Kroah-Hartman
maintainerQuoted 9 lines · Arnd Bergmann
Quoted 8 lines · On Thursday 29 October 2015 22:44:31 Tina Ruchandani wrote:
struct
mon_bin_hdrallows for a 64-bit seconds timestamp. The code currently uses 'struct timeval' to populate the timestamp inmon_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.
Quoted 7 lines
Quoted 1 line
Signed-off-by Tina Ruchandani <[email protected]>Reviewed-by Arnd Bergmann <[email protected]>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.
It's the merge window, I can't pick anything new up, please be patient and wait for 4.4-rc1 to come out first...
thanks,
greg k-h
Quoted 12 lines · On Thursday 05 November 2015 08:37:39 Greg Kroah-Hartman wrote:
Quoted 11 lines · Arnd Bergmann
Quoted 9 lines · On Thursday 29 October 2015 22:44:31 Tina Ruchandani wrote:
struct
mon_bin_hdrallows for a 64-bit seconds timestamp. The code currently uses 'struct timeval' to populate the timestamp inmon_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 <[email protected]>
Quoted 8 lines
Quoted 5 lines
Reviewed-by Arnd Bergmann <[email protected]>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.
It's the merge window, I can't pick anything new up, please be patient and wait for 4.4-rc1 to come out first...
Sorry, I wasn't thinking straight.
Arnd