Date: Mon, 1 Oct 2007 20:45:27 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: "Bjoern A. Zeeb" <bz@freebsd.org> Cc: Tom Judge <tom@tomjudge.com>, 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: <20071001201359.M2557@besplex.bde.org> In-Reply-To: <20071001090547.H85753@maildrop.int.zabbadoz.net> References: <200709241339.l8ODd6k6059694@repoman.freebsd.org> <47002674.8050707@tomjudge.com> <47002E2F.3030306@tomjudge.com> <20071001090547.H85753@maildrop.int.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 1 Oct 2007, Bjoern A. Zeeb wrote: > On Mon, 1 Oct 2007, Tom Judge wrote: > >> Tom Judge wrote: >>> Bjoern A. Zeeb wrote: >>>> bz 2007-09-24 13:39:06 UTC >>>> >>>> FreeBSD src repository >>>> >>>> Modified files: (Branch: RELENG_6) >>>> sys/ufs/ffs ffs_alloc.c Log: >>>> MFC rev. 1.147 >>>> Fix a DIV0 in case a large value for fs_avgfilesize or fs_avgfpdir >>>> is given (with newfs or tunefs) and dirsize overflows. >>>> In case dirsize is <= 0 because of an overflow set maxcontigdirs >>>> to 0 so it will be 1 later. This is what would happen for large >>>> fs_avgfilesize. [1] >>>> Submitted by: pjd [1] >>>> Revision Changes Path >>>> 1.132.2.7 +4 -1 src/sys/ufs/ffs/ffs_alloc.c >>> >>> >>> Does this by any chance fis this PR: kern/111352? >> >> s/fis/fix/ > > yes it should. I closed the PR, See the comment there. s/fix/work around/ The bug is in newfs and tunefs permitting garbage parameters, so it cannot be fixed in ffs_alloc.c. It can also be worked around better in ffs_vfsops.c: fix the garbage parameters at mount time, instead of letting them cause undefined behaviour on every directory allocation later and recovering from the overflow in some cases. ffs_vfsops.c already adjusts the parameters for file systems created by old versions of newfs which don't support them. Then they have the garbage value 0, while versions of newfs and tunefs that support them enforce them being > 0. Enforcing them being <= a maximum value belongs mext to the code that enforces them being > 0, and fixing up garbage large values belongs next to the code that fixes up garbage values of <= 0. Fixups belong in fsck_ffs too, but fsck_ffs doesn't even reference the 5-yar old avgfpdir and avgfilesize parameters. History shows that fixups at mount time take a long time to get moved to fsck_ffs. It's just easier to do runtime fixups. Fixups at mount time used to be marked with /* XXX [move to fsck] */, but now there are many more of them than there used to be, and most aren't marked. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071001201359.M2557>