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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 25 Jun 2010 22:11:19 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Ulrich Drepper <drepper@...hat.com>
cc:	Darren Hart <dvhltc@...ibm.com>, Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andreas Schwab <schwab@...hat.com>,
	Danny Feng <dfeng@...hat.com>,
	Jakub Jelinek <jakub@...hat.com>, linux-kernel@...r.kernel.org,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Oleg Nesterov <oleg@...hat.com>
Subject: Re: Q: sys_futex() && timespec_valid()

On Fri, 25 Jun 2010, Ulrich Drepper wrote:

Can you please use a mail client with proper line breaks ?

> ----- "Darren Hart" <dvhltc@...ibm.com> wrote:
> > Unless there is some good reason to object to breaking the API that I
> > am  missing, I don't mind changing it to -ETIMEDOUT (although -EINVAL
> > seems more intuitive to me).
> 
> It's only not intuitive because Oleg misrepresented or at least
> didn't describe the issue.

> The kernel already catches invalid timespec values.  Unfortunately
> the code used comes from the time when all timeouts where specified
> with relative values.  In such situations negative tv_sec values
> were in fact invalid and rejected with EINVAL.

> But for absolute timeouts tv_sec = -1 means a time before Epoch.
> This is not an invalid value, it just is one of many points in time
> which have passed and therefore the kernel has to respond with
> ETIMEDOUT.

That's simply wrong.

  ... or the TIMER_ABSTIME flag was specified in flags and the rqtp
  argument is outside the range for the clock specified by clock_id;

And I consider anything before the EPOCH or before the computer booted
outside of the range. Simply because that's outside the range which we
can read back from the clock, out of the range to which we can set the
clock.

And it's completely illogical to treat relative and abolute timeouts
different. If we'd accept that before the EPOCH or before the computer
started is valid for ABSTIME, then there is no freaking reason to
treat relative timeouts any different.

> This is no semantic change or anything like that.  It pure and
> simply a bug fix.  When Thomas worked on that come we simply missed
> updating the test for invalid timespec values.

No, that's how we treat every damned timespec in the
syscalls. clock_nanosleep(ABSTIME) has this behaviour forever and we
have this behaviour in sys_futex since we merged PI futex support way
before we added the BITSET stuff.

So just because you messed up your glibc implementation you want us to
fix glibc in the kernel based on some backwards arguments ?

> The kernel code should be fixed to always check tv_nsec for < 0 and
> > 1000000000.  But the tv_sec test for < 0 should be skipped if the
> timeout value is interpreted as an absolute time value.

Definitely NOT!

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