FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Cluster Development

 
 
LinkBack Thread Tools
 
Old 11-12-2009, 05:21 PM
David Teigland
 
Default dlm: Add down/up_write_non_owner to keep lockdep happy

On Thu, Nov 12, 2009 at 05:45:39PM +0100, Peter Zijlstra wrote:
> On Thu, 2009-11-12 at 11:14 -0600, David Teigland wrote:
> > 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):
>
> That's really something I cannot advice to do. Aside from loosing
> lock-dependency validation (not a good thing), asymmetric locking like
> that is generally very hard to analyze since its not clear who 'owns'
> what data when.
>
> There are a few places in the kernel that use the non_owner things, and
> we should generally strive to remove them, not add more.
>
> Please consider solving your problem without adding things like this.

It's an unusual use case; this lock is not protecting data in a direct
sense, but is controlling who can run in the dlm.

During normal activity, many threads are running through the dlm (any
process accessing the fs, dlm kernel threads, gfs kernel threads), they
all take the read lock when they enter and release it when they exit.

When dlm recovery needs to happen, this lock is taken in write mode to
wait for all the normal, active threads to exit the dlm, and then block
any further access to the dlm until recovery is complete. Recovery is
initiated by a userland process which takes the write lock. Recovery is
then performed by the dlm_recoverd thread which releases the write lock
when it's done, and normal activity resumes. The release from
dlm_recoverd would use up_write_non_owner() to avoid the warning.

I'm sure there are other ways to do this, but I don't know when I'll have
the time to look into them. In the mean time, the rw_semaphore is simple
and effective. (I don't mind the warning myself, but others seem to be
annoyed by it.)

Dave
 
Old 11-12-2009, 05:34 PM
David Teigland
 
Default dlm: Add down/up_write_non_owner to keep lockdep happy

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
 

Thread Tools




All times are GMT. The time now is 11:49 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org