Date: Wed, 10 Jul 2013 22:30:00 GMT From: Jilles Tjoelker <jilles@stack.nl> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/180385: [kqueue] Conflict between EVFILT_PROC NOTE_CHILD and NOTE_EXIT use of data field Message-ID: <201307102230.r6AMU0tK033005@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/180385; it has been noted by GNATS. From: Jilles Tjoelker <jilles@stack.nl> To: bug-followup@FreeBSD.org, David_A_Bright@DELL.com Cc: Subject: Re: kern/180385: [kqueue] Conflict between EVFILT_PROC NOTE_CHILD and NOTE_EXIT use of data field Date: Thu, 11 Jul 2013 00:24:21 +0200 Hi, In PR 180385, you wrote about problems with EVFILT_PROC/NOTE_TRACK. I tried to use this too (for system service management, pid 1 or close to it) but ran across a problem already while reading the man page: NOTE_TRACKERR. If NOTE_TRACKERR happens, all the tracking breaks down. How do you deal with this? NOTE_CHILD|NOTE_EXIT knotes can be seen easily by suspending the process so it does not invoke kevent() for a long time. If EVFILT_PROC is not supposed to keep zombies alive (pretty much mandatory, otherwise any user can prevent any other user from freeing up proc slots by reaping zombies), then limiting the number of knotes that do not correspond to a live kernel object implies that NOTE_TRACKERR must be possible. Removing NOTE_TRACKERR would require discarding NOTE_CHILD|NOTE_EXIT knotes when the zombie is reaped. Even then, guaranteeing no NOTE_TRACKERR may cause fork() to fail sooner than without active kqueues. The extra restrictions can be compared to how waitpid() accepts (discards) the instance of the SIGCHLD signal for the waited process, ensuring that every terminating process generates a SIGCHLD signal while bounding memory usage for undelivered signals. Splitting NOTE_CHILD|NOTE_EXIT into two knotes either requires allocating two knotes at fork() time (making NOTE_TRACKERR slightly more likely and possibly wasting some memory) or allowing the split to fail. A partial workaround for your issue may be the udata field. I think (untested) that the udata field is copied upon NOTE_CHILD. This does not allow tracking the full parent-child relationships, but does allow tracking all descendants of a particular process (except if NOTE_TRACKERR happens). -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201307102230.r6AMU0tK033005>