From mboxrd@z Thu Jan  1 00:00:00 1970
From: Steven Whitehouse <swhiteho@redhat.com>
Date: Thu, 12 Nov 2009 17:24:12 +0000
Subject: [Cluster-devel] Re: [PATCH 2/2] dlm: Add down/up_write_non_owner to
 keep lockdep happy
In-Reply-To: <20091112171457.GD20714@redhat.com>
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>
Message-ID: <1258046652.6052.885.camel@localhost.localdomain>
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

Hi,

On Thu, 2009-11-12 at 11:14 -0600, David Teigland wrote:
> On Thu, Nov 12, 2009 at 02:29:18PM +0000, Steven Whitehouse wrote:
> > Hi,
> > 
> > On Thu, 2009-11-12 at 15:22 +0100, Ingo Molnar wrote:
> > > * Steven Whitehouse <swhiteho@redhat.com> wrote:
> > > 
> > > > I looked at possibly changing this to use completions, but
> > > > it seems that the usage here is not easily adapted to that.
> > > > This patch adds suitable annotation to the write side of
> > > > the ls_in_recovery semaphore so that we don't get nasty
> > > > messages from lockdep when mounting a gfs2 filesystem.
> > > 
> > > What do those 'nasty messages' say? If they expose some bug and this
> > > patch works around that bug by hiding it then NAK ...
> > > 
> > >         Ingo
> > > 
> > The nasty messages are moaning that the lock is being taken in one
> > thread and unlocked in another. I couldn't see any bugs in the code when
> > I looked at it. Below are the messages that I get - to reproduce just
> > mount a GFS2 filesystem with the dlm lock manager. It happens on every
> > mount,
> > 
> > Steve.
> > 
> > Nov 12 15:10:01 chywoon kernel:
> > =============================================
> > 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,

Steve.