linux-kernel - RE: [PATCH] ia64: Scalability improvement of gettimeofday with jitter compensation

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: <617E1C2C70743745A92448908E030B2A01B3475A@scsmsx411.amr.corp.intel.com>
Date:	Fri, 15 Jun 2007 13:03:08 -0700
From:	"Luck, Tony" <tony.luck@...el.com>
To:	"Christoph Lameter" <clameter@....com>,
	"Hidetoshi Seto" <seto.hidetoshi@...fujitsu.com>
Cc:	<linux-ia64@...r.kernel.org>,
	"Linux Kernel list" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] ia64: Scalability improvement of gettimeofday with jitter compensation

> >   ret = cmpxchg(&last_cycle, last, new);
> >   if (ret == last)
> >     return new; /* you win! */
> >   else
> >     return ret; /* you lose. ret is winner's new */
>
> Interesting solution. But there may be multiple updates of last happening. 
> Which of the winners is the real winner?

It might not matter.  Let's look at how good a guarantee an
application can expect from gettimeofday().  First of all
there may be arbitrary delays either before, or after the
kernel comes up with the "current" time since the process
could be context switched in the glibc prologue or epilogue
for the system call.  So I think that the best that an
application can expect is:

 Given two calls to gettimeofday A and B, where through some
 external syncronization it is known that call B is initiated
 after A has completed, then B shall not return a time value
 lower than that returned by A.

Now if that is the strongest ordering that an application can
expect (and I'm not completely convinced that I'm right, other
definitions gratefully accepted), then it would appear that
is is just over-engineering to worry too much about calls that
collide inside the kernel (since these don't satisfy the
"B initiated after A completes" clause of my definition).

-Tony

[For some 50 year old British humour on the subject of time,
 read: http://www.hexmaster.com/goonscripts/what_time_is_it.html ]
-
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/