linux-kernel - Re: [PATCH 0/3] Cleanup ADJ

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]

Message-ID: <20101228125332.GA26363@riccoc20.at.omicron.at>
Date:	Tue, 28 Dec 2010 13:53:32 +0100
From:	Richard Cochran <richardcochran@...il.com>
To:	John Stultz <john.stultz@...aro.org>
Cc:	linux-kernel@...r.kernel.org,
	Richard Cochran <richard.cochran@...cron.at>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 0/3] Cleanup ADJ_SETOFFSET patch

On Tue, Dec 28, 2010 at 12:20:00PM +0100, Richard Cochran wrote:
> The exisiting code seems to assume that a timespec can only have the
> sign in one field. In other words, if tv_sec is non-zero, then tv_nsec
> must be non-negative. (I added a check for this into my patch).

Looking at ktime.h we find:

 * Be especially aware that negative values are represented in a way
 * that the tv.sec field is negative and the tv.nsec field is greater
 * or equal to zero but less than nanoseconds per second. This is the
 * same representation which is used by timespecs.
 *
 *   tv.sec < 0 and 0 >= tv.nsec < NSEC_PER_SEC

So it seems that the time values (or time intervals) in the range
-1 < x < 0 are not even possible, from the point of view of ktime.

> So it seems that I have now way to correctly encode a negative offset

I meant, "no way"---------^

> less than -1.0 into a timespec. Perhaps we could specify new rules for
> timespecs.

> 1. Time Values:
>    If tv_sec is non-zero, then tv_nsec must be non-negative.
> 
> 2. Time Deltas:
>    The sign of tv_sec and tv_nsec must be the same.

For me, the confusion gets worse when you consider the timespec values
delivered by the system for dates before the 1970 epoch. In that case,
the kernel always gives the tv_nsec value as a positive number. The
value makes sense when interpreted as a sum.

Reading consecutive clock values every 0.1 seconds produces, for
example:

{sec, nsec}        sum
-------------------------
{-2, +600000000}  -1.4
{-2, +700000000}  -1.3
{-2, +800000000}  -1.2
{-2, +900000000}  -1.1
{-1,  000000000}  -1.0
{-1, +100000000}  -0.9
{-1, +200000000}  -0.8
{-1, +300000000}  -0.7

If we say that the time value or interval in a timespec is always the
sum of the fields, still it would seem that the ktime code is broken
according to that assumption.

Perhaps someone can clarify?

Thanks,
Richard

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