linux-kernel - Re: [Y2038] [PATCH] dummy_hcd: replace timeval with timespec64

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 15 Sep 2015 16:02:07 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Pingbo Wen <pingbo.wen@...aro.org>
Cc:	y2038@...ts.linaro.org, linux-usb@...r.kernel.org,
	Felipe Balbi <balbi@...com>, linux-kernel@...r.kernel.org
Subject: Re: [Y2038] [PATCH] dummy_hcd: replace timeval with timespec64

On Tuesday 15 September 2015 21:43:19 Pingbo Wen wrote:
> 
> On Tuesday, September 15, 2015 09:14 PM, Arnd Bergmann wrote:
> > On Tuesday 15 September 2015 20:56:15 WEN Pingbo wrote:
> >> The millisecond of the last second will be normal if tv_sec is
> >> overflowed. But for y2038 consistency and demonstration purpose,
> >> and avoiding further risks, we still need to fix it here,
> >> to avoid similair problems.
> >>
> >> Signed-off-by: Pingbo Wen <pingbo.wen@...aro.org>
> >> Cc: Y2038 <y2038@...ts.linaro.org>
> >> Cc: linux-kernel@...r.kernel.org
> >> Cc: Arnd Bergmann <arnd@...db.de>
> >> Cc: Felipe Balbi <balbi@...com>
> > 
> > I just replied to the thread of the first mail, and it's good to see you had
> > the same thought about adding the usb folks to the Cc list.
> > 
> > When sending a new version of a patch you have already sent before, it's
> > common practice to use [PATCH v2] in the subject, so please do that for the
> > next version.
> > 
> 
> Ok, I thought previous thread is just draft, so I renewed one. Losing some history,
> sorry for that.

No, it's fine either way, I was just making sure you get the idea.

> 
> > Your changelog text is better than the first version, but can still be improved.
> > I would at least mention that we want to remove all uses of 'timeval' from
> > device drivers in order to better scan for y2038 problems in the drivers that
> > still use them.
> > 
> > Also, you don't mention at all the discussion we had about real time vs.
> > monotonic time for this driver. I think using monotonic time (ktime_get_ts64())
> > would be more appropriate here, but whichever you choose, you should explain
> > in the changelog why you think that one is better than the other.
> > Most of the time, we end up changing from real time to monotonic time in the
> > same patch when converting a driver to avoid 32-bit time_t, so even you don't
> > change it, you should explain why not.
> 
> ktime_get_ts64() is another choice. As we discussed in previous thread, only using
> jiffies can not keep the precise, and we should also handle the jiffies overflowing
> case, so I kept the old implementation.

Ok. As I said, it's most important to describe what the decision process was,
rather than the specific decision (real time has worked fine in the past,
so the change to monotonic is not critical here, just an additional improvement).

Let's wait for more comments to the question whether the resolution should be
changed for highspeed and superspeed mode, then you can post an updated version.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/