From: Matteo Croce <mcroce@linux.microsoft.com> To: linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, Jens Axboe <axboe@kernel.dk> Cc: linux-kernel@vger.kernel.org, "Lennart Poettering" <lennart@poettering.net>, "Luca Boccassi" <bluca@debian.org>, "Alexander Viro" <viro@zeniv.linux.org.uk>, "Damien Le Moal" <damien.lemoal@wdc.com>, "Tejun Heo" <tj@kernel.org>, "Javier González" <javier@javigon.com>, "Niklas Cassel" <niklas.cassel@wdc.com>, "Johannes Thumshirn" <johannes.thumshirn@wdc.com>, "Hannes Reinecke" <hare@suse.de>, "Matthew Wilcox" <willy@infradead.org>, "Christoph Hellwig" <hch@infradead.org>, JeffleXu <jefflexu@linux.alibaba.com> Subject: [PATCH v3 6/6] loop: increment sequence number Date: Wed, 23 Jun 2021 12:58:58 +0200 [thread overview] Message-ID: <20210623105858.6978-7-mcroce@linux.microsoft.com> (raw) In-Reply-To: <20210623105858.6978-1-mcroce@linux.microsoft.com> From: Matteo Croce <mcroce@microsoft.com> On a very loaded system, if there are many events queued up from multiple attach/detach cycles, it's impossible to match them up with the LOOP_CONFIGURE or LOOP_SET_FD call, since we don't know where the position of our own association in the queue is[1]. Not even an empty uevent queue is a reliable indication that we already received the uevent we were waiting for, since with multi-partition block devices each partition's event is queued asynchronously and might be delivered later. Increment the disk sequence number when setting or changing the backing file, so the userspace knows which backing file generated the event: # udevadm monitor -kp |grep -e ^DEVNAME -e ^DISKSEQ & [1] 263 # losetup -fP 3part [ 12.309974] loop0: detected capacity change from 0 to 2048 DEVNAME=/dev/loop0 DISKSEQ=8 [ 12.360252] loop0: p1 p2 p3 DEVNAME=/dev/loop0 DISKSEQ=8 DEVNAME=/dev/loop0p1 DISKSEQ=8 DEVNAME=/dev/loop0p2 DISKSEQ=8 DEVNAME=/dev/loop0p3 DISKSEQ=8 # losetup -D DEVNAME=/dev/loop0 DISKSEQ=9 DEVNAME=/dev/loop0p1 DISKSEQ=9 DEVNAME=/dev/loop0p2 DISKSEQ=9 DEVNAME=/dev/loop0p3 DISKSEQ=9 # losetup -fP 2part [ 29.001344] loop0: detected capacity change from 0 to 2048 DEVNAME=/dev/loop0 DISKSEQ=10 [ 29.040226] loop0: p1 p2 DEVNAME=/dev/loop0 DISKSEQ=10 DEVNAME=/dev/loop0p1 DISKSEQ=10 DEVNAME=/dev/loop0p2 DISKSEQ=10 [1] https://github.com/systemd/systemd/issues/17469#issuecomment-762919781 Signed-off-by: Matteo Croce <mcroce@microsoft.com> --- drivers/block/loop.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index 76e12f3482a9..b1c638d23306 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -735,6 +735,7 @@ static int loop_change_fd(struct loop_device *lo, struct block_device *bdev, goto out_err; /* and ... switch */ + inc_diskseq(lo->lo_disk); blk_mq_freeze_queue(lo->lo_queue); mapping_set_gfp_mask(old_file->f_mapping, lo->old_gfp_mask); lo->lo_backing_file = file; @@ -1123,6 +1124,8 @@ static int loop_configure(struct loop_device *lo, fmode_t mode, if (error) goto out_unlock; + inc_diskseq(lo->lo_disk); + if (!(file->f_mode & FMODE_WRITE) || !(mode & FMODE_WRITE) || !file->f_op->write_iter) lo->lo_flags |= LO_FLAGS_READ_ONLY; @@ -1223,6 +1226,8 @@ static int __loop_clr_fd(struct loop_device *lo, bool release) lo->lo_backing_file = NULL; spin_unlock_irq(&lo->lo_lock); + inc_diskseq(lo->lo_disk); + loop_release_xfer(lo); lo->transfer = NULL; lo->ioctl = NULL; -- 2.31.1
next prev parent reply other threads:[~2021-06-23 11:00 UTC|newest] Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-23 10:58 [PATCH v3 0/6] block: add a sequence number to disks Matteo Croce 2021-06-23 10:58 ` [PATCH v3 1/6] block: add disk sequence number Matteo Croce 2021-06-23 11:48 ` Christoph Hellwig 2021-06-23 13:10 ` Matteo Croce 2021-06-23 13:51 ` Lennart Poettering 2021-06-23 14:01 ` Hannes Reinecke 2021-06-23 14:07 ` Luca Boccassi 2021-06-23 14:21 ` Hannes Reinecke 2021-06-23 14:34 ` Luca Boccassi 2021-06-23 14:55 ` Lennart Poettering 2021-06-23 14:12 ` Lennart Poettering 2021-06-23 15:02 ` Hannes Reinecke 2021-06-23 15:34 ` Luca Boccassi 2021-06-23 15:48 ` Lennart Poettering 2021-06-23 14:28 ` Christoph Hellwig 2021-06-23 10:58 ` [PATCH v3 2/6] block: add ioctl to read the " Matteo Croce 2021-06-23 10:58 ` [PATCH v3 3/6] block: refactor sysfs code Matteo Croce 2021-06-23 11:52 ` Christoph Hellwig 2021-06-23 19:03 ` Matteo Croce 2021-06-24 6:12 ` Christoph Hellwig 2021-06-23 10:58 ` [PATCH v3 4/6] block: export diskseq in sysfs Matteo Croce 2021-06-23 10:58 ` [PATCH v3 5/6] block: increment sequence number Matteo Croce 2021-06-23 10:58 ` Matteo Croce [this message] 2021-06-23 11:57 ` [PATCH v3 6/6] loop: " Christoph Hellwig 2021-06-23 13:13 ` Luca Boccassi 2021-06-23 14:25 ` Christoph Hellwig 2021-06-23 15:29 ` Lennart Poettering 2021-06-24 6:11 ` Christoph Hellwig 2021-06-23 12:03 ` [PATCH v3 0/6] block: add a sequence number to disks Hannes Reinecke 2021-06-23 12:46 ` Luca Boccassi 2021-06-23 14:07 ` Lennart Poettering
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=20210623105858.6978-7-mcroce@linux.microsoft.com \ --to=mcroce@linux.microsoft.com \ --cc=axboe@kernel.dk \ --cc=bluca@debian.org \ --cc=damien.lemoal@wdc.com \ --cc=hare@suse.de \ --cc=hch@infradead.org \ --cc=javier@javigon.com \ --cc=jefflexu@linux.alibaba.com \ --cc=johannes.thumshirn@wdc.com \ --cc=lennart@poettering.net \ --cc=linux-block@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=niklas.cassel@wdc.com \ --cc=tj@kernel.org \ --cc=viro@zeniv.linux.org.uk \ --cc=willy@infradead.org \ --subject='Re: [PATCH v3 6/6] loop: increment sequence number' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).