cvs commit: src/sys/fs/hpfs hpfs_vnops.c src/sys/fs/msdosfs
msdosfs_denode.c src/sys/fs/ntfs ntfs_vnops.c src/sys/fs/nwfs
nwfs_node.c src/sys/fs/smbfs smbfs_node.c src/sys/fs/udf
udf_vnops.c src/sys/isofs/cd9660 cd9660_node.c src/sys/nfsclient ...
Alfred Perlstein
alfred at FreeBSD.org
Tue Jan 17 09:29:06 PST 2006
alfred 2006-01-17 17:29:03 UTC
FreeBSD src repository
Modified files:
sys/fs/hpfs hpfs_vnops.c
sys/fs/msdosfs msdosfs_denode.c
sys/fs/ntfs ntfs_vnops.c
sys/fs/nwfs nwfs_node.c
sys/fs/smbfs smbfs_node.c
sys/fs/udf udf_vnops.c
sys/isofs/cd9660 cd9660_node.c
sys/nfsclient nfs_node.c
Log:
I ran into an nfs client panic a couple of times in a row over the
last few days. I tracked it down to the fact that nfs_reclaim()
is setting vp->v_data to NULL _before_ calling vnode_destroy_object().
After silence from the mailing list I checked further and discovered
that ufs_reclaim() is unique among FreeBSD filesystems for calling
vnode_destroy_object() early, long before tossing v_data or much
of anything else, for that matter. The rest, including NFS, appear
to be identical, as if they were just clones of one original routine.
The enclosed patch fixes all file systems in essentially the same
way, by moving the call to vnode_destroy_object() to early in the
routine (before the call to vfs_hash_remove(), if any). I have
only tested NFS, but I've now run for over eighteen hours with the
patch where I wouldn't get past four or five without it.
Submitted by: Frank Mayhar
Requested by: Mohan Srinivasan
MFC After: 1 week
Revision Changes Path
1.68 +5 -1 src/sys/fs/hpfs/hpfs_vnops.c
1.91 +4 -1 src/sys/fs/msdosfs/msdosfs_denode.c
1.57 +5 -1 src/sys/fs/ntfs/ntfs_vnops.c
1.38 +5 -1 src/sys/fs/nwfs/nwfs_node.c
1.30 +4 -1 src/sys/fs/smbfs/smbfs_node.c
1.60 +5 -1 src/sys/fs/udf/udf_vnops.c
1.55 +4 -1 src/sys/isofs/cd9660/cd9660_node.c
1.79 +5 -1 src/sys/nfsclient/nfs_node.c
More information about the cvs-src
mailing list