On Fri, Oct 09, 2015 at 12:38:32PM +0200, Thomas Gleixner wrote:
> On Fri, 9 Oct 2015, Miroslav Lichvar wrote:
> > Do you feel the same about preventing the time from reaching
> > KTIME_MAX?
>
> That's going to happen in ~500 years from now.
At any time if you include accidents and attacks on ser
On Fri, 9 Oct 2015, Miroslav Lichvar wrote:
> On Fri, Oct 09, 2015 at 10:46:16AM +0100, Thomas Gleixner wrote:
> > On Thu, 8 Oct 2015, Miroslav Lichvar wrote:
> > > Applications are not allowed to rely on system time being sane?
> > > To me the current behavior looks like the kernel is throwing the
On Fri, Oct 09, 2015 at 10:46:16AM +0100, Thomas Gleixner wrote:
> On Thu, 8 Oct 2015, Miroslav Lichvar wrote:
> > Applications are not allowed to rely on system time being sane?
> > To me the current behavior looks like the kernel is throwing the
> > applications off a cliff, while it's the only t
On Thu, 8 Oct 2015, Miroslav Lichvar wrote:
> On Thu, Oct 08, 2015 at 10:52:05AM +0200, Arnd Bergmann wrote:
> > On Thursday 08 October 2015 08:23:44 Miroslav Lichvar wrote:
> > > The difference is that with the one-week step the kernel and userspace
> > > still agree on the current time and it is
On Thu, Oct 08, 2015 at 10:52:05AM +0200, Arnd Bergmann wrote:
> On Thursday 08 October 2015 08:23:44 Miroslav Lichvar wrote:
> > The difference is that with the one-week step the kernel and userspace
> > still agree on the current time and it is always valid from the kernel
> > point of view, abso
On Thursday 08 October 2015 08:23:44 Miroslav Lichvar wrote:
> On Wed, Oct 07, 2015 at 05:10:34PM +0200, Arnd Bergmann wrote:
> > On Wednesday 07 October 2015 16:23:44 Miroslav Lichvar wrote:
> > > Without the limit added by this patch make will go nuts just one week
> > > later when the 32-bit tim
On Wed, Oct 07, 2015 at 05:10:34PM +0200, Arnd Bergmann wrote:
> On Wednesday 07 October 2015 16:23:44 Miroslav Lichvar wrote:
> > Without the limit added by this patch make will go nuts just one week
> > later when the 32-bit time_t overflows to Dec 13 1901 and the files
> > will appear as 136 yea
On Wednesday 07 October 2015 16:23:44 Miroslav Lichvar wrote:
> On Wed, Oct 07, 2015 at 03:47:19PM +0200, Arnd Bergmann wrote:
> > On Wednesday 07 October 2015 15:22:17 Miroslav Lichvar wrote:
> > > This patch sets a maximum value of the system time to prevent the system
> > > time from getting too
On Wed, Oct 07, 2015 at 03:47:19PM +0200, Arnd Bergmann wrote:
> On Wednesday 07 October 2015 15:22:17 Miroslav Lichvar wrote:
> > This patch sets a maximum value of the system time to prevent the system
> > time from getting too close to the overflow. The time can't be set to a
> > larger value. W
On Wednesday 07 October 2015 15:22:17 Miroslav Lichvar wrote:
> On systems with 32-bit time_t there are quite a few problems that
> applications may have with time overflowing in year 2038. Beside getting
> to an unexpected state by not checking integer operations with time_t
> variables, some syst
10 matches
Mail list logo
