code that says this:
nfsm_request(vp, NFSPROC_FSSTAT, p, cred);
if (v3)
nfsm_postop_attr(vp, retattr);
if (!error)
nfsm_dissect(sfp, struct nfs_statfs *, NFSX_STATFS(v3));
The problem here is that if error != 0, nfsm_dissect() will not be
called, which leaves sfp == NULL. But nfs_statfs() does not bail out
at this point: it continues processing until it tries to dereference
sfp, which causes a panic. I was able to generate this crash under
the following conditions:
1) Set up a machine as an NFS server and NFS client, with amd running
(using NIS maps). /usr/local is exported, though any exported fs
can can be used to trigger the bug.
2) Log in as normal user, with home directory mounted from a SunOS 4.1.3
NFS server via amd (along with a few other NFS filesystems from same
machine).
3) Su to root and type the following:
# mount localhost:/usr/local /mnt
# df
To fix the panic, I changed the code to read:
if (!error) {
nfsm_dissect(sfp, struct nfs_statfs *, NFSX_STATFS(v3));
} else
goto nfsmout;
This is a bit kludgy in that nfsmout is a label defined by the nfsm_subs.h
macros, but these macros are themselves more than a little kludgy. This
stops the machine from crashing, but does not fix the overall bug: 'error'
somehow becomes 5 (EIO) when a statfs() is performed on the locally mounted
NFS filesystem. This seems to only happen the first time the filesystem
is accesed: on subsequent accesses, it seems to work fine again.
Now, I know there's no practical use in mounting a local filesystem
via NFS, but doing it shouldn't cause the system to melt down.
Specifically, don't allow a value < 1 for any of them (it doesn't make
sense), and don't let the low water mark be greater than the corresponding
high water mark.
Pre-Approved by: wollman
Obtained from: NetBSD
available to the kernel (VM_KMEM_SIZE). The default (32 MB) is too low
when having 512 MB or more physical memory in a server environment. This is
relevant on systems where "panic: kmem_malloc: kmem_map too small" is a
problem.
value (200) is too low in some environments, causing a fatal
"panic: get_pv_entry: cannot get a pv_entry_t". The same panic might
still occur due to temporary shortage of free physical memory
(cf. PR i386/2431).
Catch SIGUSR1 to re-init listening socket.
Document signal behaviour.
Add missing '\n's to LogPrintf(LogWARN,...)
Main() returns int not void.
AF_LOCAL ideal suggested a long time ago by: joerg
Change sd_open, sd_close and sd_ioctl to use this lock to ensure
serialization of some critical operations, thus avoiding some
race conditions. Ideas picked from NetBSD (ccd and sd devices).
This fixes one of the problems noted in PR kern/3688.
Reviewed by: "Justin T. Gibbs" <gibbs@plutotech.com>
