From: Jeff Moyer <jmoyer@redhat.com> To: linuxram@us.ibm.com (Ram Pai) Cc: autofs@linux.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [RFC PATCH]autofs4: hang and proposed fix Date: Wed, 16 Nov 2005 10:22:40 -0500 [thread overview] Message-ID: <17275.20160.12805.536289@segfault.boston.redhat.com> (raw) In-Reply-To: <20051116101740.GA9551@RAM> ==> Regarding [autofs] [RFC PATCH]autofs4: hang and proposed fix; linuxram@us.ibm.com (Ram Pai) adds: ram> Autofs4 assumes that its ->revalidate() function gets called with the ram> parent_dentry's_inode_semaphore released. This is true mostly ram> but not in one particular case. ram> Process P1 calls autofs4's ->lookup(). The lookup finds that the dentry ram> does not exist. It creates a dentry and adds to the cache. Releases ram> the parent's inode's semaphore and than calls ->revalidate(). ram> Process P2 meanwhile comes in and cached_lookup() gets called. It finds ram> the dentry in the cache and finds ->revalidate() function exists. So ram> it calls ->revalidate() holding the parent's inode's semaphore. ram> Now the automounter daemon comes in and tries to hold the same semaphore ram> in order to mount. But since the semaphore is held by P2 it ram> goes to sleep. ram> Process P1 and P2 continue waiting for the mount to complete and it never ram> happens. Deadlock. ram> The stack of the deadlock is as follows: ram> ls S 00000000 0 13049 11954 (NOTLB) ram> f5221df0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ram> 00000000 f5d44a70 c721b520 00000000 d4f33800 003d0990 c721b9d8 f5d44030 ram> f5d44164 f5220000 f5221e3c f3dd6880 f5221e68 c0215207 f3b95580 80000000 ram> Call Trace: ram> [<c0215207>] autofs4_wait+0x307/0x3d0 ram> [<c02141d3>] try_to_fill_dentry+0xf3/0x150 ram> [<c0214389>] autofs4_revalidate+0x159/0x170 ram> [<c02144e0>] autofs4_lookup+0x110/0x150 ram> [<c016f3f5>] __lookup_hash+0x85/0xb0 ram> [<c016f42a>] lookup_hash+0xa/0x10 ram> [<c016f483>] lookup_one_len+0x53/0x70 ram> [<f8851293>] stubfs_readdir+0x113/0x170 [stubfs] What's stubfs? -Jeff
WARNING: multiple messages have this Message-ID (diff)
From: Jeff Moyer <jmoyer@redhat.com> To: Ram Pai <linuxram@us.ibm.com> Cc: autofs@linux.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [RFC PATCH]autofs4: hang and proposed fix Date: Wed, 16 Nov 2005 10:22:40 -0500 [thread overview] Message-ID: <17275.20160.12805.536289@segfault.boston.redhat.com> (raw) In-Reply-To: <20051116101740.GA9551@RAM> ==> Regarding [autofs] [RFC PATCH]autofs4: hang and proposed fix; linuxram@us.ibm.com (Ram Pai) adds: ram> Autofs4 assumes that its ->revalidate() function gets called with the ram> parent_dentry's_inode_semaphore released. This is true mostly ram> but not in one particular case. ram> Process P1 calls autofs4's ->lookup(). The lookup finds that the dentry ram> does not exist. It creates a dentry and adds to the cache. Releases ram> the parent's inode's semaphore and than calls ->revalidate(). ram> Process P2 meanwhile comes in and cached_lookup() gets called. It finds ram> the dentry in the cache and finds ->revalidate() function exists. So ram> it calls ->revalidate() holding the parent's inode's semaphore. ram> Now the automounter daemon comes in and tries to hold the same semaphore ram> in order to mount. But since the semaphore is held by P2 it ram> goes to sleep. ram> Process P1 and P2 continue waiting for the mount to complete and it never ram> happens. Deadlock. ram> The stack of the deadlock is as follows: ram> ls S 00000000 0 13049 11954 (NOTLB) ram> f5221df0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ram> 00000000 f5d44a70 c721b520 00000000 d4f33800 003d0990 c721b9d8 f5d44030 ram> f5d44164 f5220000 f5221e3c f3dd6880 f5221e68 c0215207 f3b95580 80000000 ram> Call Trace: ram> [<c0215207>] autofs4_wait+0x307/0x3d0 ram> [<c02141d3>] try_to_fill_dentry+0xf3/0x150 ram> [<c0214389>] autofs4_revalidate+0x159/0x170 ram> [<c02144e0>] autofs4_lookup+0x110/0x150 ram> [<c016f3f5>] __lookup_hash+0x85/0xb0 ram> [<c016f42a>] lookup_hash+0xa/0x10 ram> [<c016f483>] lookup_one_len+0x53/0x70 ram> [<f8851293>] stubfs_readdir+0x113/0x170 [stubfs] What's stubfs? -Jeff
next prev parent reply other threads:[~2005-11-16 15:22 UTC|newest] Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top 2005-11-16 10:17 [RFC PATCH]autofs4: hang and proposed fix Ram Pai 2005-11-16 12:41 ` [autofs] " Ian Kent 2005-11-16 16:50 ` Ram Pai 2005-11-16 22:57 ` Ian Kent 2005-11-17 1:52 ` [autofs] " Ram Pai 2005-11-17 18:50 ` Ian Kent 2005-11-17 19:19 ` William H. Taber 2005-11-17 20:39 ` Ram Pai 2005-11-17 22:31 ` William H. Taber 2005-11-18 14:57 ` Ian Kent 2005-11-18 14:54 ` Ian Kent 2005-11-18 14:44 ` Ian Kent 2005-11-18 15:20 ` William H. Taber 2005-11-18 16:30 ` Ian Kent 2005-11-18 17:12 ` William H. Taber 2005-11-18 18:57 ` Ram Pai 2005-11-18 20:08 ` William H. Taber 2005-11-19 2:52 ` Ian Kent 2005-11-21 16:40 ` William H. Taber 2005-11-22 13:13 ` Ian Kent 2005-11-22 17:48 ` [autofs] " William H. Taber 2005-11-23 14:11 ` Ian Kent 2005-11-23 16:42 ` William H. Taber 2005-11-23 17:52 ` Ian Kent 2005-11-23 18:47 ` William H. Taber 2005-11-23 17:52 ` Ian Kent 2005-11-19 1:40 ` [autofs] " Ian Kent 2005-11-16 15:22 ` Jeff Moyer [this message] 2005-11-16 15:22 ` Jeff Moyer 2005-11-16 17:00 ` [autofs] " Ram Pai 2005-11-16 18:25 ` Jeff Moyer 2005-11-16 19:24 ` William H. Taber 2005-11-16 19:51 ` Ram Pai 2005-11-27 10:47 ` Ian Kent 2005-11-28 17:19 ` William H. Taber 2005-11-28 23:12 ` Badari Pulavarty 2005-11-29 14:19 ` Ian Kent 2005-11-29 16:34 ` William H. Taber 2005-11-30 14:02 ` Ian Kent 2005-11-30 16:49 ` Badari Pulavarty 2005-11-30 17:04 ` Trond Myklebust 2005-11-30 21:10 ` William H. Taber 2005-11-29 14:20 ` Ian Kent 2005-11-30 1:16 ` [autofs] " Jeff Moyer 2005-11-30 1:16 ` Jeff Moyer 2005-11-30 1:56 ` Trond Myklebust 2005-11-30 4:15 ` Jeff Moyer 2005-11-30 6:14 ` Trond Myklebust 2005-11-30 15:44 ` Ian Kent 2005-11-30 15:53 ` [autofs] " Trond Myklebust 2005-11-30 16:12 ` Ian Kent 2005-11-30 16:27 ` Ian Kent 2005-11-30 16:45 ` [autofs] " Trond Myklebust 2005-11-30 20:32 ` William H. Taber 2005-11-30 20:53 ` Trond Myklebust 2005-11-30 21:30 ` William H. Taber 2005-11-30 22:32 ` Trond Myklebust 2005-12-01 16:27 ` William H. Taber 2005-12-01 12:09 ` Ian Kent 2005-12-01 16:30 ` William H. Taber 2005-12-02 13:49 ` Ian Kent 2005-12-02 14:07 ` Jeff Moyer 2005-12-02 15:21 ` Ian Kent 2005-12-02 16:35 ` [autofs] " Will Taber 2005-12-02 17:11 ` Ian Kent 2005-12-02 15:34 ` Will Taber 2005-12-02 17:29 ` Ian Kent 2005-12-02 18:12 ` Trond Myklebust 2005-12-04 12:56 ` Christoph Hellwig 2005-12-04 12:57 ` Christoph Hellwig 2005-12-04 14:58 ` Ian Kent 2005-12-04 17:17 ` [autofs] " Christoph Hellwig 2005-12-05 14:02 ` Ian Kent 2005-12-06 21:20 ` Jeff Moyer 2005-12-06 21:40 ` Christoph Hellwig 2005-12-06 22:37 ` Jeff Moyer 2005-12-07 14:52 ` Will Taber 2005-12-07 15:18 ` Christoph Hellwig 2005-12-07 15:22 ` Brian Long 2005-12-07 15:25 ` Christoph Hellwig 2005-12-07 17:46 ` Will Taber 2005-12-08 14:16 ` Ian Kent 2005-12-09 12:12 ` Christoph Hellwig 2005-12-09 13:33 ` John T. Kohl 2005-12-13 18:39 ` Christoph Hellwig 2005-12-04 14:56 ` Ian Kent 2005-12-02 19:04 ` [autofs] " Will Taber 2005-12-04 9:39 ` Ian Kent 2005-12-02 16:04 ` [autofs] " Jeff Moyer 2005-12-02 17:36 ` Ian Kent 2005-12-02 18:33 ` [autofs] " Will Taber 2005-12-04 9:52 ` Ian Kent 2005-12-04 14:54 ` Ian Kent 2005-12-05 15:40 ` Ian Kent 2005-11-30 14:48 ` [autofs] " Ian Kent
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=17275.20160.12805.536289@segfault.boston.redhat.com \ --to=jmoyer@redhat.com \ --cc=autofs@linux.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linuxram@us.ibm.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.