After commit d3476f3dad4a (“ext4: don't set SB_RDONLY after filesystem errors”) in v6.12-rc1, the “errors=remount-ro” mode no longer sets SB_RDONLY on errors, which results in us seeing the filesystem is still in rw state after errors. The issue fixed by this patch is reported as CVE-2024-50191. https://lore.kernel.org/all/2024110851-CVE-2024-50191-f31c@gregkh/ This has actually changed the remount-ro semantics. We have some fault injection test cases where we unmount the filesystem after detecting a ro state and then check for consistency. Our customer has a similar scenario. In "errors=remount-ro" mode, some operations are performed after the file system becomes read-only. We reported similar issues to the community in 2020, https://lore.kernel.org/all/20210104160457.GG4018@xxxxxxxxxxxxxx/ Jan Kara provides a simple and effective patch. This patch somehow didn't end up merged into upstream, but this patch has been merged into our internal version for a couple years now and it works fine, is it possible to revert the patch that no longer sets SB_RDONLY and use the patch in the link above? What's worse is that after commit 95257987a638 ("ext4: drop EXT4_MF_FS_ABORTED flag") was merged in v6.6-rc1, the EXT4_FLAGS_SHUTDOWN bit is set in ext4_handle_error(). This causes the file system to not be read-only when an error is triggered in "errors=remount-ro" mode, because EXT4_FLAGS_SHUTDOWN prevents both writing and reading. I'm not sure if this is the intended behavior. But if the intention is to shut down the file system upon an error, I feel it would be better to add an "errors=shutdown" option. Regards, Baokun
