kern/37951: tmpfs panic with big mount size in 64-bit platforms

[jmmv%netbsd.org@localhost]

>Number:         37951
>Category:       kern
>Synopsis:       tmpfs panic with big mount size in 64-bit platforms
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 04 13:55:00 +0000 2008
>Originator:     Julio M. Merino Vidal
>Release:        NetBSD current (sources from 20080204)
>Organization:
>Environment:
        
        
Architecture: amd64
Machine: x86_64
>Description:
        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.

>How-To-Repeat:
        As should have been done in the first place:

        # cd /usr/tests/fs/tmpfs
        # ./t_mount large

        Alternatively:

        # mount -t tmpfs -o -s9223372036854775807 tmpfs /mnt

        Both procedures cause an immediate panic.

>Fix:
        Revert change and use size_t and ino_t types again?

>Unformatted: