mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Phillip Susi <psusi@cfl.rr.com>
To: Ayan George <ayan@ayan.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: loop device auto release patch
Date: Fri, 15 Jul 2011 15:12:50 -0400	[thread overview]
Message-ID: <4E209132.7000704@cfl.rr.com> (raw)
In-Reply-To: <4E1F3BE0.8040506@ayan.net>

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

On 7/14/2011 2:56 PM, Ayan George wrote:
>
> Hi Philip,
>
> This is the patch I'd like to submit for the loop device. I'm in the
> process of testing it now. I'm pretty confident it will work.

Looks good to me.  Forwarding to Andrew Morton.  Andrew, please 
disregard my previous patch as I think this one is better.


[-- Attachment #2: 0001-Always-invalidate-cleared-loop-block-devices.patch --]
[-- Type: text/x-patch, Size: 2920 bytes --]

>From c783ba6a26eff42d3cb0061e4fcb8ee8a16b3e67 Mon Sep 17 00:00:00 2001
From: Ayan George <ayan.george@canonical.com>
Date: Thu, 14 Jul 2011 14:16:58 -0400
Subject: [PATCH] Always invalidate cleared loop block devices

The API for loop_clr_fd() is confusing -- the second argument (bdev)
isn't necessesary as struct loop_device contains a pointer to the block
device it is assocated with.

There is a cases where loop_clr_fd() is called with NULL for bdev
which prevents the block device from ever being invalidated with
invalidate_bdev() and prevents a uevent from being emitted.

This patch removes the bdev argument from loop_clr_fd(), unconditionally
invalidates lo->lo_device when cleared, and unconditionally emits a
uevent for removed loops.

Launchpad bug for reference:

BugLink: https://bugs.launchpad.net/bugs/548546

Signed-off-by: Ayan George <ayan.george@canonical.com>
---
 drivers/block/loop.c |   24 ++++++++++++++----------
 1 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 76c8da7..a40e12b 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -987,11 +987,13 @@ loop_init_xfer(struct loop_device *lo, struct loop_func_table *xfer,
 	return err;
 }
 
-static int loop_clr_fd(struct loop_device *lo, struct block_device *bdev)
+static int loop_clr_fd(struct loop_device *lo)
 {
 	struct file *filp = lo->lo_backing_file;
 	gfp_t gfp = lo->old_gfp_mask;
 
+	struct block_device *bdev = lo->lo_device;
+
 	if (lo->lo_state != Lo_bound)
 		return -ENXIO;
 
@@ -1022,15 +1024,17 @@ static int loop_clr_fd(struct loop_device *lo, struct block_device *bdev)
 	memset(lo->lo_encrypt_key, 0, LO_KEY_SIZE);
 	memset(lo->lo_crypt_name, 0, LO_NAME_SIZE);
 	memset(lo->lo_file_name, 0, LO_NAME_SIZE);
-	if (bdev)
-		invalidate_bdev(bdev);
+
+	invalidate_bdev(bdev);
+
 	set_capacity(lo->lo_disk, 0);
 	loop_sysfs_exit(lo);
-	if (bdev) {
-		bd_set_size(bdev, 0);
-		/* let user-space know about this change */
-		kobject_uevent(&disk_to_dev(bdev->bd_disk)->kobj, KOBJ_CHANGE);
-	}
+
+	bd_set_size(bdev, 0);
+
+	/* let user-space know about this change */
+	kobject_uevent(&disk_to_dev(bdev->bd_disk)->kobj, KOBJ_CHANGE);
+
 	mapping_set_gfp_mask(filp->f_mapping, gfp);
 	lo->lo_state = Lo_unbound;
 	/* This is safe: open() is still holding a reference. */
@@ -1298,7 +1302,7 @@ static int lo_ioctl(struct block_device *bdev, fmode_t mode,
 		break;
 	case LOOP_CLR_FD:
 		/* loop_clr_fd would have unlocked lo_ctl_mutex on success */
-		err = loop_clr_fd(lo, bdev);
+		err = loop_clr_fd(lo);
 		if (!err)
 			goto out_unlocked;
 		break;
@@ -1509,7 +1513,7 @@ static int lo_release(struct gendisk *disk, fmode_t mode)
 		 * In autoclear mode, stop the loop thread
 		 * and remove configuration after last close.
 		 */
-		err = loop_clr_fd(lo, NULL);
+		err = loop_clr_fd(lo);
 		if (!err)
 			goto out_unlocked;
 	} else {
-- 
1.7.4.1


       reply	other threads:[~2011-07-15 19:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4E1F3BE0.8040506@ayan.net>
2011-07-15 19:12 ` Phillip Susi [this message]
2011-07-15 19:19   ` Andrew Morton
2011-07-15 22:28     ` Ayan George
2011-08-04  1:58     ` Phillip Susi
2011-08-04  2:06       ` Andrew Morton
2011-08-04  2:13       ` Ayan George

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=4E209132.7000704@cfl.rr.com \
    --to=psusi@cfl.rr.com \
    --cc=akpm@linux-foundation.org \
    --cc=ayan@ayan.net \
    --cc=linux-kernel@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®