This disables repair process on ro cases as it can cause system to be unresponsive on the ASSERT() in repair_io_failure().
This can happen when scrub is running and a hardware error pops up, we should fallback to ro mounts gracefully instead of being unresponsive. Reported-by: Codebird <codeb...@birds-are-nice.me> Signed-off-by: Liu Bo <bo.li....@oracle.com> --- v2: Get @fs_info from a real pointer instead of a confusing-name u64 root. fs/btrfs/scrub.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c index 2907a77..cb8a4e0 100644 --- a/fs/btrfs/scrub.c +++ b/fs/btrfs/scrub.c @@ -682,11 +682,14 @@ static int scrub_fixup_readpage(u64 inum, u64 offset, u64 root, void *fixup_ctx) struct btrfs_root *local_root; int srcu_index; + fs_info = fixup->root->fs_info; + if (fs_info->sb->s_flags & MS_RDONLY) + return -EROFS; + key.objectid = root; key.type = BTRFS_ROOT_ITEM_KEY; key.offset = (u64)-1; - fs_info = fixup->root->fs_info; srcu_index = srcu_read_lock(&fs_info->subvol_srcu); local_root = btrfs_read_fs_root_no_name(fs_info, &key); -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html