public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Srinivasa Ds <srinivasa@in.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Eric Sandeen <sandeen@redhat.com>,
	Alasdair G Kergon <agk@redhat.com>,
	linux-kernel@vger.kernel.org, dm-devel@redhat.com,
	Ingo Molnar <mingo@elte.hu>,
	arjan@infradead.org
Subject: Re: [PATCH 2.6.19 5/5] fs: freeze_bdev with semaphore not mutex
Date: Fri, 12 Jan 2007 11:53:36 +0530	[thread overview]
Message-ID: <45A72968.9030401@in.ibm.com> (raw)
In-Reply-To: <20061107150017.fb78a327.akpm@osdl.org>

[-- Attachment #1: Type: text/plain, Size: 2951 bytes --]

Andrew Morton wrote:
> On Tue, 07 Nov 2006 16:45:07 -0600
> Eric Sandeen <sandeen@redhat.com> wrote:
>
>   
>> Andrew Morton wrote:
>>
>>     
>>>> --- linux-2.6.19-rc4.orig/fs/buffer.c	2006-11-07 17:06:20.000000000 +0000
>>>> +++ linux-2.6.19-rc4/fs/buffer.c	2006-11-07 17:26:04.000000000 +0000
>>>> @@ -188,7 +188,9 @@ struct super_block *freeze_bdev(struct b
>>>>  {
>>>>  	struct super_block *sb;
>>>>  
>>>> -	mutex_lock(&bdev->bd_mount_mutex);
>>>> +	if (down_trylock(&bdev->bd_mount_sem))
>>>> +		return -EBUSY;
>>>> +
>>>>         
>
>
> Guys, I'm going to park this patch pending a full description of what it
> does, a description of what the above hunk is doing 
Iam really sorry for delayed reply. Here is my full explanation on my patch.
Patch, that I have proposed replaces the mutex on bd_mount_mutex with 
the semaphore (bd_mount_sem). It was(bd_mount_sem) used to be a 
semaphore earlier and then Ingo's patch changed it to mutex. Hence we 
had the problem in device mapper commands. But now, the proposed patch 
allows two separate device mapper commands to suspend and resume the 
logical devices. Even though this explaination is from deveice mapper 
perspective, since semaphore(bd_mount_sem) existed earlier, proposed 
patch doesn't hurt XFS code which access the freeze_bdev().
As for as the above code is concerned,Iam using down_trylock() to allow 
only one process to freeze the filesystem at a time and hence stops the 
other process from queuing up.

> and pending an
> examination of whether we'd be better off changing the mutex-debugging code
> rather than switching to semaphores.
>   
Regarding this one,I agree with what Arjan has told.
" It's not used as a mutex. Sad but true. It's not so easy to say "just
shut up the debug code", because it's just not that easy: The interface
allows double "unlock", which is fine for semaphores for example. There
fundamentally is no "owner" for this case, and all the mutex concepts
assume that there is an owner. If the owner goes away, pointers to their
task struct for example are no longer valid (used by lockdep and the
other debugging parts). It's what makes the difference between a mutex
and a semaphore: a mutex has an owner and several semantics follow from
that. These semantics allow a more efficient implementation (no multiple
"owners" possible) but once you go away from that fundamental property,
soon we'll see "oh and it needs <this extra code> to cover the wider
semantics correctly.. and soon you have a semaphore again.

Let true semaphores be semaphores, and make all real mutexes mutexes.
But lets not make actual semaphores use mutex code... ".

So Iam reproposing my patch(taken against latest kernel) here. Please 
let me know your comments on this.

Signed-off-by: Srinivasa DS <srinivasa@in.ibm.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Eric Sandeen <sandeen@sandeen.net>
Cc: dm-devel@redhat.com





[-- Attachment #2: dm.fix --]
[-- Type: text/plain, Size: 2377 bytes --]

 fs/block_dev.c     |    2 +-
 fs/buffer.c        |    6 ++++--
 fs/super.c         |    4 ++--
 include/linux/fs.h |    2 +-
 4 files changed, 8 insertions(+), 6 deletions(-)

Index: linux-2.6.20-rc4/fs/block_dev.c
===================================================================
--- linux-2.6.20-rc4.orig/fs/block_dev.c
+++ linux-2.6.20-rc4/fs/block_dev.c
@@ -411,7 +411,7 @@ static void init_once(void * foo, struct
 	{
 		memset(bdev, 0, sizeof(*bdev));
 		mutex_init(&bdev->bd_mutex);
-		mutex_init(&bdev->bd_mount_mutex);
+		sema_init(&bdev->bd_mount_sem, 1);
 		INIT_LIST_HEAD(&bdev->bd_inodes);
 		INIT_LIST_HEAD(&bdev->bd_list);
 #ifdef CONFIG_SYSFS
Index: linux-2.6.20-rc4/fs/buffer.c
===================================================================
--- linux-2.6.20-rc4.orig/fs/buffer.c
+++ linux-2.6.20-rc4/fs/buffer.c
@@ -189,7 +189,9 @@ struct super_block *freeze_bdev(struct b
 {
 	struct super_block *sb;
 
-	mutex_lock(&bdev->bd_mount_mutex);
+	if (down_trylock(&bdev->bd_mount_sem))
+		return -EBUSY;
+
 	sb = get_super(bdev);
 	if (sb && !(sb->s_flags & MS_RDONLY)) {
 		sb->s_frozen = SB_FREEZE_WRITE;
@@ -231,7 +233,7 @@ void thaw_bdev(struct block_device *bdev
 		drop_super(sb);
 	}
 
-	mutex_unlock(&bdev->bd_mount_mutex);
+	up(&bdev->bd_mount_sem);
 }
 EXPORT_SYMBOL(thaw_bdev);
 
Index: linux-2.6.20-rc4/include/linux/fs.h
===================================================================
--- linux-2.6.20-rc4.orig/include/linux/fs.h
+++ linux-2.6.20-rc4/include/linux/fs.h
@@ -458,7 +458,7 @@ struct block_device {
 	struct inode *		bd_inode;	/* will die */
 	int			bd_openers;
 	struct mutex		bd_mutex;	/* open/close mutex */
-	struct mutex		bd_mount_mutex;	/* mount mutex */
+	struct semaphore	bd_mount_sem;
 	struct list_head	bd_inodes;
 	void *			bd_holder;
 	int			bd_holders;
Index: linux-2.6.20-rc4/fs/super.c
===================================================================
--- linux-2.6.20-rc4.orig/fs/super.c
+++ linux-2.6.20-rc4/fs/super.c
@@ -753,9 +753,9 @@ int get_sb_bdev(struct file_system_type 
 	 * will protect the lockfs code from trying to start a snapshot
 	 * while we are mounting
 	 */
-	mutex_lock(&bdev->bd_mount_mutex);
+	down(&bdev->bd_mount_sem);
 	s = sget(fs_type, test_bdev_super, set_bdev_super, bdev);
-	mutex_unlock(&bdev->bd_mount_mutex);
+	up(&bdev->bd_mount_sem);
 	if (IS_ERR(s))
 		goto error_s;
 

  parent reply	other threads:[~2007-01-12 20:47 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-07 18:34 [PATCH 2.6.19 5/5] fs: freeze_bdev with semaphore not mutex Alasdair G Kergon
2006-11-07 20:18 ` [dm-devel] " Mike Snitzer
2006-11-07 20:22   ` Eric Sandeen
2006-11-07 23:34   ` Alasdair G Kergon
2006-11-07 20:28 ` Andrew Morton
2006-11-07 22:45   ` Eric Sandeen
2006-11-07 23:00     ` Andrew Morton
2006-11-08  9:54       ` Arjan van de Ven
2007-01-12  6:23       ` Srinivasa Ds [this message]
2007-01-12 10:16       ` Srinivasa Ds
2006-11-07 23:05     ` Rafael J. Wysocki
2006-11-07 23:18       ` Eric Sandeen
2006-11-07 23:42         ` Rafael J. Wysocki
2006-11-08  0:01           ` Alasdair G Kergon
2006-11-08  8:27             ` David Chinner
2006-11-08 14:25               ` Alasdair G Kergon
2006-11-08 14:43                 ` Rafael J. Wysocki
2006-11-08 15:25                   ` Alasdair G Kergon
2006-11-08 23:06                     ` Rafael J. Wysocki
2006-11-07 23:49       ` Alasdair G Kergon
2006-11-08  0:00         ` Rafael J. Wysocki
2006-11-08  3:33           ` David Chinner
2006-11-08  2:30         ` Alasdair G Kergon
2006-11-08 12:10           ` Rafael J. Wysocki
2006-11-08 18:09             ` Pavel Machek
2006-11-09 15:52               ` Rafael J. Wysocki
2006-11-09 16:00                 ` Pavel Machek
2006-11-09 19:59                   ` Rafael J. Wysocki
2006-11-09 21:17                     ` Pavel Machek
2006-11-09 21:18                       ` Rafael J. Wysocki
2006-11-09 21:41                         ` Pavel Machek
2006-11-09 22:21                           ` Rafael J. Wysocki
2006-11-09 23:11                             ` Pavel Machek
2006-11-09 23:24                               ` Alasdair G Kergon
2006-11-09 23:32                                 ` Pavel Machek
2006-11-10 12:03                                   ` Rafael J. Wysocki
2006-11-12 18:43                                     ` Pavel Machek
2006-11-12 21:53                                       ` Rafael J. Wysocki
2006-11-12 23:30                                       ` David Chinner
2006-11-13 16:11                                         ` Rafael J. Wysocki
2006-11-15 18:50                                         ` Pavel Machek
2006-11-15 19:56                                           ` Rafael J. Wysocki
2006-11-15 20:00                                             ` Rafael J. Wysocki
2006-11-15 20:23                                               ` Pavel Machek
2006-11-15 21:58                                                 ` Rafael J. Wysocki
2006-11-15 22:49                                                   ` Pavel Machek
2006-11-16 23:20                                                   ` David Chinner
2006-11-16 23:38                                                     ` Pavel Machek
2006-11-13  7:35                                       ` Stefan Seyfried
2006-11-10  0:57                             ` David Chinner
2006-11-10 10:39                               ` Pavel Machek
2006-11-12 22:30                                 ` David Chinner
2006-11-12 22:43                                   ` Rafael J. Wysocki
2006-11-13  5:43                                     ` David Chinner
2006-11-13 16:22                                       ` Rafael J. Wysocki
2006-11-14  0:10                                         ` David Chinner
2006-11-16 23:23                                     ` David Chinner
2006-11-16 23:40                                       ` Pavel Machek
2006-11-17  1:40                                         ` David Chinner
2006-11-17 15:13                                           ` Pavel Machek
2006-11-10  0:54                       ` David Chinner
2006-11-10 10:24                       ` Alan Cox
2006-11-10 10:36                         ` Pavel Machek
2006-11-10  0:33                   ` David Chinner
2006-11-10 10:38                     ` Pavel Machek
2006-11-08 20:48             ` Nigel Cunningham
2006-11-08 21:08               ` Rafael J. Wysocki
2006-11-07 23:23   ` Alasdair G Kergon
2006-11-07 23:39   ` Ingo Molnar

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=45A72968.9030401@in.ibm.com \
    --to=srinivasa@in.ibm.com \
    --cc=agk@redhat.com \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=dm-devel@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=sandeen@redhat.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