On Thu, Jun 1, 2023 at 3:28 AM Christoph Hellwig <hch@xxxxxx> wrote: > > Note that the last attempt to do this got reverted by Linus in commit > a32e236eb93e ("Partially revert "block: fail op_is_write() requests to > read-only partitions") because device mapper relyied on not enforcing > the read-only state when used together with older lvm-tools. I'm certainly happy to try again, but I have my doubts whether this will work. Note that the problem case is for a device that *used* to be writable, but became read-only later, and there's an existing writer that needs that writability. The lvm fix was not to stop writing, but to simply not mark it read-only too early. So I do think that the problem here is purely in the block layer. The logic wrt "bdev_read_only()" is not necessarily a "right now it's read-only", but more of a thing that should be checked purely when the device is opened. Which is pretty much exactly what we do. So honestly, that whole test for + if (op_is_write(bio_op(bio)) && bio_sectors(bio) && + bdev_read_only(bdev)) { may look "obviously correct", but it's also equally valid to view it as "obviously garbage", simply because the test is being done at the wrong point. The same way you can write to a file that was opened for writing, but has then become read-only afterwards, writing to a device with a bdev that was writable when you *started* writing is not at all necessarily wrong. So please at least consider the possibility that that test - while it looks obvious - is simply buggy. Linus -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel