cvs commit: src/sys/ufs/ffs ffs_alloc.c
brde at optusnet.com.au
Mon Oct 1 03:45:33 PDT 2007
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. 
>>>> Submitted by: pjd 
>>>> Revision Changes Path
>>>> 18.104.22.168 +4 -1 src/sys/ufs/ffs/ffs_alloc.c
>>> Does this by any chance fis this PR: kern/111352?
> yes it should. I closed the PR, See the comment there.
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
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
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.
More information about the cvs-src