linux-kernel - Re: [PATCH] Revised timerfd() interface

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <46E4B6D1.6080909@gmx.net>
Date:	Mon, 10 Sep 2007 05:15:29 +0200
From:	Michael Kerrisk <mtk-manpages@....net>
To:	Davide Libenzi <davidel@...ilserver.org>
CC:	Andrew Morton <akpm@...ux-foundation.org>, corbet@....net,
	jengelh@...putergmbh.de, hch@....de, stable@...nel.org,
	Ulrich Drepper <drepper@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	tglx@...utronix.de, rdunlap@...otime.net
Subject: Re: [PATCH] Revised timerfd() interface

Hi Davide,

>> This function is *not at all* equivalent to the "get"
>> functionality of the previous APIs.  The "get" functionality
>> of POSIX timers (for example) returns a structure that contains
>> the timer interval and the *time until the next expiration of
>> the timer* (not the initial timer string, as your code above
>> does).
>> So come up with a reliable, race-free way of doing that in
>> userspace.  Then make it work for both CLOCK_MONOTONIC and
>> CLOCK_REALTIME timers.  (You'll certainly need to be making
>> some additional system calls, by the way: at least some
>> calls to clock_gettime().)
> 
> No, I don't think I will. Since 1) it's so trivial it's not even 
> challenging 

Well, it seems to me that the proposed library wrapper code
could start to get rather verbose by the time one adds in
these changes (plus the mutexes).

> 2) you know it can be done (I assume) 

Sorry -- I was probably speaking too rhetorically.  In fact, it's
not completely clear to me that it can (always) be done.  For
example, the answer depends on knowing the clockid.  But
what if the file descriptor has been handed off to some code
that doesn't know the clock type (i.e., isn't accessing the fd
via your suggested library)?

Cheers,

Michael

> 3) it solves a non-case 
> made up to justify an API/kernel-code bloating.
> But you don't need *my* signoff. Cook a working patch, make a case for it, 
> and gather support and signoffs. I won't be acking it because, as I said 
> many times, I think it's useless bloating.

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