linux-kernel - Re: [RFC PATCH] waitfd: file descriptor to wait on child processes

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: <493EC53F.8060106@redhat.com>
Date:	Tue, 09 Dec 2008 14:21:35 -0500
From:	Casey Dahlin <cdahlin@...hat.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Linux Kernel <linux-kernel@...r.kernel.org>,
	Scott James Remnant <scott@...split.com>
Subject: Re: [RFC PATCH] waitfd: file descriptor to wait on child processes

Alan Cox wrote:
>>> This propogates the fundamental braindamage of waitpid - the fact the
>>> notification only works on child process trees.
>>>
>>> Here is a more elegant suggestion - use epoll, inotify and friends  fully
>>> on /proc process nodes.
>>>       
>
>   
>> Last I checked inotify was not supported in /proc, or at least most of 
>> it. What kind of work load is it to change that?
>>     
>
> I don't know but I think it would be the better approach to find it. That
> also separates notification of state to parents from the general problem
> of wanting to know when a service has died, which seems to be an ever
> more common point of interest on the desktop in particular.
>
>   
Of course, using inotify on proc will not (and should not) actually reap 
dead processes, meaning waitpid() isn't obviated by the change (though 
now it is always called on a specific pid and is never expected to block 
or EAGAIN). We also introduce a new gotcha for userspace programs: this 
mechanism works identically for child and non-child processes, so a 
process may or may not be waitable when returned. A simple "do not shoot 
self in foot" should suffice for this though.

Also, it doesn't work if /proc hasn't been mounted, which just so 
happens to matter for my particular use cases :)
> File content change notification for /proc is hard because the contents
> don't exist in the normal way and get updated but can be done if there is
> a wait queue for the job. Actual changes to structure (new directories
> etc) is in part a similar problem but there are clear points already in
> existence when the proc nodes are created/destroyed and thus notification
> can occur.
>
>   
Changes to structure are more interesting in terms of this particular 
problem anyway, and definitely simpler to capture.

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