Cluster-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Becker <Joel.Becker@oracle.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] Re: [PATCH 2/2] configfs: Rework configfs_depend_item() locking and make lockdep happy
Date: Tue, 27 Jan 2009 20:13:53 -0800	[thread overview]
Message-ID: <20090128041353.GF7244@mail.oracle.com> (raw)
In-Reply-To: <1229623218-8056-3-git-send-email-louis.rilling@kerlabs.com>

On Thu, Dec 18, 2008 at 07:00:18PM +0100, Louis Rilling wrote:
> configfs_depend_item() recursively locks all inodes mutex from configfs root to
> the target item, which makes lockdep unhappy. The purpose of this recursive
> locking is to ensure that the item tree can be safely parsed and that the target
> item, if found, is not about to leave.
> 
> This patch reworks configfs_depend_item() locking using configfs_dirent_lock.
> Since configfs_dirent_lock protects all changes to the configfs_dirent tree, and
> protects tagging of items to be removed, this lock can be used instead of the
> inodes mutex lock chain.
> This needs that the check for dependents be done atomically with
> CONFIGFS_USET_DROPPING tagging.
> 
> Now lockdep looks happy with configfs.

	This looks almost, but not quite right.
	In the create path, we do configfs_new_dirent() before we set
sd->s_type.  But configfs_new_dirent() attaches sd->s_sibling.  So, in
aonther thread, configfs_depend_prep() can traverse this s_sibling
without CONFIGFS_USET_CREATING being set.  This turns out to be safe
because CONFIGFS_DIR is also not set - but boy I'd like a comment about
that.
	What if we're in mkdir(2) in one thread and another thread is  
trying to pin the parent directory?  That is, we are inside
configfs_mkdir(parent, new_dentry, mode).  The other thread is doing
configfs_depend_item(subsys, parent).  With this patch, the other thread
will not take parent->i_mutex.  It will happily determine that
parent is part of the tree and bump its s_dependent with no locking.  Is
this OK?
	If it is - isn't this patch good without any other reason?  That
is, aside from the issues of lockdep, isn't it better for
configfs_depend_item() to never have to worry about the VFS locks other
than the configfs root?

Joel


-- 

 The zen have a saying:
 "When you learn how to listen, ANYONE can be your teacher."

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



  parent reply	other threads:[~2009-01-28  4:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20081218111536.GR19128@hawkmoon.kerlabs.com>
     [not found] ` <1229623218-8056-1-git-send-email-louis.rilling@kerlabs.com>
     [not found]   ` <20090126115151.GC7532@hawkmoon.kerlabs.com>
2009-01-28  3:44     ` [Cluster-devel] Re: Make lockdep happy with configfs Joel Becker
     [not found] ` <1229623218-8056-2-git-send-email-louis.rilling@kerlabs.com>
2009-01-28  3:55   ` [Cluster-devel] Re: [PATCH 1/2] configfs: Silence lockdep on mkdir() and rmdir() Joel Becker
     [not found] ` <1229623218-8056-3-git-send-email-louis.rilling@kerlabs.com>
2009-01-28  4:13   ` Joel Becker [this message]
     [not found] <1233166713-9668-1-git-send-email-louis.rilling@kerlabs.com>
     [not found] ` <1233166713-9668-3-git-send-email-louis.rilling@kerlabs.com>
2009-04-29 18:52   ` [Cluster-devel] Re: [PATCH 2/2] configfs: Rework configfs_depend_item() locking and make lockdep happy Joel Becker
     [not found]     ` <20090430091828.GB13896@hawkmoon.kerlabs.com>
2009-04-30 17:20       ` Joel Becker
2009-04-30 17:30         ` 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=20090128041353.GF7244@mail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox