From: Dawson Engler <engler@coverity.dreamhost.com>
To: linux-kernel@vger.kernel.org
Cc: developers@coverity.com
Subject: [CHECKER] potential NFS deadlock in 2.6.8.1
Date: Tue, 7 Sep 2004 19:49:50 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.58.0409071949070.28006@coverity.dreamhost.com> (raw)
Hi All,
below is a possible deadlock in the linux-2.6.8.1 NFS found by a static
deadlock checker I'm writing. Let me know if it looks valid and/or
whether the output is too cryptic.
Thanks,
Dawson
------------------------------------------------------------------
ERROR:DEADLOCK: 2 thread cycle:
lock_kernel <<===>> client_sema
[both traces look valid]
thread 1: lock_kernel ==>> client_sema
2 traces
trace 1: ncalls=2, ncond=0
fs/nfsd/nfssvc.c:nfsd
172: nfsd(struct svc_rqst *rqstp)
173: {
174: struct svc_serv *serv = rqstp->rq_server;
175: struct fs_struct *fsp;
176: int err;
...
257: break;
258: err = signo;
259: }
260:
===> 261: lock_kernel();
...
266: /* Check if this is last thread */
267: if (serv->sv_nrthreads==1) {
268:
269: printk(KERN_WARNING "nfsd: last server has exited\n");
270: if (err != SIG_NOCLEAN) {
...
272: nfsd_export_flush();
273: }
274: nfsd_serv = NULL;
275: nfsd_racache_shutdown(); /* release read-ahead cache */
===> 276: nfs4_state_shutdown();
fs/nfsd/nfs4state.c:nfs4_state_shutdown
2703: nfs4_state_shutdown(void)
2704: {
===> 2705: nfs4_lock_state();
fs/nfsd/nfs4state.c:nfs4_lock_state
91: nfs4_lock_state(void)
92: {
===> 93: down(&client_sema);
trace 2: ncalls=2, ncond=0
fs/nfsd/nfssvc.c:nfsd_svc
79: nfsd_svc(unsigned short port, int nrservs)
80: {
81: int error;
82: int none_left;
83: struct list_head *victim;
84:
===> 85: lock_kernel();
...
130: victim = victim->next;
131: send_sig(SIG_NOCLEAN, nl->task, 1);
132: nrservs++;
133: }
134: failure:
...
136: svc_destroy(nfsd_serv); /* Release server */
137: if (none_left) {
138: nfsd_serv = NULL;
139: nfsd_racache_shutdown();
===> 140: nfs4_state_shutdown();
fs/nfsd/nfs4state.c:nfs4_state_shutdown
2703: nfs4_state_shutdown(void)
2704: {
===> 2705: nfs4_lock_state();
fs/nfsd/nfs4state.c:nfs4_lock_state
91: nfs4_lock_state(void)
92: {
===> 93: down(&client_sema);
---------------------------------------------------------
[both of these traces look valid]
thread 2: client_sema ==>> lock_kernel
[looks valid]
trace 1: ncalls=2, ncond=0
fs/nfsd/nfs4state.c:nfsd4_lock
2084: nfsd4_lock(struct svc_rqst *rqstp, struct svc_fh *current_fh, struct nfsd4_lock *lock)
2085: {
2086: struct nfs4_stateowner *lock_sop = NULL, *open_sop = NULL;
2087: struct nfs4_stateid *lock_stp;
2088: struct file *filp;
...
2103: if (check_lock_length(lock->lk_offset, lock->lk_length))
2104: return nfserr_inval;
2105:
2106: lock->lk_stateowner = NULL;
===> 2107: nfs4_lock_state();
fs/nfsd/nfs4state.c:nfs4_lock_state
91: nfs4_lock_state(void)
92: {
===> 93: down(&client_sema);
path to B acquisition:
...
2229: dprintk("NFSD: nfsd4_lock: posix_lock_file() failed! status %d\n",status);
2230: goto out_destroy_new_stateid;
2231: }
2232:
2233: conflicting_lock:
...
2235: status = nfserr_denied;
2236: /* XXX There is a race here. Future patch needed to provide
2237: * an atomic posix_lock_and_test_file
2238: */
===> 2239: if (!(conflock = posix_test_lock(filp, &file_lock))) {
fs/locks.c:posix_test_lock
598: posix_test_lock(struct file *filp, struct file_lock *fl)
599: {
600: struct file_lock *cfl;
601:
===> 602: lock_kernel();
trace 3: ncalls=2, ncond=0
fs/nfsd/nfs4state.c:nfsd4_release_lockowner
...
===> 2463: nfs4_lock_state();
fs/nfsd/nfs4state.c:nfs4_lock_state
91: nfs4_lock_state(void)
92: {
===> 93: down(&client_sema);
...
===> 2476: if (check_for_locks(&stp->st_vfs_file, local))
fs/nfsd/nfs4state.c:check_for_locks
2427: check_for_locks(struct file *filp, struct nfs4_stateowner *lowner)
2428: {
2429: struct file_lock **flpp;
2430: struct inode *inode = filp->f_dentry->d_inode;
2431: int status = 0;
2432:
===> 2433: lock_kernel();
next reply other threads:[~2004-09-08 2:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-08 2:49 Dawson Engler [this message]
2004-09-08 3:08 ` Nick Piggin
2004-09-08 3:29 ` Greg Banks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.58.0409071949070.28006@coverity.dreamhost.com \
--to=engler@coverity.dreamhost.com \
--cc=developers@coverity.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®