linux-kernel - Re: Q: sys_futex() && timespec

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]

Message-ID: <AANLkTil7vXFkl89GbM022NrDT469XaYpMitNvrrnEiGn@mail.gmail.com>
Date:	Mon, 28 Jun 2010 09:04:41 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andreas Schwab <schwab@...hat.com>
Cc:	Ulrich Drepper <drepper@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Darren Hart <dvhltc@...ibm.com>, Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Danny Feng <dfeng@...hat.com>,
	Jakub Jelinek <jakub@...hat.com>, linux-kernel@...r.kernel.org,
	Oleg Nesterov <oleg@...hat.com>
Subject: Re: Q: sys_futex() && timespec_valid()

On Mon, Jun 28, 2010 at 8:29 AM, Andreas Schwab <schwab@...hat.com> wrote:
> Linus Torvalds <torvalds@...ux-foundation.org> writes:
>
>> We know it's not a valid absolute timeout, since there's no way
>> somebody is "waiting" for something that happened in the sixties.
>
> Should it reject timestamps from the seventies?

Conceptually, we could certainly say "any timeouts from before the
boot of the machine are obviously bogus". It would be stupid and
complicated, and it would be a total pain for anybody who wants to do
migration or anything like that, so we shouldn't do it, but I could
imagine some system that rejected such timeouts as "crazy".

At the same time, for us, there's simply no _reason_ to do that. A
positive time_t value is well-defined. In contrast, a negative tv_sec
value is inherently suspect. Traditionally, you couldn't even know if
time_t was a signed quantity to begin with! And on 32-bit machines, a
negative time_t is quite often the result of overflow (no, you don't
have to get to 2038 to see it - you can get overflows from simply
doing large relative timeouts etc).

So there is no _reason_ to reject timestamps from the seventies. Why
would we care about a specific date? In contrast, negative timestamps
make no sense for absolute timeouts, and they are inherently much less
trustworthy. So it's not about 1970 per se, it's more an issue about
the fundamental representation of time.

In other words, think of negative tv_sec values as a "hmm, I wonder
what the thing is thinking - let's reject it, because I don't want to
guess what the heck is wrong with this guy".

And it's also what we've apparently been doing for a long time, so
changing it had better had some serious reason.

There are certainly cases where negative tv_sec makes sense. Dates on
files, things like that. But why would it make sense to have a
negative tv_sec for an absolute timeout? (Side note: for a _relative_
timeout a negative value makes much more sense: it happens quite
naturally when you end up subtracting two times from each other - but
Ulrich seems to explicitly want negative time for the case where it
makes _less_ sense)

                       Linus
--
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/