From owner-freebsd-bugs@FreeBSD.ORG Wed Jul 10 22:30:02 2013 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 35D2BB65 for ; Wed, 10 Jul 2013 22:30:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 0D2391F0C for ; Wed, 10 Jul 2013 22:30:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6AMU1HV033006 for ; Wed, 10 Jul 2013 22:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6AMU0tK033005; Wed, 10 Jul 2013 22:30:00 GMT (envelope-from gnats) Date: Wed, 10 Jul 2013 22:30:00 GMT Message-Id: <201307102230.r6AMU0tK033005@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Jilles Tjoelker Subject: Re: kern/180385: [kqueue] Conflict between EVFILT_PROC NOTE_CHILD and NOTE_EXIT use of data field X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Jilles Tjoelker List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 22:30:02 -0000 The following reply was made to PR kern/180385; it has been noted by GNATS. From: Jilles Tjoelker 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