From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 19 14:08:36 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A579316A402; Mon, 19 Feb 2007 14:08:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7430013C467; Mon, 19 Feb 2007 14:08:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1C535495AF; Mon, 19 Feb 2007 09:08:36 -0500 (EST) Date: Mon, 19 Feb 2007 14:08:36 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Josef Karthauser In-Reply-To: <20070219135921.E80197@fledge.watson.org> Message-ID: <20070219140721.S80197@fledge.watson.org> References: <20070204023711.GA3393@genius.tao.org.uk> <20070215135750.GR64768@obiwan.tataz.chchile.org> <20070215152259.GA2950@genius.tao.org.uk> <20070215153135.GI39168@deviant.kiev.zoral.com.ua> <20070216125007.D38234@fledge.watson.org> <20070216143656.GM39168@deviant.kiev.zoral.com.ua> <20070218224158.GA1297@genius.tao.org.uk> <20070219135921.E80197@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: hackers@freebsd.org, Jeremie Le Hen , fs@freebsd.org Subject: Re: nullfs and named pipes. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 14:08:36 -0000 On Mon, 19 Feb 2007, Robert Watson wrote: > On Sun, 18 Feb 2007, Josef Karthauser wrote: > > Well, the worry would be that you would be replacing a clean error on > failure with an occasional panic, the normal symptom of a race condition. > > I think I'm alright with the VFIFO case above, but I'm quite uncomfortable > with the VSOCK case. In particular, I suspect that if the socket is closed, > v_un will be reset in the lower layer, but continue to be a stale pointer in > the upper layer, leading to accessing free'd or re-allocated kernel memory > resulting in much badness. I've noticed tested this, but you might give it > a try and see what happens. Bad typing day. Should read "not tested this". In any case, you get the idea: the problem here is a potential coherency issue on contents of v_un between the two file system layers. Robert N M Watson Computer Laboratory University of Cambridge