Date: Mon, 3 Oct 2005 15:33:48 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: kris@obsecurity.org Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/ufs/ffs ffs_alloc.c Message-ID: <200510032233.j93MXnvc019498@gw.catspoiler.org> In-Reply-To: <20051003221608.GA98675@xor.obsecurity.org>
index | next in thread | previous in thread | raw e-mail
On 3 Oct, Kris Kennaway wrote: > On Mon, Oct 03, 2005 at 09:57:43PM +0000, Don Lewis wrote: >> truckman 2005-10-03 21:57:43 UTC >> >> FreeBSD src repository >> >> Modified files: >> sys/ufs/ffs ffs_alloc.c >> Log: >> Initialize the inode i_flag field in ffs_valloc() to clean up any >> stale flag bits left over from before the inode was recycled. >> >> Without this change, a leftover IN_SPACECOUNTED flag could prevent >> softdep_freefile() and softdep_releasefile() from incrementing >> fs_pendinginodes. Because handle_workitem_freefile() unconditionally >> decrements fs_pendinginodes, a negative value could be reported at >> file system unmount time with a message like: >> unmount pending error: blocks 0 files -3 >> The pending block count in fs_pendingblocks could also be negative >> for similar reasons. These errors can cause the data returned by >> statfs() to be slightly incorrect. Some other cleanup code in >> softdep_releasefile() could also be incorrectly bypassed. >> >> MFC after: 3 days > > Yeah! > > This also affects 5.x, by the way. Probably 4.x as well. I'm planning on MFC'ing this all the way back once it has aged sufficiently.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200510032233.j93MXnvc019498>