From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Teigland Date: Fri, 26 Jan 2007 09:37:50 -0600 Subject: [Cluster-devel] [GFS2] Put back semaphore to avoid umount problem In-Reply-To: <1169807818.11001.121.camel@quoit.chygwyn.com> References: <1169802527.11001.118.camel@quoit.chygwyn.com> <1169807818.11001.121.camel@quoit.chygwyn.com> Message-ID: <20070126153750.GB18186@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Fri, Jan 26, 2007 at 10:36:58AM +0000, Steven Whitehouse wrote: > Hi, > > Hmm. This doesn't seem to be quite the thing: Yep, glock_put is being called from within invalidate_inodes, so we're recursively taking the new sem. Here's the original comment I added describing the problem: /* invalidate_inodes() requires that the sb inodes list not change, but an async completion callback for an unlock can occur which does glock_put() which can call iput() which will change the sb inodes list. invalidate_inodes_mutex prevents glock_put()'s during an invalidate_inodes() */ So, we're trying to prevent async completions from mucking with the inodes while we're in invalidate_inodes. Perhaps we could take the new read sem inside gfs2_glock_cb which still blocks async completions when we need to but not in a code path that's called from elsewhere.