From: Chris Mason <chris.mason@oracle.com>
To: Jan Schmidt <list.btrfs@jan-o-sch.net>
Cc: linux-btrfs@vger.kernel.org, lizf@cn.fujitsu.com, sensille@gmx.net
Subject: Re: [PATCH v1 05/10] Btrfs: add nested locking mode for paths
Date: Thu, 22 Dec 2011 14:16:17 -0500 [thread overview]
Message-ID: <20111222191617.GH19266@shiny> (raw)
In-Reply-To: <108c7352f9047f90144360a5609816464b33afff.1324568416.git.list.btrfs@jan-o-sch.net>
On Thu, Dec 22, 2011 at 05:03:19PM +0100, Jan Schmidt wrote:
> From: Arne Jansen <sensille@gmx.net>
>
> This patch adds the possibilty to read-lock an extent even if it is already
> write-locked from the same thread. btrfs_find_all_roots() needs this
> capability.
I'd rather not add a nested flag to the locking code, lets just make the
nesting explicitly allowed.
You shouldn't need locks around lock->owner. Either your process owns
the lock (and it won't change away from your pid), or you don't own it
and it won't be your pid. Just make sure the owner field gets cleared
when you do your final unlock.
So, if you are the owner of a write lock, you can add more write locks
or a read lock as required.
Could you please describe the case where btrfs_find_all_roots needs
this?
-chris
next prev parent reply other threads:[~2011-12-22 19:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-22 16:03 [PATCH v1 00/10] Btrfs: backref walking rewrite Jan Schmidt
2011-12-22 16:03 ` [PATCH v1 01/10] Btrfs: generic data structure to build unique lists Jan Schmidt
2011-12-22 16:03 ` [PATCH v1 02/10] Btrfs: added helper btrfs_next_item() Jan Schmidt
2011-12-22 16:03 ` [PATCH v1 03/10] Btrfs: mark delayed refs as for cow Jan Schmidt
2011-12-22 16:03 ` [PATCH v1 04/10] Btrfs: always save ref_root in delayed refs Jan Schmidt
2011-12-22 16:03 ` [PATCH v1 05/10] Btrfs: add nested locking mode for paths Jan Schmidt
2011-12-22 19:16 ` Chris Mason [this message]
2011-12-23 15:23 ` Jan Schmidt
2011-12-22 16:03 ` [PATCH v1 06/10] Btrfs: add sequence numbers to delayed refs Jan Schmidt
2011-12-22 16:03 ` [PATCH v1 07/10] Btrfs: put back delayed refs that are too new Jan Schmidt
2011-12-22 16:03 ` [PATCH v1 08/10] Btrfs: add waitqueue instead of doing busy waiting for more delayed refs Jan Schmidt
2011-12-22 16:03 ` [PATCH v1 09/10] Btrfs: added btrfs_find_all_roots() Jan Schmidt
2011-12-22 16:03 ` [PATCH v1 10/10] Btrfs: new backref walking code Jan Schmidt
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=20111222191617.GH19266@shiny \
--to=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=list.btrfs@jan-o-sch.net \
--cc=lizf@cn.fujitsu.com \
--cc=sensille@gmx.net \
/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;
as well as URLs for NNTP newsgroup(s).