From: Bart Van Assche <bvanassche@acm.org>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
Jens Axboe <axboe@kernel.dk>,
linux-block <linux-block@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Christoph Hellwig <hch@lst.de>,
Damien Le Moal <dlemoal@kernel.org>
Subject: Re: [PATCH] loop: Fix NULL pointer dereference by synchronizing lo_release and loop_queue_rq
Date: Mon, 11 May 2026 08:58:07 -0700 [thread overview]
Message-ID: <c0047a38-3d02-4ce5-88b0-2b7d0b9b69fa@acm.org> (raw)
In-Reply-To: <e33b4060-69d9-4d02-a330-2fbd19249237@I-love.SAKURA.ne.jp>
On 5/11/26 4:43 AM, Tetsuo Handa wrote:
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index 0000913f7efc..9be47ce97dab 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -93,6 +93,7 @@ struct loop_cmd {
> static DEFINE_IDR(loop_index_idr);
> static DEFINE_MUTEX(loop_ctl_mutex);
> static DEFINE_MUTEX(loop_validate_mutex);
> +DEFINE_SRCU(loop_io_srcu);
>
> /**
> * loop_global_lock_killable() - take locks for safe loop_validate_file() test
> @@ -1747,8 +1748,19 @@ static void lo_release(struct gendisk *disk)
> need_clear = (lo->lo_state == Lo_rundown);
> mutex_unlock(&lo->lo_mutex);
>
> - if (need_clear)
> + if (need_clear) {
> + /*
> + * Now that loop_queue_rq() sees lo->lo_state != Lo_bound,
> + * wait for already started loop_queue_rq() to complete.
> + */
> + synchronize_srcu(&loop_io_srcu);
> + /*
> + * Now that no more works are scheduled by loop_queue_rq(),
> + * wait for already scheduled works to complete.
> + */
> + drain_workqueue(lo->workqueue);
> __loop_clr_fd(lo);
> + }
> }
There is already a mechanism in the block layer to wait for pending
.queue_rq() calls to complete. Please take a look at
blk_mq_quiesce_queue().
> static void lo_free_disk(struct gendisk *disk)
> @@ -1854,11 +1866,15 @@ static blk_status_t loop_queue_rq(struct blk_mq_hw_ctx *hctx,
> struct request *rq = bd->rq;
> struct loop_cmd *cmd = blk_mq_rq_to_pdu(rq);
> struct loop_device *lo = rq->q->queuedata;
> + int idx;
>
> blk_mq_start_request(rq);
>
> - if (data_race(READ_ONCE(lo->lo_state)) != Lo_bound)
> + idx = srcu_read_lock(&loop_io_srcu);
> + if (data_race(READ_ONCE(lo->lo_state)) != Lo_bound) {
> + srcu_read_unlock(&loop_io_srcu, idx);
> return BLK_STS_IOERR;
> + }
>
> switch (req_op(rq)) {
> case REQ_OP_FLUSH:
> @@ -1888,6 +1904,7 @@ static blk_status_t loop_queue_rq(struct blk_mq_hw_ctx *hctx,
> #endif
> loop_queue_work(lo, cmd);
>
> + srcu_read_unlock(&loop_io_srcu, idx);
> return BLK_STS_OK;
> }
Why SRCU instead of RCU? The loop driver doesn't set BLK_MQ_F_BLOCKING
and hence must not sleep inside loop_queue_rq(). Additionally, the block
layer already holds an RCU lock around all loop_queue_rq() calls. From
block/blk-mq.h:
/* run the code block in @dispatch_ops with rcu/srcu read lock held */
#define __blk_mq_run_dispatch_ops(q, check_sleep, dispatch_ops) \
do { \
if ((q)->tag_set->flags & BLK_MQ_F_BLOCKING) { \
struct blk_mq_tag_set *__tag_set = (q)->tag_set; \
int srcu_idx; \
\
might_sleep_if(check_sleep); \
srcu_idx = srcu_read_lock(__tag_set->srcu); \
(dispatch_ops); \
srcu_read_unlock(__tag_set->srcu, srcu_idx); \
} else { \
rcu_read_lock(); \
(dispatch_ops); \
rcu_read_unlock(); \
} \
} while (0)
Thanks,
Bart.
next prev parent reply other threads:[~2026-05-11 15:58 UTC|newest]
Thread overview: 7+ 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 [this message]
2026-05-11 17:43 ` Tetsuo Handa
2026-05-12 11:46 ` Tetsuo Handa
2026-05-15 1:38 ` [PATCH v2] " 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=c0047a38-3d02-4ce5-88b0-2b7d0b9b69fa@acm.org \
--to=bvanassche@acm.org \
--cc=axboe@kernel.dk \
--cc=dlemoal@kernel.org \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
/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.