Date: Mon, 29 May 2006 14:10:25 GMT From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/98064: Crash with FIFOs (named pipes) and truncate() Message-ID: <200605291410.k4TEAPYD038959@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/98064; it has been noted by GNATS. From: Bruce Evans <bde@zeta.org.au> To: Maxim Konovalov <maxim@macomnet.ru> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200605291410.k4TEAPYD038959>