All of lore.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Nitin Gupta <ngupta@vflare.org>,
	linux-kernel@vger.kernel.org,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [PATCHv3 9/9] zram: add dynamic device add/remove functionality
Date: Mon, 4 May 2015 11:20:08 +0900	[thread overview]
Message-ID: <20150504022008.GA14452@blaptop> (raw)
In-Reply-To: <20150430065111.GC950@swordfish>

Hello Sergey,

On Thu, Apr 30, 2015 at 03:51:12PM +0900, Sergey Senozhatsky wrote:
> On (04/30/15 15:44), Minchan Kim wrote:
> > > > I think the problem of deadlock is that you are trying to remove sysfs file
> > > > in sysfs handler.
> > > > 
> > > > #> echo 1 > /sys/xxx/zram_remove
> > > > 
> > > > kernfs_fop_write - hold s_active
> > > >   -> zram_remove_store
> > > >     -> zram_remove
> > > >       -> sysfs_remove_group - hold s_active *again*
> > > > 
> > > > Right?
> > > > 
> > > 
> > > are those same s_active locks?
> > > 
> > > 
> > > we hold (s_active#163) and (&bdev->bd_mutex) and want to acquire (s_active#162)
> > 
> > Thanks for sharing the message.
> > You're right. It's another lock so it shouldn't be a reason.
> > Okay, I will review it. Please give me time.
> > 
> 
> sure, no problem and no rush. thanks!

I had a time to think over it.

I think your patch is rather tricky so someone cannot see sysfs
although he already opened /dev/zram but after a while he can see sysfs.
It's weired.

I want to fix it more generic way. Othewise, we might have trouble with
locking problem sometime. We already have experieced it with init_lock
although we finally fixed it.

I think we can fix it with below patch I hope it's more general and right
approach. It's based on your [zram: return zram device_id from zram_add()]

What do you think about?

>From e943df5407b880f9262ef959b270226fdc81bc9f Mon Sep 17 00:00:00 2001
From: Minchan Kim <minchan@kernel.org>
Date: Mon, 4 May 2015 08:36:07 +0900
Subject: [PATCH 1/2] zram: close race by open overriding

[1] introduced bdev->bd_mutex to protect a race between mount
and reset. At that time, we don't have dynamic zram-add/remove
feature so it was okay.

However, as we introduce dynamic device feature, bd_mutex became
trouble.

	CPU 0

echo 1 > /sys/block/zram<id>/reset
  -> kernfs->s_active(A)
    -> zram:reset_store->bd_mutex(B)

	CPU 1

echo <id> > /sys/class/zram/zram-remove
  ->zram:zram_remove: bd_mutex(B)
  -> sysfs_remove_group
    -> kernfs->s_active(A)

IOW, AB -> BA deadlock

The reason we are holding bd_mutex for zram_remove is to prevent
any incoming open /dev/zram[0-9]. Otherwise, we could remove zram
others already have opened. But it causes above deadlock problem.

To fix the problem, this patch overrides block_device.open and
it returns -EBUSY if zram asserts he claims zram to reset so any
incoming open will be failed so we don't need to hold bd_mutex
for zram_remove ayn more.

This patch is to prepare for zram-add/remove feature.

[1] ba6b17: zram: fix umount-reset_store-mount race condition
Signed-off-by: Minchan Kim <minchan@kernel.org>
---
 drivers/block/zram/zram_drv.c | 42 ++++++++++++++++++++++++++++++++----------
 drivers/block/zram/zram_drv.h |  4 ++++
 2 files changed, 36 insertions(+), 10 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 3df4394..7fb72dc 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -1074,13 +1074,6 @@ static ssize_t reset_store(struct device *dev,
 	if (!bdev)
 		return -ENOMEM;
 
-	mutex_lock(&bdev->bd_mutex);
-	/* Do not reset an active device! */
-	if (bdev->bd_openers) {
-		ret = -EBUSY;
-		goto out;
-	}
-
 	ret = kstrtou16(buf, 10, &do_reset);
 	if (ret)
 		goto out;
@@ -1090,23 +1083,52 @@ static ssize_t reset_store(struct device *dev,
 		goto out;
 	}
 
+	mutex_lock(&bdev->bd_mutex);
+	/* Do not reset an active device or claimed device */
+	if (bdev->bd_openers || zram->claim) {
+		ret = -EBUSY;
+		mutex_unlock(&bdev->bd_mutex);
+		goto out;
+	}
+
+	/* From now on, anyone can't open /dev/zram[0-9] */
+	zram->claim = true;
+	mutex_unlock(&bdev->bd_mutex);
+
 	/* Make sure all pending I/O is finished */
 	fsync_bdev(bdev);
 	zram_reset_device(zram);
 
-	mutex_unlock(&bdev->bd_mutex);
 	revalidate_disk(zram->disk);
 	bdput(bdev);
 
-	return len;
+	mutex_lock(&bdev->bd_mutex);
+	zram->claim = false;
+	mutex_unlock(&bdev->bd_mutex);
 
+	return len;
 out:
-	mutex_unlock(&bdev->bd_mutex);
 	bdput(bdev);
 	return ret;
 }
 
+static int zram_open(struct block_device *bdev, fmode_t mode)
+{
+	int ret = 0;
+	struct zram *zram;
+
+	WARN_ON(!mutex_is_locked(&bdev->bd_mutex));
+
+	zram = bdev->bd_disk->private_data;
+	/* zram was claimed to reset so open request fails */
+	if (zram->claim)
+		ret = -EBUSY;
+
+	return ret;
+}
+
 static const struct block_device_operations zram_devops = {
+	.open = zram_open,
 	.swap_slot_free_notify = zram_slot_free_notify,
 	.rw_page = zram_rw_page,
 	.owner = THIS_MODULE
diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h
index 042994e..6dbe2df 100644
--- a/drivers/block/zram/zram_drv.h
+++ b/drivers/block/zram/zram_drv.h
@@ -115,5 +115,9 @@ struct zram {
 	 */
 	u64 disksize;	/* bytes */
 	char compressor[10];
+	/*
+	 * zram is claimed so open request will be failed
+	 */
+	bool claim; /* Protected by bdev->bd_mutex */
 };
 #endif
-- 
1.9.3

-- 
Kind regards,
Minchan Kim

  reply	other threads:[~2015-05-04  2:20 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-27 13:21 [PATCHv3 0/9] introduce on-demand device creation Sergey Senozhatsky
2015-04-27 13:21 ` [PATCHv3 1/9] zram: add `compact` sysfs entry to documentation Sergey Senozhatsky
2015-04-27 13:21 ` [PATCHv3 2/9] zram: cosmetic ZRAM_ATTR_RO code formatting tweak Sergey Senozhatsky
2015-04-27 13:21 ` [PATCHv3 3/9] zram: use idr instead of `zram_devices' array Sergey Senozhatsky
2015-04-27 13:21 ` [PATCHv3 4/9] zram: reorganize code layout Sergey Senozhatsky
2015-04-27 13:21 ` [PATCHv3 5/9] zram: remove max_num_devices limitation Sergey Senozhatsky
2015-04-27 13:21 ` [PATCHv3 6/9] zram: report every added and removed device Sergey Senozhatsky
2015-04-27 13:21 ` [PATCHv3 7/9] zram: trivial: correct flag operations comment Sergey Senozhatsky
2015-04-27 13:21 ` [PATCHv3 8/9] zram: return zram device_id from zram_add() Sergey Senozhatsky
2015-04-27 13:21 ` [PATCHv3 9/9] zram: add dynamic device add/remove functionality Sergey Senozhatsky
2015-04-29  0:16   ` Sergey Senozhatsky
2015-04-29  6:48     ` Minchan Kim
2015-04-29  7:02       ` Sergey Senozhatsky
2015-04-29  7:23         ` Sergey Senozhatsky
2015-04-30  5:47           ` Minchan Kim
2015-04-30  6:34             ` Sergey Senozhatsky
2015-04-30  6:44               ` Minchan Kim
2015-04-30  6:51                 ` Sergey Senozhatsky
2015-05-04  2:20                   ` Minchan Kim [this message]
2015-05-04  2:28                     ` Minchan Kim
2015-05-04  6:32                       ` Sergey Senozhatsky
2015-05-04  6:29                     ` Sergey Senozhatsky
2015-05-04 11:34                     ` Sergey Senozhatsky
2015-04-30  6:44               ` Sergey Senozhatsky
2015-04-27 13:41 ` [PATCHv3 0/9] introduce on-demand device creation Sergey Senozhatsky

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=20150504022008.GA14452@blaptop \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ngupta@vflare.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=sergey.senozhatsky@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.