On Wed, May 10, 2023 at 04:17:01PM +0200, Loic Poulain wrote: > No, because the file itself is writable, but not the underlying block. Eww. > I agree, it would make more sense to simply deny the block open fops > instead... but it could be considered as uapi breakage as we may have > some existing applications opening the device RW, and simply > ignore/discard the sys write errors for ro devices... True. I suspect the right thing might be to still only open the device read-only. Which brings us to the next mess that ->open for block devices is only called once, but different openers might have different flags (with write and nodelay being the once that matter). > but if it's > acceptable let's do it. For sure, we could argue that making the mmap > failing is also a change in uapi behavior, We really should fail it. Unlike the device open, where allowing it feels wrong to me, but at least has use cases being able to create a shared writable mmap doesn't have any point. > but except reconsidering > a32e236eb93e which may be obsolete today, I don't see a better > solution to prevent unwanted writing. I think we need to absolutely reconsider it (in addition to your patch), especially as I just got another report related to it. I'll need to talk to the DM folks to figure out if we can do a workaround in dm somehow.
