From owner-freebsd-fs@FreeBSD.ORG Mon Feb 19 14:29:11 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D316116A400; Mon, 19 Feb 2007 14:29:11 +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 9E05213C48E; Mon, 19 Feb 2007 14:29:11 +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 CD30A4969A; Mon, 19 Feb 2007 09:29:10 -0500 (EST) Date: Mon, 19 Feb 2007 14:29:10 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Josef Karthauser In-Reply-To: <20070219140721.S80197@fledge.watson.org> Message-ID: <20070219142816.N80197@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> <20070219140721.S80197@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-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 14:29:11 -0000 On Mon, 19 Feb 2007, Robert Watson wrote: > 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. For some reason I was thinking of v_fifoinfo as being stable after it is initialized, but in fact, it is not, as it can be free'd later. Also, the layers could become out of sync following a reboot. So in conclusion, I think the fifo part of the patch also suffers from the same problem. Robert N M Watson Computer Laboratory University of Cambridge