-ENOMEM from server file system leaves dentry held
Subsystems (2)
We are running on 2.4.17 on the server. I think the client had 2.4.13.
Anyway, I traced the code and found a way that the dentry is left held through one iteration of a server write. I did this with kdb.
The code path starts in net/sunrpc/svc.c:svc_process() which alls nfsd_dispatch().
nfsd_dispatch() calls nfsd3_proc_write() at:
nfserr = proc->pc_func(rqstp, rqstp->rq_argp, rqstp->rq_resp);
if (nfserr == nfserr_dropit) {
dprintk("nfsd: Dropping request due to malloc failure!\n");
nfsd_cache_update(rqstp, RC_NOCACHE, NULL);
return 0;
}nfsd3_proc_write calls nfsd_write()nfsd_write() calls nfsd_open() works (and does the fh_verify() which holds the dentry).
nfsd_write calls the underlying file system and let's say it returns -ENOMEM. nfserrno() will convert this to nfserr_dropit.
This gets returned up to nfs3_proc_write() which then returns nfserr_dropit to nfsd_dispatch(). The above code return's 0 to svc_process().
svc_process drops the packet without calling the release function so the handle is never released.
Not sure what the appropriate fix is, but one could call the release function in nfsd_write if it is about to return "drop it" and the nfsd_open succeeded.
Or is a file system never supposed to return -ENOMEM when the write file op is called?
Tnanks,
Signature · 13 lines
[email protected] 952-882-0616 952-221-1183 cell ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ NFS maillist - [email protected] https://lists.sourceforge.net/lists/listinfo/nfs