Linux block layer
 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: Wed, 26 Aug 2026 10:44:19 -0700	[thread overview]
Message-ID: <d2f387b9-031a-4306-9323-56f98a8241b7@acm.org> (raw)
In-Reply-To: <3bb080d0-4421-4012-8a62-6a2bf165cbd9@I-love.SAKURA.ne.jp>

On 8/26/26 3:37 AM, Tetsuo Handa wrote:
> Current situation is a result of what we had considered 4 years ago; we don't need
> to destroy workqueue (note that destroy_workqueue() implies drain_workqueue()) from
> __loop_clr_fd() ( https://lkml.kernel.org/r/20220330052917.2566582-16-hch@lst.de ).
> 
> Since there is a
> 
>    Chain exists of:
>      (wq_completion)loop0 --> system_transition_mutex/1 --> &disk->open_mutex
>    
>     Possible unsafe locking scenario:
>    
>           CPU0                    CPU1
>           ----                    ----
>      lock(&disk->open_mutex);
>                                   lock(system_transition_mutex/1);
>                                   lock(&disk->open_mutex);
>      lock((wq_completion)loop0);

This ABBA locking scenario can only be triggered if a loop device is
bound to a sysfs attribute with read or write methods that lock
system_transition_mutex, e.g. /sys/kernel/power, isn't it?

> dependency, but my proposal to forbid binding loop device to pseudo files
> ( https://lkml.kernel.org/r/148efba2-a0b6-47d7-ac76-b19d2f4b696c@I-love.SAKURA.ne.jp )
 > was rejected by Christoph, we are stuck in a
 >
>    Draining workqueue with open_mutex held causes creating a complex lock dependency
>    chain involving the global system_transition_mutex. (Maybe there are other paths
>    that create similar dependency chain if we drain workqueue with open_mutex held.)
> 
> versus
> 
>    Not draining workqueue causes NULL pointer dereference in lo_rw_aio().
> 
> collision. Therefore,
> 
>    Draining workqueue *without open_mutex held* can avoid creating a complex lock
>    dependency chain involving the global system_transition_mutex and can also avoid
>    NULL pointer dereference in lo_rw_aio().
> 
> is my solution.

Releasing and reacquiring disk->open_mutex from __loop_clr_fd() seems
risky to me. There is plenty of code in block/bdev.c that assumes that
disk->open_mutex is not released by lo_release().

I think there is another solution: instead of draining the workqueue
from inside __loop_clr_fd(), postpone it until the next time the loop
device is bound. See also the patch below.

Regarding your earlier request for a Sashiko review: I will look into
configuring Sashiko such that I can run "sashiko review ${commit_id}"
locally. The only part I'm missing right now is a Sashiko API key.

Thanks,

Bart.

loop: Serialize I/O and queue limits updates

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 119758b45e47..1406932fae93 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1086,6 +1086,12 @@ static int loop_configure(struct loop_device *lo, 
blk_mode_t mode,
  			error = -ENOMEM;
  			goto out_unlock;
  		}
+	} else {
+		/*
+		 * Wait until all work related to a previously bound file has
+		 * finished.
+		 */
+		flush_workqueue(lo->workqueue);
  	}

  	/* suppress uevents while reconfiguring the device */
@@ -1154,11 +1160,27 @@ static int loop_configure(struct loop_device 
*lo, blk_mode_t mode,
  static void __loop_clr_fd(struct gendisk *disk, struct loop_device *lo)
  	__must_hold(&disk->open_mutex)
  {
+	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);
+
  	mutex_lock(&lo->lo_mutex);
  	filp = lo->lo_backing_file;
  	lo->lo_backing_file = NULL;
@@ -1169,17 +1191,12 @@ static void __loop_clr_fd(struct gendisk *disk, 
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(disk);
  	loop_sysfs_exit(lo);
@@ -1217,6 +1234,9 @@ static void __loop_clr_fd(struct gendisk *disk, 
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-26 17:44 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-18  0:02 [syzbot] [block?] general protection fault in lo_rw_aio syzbot
2026-04-21 11:05 ` Tetsuo Handa
2026-05-11 11:43   ` [PATCH] loop: Fix NULL pointer dereference by synchronizing lo_release and loop_queue_rq Tetsuo Handa
2026-05-11 15:58     ` Bart Van Assche
2026-05-11 17:43       ` Tetsuo Handa
2026-05-12 11:46         ` Tetsuo Handa
2026-05-15  1:38           ` [PATCH v2] " Tetsuo Handa
2026-05-19  0:40             ` Andrew Morton
2026-05-19  9:27               ` Tetsuo Handa
2026-05-20  3:06                 ` Ming Lei
2026-05-20  6:36                   ` Tetsuo Handa
2026-05-20  7:49                     ` Ming Lei
2026-05-20  8:20                       ` Tetsuo Handa
2026-05-20  8:54                         ` Ming Lei
2026-05-25  3:40                           ` [PATCH v3] loop: Fix NULL pointer dereference in lo_rw_aio() Tetsuo Handa
2026-05-25 15:19                             ` Ming Lei
2026-05-26  0:25                               ` Tetsuo Handa
2026-05-27  1:20                                 ` Ming Lei
2026-05-27  1:35                                   ` Tetsuo Handa
2026-05-27  3:00                                     ` Ming Lei
2026-05-27 11:29                                       ` Tetsuo Handa
2026-05-27 18:11                                         ` Damien Le Moal
2026-05-28  8:38                                           ` Christoph Hellwig
2026-05-28 10:16                                             ` Qu Wenruo
2026-06-01 14:40                                               ` Christoph Hellwig
2026-06-01 16:29                                                 ` Brian Foster
2026-06-01 22:27                                                   ` Qu Wenruo
2026-06-01 15:29                                               ` Ming Lei
2026-06-01 21:51                                                 ` Hillf Danton
2026-06-01 22:14                                                   ` Ming Lei
2026-06-01 23:17                                                     ` Hillf Danton
2026-06-01 23:36                                                       ` Ming Lei
2026-06-02  2:02                                                         ` Hillf Danton
2026-05-28  5:43                                       ` Hillf Danton
2026-05-28 23:00                                         ` Hillf Danton
2026-05-29  0:14                                           ` Tetsuo Handa
2026-05-29  7:04                                             ` Hillf Danton
2026-05-29 22:05                                               ` Hillf Danton
2026-05-30 23:57                                                 ` Tetsuo Handa
2026-06-07 10:54                                                   ` [PATCH v4] " Tetsuo Handa
2026-06-09 17:50                                                     ` Al Viro
2026-06-13 11:00                                                       ` Tetsuo Handa
2026-06-19 14:33                                                         ` Tetsuo Handa
2026-06-20  7:39                                                           ` Al Viro
2026-06-20  9:42                                                             ` Tetsuo Handa
2026-07-13  3:04                                                       ` Hillf Danton
2026-07-13 11:02                                                         ` Tetsuo Handa
2026-07-14  4:38                                                           ` Hillf Danton
2026-07-16  0:05                                                             ` [PATCH v5] " 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
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 [this message]
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-07-15 16:01 ` [syzbot] [block?] general protection fault in lo_rw_aio Bart Van Assche
2026-07-15 16:02   ` syzbot

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=d2f387b9-031a-4306-9323-56f98a8241b7@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