All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
To: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>, Hillf Danton <hdanton@sina.com>,
	Pavel Tatashin <pasha.tatashin@soleen.com>,
	Tyler Hicks <tyhicks@linux.microsoft.com>,
	linux-block <linux-block@vger.kernel.org>
Subject: Re: [PATCH] loop: replace loop_ctl_mutex with loop_idr_spinlock
Date: Sat, 28 Aug 2021 11:22:59 +0900	[thread overview]
Message-ID: <b9d7b6b1-236a-438b-bee7-6d65b7b58905@i-love.sakura.ne.jp> (raw)
In-Reply-To: <73c53177-be1b-cff1-a09e-ef7979a95200@i-love.sakura.ne.jp>

On 2021/08/28 10:10, Tetsuo Handa wrote:
> If we don't ignore forced module unload, we could update my patch to keep only
> mutex_destroy() and kfree() deferred by a refcount, for only lo->lo_state,
> lo->lo_refcnt and lo->lo_encryption would be accessed under lo->lo_mutex
> serialization. There is no need to defer "del_gendisk() + idr_remove()"
> sequence for concurrent callers.
> 

OK, here is a delta patch to make it no longer best effort.
We can consider removal of cryptoloop module after this patch,
starting from a printk() for deprecated message.

 drivers/block/loop.c | 31 +++++++++++++------------------
 1 file changed, 13 insertions(+), 18 deletions(-)

--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -2113,7 +2113,11 @@ int loop_register_transfer(struct loop_func_table *funcs)
 	return 0;
 }
 
-static void loop_remove(struct loop_device *lo);
+static void loop_destroy(struct loop_device *lo)
+{
+	mutex_destroy(&lo->lo_mutex);
+	kfree(lo);
+}
 
 int loop_unregister_transfer(int number)
 {
@@ -2137,7 +2141,7 @@ int loop_unregister_transfer(int number)
 			loop_release_xfer(lo);
 		mutex_unlock(&lo->lo_mutex);
 		if (refcount_dec_and_test(&lo->idr_visible))
-			loop_remove(lo);
+			loop_destroy(lo);
 		spin_lock(&loop_idr_spinlock);
 	}
 	spin_unlock(&loop_idr_spinlock);
@@ -2426,9 +2430,6 @@ static void loop_remove(struct loop_device *lo)
 	spin_lock(&loop_idr_spinlock);
 	idr_remove(&loop_index_idr, lo->lo_number);
 	spin_unlock(&loop_idr_spinlock);
-	/* There is no route which can find this loop device. */
-	mutex_destroy(&lo->lo_mutex);
-	kfree(lo);
 }
 
 static void loop_probe(dev_t dev)
@@ -2452,7 +2453,7 @@ static int loop_control_remove(int idx)
 
 	/*
 	 * Identify the loop device to remove. Skip the device if it is owned by
-	 * loop_remove()/loop_add() where it is not safe to access lo_mutex.
+	 * loop_add() where it is not safe to access lo_mutex.
 	 */
 	spin_lock(&loop_idr_spinlock);
 	lo = idr_find(&loop_index_idr, idx);
@@ -2479,19 +2480,11 @@ static int loop_control_remove(int idx)
 	mutex_unlock(&lo->lo_mutex);
 	/* Hide this loop device. */
 	refcount_dec(&lo->idr_visible);
-	/*
-	 * Try to wait for concurrent callers (they should complete shortly due to
-	 * lo->lo_state == Lo_deleting) operating on this loop device, in order to
-	 * help that subsequent loop_add() will not to fail with -EEXIST.
-	 * Note that this is best effort.
-	 */
-	for (ret = 0; refcount_read(&lo->idr_visible) != 1 && ret < HZ; ret++)
-		schedule_timeout_killable(1);
-	ret = 0;
+	/* Remove this loop device, but wait concurrent callers before destroy. */
+	loop_remove(lo);
 out:
-	/* Remove this loop device. */
 	if (refcount_dec_and_test(&lo->idr_visible))
-		loop_remove(lo);
+		loop_destroy(lo);
 	return ret;
 }
 
@@ -2623,8 +2616,10 @@ static void __exit loop_exit(void)
 	 * There is no need to use loop_idr_spinlock here, for nobody else can
 	 * access loop_index_idr when this module is unloading.
 	 */
-	idr_for_each_entry(&loop_index_idr, lo, id)
+	idr_for_each_entry(&loop_index_idr, lo, id) {
 		loop_remove(lo);
+		loop_destroy(lo);
+	}
 
 	idr_destroy(&loop_index_idr);
 }
-- 
2.25.1


  reply	other threads:[~2021-08-28  2:23 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-26 16:03 [PATCH] loop: replace loop_ctl_mutex with loop_idr_spinlock Tetsuo Handa
2021-08-27 18:43 ` Christoph Hellwig
2021-08-28  1:10   ` Tetsuo Handa
2021-08-28  2:22     ` Tetsuo Handa [this message]
2021-08-28  7:18     ` Christoph Hellwig
2021-08-28 13:50       ` Tetsuo Handa
2021-08-29  1:22         ` [PATCH v2] loop: reduce the loop_ctl_mutex scope Tetsuo Handa
2021-08-29 13:47           ` [PATCH v3] " Tetsuo Handa
2021-08-30  7:13             ` Christoph Hellwig
2021-09-01  5:36               ` Christoph Hellwig
2021-09-01  5:47                 ` Tetsuo Handa
2021-09-01  6:10             ` Christoph Hellwig
2021-09-02  0:07               ` [PATCH v3 (repost)] " Tetsuo Handa
2021-09-04  4:16             ` [PATCH v3] " Jens Axboe
2021-08-31  3:19 ` [loop] 8883efd909: stress-ng.loop.ops_per_sec 148.4% improvement kernel test robot
2021-08-31  3:19   ` kernel test robot

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=b9d7b6b1-236a-438b-bee7-6d65b7b58905@i-love.sakura.ne.jp \
    --to=penguin-kernel@i-love.sakura.ne.jp \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=hdanton@sina.com \
    --cc=linux-block@vger.kernel.org \
    --cc=pasha.tatashin@soleen.com \
    --cc=tyhicks@linux.microsoft.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.