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
