* [PATCH 09/13] f2fs: fix to do sanity check on valid node/block count @ 2019-04-15 7:30 Chao Yu 2019-04-15 7:30 ` [PATCH 10/13] f2fs: fix to do sanity check on valid block count of segment Chao Yu ` (3 more replies) 0 siblings, 4 replies; 9+ messages in thread From: Chao Yu @ 2019-04-15 7:30 UTC (permalink / raw) To: jaegeuk; +Cc: linux-f2fs-devel, linux-kernel, chao, Chao Yu As Jungyeon reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203229 - Overview When mounting the attached crafted image, following errors are reported. Additionally, it hangs on sync after trying to mount it. The image is intentionally fuzzed from a normal f2fs image for testing. Compile options for F2FS are as follows. CONFIG_F2FS_FS=y CONFIG_F2FS_STAT_FS=y CONFIG_F2FS_FS_XATTR=y CONFIG_F2FS_FS_POSIX_ACL=y CONFIG_F2FS_CHECK_FS=y - Reproduces mkdir test mount -t f2fs tmp.img test sync - Kernel message kernel BUG at fs/f2fs/recovery.c:591! RIP: 0010:recover_data+0x12d8/0x1780 Call Trace: f2fs_recover_fsync_data+0x613/0x710 f2fs_fill_super+0x1043/0x1aa0 mount_bdev+0x16d/0x1a0 mount_fs+0x4a/0x170 vfs_kern_mount+0x5d/0x100 do_mount+0x200/0xcf0 ksys_mount+0x79/0xc0 __x64_sys_mount+0x1c/0x20 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 With corrupted image wihch has out-of-range valid node/block count, during recovery, once we failed due to no free space, it will trigger kernel panic. Adding sanity check on valid node/block count in f2fs_sanity_check_ckpt() to detect such condition, so that potential panic can be avoided. Signed-off-by: Chao Yu <yuchao0@huawei.com> --- fs/f2fs/super.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index 2cd78583218a..cbbb1e35070d 100644 --- a/fs/f2fs/super.c +++ b/fs/f2fs/super.c @@ -2592,7 +2592,8 @@ int f2fs_sanity_check_ckpt(struct f2fs_sb_info *sbi) unsigned int log_blocks_per_seg; unsigned int segment_count_main; unsigned int cp_pack_start_sum, cp_payload; - block_t user_block_count; + block_t user_block_count, valid_user_blocks; + block_t avail_node_count, valid_node_count; int i, j; total = le32_to_cpu(raw_super->segment_count); @@ -2627,6 +2628,24 @@ int f2fs_sanity_check_ckpt(struct f2fs_sb_info *sbi) return 1; } + valid_user_blocks = le64_to_cpu(ckpt->valid_block_count); + if (valid_user_blocks > user_block_count) { + f2fs_msg(sbi->sb, KERN_ERR, + "Wrong valid_user_blocks: %u, user_block_count: %u", + valid_user_blocks, user_block_count); + return 1; + } + + valid_node_count = le32_to_cpu(ckpt->valid_node_count); + avail_node_count = sbi->total_node_count - sbi->nquota_files - + F2FS_RESERVED_NODE_NUM; + if (valid_node_count > avail_node_count) { + f2fs_msg(sbi->sb, KERN_ERR, + "Wrong valid_node_count: %u, avail_node_count: %u", + valid_node_count, avail_node_count); + return 1; + } + main_segs = le32_to_cpu(raw_super->segment_count_main); blocks_per_seg = sbi->blocks_per_seg; -- 2.18.0.rc1 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH 10/13] f2fs: fix to do sanity check on valid block count of segment 2019-04-15 7:30 [PATCH 09/13] f2fs: fix to do sanity check on valid node/block count Chao Yu @ 2019-04-15 7:30 ` Chao Yu 2019-04-15 7:30 ` [PATCH 11/13] f2fs: fix to avoid panic in f2fs_inplace_write_data() Chao Yu ` (2 subsequent siblings) 3 siblings, 0 replies; 9+ messages in thread From: Chao Yu @ 2019-04-15 7:30 UTC (permalink / raw) To: jaegeuk; +Cc: linux-f2fs-devel, linux-kernel, chao, Chao Yu As Jungyeon reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203233 - Overview When mounting the attached crafted image and running program, following errors are reported. Additionally, it hangs on sync after running program. The image is intentionally fuzzed from a normal f2fs image for testing. Compile options for F2FS are as follows. CONFIG_F2FS_FS=y CONFIG_F2FS_STAT_FS=y CONFIG_F2FS_FS_XATTR=y CONFIG_F2FS_FS_POSIX_ACL=y CONFIG_F2FS_CHECK_FS=y - Reproduces cc poc_13.c mkdir test mount -t f2fs tmp.img test cp a.out test cd test sudo ./a.out sync - Kernel messages F2FS-fs (sdb): Bitmap was wrongly set, blk:4608 kernel BUG at fs/f2fs/segment.c:2102! RIP: 0010:update_sit_entry+0x394/0x410 Call Trace: f2fs_allocate_data_block+0x16f/0x660 do_write_page+0x62/0x170 f2fs_do_write_node_page+0x33/0xa0 __write_node_page+0x270/0x4e0 f2fs_sync_node_pages+0x5df/0x670 f2fs_write_checkpoint+0x372/0x1400 f2fs_sync_fs+0xa3/0x130 f2fs_do_sync_file+0x1a6/0x810 do_fsync+0x33/0x60 __x64_sys_fsync+0xb/0x10 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 sit.vblocks and sum valid block count in sit.valid_map may be inconsistent, segment w/ zero vblocks will be treated as free segment, while allocating in free segment, we may allocate a free block, if its bitmap is valid previously, it can cause kernel crash due to bitmap verification failure. Anyway, to avoid further serious metadata inconsistence and corruption, it is necessary and worth to detect SIT inconsistence. So let's enable check_block_count() to verify vblocks and valid_map all the time rather than do it only CONFIG_F2FS_CHECK_FS is enabled. Signed-off-by: Chao Yu <yuchao0@huawei.com> --- fs/f2fs/segment.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h index b333ecca6ed6..429007b8036e 100644 --- a/fs/f2fs/segment.h +++ b/fs/f2fs/segment.h @@ -673,7 +673,6 @@ static inline void verify_fio_blkaddr(struct f2fs_io_info *fio) static inline int check_block_count(struct f2fs_sb_info *sbi, int segno, struct f2fs_sit_entry *raw_sit) { -#ifdef CONFIG_F2FS_CHECK_FS bool is_valid = test_bit_le(0, raw_sit->valid_map) ? true : false; int valid_blocks = 0; int cur_pos = 0, next_pos; @@ -700,7 +699,7 @@ static inline int check_block_count(struct f2fs_sb_info *sbi, set_sbi_flag(sbi, SBI_NEED_FSCK); return -EINVAL; } -#endif + /* check segment usage, and check boundary of a given segment number */ if (unlikely(GET_SIT_VBLOCKS(raw_sit) > sbi->blocks_per_seg || segno > TOTAL_SEGS(sbi) - 1)) { -- 2.18.0.rc1 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH 11/13] f2fs: fix to avoid panic in f2fs_inplace_write_data() 2019-04-15 7:30 [PATCH 09/13] f2fs: fix to do sanity check on valid node/block count Chao Yu 2019-04-15 7:30 ` [PATCH 10/13] f2fs: fix to do sanity check on valid block count of segment Chao Yu @ 2019-04-15 7:30 ` Chao Yu 2019-04-15 7:30 ` [PATCH 12/13] f2fs: fix to set FI_UPDATE_WRITE correctly Chao Yu 2019-04-15 7:30 ` [PATCH 13/13] f2fs: don't recovery orphan inode on readonly device Chao Yu 3 siblings, 0 replies; 9+ messages in thread From: Chao Yu @ 2019-04-15 7:30 UTC (permalink / raw) To: jaegeuk; +Cc: linux-f2fs-devel, linux-kernel, chao, Chao Yu As Jungyeon reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203239 - Overview When mounting the attached crafted image and running program, following errors are reported. Additionally, it hangs on sync after running program. The image is intentionally fuzzed from a normal f2fs image for testing. Compile options for F2FS are as follows. CONFIG_F2FS_FS=y CONFIG_F2FS_STAT_FS=y CONFIG_F2FS_FS_XATTR=y CONFIG_F2FS_FS_POSIX_ACL=y CONFIG_F2FS_CHECK_FS=y - Reproduces cc poc_15.c ./run.sh f2fs sync - Kernel messages ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:3162! RIP: 0010:f2fs_inplace_write_data+0x12d/0x160 Call Trace: f2fs_do_write_data_page+0x3c1/0x820 __write_data_page+0x156/0x720 f2fs_write_cache_pages+0x20d/0x460 f2fs_write_data_pages+0x1b4/0x300 do_writepages+0x15/0x60 __filemap_fdatawrite_range+0x7c/0xb0 file_write_and_wait_range+0x2c/0x80 f2fs_do_sync_file+0x102/0x810 do_fsync+0x33/0x60 __x64_sys_fsync+0xb/0x10 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The reason is f2fs_inplace_write_data() will trigger kernel panic due to data block locates in node type segment. To avoid panic, let's just return error code and set SBI_NEED_FSCK to give a hint to fsck for latter repairing. Signed-off-by: Chao Yu <yuchao0@huawei.com> --- fs/f2fs/segment.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c index b59d1c85863b..8388d2abacb5 100644 --- a/fs/f2fs/segment.c +++ b/fs/f2fs/segment.c @@ -3184,13 +3184,18 @@ int f2fs_inplace_write_data(struct f2fs_io_info *fio) { int err; struct f2fs_sb_info *sbi = fio->sbi; + unsigned int segno; fio->new_blkaddr = fio->old_blkaddr; /* i/o temperature is needed for passing down write hints */ __get_segment_type(fio); - f2fs_bug_on(sbi, !IS_DATASEG(get_seg_entry(sbi, - GET_SEGNO(sbi, fio->new_blkaddr))->type)); + segno = GET_SEGNO(sbi, fio->new_blkaddr); + + if (!IS_DATASEG(get_seg_entry(sbi, segno)->type)) { + set_sbi_flag(sbi, SBI_NEED_FSCK); + return -EFAULT; + } stat_inc_inplace_blocks(fio->sbi); -- 2.18.0.rc1 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH 12/13] f2fs: fix to set FI_UPDATE_WRITE correctly 2019-04-15 7:30 [PATCH 09/13] f2fs: fix to do sanity check on valid node/block count Chao Yu 2019-04-15 7:30 ` [PATCH 10/13] f2fs: fix to do sanity check on valid block count of segment Chao Yu 2019-04-15 7:30 ` [PATCH 11/13] f2fs: fix to avoid panic in f2fs_inplace_write_data() Chao Yu @ 2019-04-15 7:30 ` Chao Yu 2019-04-15 7:30 ` [PATCH 13/13] f2fs: don't recovery orphan inode on readonly device Chao Yu 3 siblings, 0 replies; 9+ messages in thread From: Chao Yu @ 2019-04-15 7:30 UTC (permalink / raw) To: jaegeuk; +Cc: linux-f2fs-devel, linux-kernel, chao, Chao Yu This patch fixes to set FI_UPDATE_WRITE only if in-place IO was issued. Signed-off-by: Chao Yu <yuchao0@huawei.com> --- fs/f2fs/data.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index ee5c7962b0f3..f6191b5a0e48 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -1879,9 +1879,10 @@ int f2fs_do_write_data_page(struct f2fs_io_info *fio) true); if (PageWriteback(page)) end_page_writeback(page); + } else { + set_inode_flag(inode, FI_UPDATE_WRITE); } trace_f2fs_do_write_data_page(fio->page, IPU); - set_inode_flag(inode, FI_UPDATE_WRITE); return err; } -- 2.18.0.rc1 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH 13/13] f2fs: don't recovery orphan inode on readonly device 2019-04-15 7:30 [PATCH 09/13] f2fs: fix to do sanity check on valid node/block count Chao Yu ` (2 preceding siblings ...) 2019-04-15 7:30 ` [PATCH 12/13] f2fs: fix to set FI_UPDATE_WRITE correctly Chao Yu @ 2019-04-15 7:30 ` Chao Yu 2019-04-15 8:10 ` [f2fs-dev] " Ju Hyung Park 3 siblings, 1 reply; 9+ messages in thread From: Chao Yu @ 2019-04-15 7:30 UTC (permalink / raw) To: jaegeuk; +Cc: linux-f2fs-devel, linux-kernel, chao, Chao Yu As JuHyung Park reported in mailing list: https://sourceforge.net/p/linux-f2fs/mailman/message/36639787/ generic_make_request: Trying to write to read-only block-device loop0 (partno 0) WARNING: CPU: 0 PID: 23437 at block/blk-core.c:2174 generic_make_request_checks+0x594/0x630 generic_make_request+0x46/0x3d0 submit_bio+0x30/0x110 __submit_merged_bio+0x68/0x390 f2fs_submit_page_write+0x1bb/0x7f0 f2fs_do_write_meta_page+0x7f/0x160 __f2fs_write_meta_page+0x70/0x140 f2fs_sync_meta_pages+0x140/0x250 f2fs_write_checkpoint+0x5c5/0x17b0 f2fs_sync_fs+0x9c/0x110 sync_filesystem+0x66/0x80 f2fs_recover_fsync_data+0x790/0xa30 f2fs_fill_super+0xe4e/0x1980 mount_bdev+0x518/0x610 mount_fs+0x34/0x13f vfs_kern_mount.part.11+0x4f/0x120 do_mount+0x2d1/0xe40 __x64_sys_mount+0xbf/0xe0 do_syscall_64+0x4a/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 print_req_error: I/O error, dev loop0, sector 4096 If block device is readonly, we should never trigger write IO from filesystem layer, but previously, orphan recovery didn't consider such condition, result in triggering above warning, fix it. Reported-by: JuHyung Park <qkrwngud825@gmail.com> Signed-off-by: Chao Yu <yuchao0@huawei.com> --- fs/f2fs/checkpoint.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c index a7ad1b1e5750..90e1bab86269 100644 --- a/fs/f2fs/checkpoint.c +++ b/fs/f2fs/checkpoint.c @@ -674,6 +674,12 @@ int f2fs_recover_orphan_inodes(struct f2fs_sb_info *sbi) if (!is_set_ckpt_flags(sbi, CP_ORPHAN_PRESENT_FLAG)) return 0; + if (bdev_read_only(sbi->sb->s_bdev)) { + f2fs_msg(sbi->sb, KERN_INFO, "write access " + "unavailable, skipping orphan cleanup"); + return 0; + } + if (s_flags & SB_RDONLY) { f2fs_msg(sbi->sb, KERN_INFO, "orphan cleanup on readonly fs"); sbi->sb->s_flags &= ~SB_RDONLY; -- 2.18.0.rc1 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [f2fs-dev] [PATCH 13/13] f2fs: don't recovery orphan inode on readonly device 2019-04-15 7:30 ` [PATCH 13/13] f2fs: don't recovery orphan inode on readonly device Chao Yu @ 2019-04-15 8:10 ` Ju Hyung Park 2019-04-15 8:56 ` Chao Yu 0 siblings, 1 reply; 9+ messages in thread From: Ju Hyung Park @ 2019-04-15 8:10 UTC (permalink / raw) To: Chao Yu; +Cc: Jaegeuk Kim, linux-kernel, linux-f2fs-devel Hi, Thanks for the fix. I'll try this sooner than later. One minor request though, can you change "JuHyung Park <qkrwngud825@gmail.com>" to "Park Ju Hyung <qkrwngud825@gmail.com>"? That's my preference and I'd like to avoid any inconsistencies. One additional question from reviewing the code surrounding it: does it really makes sense to cleanup orphan inodes even when the "ro" mount option is passed? It's an explicit request from the user not to write to the block device/image. Thanks. On Mon, Apr 15, 2019 at 4:31 PM Chao Yu <yuchao0@huawei.com> wrote: > > As JuHyung Park reported in mailing list: > > https://sourceforge.net/p/linux-f2fs/mailman/message/36639787/ > > generic_make_request: Trying to write to read-only block-device loop0 (partno 0) > WARNING: CPU: 0 PID: 23437 at block/blk-core.c:2174 generic_make_request_checks+0x594/0x630 > > generic_make_request+0x46/0x3d0 > submit_bio+0x30/0x110 > __submit_merged_bio+0x68/0x390 > f2fs_submit_page_write+0x1bb/0x7f0 > f2fs_do_write_meta_page+0x7f/0x160 > __f2fs_write_meta_page+0x70/0x140 > f2fs_sync_meta_pages+0x140/0x250 > f2fs_write_checkpoint+0x5c5/0x17b0 > f2fs_sync_fs+0x9c/0x110 > sync_filesystem+0x66/0x80 > f2fs_recover_fsync_data+0x790/0xa30 > f2fs_fill_super+0xe4e/0x1980 > mount_bdev+0x518/0x610 > mount_fs+0x34/0x13f > vfs_kern_mount.part.11+0x4f/0x120 > do_mount+0x2d1/0xe40 > __x64_sys_mount+0xbf/0xe0 > do_syscall_64+0x4a/0xf0 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > print_req_error: I/O error, dev loop0, sector 4096 > > If block device is readonly, we should never trigger write IO from > filesystem layer, but previously, orphan recovery didn't consider > such condition, result in triggering above warning, fix it. > > Reported-by: JuHyung Park <qkrwngud825@gmail.com> > Signed-off-by: Chao Yu <yuchao0@huawei.com> > --- > fs/f2fs/checkpoint.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c > index a7ad1b1e5750..90e1bab86269 100644 > --- a/fs/f2fs/checkpoint.c > +++ b/fs/f2fs/checkpoint.c > @@ -674,6 +674,12 @@ int f2fs_recover_orphan_inodes(struct f2fs_sb_info *sbi) > if (!is_set_ckpt_flags(sbi, CP_ORPHAN_PRESENT_FLAG)) > return 0; > > + if (bdev_read_only(sbi->sb->s_bdev)) { > + f2fs_msg(sbi->sb, KERN_INFO, "write access " > + "unavailable, skipping orphan cleanup"); > + return 0; > + } > + > if (s_flags & SB_RDONLY) { > f2fs_msg(sbi->sb, KERN_INFO, "orphan cleanup on readonly fs"); > sbi->sb->s_flags &= ~SB_RDONLY; > -- > 2.18.0.rc1 > > > > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [f2fs-dev] [PATCH 13/13] f2fs: don't recovery orphan inode on readonly device 2019-04-15 8:10 ` [f2fs-dev] " Ju Hyung Park @ 2019-04-15 8:56 ` Chao Yu 2019-04-15 11:04 ` Ju Hyung Park 0 siblings, 1 reply; 9+ messages in thread From: Chao Yu @ 2019-04-15 8:56 UTC (permalink / raw) To: Ju Hyung Park; +Cc: Jaegeuk Kim, linux-kernel, linux-f2fs-devel On 2019/4/15 16:10, Ju Hyung Park wrote: > Hi, > > Thanks for the fix. I'll try this sooner than later. > > One minor request though, can you change > "JuHyung Park <qkrwngud825@gmail.com>" > to > "Park Ju Hyung <qkrwngud825@gmail.com>"? > > That's my preference and I'd like to avoid any inconsistencies. Sure, will update it in next version. :) > > One additional question from reviewing the code surrounding it: > does it really makes sense to cleanup orphan inodes even when the "ro" > mount option is passed? > It's an explicit request from the user not to write to the block device/image. Now, f2fs follows the rule that ext4 kept, you can check codes in ext4_orphan_cleanup() if (bdev_read_only(sb->s_bdev)) { ext4_msg(sb, KERN_ERR, "write access " "unavailable, skipping orphan cleanup"); return; } ... if (s_flags & SB_RDONLY) { ext4_msg(sb, KERN_INFO, "orphan cleanup on readonly fs"); sb->s_flags &= ~SB_RDONLY; } There are two points in above codes: - if block device is readonly, filesystem should not execute any recovery flow which can trigger write IO. - if filesystem was mounted as readonly one, and recovery is needed, it will ignore readonly flag and update data in device for journal recovery during mount. So IMO, readonly mountoption sematics is only try to restrict data/meta update behavior that is triggered by user from mountpoint, but filesystem still can do any updates on a writable device if it needs, mostly like recovery flow. Anyway, if you want to limit any updates on block device, making it readonly will be a good choice. :) Thanks, > > Thanks. > > On Mon, Apr 15, 2019 at 4:31 PM Chao Yu <yuchao0@huawei.com> wrote: >> >> As JuHyung Park reported in mailing list: >> >> https://sourceforge.net/p/linux-f2fs/mailman/message/36639787/ >> >> generic_make_request: Trying to write to read-only block-device loop0 (partno 0) >> WARNING: CPU: 0 PID: 23437 at block/blk-core.c:2174 generic_make_request_checks+0x594/0x630 >> >> generic_make_request+0x46/0x3d0 >> submit_bio+0x30/0x110 >> __submit_merged_bio+0x68/0x390 >> f2fs_submit_page_write+0x1bb/0x7f0 >> f2fs_do_write_meta_page+0x7f/0x160 >> __f2fs_write_meta_page+0x70/0x140 >> f2fs_sync_meta_pages+0x140/0x250 >> f2fs_write_checkpoint+0x5c5/0x17b0 >> f2fs_sync_fs+0x9c/0x110 >> sync_filesystem+0x66/0x80 >> f2fs_recover_fsync_data+0x790/0xa30 >> f2fs_fill_super+0xe4e/0x1980 >> mount_bdev+0x518/0x610 >> mount_fs+0x34/0x13f >> vfs_kern_mount.part.11+0x4f/0x120 >> do_mount+0x2d1/0xe40 >> __x64_sys_mount+0xbf/0xe0 >> do_syscall_64+0x4a/0xf0 >> entry_SYSCALL_64_after_hwframe+0x44/0xa9 >> >> print_req_error: I/O error, dev loop0, sector 4096 >> >> If block device is readonly, we should never trigger write IO from >> filesystem layer, but previously, orphan recovery didn't consider >> such condition, result in triggering above warning, fix it. >> >> Reported-by: JuHyung Park <qkrwngud825@gmail.com> >> Signed-off-by: Chao Yu <yuchao0@huawei.com> >> --- >> fs/f2fs/checkpoint.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c >> index a7ad1b1e5750..90e1bab86269 100644 >> --- a/fs/f2fs/checkpoint.c >> +++ b/fs/f2fs/checkpoint.c >> @@ -674,6 +674,12 @@ int f2fs_recover_orphan_inodes(struct f2fs_sb_info *sbi) >> if (!is_set_ckpt_flags(sbi, CP_ORPHAN_PRESENT_FLAG)) >> return 0; >> >> + if (bdev_read_only(sbi->sb->s_bdev)) { >> + f2fs_msg(sbi->sb, KERN_INFO, "write access " >> + "unavailable, skipping orphan cleanup"); >> + return 0; >> + } >> + >> if (s_flags & SB_RDONLY) { >> f2fs_msg(sbi->sb, KERN_INFO, "orphan cleanup on readonly fs"); >> sbi->sb->s_flags &= ~SB_RDONLY; >> -- >> 2.18.0.rc1 >> >> >> >> _______________________________________________ >> Linux-f2fs-devel mailing list >> Linux-f2fs-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > . > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [f2fs-dev] [PATCH 13/13] f2fs: don't recovery orphan inode on readonly device 2019-04-15 8:56 ` Chao Yu @ 2019-04-15 11:04 ` Ju Hyung Park 2019-04-15 11:31 ` Chao Yu 0 siblings, 1 reply; 9+ messages in thread From: Ju Hyung Park @ 2019-04-15 11:04 UTC (permalink / raw) To: Chao Yu; +Cc: Jaegeuk Kim, linux-kernel, linux-f2fs-devel Thanks for the explanation. And yes, this patch fixed it, the kernel log is now clean. Thanks! [ 22.506553] F2FS-fs (loop0): write access unavailable, skipping orphan cleanup [ 22.506555] F2FS-fs (loop0): recover fsync data on readonly fs [ 22.506556] F2FS-fs (loop0): quota file may be corrupted, skip loading it [ 22.507015] F2FS-fs (loop0): Mounted with checkpoint version = 26e7ba3e On Mon, Apr 15, 2019 at 5:57 PM Chao Yu <yuchao0@huawei.com> wrote: > > On 2019/4/15 16:10, Ju Hyung Park wrote: > > Hi, > > > > Thanks for the fix. I'll try this sooner than later. > > > > One minor request though, can you change > > "JuHyung Park <qkrwngud825@gmail.com>" > > to > > "Park Ju Hyung <qkrwngud825@gmail.com>"? > > > > That's my preference and I'd like to avoid any inconsistencies. > > Sure, will update it in next version. :) > > > > > One additional question from reviewing the code surrounding it: > > does it really makes sense to cleanup orphan inodes even when the "ro" > > mount option is passed? > > It's an explicit request from the user not to write to the block device/image. > > Now, f2fs follows the rule that ext4 kept, you can check codes in > ext4_orphan_cleanup() > > if (bdev_read_only(sb->s_bdev)) { > ext4_msg(sb, KERN_ERR, "write access " > "unavailable, skipping orphan cleanup"); > return; > } > ... > if (s_flags & SB_RDONLY) { > ext4_msg(sb, KERN_INFO, "orphan cleanup on readonly fs"); > sb->s_flags &= ~SB_RDONLY; > } > > There are two points in above codes: > - if block device is readonly, filesystem should not execute any recovery flow > which can trigger write IO. > - if filesystem was mounted as readonly one, and recovery is needed, it will > ignore readonly flag and update data in device for journal recovery during mount. > > So IMO, readonly mountoption sematics is only try to restrict data/meta update > behavior that is triggered by user from mountpoint, but filesystem still can do > any updates on a writable device if it needs, mostly like recovery flow. > > Anyway, if you want to limit any updates on block device, making it readonly > will be a good choice. :) > > Thanks, > > > > > Thanks. > > > > On Mon, Apr 15, 2019 at 4:31 PM Chao Yu <yuchao0@huawei.com> wrote: > >> > >> As JuHyung Park reported in mailing list: > >> > >> https://sourceforge.net/p/linux-f2fs/mailman/message/36639787/ > >> > >> generic_make_request: Trying to write to read-only block-device loop0 (partno 0) > >> WARNING: CPU: 0 PID: 23437 at block/blk-core.c:2174 generic_make_request_checks+0x594/0x630 > >> > >> generic_make_request+0x46/0x3d0 > >> submit_bio+0x30/0x110 > >> __submit_merged_bio+0x68/0x390 > >> f2fs_submit_page_write+0x1bb/0x7f0 > >> f2fs_do_write_meta_page+0x7f/0x160 > >> __f2fs_write_meta_page+0x70/0x140 > >> f2fs_sync_meta_pages+0x140/0x250 > >> f2fs_write_checkpoint+0x5c5/0x17b0 > >> f2fs_sync_fs+0x9c/0x110 > >> sync_filesystem+0x66/0x80 > >> f2fs_recover_fsync_data+0x790/0xa30 > >> f2fs_fill_super+0xe4e/0x1980 > >> mount_bdev+0x518/0x610 > >> mount_fs+0x34/0x13f > >> vfs_kern_mount.part.11+0x4f/0x120 > >> do_mount+0x2d1/0xe40 > >> __x64_sys_mount+0xbf/0xe0 > >> do_syscall_64+0x4a/0xf0 > >> entry_SYSCALL_64_after_hwframe+0x44/0xa9 > >> > >> print_req_error: I/O error, dev loop0, sector 4096 > >> > >> If block device is readonly, we should never trigger write IO from > >> filesystem layer, but previously, orphan recovery didn't consider > >> such condition, result in triggering above warning, fix it. > >> > >> Reported-by: JuHyung Park <qkrwngud825@gmail.com> > >> Signed-off-by: Chao Yu <yuchao0@huawei.com> > >> --- > >> fs/f2fs/checkpoint.c | 6 ++++++ > >> 1 file changed, 6 insertions(+) > >> > >> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c > >> index a7ad1b1e5750..90e1bab86269 100644 > >> --- a/fs/f2fs/checkpoint.c > >> +++ b/fs/f2fs/checkpoint.c > >> @@ -674,6 +674,12 @@ int f2fs_recover_orphan_inodes(struct f2fs_sb_info *sbi) > >> if (!is_set_ckpt_flags(sbi, CP_ORPHAN_PRESENT_FLAG)) > >> return 0; > >> > >> + if (bdev_read_only(sbi->sb->s_bdev)) { > >> + f2fs_msg(sbi->sb, KERN_INFO, "write access " > >> + "unavailable, skipping orphan cleanup"); > >> + return 0; > >> + } > >> + > >> if (s_flags & SB_RDONLY) { > >> f2fs_msg(sbi->sb, KERN_INFO, "orphan cleanup on readonly fs"); > >> sbi->sb->s_flags &= ~SB_RDONLY; > >> -- > >> 2.18.0.rc1 > >> > >> > >> > >> _______________________________________________ > >> Linux-f2fs-devel mailing list > >> Linux-f2fs-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > > . > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [f2fs-dev] [PATCH 13/13] f2fs: don't recovery orphan inode on readonly device 2019-04-15 11:04 ` Ju Hyung Park @ 2019-04-15 11:31 ` Chao Yu 0 siblings, 0 replies; 9+ messages in thread From: Chao Yu @ 2019-04-15 11:31 UTC (permalink / raw) To: Ju Hyung Park; +Cc: Jaegeuk Kim, linux-kernel, linux-f2fs-devel On 2019/4/15 19:04, Ju Hyung Park wrote: > Thanks for the explanation. > > And yes, this patch fixed it, the kernel log is now clean. Thanks for the quick test. :) Thanks, > > Thanks! > > [ 22.506553] F2FS-fs (loop0): write access unavailable, skipping > orphan cleanup > [ 22.506555] F2FS-fs (loop0): recover fsync data on readonly fs > [ 22.506556] F2FS-fs (loop0): quota file may be corrupted, skip loading it > [ 22.507015] F2FS-fs (loop0): Mounted with checkpoint version = 26e7ba3e > > On Mon, Apr 15, 2019 at 5:57 PM Chao Yu <yuchao0@huawei.com> wrote: >> >> On 2019/4/15 16:10, Ju Hyung Park wrote: >>> Hi, >>> >>> Thanks for the fix. I'll try this sooner than later. >>> >>> One minor request though, can you change >>> "JuHyung Park <qkrwngud825@gmail.com>" >>> to >>> "Park Ju Hyung <qkrwngud825@gmail.com>"? >>> >>> That's my preference and I'd like to avoid any inconsistencies. >> >> Sure, will update it in next version. :) >> >>> >>> One additional question from reviewing the code surrounding it: >>> does it really makes sense to cleanup orphan inodes even when the "ro" >>> mount option is passed? >>> It's an explicit request from the user not to write to the block device/image. >> >> Now, f2fs follows the rule that ext4 kept, you can check codes in >> ext4_orphan_cleanup() >> >> if (bdev_read_only(sb->s_bdev)) { >> ext4_msg(sb, KERN_ERR, "write access " >> "unavailable, skipping orphan cleanup"); >> return; >> } >> ... >> if (s_flags & SB_RDONLY) { >> ext4_msg(sb, KERN_INFO, "orphan cleanup on readonly fs"); >> sb->s_flags &= ~SB_RDONLY; >> } >> >> There are two points in above codes: >> - if block device is readonly, filesystem should not execute any recovery flow >> which can trigger write IO. >> - if filesystem was mounted as readonly one, and recovery is needed, it will >> ignore readonly flag and update data in device for journal recovery during mount. >> >> So IMO, readonly mountoption sematics is only try to restrict data/meta update >> behavior that is triggered by user from mountpoint, but filesystem still can do >> any updates on a writable device if it needs, mostly like recovery flow. >> >> Anyway, if you want to limit any updates on block device, making it readonly >> will be a good choice. :) >> >> Thanks, >> >>> >>> Thanks. >>> >>> On Mon, Apr 15, 2019 at 4:31 PM Chao Yu <yuchao0@huawei.com> wrote: >>>> >>>> As JuHyung Park reported in mailing list: >>>> >>>> https://sourceforge.net/p/linux-f2fs/mailman/message/36639787/ >>>> >>>> generic_make_request: Trying to write to read-only block-device loop0 (partno 0) >>>> WARNING: CPU: 0 PID: 23437 at block/blk-core.c:2174 generic_make_request_checks+0x594/0x630 >>>> >>>> generic_make_request+0x46/0x3d0 >>>> submit_bio+0x30/0x110 >>>> __submit_merged_bio+0x68/0x390 >>>> f2fs_submit_page_write+0x1bb/0x7f0 >>>> f2fs_do_write_meta_page+0x7f/0x160 >>>> __f2fs_write_meta_page+0x70/0x140 >>>> f2fs_sync_meta_pages+0x140/0x250 >>>> f2fs_write_checkpoint+0x5c5/0x17b0 >>>> f2fs_sync_fs+0x9c/0x110 >>>> sync_filesystem+0x66/0x80 >>>> f2fs_recover_fsync_data+0x790/0xa30 >>>> f2fs_fill_super+0xe4e/0x1980 >>>> mount_bdev+0x518/0x610 >>>> mount_fs+0x34/0x13f >>>> vfs_kern_mount.part.11+0x4f/0x120 >>>> do_mount+0x2d1/0xe40 >>>> __x64_sys_mount+0xbf/0xe0 >>>> do_syscall_64+0x4a/0xf0 >>>> entry_SYSCALL_64_after_hwframe+0x44/0xa9 >>>> >>>> print_req_error: I/O error, dev loop0, sector 4096 >>>> >>>> If block device is readonly, we should never trigger write IO from >>>> filesystem layer, but previously, orphan recovery didn't consider >>>> such condition, result in triggering above warning, fix it. >>>> >>>> Reported-by: JuHyung Park <qkrwngud825@gmail.com> >>>> Signed-off-by: Chao Yu <yuchao0@huawei.com> >>>> --- >>>> fs/f2fs/checkpoint.c | 6 ++++++ >>>> 1 file changed, 6 insertions(+) >>>> >>>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c >>>> index a7ad1b1e5750..90e1bab86269 100644 >>>> --- a/fs/f2fs/checkpoint.c >>>> +++ b/fs/f2fs/checkpoint.c >>>> @@ -674,6 +674,12 @@ int f2fs_recover_orphan_inodes(struct f2fs_sb_info *sbi) >>>> if (!is_set_ckpt_flags(sbi, CP_ORPHAN_PRESENT_FLAG)) >>>> return 0; >>>> >>>> + if (bdev_read_only(sbi->sb->s_bdev)) { >>>> + f2fs_msg(sbi->sb, KERN_INFO, "write access " >>>> + "unavailable, skipping orphan cleanup"); >>>> + return 0; >>>> + } >>>> + >>>> if (s_flags & SB_RDONLY) { >>>> f2fs_msg(sbi->sb, KERN_INFO, "orphan cleanup on readonly fs"); >>>> sbi->sb->s_flags &= ~SB_RDONLY; >>>> -- >>>> 2.18.0.rc1 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Linux-f2fs-devel mailing list >>>> Linux-f2fs-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel >>> . >>> > . > ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-04-15 11:31 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-04-15 7:30 [PATCH 09/13] f2fs: fix to do sanity check on valid node/block count Chao Yu 2019-04-15 7:30 ` [PATCH 10/13] f2fs: fix to do sanity check on valid block count of segment Chao Yu 2019-04-15 7:30 ` [PATCH 11/13] f2fs: fix to avoid panic in f2fs_inplace_write_data() Chao Yu 2019-04-15 7:30 ` [PATCH 12/13] f2fs: fix to set FI_UPDATE_WRITE correctly Chao Yu 2019-04-15 7:30 ` [PATCH 13/13] f2fs: don't recovery orphan inode on readonly device Chao Yu 2019-04-15 8:10 ` [f2fs-dev] " Ju Hyung Park 2019-04-15 8:56 ` Chao Yu 2019-04-15 11:04 ` Ju Hyung Park 2019-04-15 11:31 ` Chao Yu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).