From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Whitehouse Date: Sat, 08 Sep 2007 16:04:40 +0100 Subject: [Cluster-devel] [PATCH] unlock page lock before doing a dq In-Reply-To: <20070908142528.GB31007@dhcp-243-37.rdu.redhat.com> References: <20070908142528.GB31007@dhcp-243-37.rdu.redhat.com> Message-ID: <1189263880.1068.30.camel@quoit> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, The bug has been verified not to exist on the latest kernel, so I don't think we need this patch, Steve. On Sat, 2007-09-08 at 10:25 -0400, Josef Bacik wrote: > Hello, > > There is a lockup condition where we get an error while perparing to write (such > as ENOSPC) and we go to do the gfs2_glock_dq_m and the glock has been marked > dirty. Since we are already holding the page lock, we will deadlock because we > will try to flush all the pages back to disk and try to take the pagelock again. > Wendy you said I would be doing this in a transaction, but if there as error > inside where we started the transaction, we goto out, where we stop the > transaction first and then go on and unlock the page. This fixes RH bz 280791. > Thank you, > > Josef > > --- 18.34/fs/gfs2/ops_address.c.josef 2007-09-07 15:07:03.000000000 -0400 > +++ 18.34/fs/gfs2/ops_address.c 2007-09-07 15:12:45.000000000 -0400 > @@ -457,8 +457,10 @@ out_alloc_put: > gfs2_alloc_put(ip); > } > out_unlock: > + unlock_page(page); > gfs2_glock_dq_m(1, &ip->i_gh); > gfs2_holder_uninit(&ip->i_gh); > + lock_page(page); > } > > return error; >