Linux-Next discussions
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	Markus Elfring <Markus.Elfring@web.de>,
	linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Damien Le Moal <dlemoal@kernel.org>, Jens Axboe <axboe@kernel.dk>
Cc: linux-kernel@vger.kernel.org, linux-next@vger.kernel.org,
	lkp@intel.com, oe-lkp@lists.linux.dev,
	Christian Brauner <brauner@kernel.org>,
	Christoph Hellwig <hch@infradead.org>,
	Christoph Hellwig <hch@lst.de>, Hillf Danton <hdanton@sina.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Mark Brown <broonie@kernel.org>,
	Oliver Sang <oliver.sang@intel.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v6] loop: Fix NULL pointer dereference in lo_rw_aio()
Date: Tue, 25 Aug 2026 15:18:24 -0700	[thread overview]
Message-ID: <845464ce-43c0-45b3-94ea-ccc830fbc76f@acm.org> (raw)
In-Reply-To: <c41e9198-86a8-4bcd-a608-6f457b24f345@I-love.SAKURA.ne.jp>

On 8/25/26 8:13 AM, Tetsuo Handa wrote:
> As of commit fe4c990e6a30 ("loop: Add __guarded_by() annotations") in block-loop branch,
> 
>    modprobe loop
>    losetup /dev/loop0 testfile.img; losetup /dev/loop1 /dev/loop0; losetup -D
>    sleep 1
>    losetup /dev/loop1 testfile.img; losetup /dev/loop0 /dev/loop1; losetup -D
> 
> causes lockdep warning. This is a false positive, but we need to avoid it anyway.

Thanks for having shared the above reproducer. I have dropped the 
patches that protect all lo_backing_file dereferences with lo_mutex. It
is too tricky to get this right and at the same time to keep lockdep
happy.

> you also recognized that we can't call drain_workqueue() or flush_workqueue().
> 
> Therefore, I chose to temporarily drop lo->lo_disk->open_mutex in order to
> make it possible to safely perform drain_workqueue().

There is another possibility: set QUEUE_FLAG_DYING in __loop_clr_fd() 
before modifying queue limits and clear it again after modifying queue
limits has finished. Feedback on the patch below is welcome.

Thanks,

Bart.

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index df72350cad15..2fb9dc8ea47e 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1153,11 +1153,30 @@ static int loop_configure(struct loop_device 
*lo, blk_mode_t mode,

  static void __loop_clr_fd(struct loop_device *lo)
  {
+	struct request_queue *q = lo->lo_queue;
  	struct queue_limits lim;
+	unsigned int memflags;
  	struct file *filp;
  	gfp_t gfp = lo->old_gfp_mask;
  	int err;

+	/*
+	 * Prevent that new asynchronous I/O is submitted while queue limits
+	 * are being modified.
+	 */
+	blk_queue_flag_set(QUEUE_FLAG_DYING, q);
+
+	/* Wait until asynchronous I/O has finished. */
+	memflags = blk_mq_freeze_queue(q);
+	blk_mq_unfreeze_queue(q, memflags);
+
+	/* Wait until I/O dispatching has finished. */
+	blk_mq_quiesce_queue(q);
+	blk_mq_unquiesce_queue(q);
+
+	/* Wait until all I/O-related work has finished. */
+	flush_workqueue(lo->workqueue);
+
  	mutex_lock(&lo->lo_mutex);
  	filp = lo->lo_backing_file;
  	lo->lo_backing_file = NULL;
@@ -1168,17 +1187,12 @@ static void __loop_clr_fd(struct loop_device *lo)
  	lo->lo_sizelimit = 0;
  	memset(lo->lo_file_name, 0, LO_NAME_SIZE);

-	/*
-	 * Reset the block size to the default.
-	 *
-	 * No queue freezing needed because this is called from the final
-	 * ->release call only, so there can't be any outstanding I/O.
-	 */
-	lim = queue_limits_start_update(lo->lo_queue);
+	/* Reset the block size to the default. */
+	lim = queue_limits_start_update(q);
  	lim.logical_block_size = SECTOR_SIZE;
  	lim.physical_block_size = SECTOR_SIZE;
  	lim.io_min = SECTOR_SIZE;
-	queue_limits_commit_update(lo->lo_queue, &lim);
+	queue_limits_commit_update(q, &lim);

  	invalidate_disk(lo->lo_disk);
  	loop_sysfs_exit(lo);
@@ -1216,6 +1230,9 @@ static void __loop_clr_fd(struct loop_device *lo)
  	WRITE_ONCE(lo->lo_state, Lo_unbound);
  	mutex_unlock(&lo->lo_mutex);

+	/* Reallow I/O. */
+	blk_queue_flag_clear(QUEUE_FLAG_DYING, q);
+
  	fput(filp);
  }



  reply	other threads:[~2026-08-25 22:18 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260714043834.554-1-hdanton@sina.com>
2026-07-16  0:05 ` [PATCH v5] loop: Fix NULL pointer dereference in lo_rw_aio() Tetsuo Handa
2026-08-23 11:17   ` [PATCH v6] " Tetsuo Handa
2026-08-23 15:57     ` Markus Elfring
2026-08-24 22:06       ` Tetsuo Handa
2026-08-24 22:53         ` Bart Van Assche
2026-08-24 23:24           ` Bart Van Assche
2026-08-25 15:13             ` Tetsuo Handa
2026-08-25 22:18               ` Bart Van Assche [this message]
2026-08-25 23:28                 ` Tetsuo Handa
2026-08-25 23:16               ` Bart Van Assche
2026-08-26 10:37                 ` Tetsuo Handa
2026-08-26 17:44                   ` Bart Van Assche
2026-08-27 15:30                     ` Tetsuo Handa
2026-08-27 17:28                       ` Bart Van Assche
2026-08-28 15:53                         ` [PATCH v7] " Tetsuo Handa
2026-08-28 16:29                           ` Bart Van Assche
2026-08-29  5:17                             ` Tetsuo Handa
2026-08-29  5:55                               ` Tetsuo Handa

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=845464ce-43c0-45b3-94ea-ccc830fbc76f@acm.org \
    --to=bvanassche@acm.org \
    --cc=Markus.Elfring@web.de \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=broonie@kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=hdanton@sina.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=oe-lkp@lists.linux.dev \
    --cc=oliver.sang@intel.com \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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