public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Tso" <tytso@mit.edu>
To: Deepanshu Kartikey <kartikey406@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	axboe@kernel.dk, dvyukov@google.com, adilger.kernel@dilger.ca,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-ext4@vger.kernel.org,
	syzbot+fb32afec111a7d61b939@syzkaller.appspotmail.com
Subject: Re: [PATCH] loop: block loop reconfiguration of offset/sizelimit on mounted device
Date: Mon, 30 Mar 2026 15:00:52 -0400	[thread overview]
Message-ID: <20260330190052.GA50033@macsyma.local> (raw)
In-Reply-To: <CADhLXY6Cu+O_jeL9xxORtLg-LU6pdBxFb29yhS=d2rTtgbA2tw@mail.gmail.com>

On Mon, Mar 30, 2026 at 08:03:55PM +0530, Deepanshu Kartikey wrote:
> 
> The check would be:
> 
> #ifndef CONFIG_BLK_DEV_WRITE_MOUNTED
> if ((lo->lo_offset != info->lo_offset ||
>      lo->lo_sizelimit != info->lo_sizelimit) &&
>     lo->lo_device->bd_writers < 0) {
> err = -EBUSY;
> goto out_unlock;
> }
> #endif

Can you please move bdev_writes_blocked() into
include/linux/blk_types.h as an inline function as Christoph
suggested?

The reason for that is that "bdev_writers < 0" is an implementation
detail and it might change in the future, and then loop driver might
break unexpectedly.  Using bdev_writes_blocked() is also much clearer
from a code readability perspective.

> Regarding Christoph's point about increasing lo_sizelimit being
> safe - should I narrow the check to only block shrinking and
> offset changes?

Yes, I think we should allow the loop device to grow, since that's
harmless and there are some legitimate use cases when people might
want to do this and then trigger an online resize so the file system
grows to use the added space.

						- Ted

      reply	other threads:[~2026-03-30 19:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-30  4:43 [PATCH] loop: block loop reconfiguration of offset/sizelimit on mounted device Deepanshu Kartikey
2026-03-30  5:54 ` Christoph Hellwig
2026-03-30 13:38   ` Theodore Tso
2026-03-30 14:33     ` Deepanshu Kartikey
2026-03-30 19:00       ` Theodore Tso [this message]

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=20260330190052.GA50033@macsyma.local \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=axboe@kernel.dk \
    --cc=dvyukov@google.com \
    --cc=hch@infradead.org \
    --cc=kartikey406@gmail.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzbot+fb32afec111a7d61b939@syzkaller.appspotmail.com \
    /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