From: Mike Snitzer <snitzer@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, dm-devel@redhat.com,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [dm-devel] enforce read-only state at the block layer
Date: Tue, 6 Jun 2023 12:11:00 -0400 [thread overview]
Message-ID: <ZH9alEbuNxHNwYYe@redhat.com> (raw)
In-Reply-To: <20230601072829.1258286-1-hch@lst.de>
On Thu, Jun 01 2023 at 3:28P -0400,
Christoph Hellwig <hch@lst.de> wrote:
> Hi all,
>
> I've recently got a report where a file system can write to a read-only
> block device, and while I've not found the root cause yet, it is very
> clear that we should not prevents writes to read-only at all.
>
> This did in fact get fixed 5 years ago, but Linus reverted it as older
> lvm2 tools relying on this broken behavior. This series tries to
> restore it, although I'm still worried about thee older lvm2 tools
> to be honest. Question to the device mapper maintainers: is the
> any good way to work around that behavior in device mapper if needed
> instead of leaving the core block layer and drivers exposed?
Given the block core change (in patch 3) _and_ old lvm2 code: it'll
obviously fail.
Not sure of a crafty hack to workaround. Hopefully 5 year old lvm2
remains tightly coupled to kernels of the same vintage and we get
lucky moving forward.
So I agree with Linus, worth trying this simple change again and
seeing if there is fallout. Revert/worry about it again as needed.
Mike
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
WARNING: multiple messages have this Message-ID (diff)
From: Mike Snitzer <snitzer@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>,
Linus Torvalds <torvalds@linux-foundation.org>,
dm-devel@redhat.com, linux-block@vger.kernel.org
Subject: Re: enforce read-only state at the block layer
Date: Tue, 6 Jun 2023 12:11:00 -0400 [thread overview]
Message-ID: <ZH9alEbuNxHNwYYe@redhat.com> (raw)
In-Reply-To: <20230601072829.1258286-1-hch@lst.de>
On Thu, Jun 01 2023 at 3:28P -0400,
Christoph Hellwig <hch@lst.de> wrote:
> Hi all,
>
> I've recently got a report where a file system can write to a read-only
> block device, and while I've not found the root cause yet, it is very
> clear that we should not prevents writes to read-only at all.
>
> This did in fact get fixed 5 years ago, but Linus reverted it as older
> lvm2 tools relying on this broken behavior. This series tries to
> restore it, although I'm still worried about thee older lvm2 tools
> to be honest. Question to the device mapper maintainers: is the
> any good way to work around that behavior in device mapper if needed
> instead of leaving the core block layer and drivers exposed?
Given the block core change (in patch 3) _and_ old lvm2 code: it'll
obviously fail.
Not sure of a crafty hack to workaround. Hopefully 5 year old lvm2
remains tightly coupled to kernels of the same vintage and we get
lucky moving forward.
So I agree with Linus, worth trying this simple change again and
seeing if there is fallout. Revert/worry about it again as needed.
Mike
next prev parent reply other threads:[~2023-06-06 16:11 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-01 7:28 [dm-devel] enforce read-only state at the block layer Christoph Hellwig
2023-06-01 7:28 ` Christoph Hellwig
2023-06-01 7:28 ` [dm-devel] [PATCH 1/3] block: remove a duplicate bdev_read_only declaration Christoph Hellwig
2023-06-01 7:28 ` Christoph Hellwig
2023-06-01 7:28 ` [dm-devel] [PATCH 2/3] block: simplify the check for flushes in bio_check_ro Christoph Hellwig
2023-06-01 7:28 ` Christoph Hellwig
2023-06-01 7:28 ` [dm-devel] [PATCH 3/3] block: fail writes to read-only devices Christoph Hellwig
2023-06-01 7:28 ` Christoph Hellwig
2023-06-02 1:02 ` [dm-devel] " Linus Torvalds
2023-06-02 1:02 ` Linus Torvalds
2023-06-02 15:41 ` [dm-devel] " Christoph Hellwig
2023-06-02 15:41 ` Christoph Hellwig
2023-06-02 15:56 ` [dm-devel] " Linus Torvalds
2023-06-02 15:56 ` Linus Torvalds
2023-06-06 16:13 ` [dm-devel] " Mike Snitzer
2023-06-06 16:13 ` Mike Snitzer
2023-06-06 16:11 ` Mike Snitzer [this message]
2023-06-06 16:11 ` enforce read-only state at the block layer Mike Snitzer
2023-06-07 5:33 ` [dm-devel] " Christoph Hellwig
2023-06-07 5:33 ` 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=ZH9alEbuNxHNwYYe@redhat.com \
--to=snitzer@kernel.org \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=torvalds@linux-foundation.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 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.