From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 17:42:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 884F816A4CE; Fri, 12 Nov 2004 17:42:22 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22B6743D2D; Fri, 12 Nov 2004 17:42:22 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id iACHgBAN066957; Fri, 12 Nov 2004 09:42:15 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200411121742.iACHgBAN066957@gw.catspoiler.org> Date: Fri, 12 Nov 2004 09:42:11 -0800 (PST) From: Don Lewis To: rwatson@FreeBSD.org In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: jmg@FreeBSD.org cc: silby@FreeBSD.org cc: current@FreeBSD.org Subject: Re: Race in pipe tear-down, perhaps kqueue-related? (was: Re: Fatal trap , 12: page fault in kern/kern_mutex.c:744) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2004 17:42:22 -0000 On 12 Nov, Robert Watson wrote: > > On Fri, 12 Nov 2004, Peter Holm wrote: > >> GENERIC HEAD from Nov 11 08:05 UTC >> http://www.holm.cc/stress/log/cons87.html > > This looks like a bug in the pipe code where-in a partially initialized > pipe is free'd due to memory allocation problems (hitting a resource > limit). pipeclose() is called when pipe_create() fails on one of the two > pipe endpoints, but it looks like pipeclose() is unprepared for the > eventuality that this is the case, as it attempts to generate wakeup > events on the pipe endpoint using pipeselwakeup(), which is not the right > thing to do while the pipe is not yet initialized. Maybe we need a > special pipeclose() tear-down path that doesn't assume the pipe has > already been fully initialized? Sounds similar to what I did in the fifo open/close code, though I seem to recall that the motivation was related to locking.