Date: Mon, 3 Oct 2005 18:16:08 -0400 From: Kris Kennaway <kris@obsecurity.org> To: Don Lewis <truckman@FreeBSD.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: <20051003221608.GA98675@xor.obsecurity.org> In-Reply-To: <200510032157.j93LvhM7022905@repoman.freebsd.org> References: <200510032157.j93LvhM7022905@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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. Kris [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDQa2oWry0BWjoQKURAgM2AKDqbqNvzq68EkMZEmSvn5bcS6RSAQCggLl/ kkzX6Ow3+9yL8H1wgMS84Rk= =6lw+ -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051003221608.GA98675>