Skip to contentSkip to conversation

fh_lock again

DISCUSSION Wendy Cheng 1 participant 1 message Feb 17, 2003

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

On 2.4.19 kernel within nfsd_create():

there is a check to see whether the response file handle has been verified:

if (!resfph->fh_dentry) {
    fh_lock(fhp);
    ....
}

The inode semaphore withing the fh_lock() hangs one of the nfsds while running a failover test (we're trying out a high availability file server design). The client is doing a "mkdir" request. Similar problems are also found in "remove" and "rmdir" requests. All runs are under NFS version 3.

Unlike the remove and rmdir where we added "fh_put" after the nfsd_unlink() calls to make the hang go away, the hang within the nfsd_create() makes me a little bit uneasy. Not sure whether we do something wrong in
the failover logic or it is just simply a linux nfsd coding oversight - could some nfsd gurus take a look (linux/open source is a new thing to me). My question is, in simple words, where should this inode semaphore (inode->i_sem) get released ? Is this a nfs v3 coding oversight or the semaphore is released somewhere in nfsd path that I don't know about (found a fh_put in nfssvc_release_fhandle() within nfsxdr.c but with xdr's extensive use of function pointers, it is hard to figure out who uses it).

Any help would be greatly appreciated.

Wendy