From: Christian Brauner <brauner@kernel.org>
To: Daan De Meyer <daan.j.demeyer@gmail.com>
Cc: linux-block@vger.kernel.org, axboe@kernel.dk, hch@infradead.org,
Daan De Meyer <daan@amutable.com>
Subject: Re: [PATCH v3 1/3] loop: fix partition scan race between udev and loop_reread_partitions()
Date: Tue, 31 Mar 2026 13:45:19 +0200 [thread overview]
Message-ID: <20260331-vertagen-formgebend-1036bb16302e@brauner> (raw)
In-Reply-To: <20260331105130.1077599-1-daan@amutable.com>
On Tue, Mar 31, 2026 at 10:51:28AM +0000, Daan De Meyer wrote:
> When LOOP_CONFIGURE is called with LO_FLAGS_PARTSCAN, the following
> sequence occurs:
>
> 1. disk_force_media_change() sets GD_NEED_PART_SCAN
> 2. Uevent suppression is lifted and a KOBJ_CHANGE uevent is sent
> 3. loop_global_unlock() releases the lock
> 4. loop_reread_partitions() calls bdev_disk_changed() to scan
>
> There is a race between steps 2 and 4: when udev receives the uevent
> and opens the device before loop_reread_partitions() runs,
> blkdev_get_whole() in bdev.c sees GD_NEED_PART_SCAN set and calls
> bdev_disk_changed() for a first scan. Then loop_reread_partitions()
> does a second scan. The open_mutex serializes these two scans, but
> does not prevent both from running.
>
> The second scan in bdev_disk_changed() drops all partition devices
> from the first scan (via blk_drop_partitions()) before re-adding
> them, causing partition block devices to briefly disappear. This
> breaks any systemd unit with BindsTo= on the partition device: systemd
> observes the device going dead, fails the dependent units, and does
> not retry them when the device reappears.
>
> Fix this by removing the GD_NEED_PART_SCAN set from
> disk_force_media_change() entirely. None of the current callers need
> the lazy on-open partition scan triggered by this flag:
>
> - floppy: sets GENHD_FL_NO_PART, so disk_has_partscan() is always
> false and GD_NEED_PART_SCAN has no effect.
> - loop (loop_configure, loop_change_fd): when LO_FLAGS_PARTSCAN is
> set, loop_reread_partitions() performs an explicit scan. When not
> set, GD_SUPPRESS_PART_SCAN prevents the lazy scan path.
> - loop (__loop_clr_fd): calls bdev_disk_changed() explicitly if
> LO_FLAGS_PARTSCAN is set.
> - nbd (nbd_clear_sock_ioctl): capacity is set to zero immediately
> after; nbd manages GD_NEED_PART_SCAN explicitly elsewhere.
>
> With GD_NEED_PART_SCAN no longer set by disk_force_media_change(),
> udev opening the loop device after the uevent no longer triggers a
> redundant scan in blkdev_get_whole(), and only the single explicit
> scan from loop_reread_partitions() runs.
>
> A regression test for this bug has been submitted to blktests:
> https://github.com/linux-blktests/blktests/pull/240.
>
> Fixes: 9f65c489b68d ("loop: raise media_change event")
> Signed-off-by: Daan De Meyer <daan@amutable.com>
> ---
Looks good to me,
Acked-by: Christian Brauner <brauner@kernel.org>
next prev parent reply other threads:[~2026-03-31 11:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-31 10:51 [PATCH v3 1/3] loop: fix partition scan race between udev and loop_reread_partitions() Daan De Meyer
2026-03-31 11:45 ` Christian Brauner [this message]
2026-03-31 13:07 ` Jens Axboe
2026-03-31 14:59 ` Christoph Hellwig
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=20260331-vertagen-formgebend-1036bb16302e@brauner \
--to=brauner@kernel.org \
--cc=axboe@kernel.dk \
--cc=daan.j.demeyer@gmail.com \
--cc=daan@amutable.com \
--cc=hch@infradead.org \
--cc=linux-block@vger.kernel.org \
/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