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
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
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
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, 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 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
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
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
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,
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
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
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
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
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,
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
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.
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
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 system calls have unexpected behavior, e.g. the system
time can't be set
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 system calls have unexpected behavior, e.g. the system
time can't be set
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
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
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.
On Wed, Apr 15, 2015 at 12:17:36PM -0400, Justin Keller wrote:
> Is there a reason for "step = leap"?
It's there to not change the behavior when a leap second occurs, the
clock still needs to be stepped. I guess it could be optimized a bit,
if it used "if (unlikely(leap || tk->xtime_sec >=
On Wed, Apr 15, 2015 at 10:31:54PM +0100, One Thousand Gnomes wrote:
> On Wed, 15 Apr 2015 17:41:28 +0200
> Miroslav Lichvar wrote:
> > larger value. When the maximum is reached in normal time accumulation,
> > the clock will be stepped back by one week.
>
> Which itself is open to exploits and
On Wed, Apr 15, 2015 at 10:31:54PM +0100, One Thousand Gnomes wrote:
On Wed, 15 Apr 2015 17:41:28 +0200
Miroslav Lichvar mlich...@redhat.com wrote:
larger value. When the maximum is reached in normal time accumulation,
the clock will be stepped back by one week.
Which itself is open to
On Wed, Apr 15, 2015 at 12:17:36PM -0400, Justin Keller wrote:
Is there a reason for step = leap?
It's there to not change the behavior when a leap second occurs, the
clock still needs to be stepped. I guess it could be optimized a bit,
if it used if (unlikely(leap || tk-xtime_sec =
On Wed, 15 Apr 2015 17:41:28 +0200
Miroslav Lichvar wrote:
> On systems with 32-bit time_t, it seems there are quite a few problems
> that applications may have with time overflowing in year 2038. Beside
Even ext4 is still broken for 2038.
> larger value. When the maximum is reached in normal
Is there a reason for "step = leap"?
On Wed, Apr 15, 2015 at 11:41 AM, Miroslav Lichvar wrote:
> On systems with 32-bit time_t, it seems there are quite a few problems
> that applications may have with time overflowing in year 2038. Beside
> getting in an unexpected state by not checking integer
On Wednesday 15 April 2015 17:41:28 Miroslav Lichvar wrote:
> On systems with 32-bit time_t, it seems there are quite a few problems
> that applications may have with time overflowing in year 2038. Beside
> getting in an unexpected state by not checking integer operations with
> time_t variables,
On systems with 32-bit time_t, it seems there are quite a few problems
that applications may have with time overflowing in year 2038. Beside
getting in an unexpected state by not checking integer operations with
time_t variables, some system calls have unexpected behavior, e.g. the
system time
On systems with 32-bit time_t, it seems there are quite a few problems
that applications may have with time overflowing in year 2038. Beside
getting in an unexpected state by not checking integer operations with
time_t variables, some system calls have unexpected behavior, e.g. the
system time
On Wednesday 15 April 2015 17:41:28 Miroslav Lichvar wrote:
On systems with 32-bit time_t, it seems there are quite a few problems
that applications may have with time overflowing in year 2038. Beside
getting in an unexpected state by not checking integer operations with
time_t variables, some
Is there a reason for step = leap?
On Wed, Apr 15, 2015 at 11:41 AM, Miroslav Lichvar mlich...@redhat.com wrote:
On systems with 32-bit time_t, it seems there are quite a few problems
that applications may have with time overflowing in year 2038. Beside
getting in an unexpected state by not
On Wed, 15 Apr 2015 17:41:28 +0200
Miroslav Lichvar mlich...@redhat.com wrote:
On systems with 32-bit time_t, it seems there are quite a few problems
that applications may have with time overflowing in year 2038. Beside
Even ext4 is still broken for 2038.
larger value. When the maximum is
34 matches
Mail list logo
