linux-kernel - Re: [RESEND][RFC PATCH v2] waitfd

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: <49691134.1070005@redhat.com>
Date:	Sat, 10 Jan 2009 16:20:52 -0500
From:	Casey Dahlin <cdahlin@...hat.com>
To:	Scott James Remnant <scott@...onical.com>
CC:	Roland McGrath <roland@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Ulrich Drepper <drepper@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Davide Libenzi <davidel@...ilserver.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [RESEND][RFC PATCH v2] waitfd

Scott James Remnant wrote:
> On Thu, 2009-01-08 at 15:36 -0500, Casey Dahlin wrote:
>
>   
>> Roland McGrath wrote:
>>     
>>>>> Since waitfd shouldn't consume the child termination notification
>>>>> waitfd should be more widely usable than the wait*() interfaces.
>>>>>           
>>> waitid can be used that way with WNOWAIT.
>>>       
>> Yes, but waitfd does not have this flag. The reason being waitfd just
>> calls waitid internally, and there is no guarantee (afaik) that
>> calling waitid with WNOWAIT multiple times in succession will yield
>> different results each time. This breaks the streaming behavior of the
>> descriptor.
>>
>>     
> This would definitely be a Nice To Have though!
>
> Being able to use waitid() on another process of the same uid, with
> WNOHANG, in a streaming fashion would be a *very* cool thing.
>
> Scott
>   
That could be done in a separate patch for waitid itself, and its a 
simple change to propagate it through waitfd (just one less EINVAL 
case). In terms of waitfd we'd be supersetting the interface, so its no 
big deal to add. In terms of waitid I'd have to check and make sure that 
we wouldn't be breaking compliance by allowing it to return something 
different on every call (this would likely affect cases where 
waitid(WNOWAIT) was used even in a normal fashion as well).

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