linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org,
	Paul Clements <paul.clements@steeleye.com>
Subject: [PATCH 007 of 8] md/bitmap: Tidy up i_writecount handling in md/bitmap
Date: Fri, 12 May 2006 16:08:04 +1000	[thread overview]
Message-ID: <1060512060804.8079@suse.de> (raw)
In-Reply-To: 20060512160121.7872.patches@notabene


md/bitmap modifies i_writecount of a bitmap file to make sure
that no-one else writes to it.  
The reverting of the change is sometimes done twice, and there
is one error path where it is omitted.

This patch tidies that up.

Signed-off-by: Neil Brown <neilb@suse.de>

### Diffstat output
 ./drivers/md/bitmap.c |    8 +-------
 ./drivers/md/md.c     |   49 ++++++++++++++++++++++++++++++-------------------
 2 files changed, 31 insertions(+), 26 deletions(-)

diff ./drivers/md/bitmap.c~current~ ./drivers/md/bitmap.c
--- ./drivers/md/bitmap.c~current~	2006-05-12 15:59:53.000000000 +1000
+++ ./drivers/md/bitmap.c	2006-05-12 16:00:03.000000000 +1000
@@ -625,7 +625,6 @@ static void drain_write_queues(struct bi
 static void bitmap_file_put(struct bitmap *bitmap)
 {
 	struct file *file;
-	struct inode *inode;
 	unsigned long flags;
 
 	spin_lock_irqsave(&bitmap->lock, flags);
@@ -637,13 +636,8 @@ static void bitmap_file_put(struct bitma
 
 	bitmap_file_unmap(bitmap);
 
-	if (file) {
-		inode = file->f_mapping->host;
-		spin_lock(&inode->i_lock);
-		atomic_set(&inode->i_writecount, 1); /* allow writes again */
-		spin_unlock(&inode->i_lock);
+	if (file)
 		fput(file);
-	}
 }
 
 

diff ./drivers/md/md.c~current~ ./drivers/md/md.c
--- ./drivers/md/md.c~current~	2006-05-12 15:54:48.000000000 +1000
+++ ./drivers/md/md.c	2006-05-12 16:00:03.000000000 +1000
@@ -2864,6 +2864,32 @@ out:
 	return err;
 }
 
+/* similar to deny_write_access, but accounts for our holding a reference
+ * to the file ourselves */
+static int deny_bitmap_write_access(struct file * file)
+{
+	struct inode *inode = file->f_mapping->host;
+
+	spin_lock(&inode->i_lock);
+	if (atomic_read(&inode->i_writecount) > 1) {
+		spin_unlock(&inode->i_lock);
+		return -ETXTBSY;
+	}
+	atomic_set(&inode->i_writecount, -1);
+	spin_unlock(&inode->i_lock);
+
+	return 0;
+}
+
+static void restore_bitmap_write_access(struct file *file)
+{
+	struct inode *inode = file->f_mapping->host;
+
+	spin_lock(&inode->i_lock);
+	atomic_set(&inode->i_writecount, 1);
+	spin_unlock(&inode->i_lock);
+}
+
 static int do_md_stop(mddev_t * mddev, int ro)
 {
 	int err = 0;
@@ -2927,7 +2953,7 @@ static int do_md_stop(mddev_t * mddev, i
 
 		bitmap_destroy(mddev);
 		if (mddev->bitmap_file) {
-			atomic_set(&mddev->bitmap_file->f_dentry->d_inode->i_writecount, 1);
+			restore_bitmap_write_access(mddev->bitmap_file);
 			fput(mddev->bitmap_file);
 			mddev->bitmap_file = NULL;
 		}
@@ -3531,23 +3557,6 @@ abort_export:
 	return err;
 }
 
-/* similar to deny_write_access, but accounts for our holding a reference
- * to the file ourselves */
-static int deny_bitmap_write_access(struct file * file)
-{
-	struct inode *inode = file->f_mapping->host;
-
-	spin_lock(&inode->i_lock);
-	if (atomic_read(&inode->i_writecount) > 1) {
-		spin_unlock(&inode->i_lock);
-		return -ETXTBSY;
-	}
-	atomic_set(&inode->i_writecount, -1);
-	spin_unlock(&inode->i_lock);
-
-	return 0;
-}
-
 static int set_bitmap_file(mddev_t *mddev, int fd)
 {
 	int err;
@@ -3595,8 +3604,10 @@ static int set_bitmap_file(mddev_t *mdde
 		mddev->pers->quiesce(mddev, 0);
 	}
 	if (fd < 0) {
-		if (mddev->bitmap_file)
+		if (mddev->bitmap_file) {
+			restore_bitmap_write_access(mddev->bitmap_file);
 			fput(mddev->bitmap_file);
+		}
 		mddev->bitmap_file = NULL;
 	}
 

  parent reply	other threads:[~2006-05-12  6:08 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-12  6:07 [PATCH 000 of 8] md/bitmap: Introduction - rework management of bitmap files NeilBrown
2006-05-12  6:07 ` [PATCH 001 of 8] md/bitmap: Fix online removal of file-backed bitmaps NeilBrown
2006-05-12  6:07 ` [PATCH 002 of 8] md/bitmap: Remove bitmap writeback daemon NeilBrown
2006-05-12 17:40   ` Andrew Morton
2006-05-13  3:14     ` Neil Brown
2006-05-13  6:59       ` Andrew Morton
2006-05-12  6:07 ` [PATCH 003 of 8] md/bitmap: Cleaner separation of page attribute handlers in md/bitmap NeilBrown
2006-05-12  6:07 ` [PATCH 004 of 8] md/bitmap: Use set_bit etc for bitmap page attributes NeilBrown
2006-05-12  6:07 ` [PATCH 005 of 8] md/bitmap: Remove unnecessary page reference manipulations from md/bitmap code NeilBrown
2006-05-12  6:07 ` [PATCH 006 of 8] md/bitmap: Remove dead code from md/bitmap NeilBrown
2006-05-12  6:08 ` NeilBrown [this message]
2006-05-12  6:08 ` [PATCH 008 of 8] md/bitmap: Change md/bitmap file handling to use bmap to file blocks NeilBrown
2006-05-12 17:47   ` Andrew Morton
2006-05-13  3:46     ` Neil Brown
2006-05-13  6:59       ` Andrew Morton
2006-05-13 15:29         ` Paul Clements
2006-05-13 15:42           ` Andrew Morton
2006-05-14 11:15             ` Neil Brown
2006-05-14 11:22               ` Andrew Morton
2006-05-15  0:26         ` Neil Brown
2006-05-15 21:04           ` Andrew Morton
2006-05-15 23:03             ` Neil Brown

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=1060512060804.8079@suse.de \
    --to=neilb@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=paul.clements@steeleye.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;
as well as URLs for NNTP newsgroup(s).