linux-kernel - Re: [take19 0/4] kevent: Generic event handling mechanism.

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: <4532B99B.9030403@redhat.com>
Date:	Sun, 15 Oct 2006 15:43:39 -0700
From:	Ulrich Drepper <drepper@...hat.com>
To:	Evgeniy Polyakov <johnpol@....mipt.ru>
CC:	Ulrich Drepper <drepper@...il.com>,
	lkml <linux-kernel@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Andrew Morton <akpm@...l.org>, netdev <netdev@...r.kernel.org>,
	Zach Brown <zach.brown@...cle.com>,
	Christoph Hellwig <hch@...radead.org>,
	Chase Venters <chase.venters@...entec.com>
Subject: Re: [take19 0/4] kevent: Generic event handling mechanism.

Evgeniy Polyakov wrote:
> In context you have cut, one updated signal mask between calls to event
> delivery mechanism (using for example signal()), so it has exactly the
> same price.

No, it does not.  If the signal mask is recomputed by the program for 
each new wait call then you have a lot more work to do when the signal 
mask is implicitly specified.

> I created it just because I think that POSIX workaround to add signals
> into the syscall parameters is not good enough.

Not good enough?  It does exactly what it is supposed to do.  What can 
there be "not good enough"?

> You again cut my explanation on why just pure timeout is used.
> We start a syscall, which can block forever, so we want to limit it's
> time, and we add special parameter to show how long this syscall should
> run. Timeout is not about how long we should sleep (which indeed can be
> absolute), but how long syscall should run - which is related to the 
> time syscall started.

I know very well what a timeout is.  But the way the timeout can be 
specified can vary.  It is often useful (as for select, poll) to specify 
relative timeouts.

But there are equally useful uses where the timeout is needed at a 
specific point in time.  Without a syscall interface which can have a 
absolute timeout parameter we'd have to write as a poor approximation at 
userlever

     clock_gettime (CLOCK_REALTIME, &ts);
     struct timespec rel;
     rel.tv_sec = abstmo.tv_sec - ts.tv_sec;
     rel.tv_nsec = abstmo.tv_sec - ts.tv_nsec;
     if (rel.tv_nsec < 0) {
       rel.tv_nsec += 1000000000;
       --rel.tv_sec;
     }
     if (rel.tv_sec < 0)
       inttmo = -1;  // or whatever is used for return immediately
     else
       inttmo = rel.tv_sec * UINT64_C(1000000000) + rel.tv_nsec;

      wait(..., inttmo, ...)

Not only is this much more expensive to do at userlevel, it is also 
inadequate because calls to settimeofday() do  not cause a recomputation 
of the timeout.

See Ingo's RT futex stuff as an example for a kernel interface which 
does it right.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
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/