From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Teigland <teigland@redhat.com>
Date: Thu, 12 Nov 2009 12:34:47 -0600
Subject: [Cluster-devel] Re: [PATCH 2/2] dlm: Add down/up_write_non_owner to
	keep lockdep happy
In-Reply-To: <1258046652.6052.885.camel@localhost.localdomain>
References: <1255445776-3112-1-git-send-email-swhiteho@redhat.com>
	<1255445776-3112-2-git-send-email-swhiteho@redhat.com>
	<1255445776-3112-3-git-send-email-swhiteho@redhat.com>
	<20091112142211.GA468@elte.hu>
	<1258036158.6052.874.camel@localhost.localdomain>
	<20091112171457.GD20714@redhat.com>
	<1258046652.6052.885.camel@localhost.localdomain>
Message-ID: <20091112183446.GG20714@redhat.com>
List-Id: <cluster-devel.redhat.com>
To: cluster-devel.redhat.com
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On Thu, Nov 12, 2009 at 05:24:12PM +0000, Steven Whitehouse wrote:
> > > Nov 12 15:10:01 chywoon kernel: [ INFO: possible recursive locking
> > > detected ]
> > 
> > That recursive locking trace is something different.  up_write_non_owner()
> > addresses this trace, which as you say, is from doing the down and up from
> > different threads (which is the intention):
> > 
> I don't think it is different, the traces differ due to the ordering of
> running of dlm_recoverd and mount.gfs2,

I explained the "recursive locking" warning back in Sep:

 > I've not looked at how to remove this "recursive" message.  What
 > happens is that mount calls dlm_new_lockspace() which returns with
 > in_recovery locked.  mount then makes a lock request which blocks on
 > in_recovery (as expected) until the dlm_recoverd thread completes
 > recovery and releases the in_recovery lock (triggering the unlock
 > balance) to allow locking activity.

It doesn't appear to me that up_write_non_owner() would suppress that.

Dave