From owner-freebsd-bugs@FreeBSD.ORG Mon May 29 14:10:35 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 465AD16AE4A for ; Mon, 29 May 2006 14:10:35 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3F8043D7F for ; Mon, 29 May 2006 14:10:25 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k4TEAPWa038960 for ; Mon, 29 May 2006 14:10:25 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k4TEAPYD038959; Mon, 29 May 2006 14:10:25 GMT (envelope-from gnats) Date: Mon, 29 May 2006 14:10:25 GMT Message-Id: <200605291410.k4TEAPYD038959@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Bruce Evans Cc: Subject: Re: kern/98064: Crash with FIFOs (named pipes) and truncate() X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2006 14:10:42 -0000 The following reply was made to PR kern/98064; it has been noted by GNATS. From: Bruce Evans To: Maxim Konovalov Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/98064: Crash with FIFOs (named pipes) and truncate() Date: Tue, 30 May 2006 00:04:23 +1000 (EST) On Mon, 29 May 2006, Maxim Konovalov wrote: >> I have used used the following fixes in this area for many years. They >> make truncate() on a fifo and some other file types always succeed >> instead of wandering off into UFS_TRUNCATE() (which is always (?) >> ffs_truncate()) and tending to cause panics there. > [...] > > Why doesn't RELENG_4 suffer from this? The code of ufs_setattr() is > very similar there. Hmm, my fixes are for ~5.2 and they may be unnecessary there too. I don't remember noticing this particular problem. Perhaps some changes in -current resulted in ffs_update() doing more and happening to do something bad. Unfortunately, the PR doesn't contain much debugging info so it isn't clear that the problem is in ffs_update(). I just found another problem. ffs_truncate() panics for read-only file systems. The unpatched ufs_setattr() only returns early for read-only file systems in the VREG, VLNK and VDIR cases. So ffs_truncate() on a fifo on a read-only file system can apparently very easily panic. The panic in ffs_truncate() is strangely placed after doing some things, both null things and things that attempt to write to the file system. These things are mainly: - handling extended attributes. I don't understand the details. - the !IO_NORMAL case (whatever that is). Returns success without checking for read-only. - new size too large. Returns failure early. - a subcase of the VLNK case. Attempts to write even to read-only file systems. Such writes are handled bogusly at lower levels and hopefully don't reach the disks (I use printfs to detect these and others. Most involve setting file times for read-only file systems or directives to set file times that aren't handled properly on changing from rw to ro. Here there is a file size change so not writing to disk might cause more serious problems). Returns early. In my previous reply I said that the VLNK case is unreachable and it panics if DIAGNOSTIC is configured. Actually, only a subcase of the subcase panics. - null truncates (ones which don't change the size). These are not quite null. They attempt to set the file times even for read-only file systems. Such writes are handled bogusly as above. Returns early. If ffs_update() gets through these things without returning, it always panics in the read-only case. The test program truncates to a nonzero length, presumably to get past the null truncate case, and its panic is not for the read-only case so it must be getting past the panic for that too. Bruce