Bug 91879

Summary: [patch] Panic in nfs_putpages() on 6-stable.
Product: Base System Reporter: frank
Component: kernAssignee: Alfred Perlstein <alfred>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 7.0-CURRENT   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description frank 2006-01-16 18:50:07 UTC 

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.

After further silence from the mailing lists, I went ahead and fixed the problem.

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.

I suggest MFC to (at least) 6-stable ASAP; that is in fact where I tested it.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2006-01-19 00:46:49 UTC 
State Changed
From-To: open->patched

Fixed in head in r1.91.
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2006-01-19 00:46:49 UTC 
Responsible Changed
From-To: freebsd-bugs->alfred

MFC reminder for committer.
Comment 3 Rong-En Fan 2006-03-13 14:56:28 UTC 
From cvs-src logs, this has been MFC'ed by scottl@
yesterday.
Comment 4 Xin LI freebsd_committer freebsd_triage 2006-09-11 16:40:47 UTC 
State Changed
From-To: patched->closed

scottl@ has MFC'ed the change to RELENG_6.