[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
kern/37951: tmpfs panic with big mount size in 64-bit platforms
>Synopsis: tmpfs panic with big mount size in 64-bit platforms
>Arrival-Date: Mon Feb 04 13:55:00 +0000 2008
>Originator: Julio M. Merino Vidal
>Release: NetBSD current (sources from 20080204)
Mounting a tmpfs with a size of 9223372036854775807 bytes (the
maximum number that can be passed to mount_tmpfs) immediately
crashes a NetBSD/amd64 box.
The problem comes from tmpfs.h version 1.30 (merge of the vmlocking
branch). In that change, multiple fields of the tmpfs_mount
structure were changed to u_int (why not unsigned int?) so that
they can be accessed atomically. These variables went from being
64-bits wide to 32-bits only.
However, the part of the code that initializes those does not use
unsigned ints. It uses the correct types to hold the numbers, which
in these two cases should be 64-bit integers (shouldn't the compiler
raise warnings about loss of precision?). As a result, the original
values are truncated to weird values and the allocation of the root
node fails later on in:
KASSERT(error == 0 && root != NULL)
The call to tmpfs_alloc_node returns ENOSPC because TMPFS_POOL_GET
fails given that the values for the max pages and nodes are bogus.
As should have been done in the first place:
# cd /usr/tests/fs/tmpfs
# ./t_mount large
# mount -t tmpfs -o -s9223372036854775807 tmpfs /mnt
Both procedures cause an immediate panic.
Revert change and use size_t and ino_t types again?
Main Index |
Thread Index |