All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Becker <Joel.Becker@oracle.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] Re: configfs, dlm_controld & lockdep
Date: Thu, 11 Dec 2008 09:34:37 -0800	[thread overview]
Message-ID: <20081211173437.GA25844@ca-server1.us.oracle.com> (raw)
In-Reply-To: <20081211144441.GA19128@hawkmoon.kerlabs.com>

On Thu, Dec 11, 2008 at 03:44:41PM +0100, Louis Rilling wrote:
> These warnings are known issues. This results from a lack of lockdep annotations
> in configfs. I must admit that I started to send patches for that a few months
> ago, and then could not find time to finish this work.
> 
> The problem is a bit harder than just playing with I_MUTEX_CHILD, I_MUTEX_PARENT
> and I_MUTEX_NORMAL, since configfs recursively locks variable numbers
> (this can go to as many as the depth of the whole configfs tree) of
> config_group inodes during operations like mkdir(), rmdir(), and depend_item().
> 
> I was working on two kinds of solutions:
> 1) insert lockdep_off()/lockdep_on() at the places of recursion,
> 2) separate default groups inode mutex classes according to their depth under
> the created group they belong to.
> 
> People tend to reject any proposition like 1), but IIRC Joel was tending to
> accept it.
> 
> Solution 2) does not work for depend_item(). This needs to rework the locking
> scheme of depend_item() by removing the variable lock recursion depth, and I
> think that it's doable thanks to the configfs_dirent_lock.
> 	Joel, what do you think about this?

	I've been waiting for your patch for (1).  I am wary of the (2)
approach.  Not because it wouldn't work for mkdir(2) - I think it would.
But rmdir(2) has the same recursive locking, with far more importance
(live objects), and would print the same error.

Joel

-- 

Life's Little Instruction Book #267

	"Lie on your back and look at the stars."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127



WARNING: multiple messages have this Message-ID (diff)
From: Joel Becker <Joel.Becker@oracle.com>
To: Steven Whitehouse <swhiteho@redhat.com>,
	linux-kernel@vger.kernel.org, cluster-devel@redhat.com
Subject: Re: configfs, dlm_controld & lockdep
Date: Thu, 11 Dec 2008 09:34:37 -0800	[thread overview]
Message-ID: <20081211173437.GA25844@ca-server1.us.oracle.com> (raw)
In-Reply-To: <20081211144441.GA19128@hawkmoon.kerlabs.com>

On Thu, Dec 11, 2008 at 03:44:41PM +0100, Louis Rilling wrote:
> These warnings are known issues. This results from a lack of lockdep annotations
> in configfs. I must admit that I started to send patches for that a few months
> ago, and then could not find time to finish this work.
> 
> The problem is a bit harder than just playing with I_MUTEX_CHILD, I_MUTEX_PARENT
> and I_MUTEX_NORMAL, since configfs recursively locks variable numbers
> (this can go to as many as the depth of the whole configfs tree) of
> config_group inodes during operations like mkdir(), rmdir(), and depend_item().
> 
> I was working on two kinds of solutions:
> 1) insert lockdep_off()/lockdep_on() at the places of recursion,
> 2) separate default groups inode mutex classes according to their depth under
> the created group they belong to.
> 
> People tend to reject any proposition like 1), but IIRC Joel was tending to
> accept it.
> 
> Solution 2) does not work for depend_item(). This needs to rework the locking
> scheme of depend_item() by removing the variable lock recursion depth, and I
> think that it's doable thanks to the configfs_dirent_lock.
> 	Joel, what do you think about this?

	I've been waiting for your patch for (1).  I am wary of the (2)
approach.  Not because it wouldn't work for mkdir(2) - I think it would.
But rmdir(2) has the same recursive locking, with far more importance
(live objects), and would print the same error.

Joel

-- 

Life's Little Instruction Book #267

	"Lie on your back and look at the stars."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

  reply	other threads:[~2008-12-11 17:34 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-11 14:20 [Cluster-devel] configfs, dlm_controld & lockdep Steven Whitehouse
2008-12-11 14:20 ` Steven Whitehouse
2008-12-11 14:44 ` Louis Rilling
2008-12-11 17:34   ` Joel Becker [this message]
2008-12-11 17:34     ` Joel Becker
2008-12-12 10:06     ` Louis Rilling
2008-12-12 15:29       ` [PATCH] configfs: Silence lockdep on mkdir(), rmdir() and configfs_depend_item() Louis Rilling
2008-12-17 21:40         ` [Cluster-devel] " Andrew Morton
2008-12-17 21:40           ` Andrew Morton
2008-12-17 22:03           ` [Cluster-devel] " Joel Becker
2008-12-17 22:03             ` Joel Becker
2008-12-17 22:09             ` [Cluster-devel] " Andrew Morton
2008-12-17 22:09               ` Andrew Morton
2008-12-18  7:26           ` Peter Zijlstra
2008-12-18  9:27             ` [Cluster-devel] " Joel Becker
2008-12-18  9:27               ` Joel Becker
2008-12-18 11:15               ` Louis Rilling
2008-12-18 18:00                 ` Make lockdep happy with configfs Louis Rilling
2009-01-26 11:51                   ` Louis Rilling
2009-01-28  3:44                     ` [Cluster-devel] " Joel Becker
2009-01-28  3:44                       ` Joel Becker
2008-12-18 18:00                 ` [PATCH 1/2] configfs: Silence lockdep on mkdir() and rmdir() Louis Rilling
2009-01-28  3:55                   ` [Cluster-devel] " Joel Becker
2009-01-28  3:55                     ` Joel Becker
2009-01-28 10:38                     ` Louis Rilling
2008-12-18 18:00                 ` [PATCH 2/2] configfs: Rework configfs_depend_item() locking and make lockdep happy Louis Rilling
2009-01-28  4:13                   ` [Cluster-devel] " Joel Becker
2009-01-28  4:13                     ` Joel Becker
2009-01-28 10:32                     ` Louis Rilling
2008-12-18 11:26               ` [Cluster-devel] Re: [PATCH] configfs: Silence lockdep on mkdir(), rmdir() and configfs_depend_item() Steven Whitehouse
2008-12-18 11:26                 ` Steven Whitehouse
2008-12-18 11:48                 ` Louis Rilling
2008-12-18 11:56               ` Peter Zijlstra
2008-12-18 12:28                 ` Peter Zijlstra
2008-12-18 22:58                   ` [Cluster-devel] " Joel Becker
2008-12-18 22:58                     ` Joel Becker
2008-12-19 10:29                     ` Louis Rilling
2009-01-26 12:30                     ` Peter Zijlstra
2009-01-26 13:24                       ` Louis Rilling
2009-01-26 13:41                         ` Peter Zijlstra
2009-01-26 14:00                           ` Louis Rilling
2009-01-26 14:19                             ` Peter Zijlstra
2009-01-26 14:55                               ` Louis Rilling
2009-01-28  3:05                                 ` [Cluster-devel] " Joel Becker
2009-01-28  3:05                                   ` Joel Becker
2009-01-28  3:41                       ` [Cluster-devel] " Joel Becker
2009-01-28  3:41                         ` Joel Becker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081211173437.GA25844@ca-server1.us.oracle.com \
    --to=joel.becker@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.