Description
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode w/ "mode=lfs" mount option, generic/299 will cause system panic as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2835! Call Trace: <TASK> f2fs_allocate_data_block+0x6f4/0xc50 f2fs_map_blocks+0x970/0x1550 f2fs_iomap_begin+0xb2/0x1e0 iomap_iter+0x1d6/0x430 __iomap_dio_rw+0x208/0x9a0 f2fs_file_write_iter+0x6b3/0xfa0 aio_write+0x15d/0x2e0 io_submit_one+0x55e/0xab0 __x64_sys_io_submit+0xa5/0x230 do_syscall_64+0x84/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0010:new_curseg+0x70f/0x720 The root cause of we run out-of-space is: in f2fs_map_blocks(), f2fs may trigger foreground gc only if it allocates any physical block, it will be a little bit later when there is multiple threads writing data w/ aio/dio/bufio method in parallel, since we always use OPU in lfs mode, so f2fs_map_blocks() does block allocations aggressively. In order to fix this issue, let's give a chance to trigger foreground gc in prior to block allocation in f2fs_map_blocks().
Product status
36abef4e796d382e81a0c2d21ea5327481dd7154 before f289690f50a01c3e085d87853392d5b7436a4cee
36abef4e796d382e81a0c2d21ea5327481dd7154 before 82765ce5c7a56f9309ee45328e763610eaf11253
36abef4e796d382e81a0c2d21ea5327481dd7154 before 264ede8a52f18647ed5bb5f2bd9bf54f556ad8f5
36abef4e796d382e81a0c2d21ea5327481dd7154 before 385e64a0744584397b4b52b27c96703516f39968
36abef4e796d382e81a0c2d21ea5327481dd7154 before 1005a3ca28e90c7a64fa43023f866b960a60f791
4.8
Any version before 4.8
6.6.102
6.12.42
6.15.10
6.16.1
6.17
References
git.kernel.org/...c/f289690f50a01c3e085d87853392d5b7436a4cee
git.kernel.org/...c/82765ce5c7a56f9309ee45328e763610eaf11253
git.kernel.org/...c/264ede8a52f18647ed5bb5f2bd9bf54f556ad8f5
git.kernel.org/...c/385e64a0744584397b4b52b27c96703516f39968
git.kernel.org/...c/1005a3ca28e90c7a64fa43023f866b960a60f791
