fs/f2fs/segment.c | 1 + 1 file changed, 1 insertion(+)
mkdir /mnt/test/comp
f2fs_io setflags compression /mnt/test/comp
dd if=/dev/zero of=/mnt/test/comp/testfile bs=16k count=1
truncate --size 13 /mnt/test/comp/testfile
In the above scenario, we can get a BUG_ON.
kernel BUG at fs/f2fs/segment.c:3589!
Call Trace:
do_write_page+0x78/0x390 [f2fs]
f2fs_outplace_write_data+0x62/0xb0 [f2fs]
f2fs_do_write_data_page+0x275/0x740 [f2fs]
f2fs_write_single_data_page+0x1dc/0x8f0 [f2fs]
f2fs_write_multi_pages+0x1e5/0xae0 [f2fs]
f2fs_write_cache_pages+0xab1/0xc60 [f2fs]
f2fs_write_data_pages+0x2d8/0x330 [f2fs]
do_writepages+0xcf/0x270
__writeback_single_inode+0x44/0x350
writeback_sb_inodes+0x242/0x530
__writeback_inodes_wb+0x54/0xf0
wb_writeback+0x192/0x310
wb_workfn+0x30d/0x400
The reason is we gave CURSEG_ALL_DATA_ATGC to COMPR_ADDR where the
page was set the gcing flag by set_cluster_dirty().
Cc: stable@vger.kernel.org
Fixes: 4961acdd65c9 ("f2fs: fix to tag gcing flag on page during block migration")
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
---
fs/f2fs/segment.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 6e8a4b332ad5..ce2300391031 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -3484,6 +3484,7 @@ static int __get_segment_type_6(struct f2fs_io_info *fio)
if (fio->sbi->am.atgc_enabled &&
(fio->io_type == FS_DATA_IO) &&
(fio->sbi->gc_mode != GC_URGENT_HIGH) &&
+ __is_valid_data_blkaddr(fio->old_blkaddr) &&
!is_inode_flag_set(inode, FI_OPU_WRITE))
return CURSEG_ALL_DATA_ATGC;
else
--
2.45.2.627.g7a2c4fd464-goog
On 2024/6/18 10:23, Jaegeuk Kim wrote:
> mkdir /mnt/test/comp
> f2fs_io setflags compression /mnt/test/comp
> dd if=/dev/zero of=/mnt/test/comp/testfile bs=16k count=1
> truncate --size 13 /mnt/test/comp/testfile
>
> In the above scenario, we can get a BUG_ON.
> kernel BUG at fs/f2fs/segment.c:3589!
> Call Trace:
> do_write_page+0x78/0x390 [f2fs]
> f2fs_outplace_write_data+0x62/0xb0 [f2fs]
> f2fs_do_write_data_page+0x275/0x740 [f2fs]
> f2fs_write_single_data_page+0x1dc/0x8f0 [f2fs]
> f2fs_write_multi_pages+0x1e5/0xae0 [f2fs]
> f2fs_write_cache_pages+0xab1/0xc60 [f2fs]
> f2fs_write_data_pages+0x2d8/0x330 [f2fs]
> do_writepages+0xcf/0x270
> __writeback_single_inode+0x44/0x350
> writeback_sb_inodes+0x242/0x530
> __writeback_inodes_wb+0x54/0xf0
> wb_writeback+0x192/0x310
> wb_workfn+0x30d/0x400
>
> The reason is we gave CURSEG_ALL_DATA_ATGC to COMPR_ADDR where the
> page was set the gcing flag by set_cluster_dirty().
>
> Cc: stable@vger.kernel.org
> Fixes: 4961acdd65c9 ("f2fs: fix to tag gcing flag on page during block migration")
> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Reviewed-by: Chao Yu <chao@kernel.org>
Thanks,
On 06/19/2024, Chao Yu wrote:
> On 2024/6/18 10:23, Jaegeuk Kim wrote:
> > mkdir /mnt/test/comp
> > f2fs_io setflags compression /mnt/test/comp
> > dd if=/dev/zero of=/mnt/test/comp/testfile bs=16k count=1
> > truncate --size 13 /mnt/test/comp/testfile
> >
> > In the above scenario, we can get a BUG_ON.
> > kernel BUG at fs/f2fs/segment.c:3589!
> > Call Trace:
> > do_write_page+0x78/0x390 [f2fs]
> > f2fs_outplace_write_data+0x62/0xb0 [f2fs]
> > f2fs_do_write_data_page+0x275/0x740 [f2fs]
> > f2fs_write_single_data_page+0x1dc/0x8f0 [f2fs]
> > f2fs_write_multi_pages+0x1e5/0xae0 [f2fs]
> > f2fs_write_cache_pages+0xab1/0xc60 [f2fs]
> > f2fs_write_data_pages+0x2d8/0x330 [f2fs]
> > do_writepages+0xcf/0x270
> > __writeback_single_inode+0x44/0x350
> > writeback_sb_inodes+0x242/0x530
> > __writeback_inodes_wb+0x54/0xf0
> > wb_writeback+0x192/0x310
> > wb_workfn+0x30d/0x400
> >
> > The reason is we gave CURSEG_ALL_DATA_ATGC to COMPR_ADDR where the
> > page was set the gcing flag by set_cluster_dirty().
> >
> > Cc: stable@vger.kernel.org
> > Fixes: 4961acdd65c9 ("f2fs: fix to tag gcing flag on page during block migration")
> > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
>
> Reviewed-by: Chao Yu <chao@kernel.org>
Hi Jaegeuk,
I've been running my personal Pixel 8a device with this change for the past
3 days and haven't hit any kernal panics since applying it. Feel free to
include:
Tested-by: Will McVicker <willmcvicker@google.com>
Thanks,
Will
© 2016 - 2025 Red Hat, Inc.