Re: [PATCH 4.19] ext4: fix race condition between ext4_ioctl_setflags and ext4_fiemap

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



在 2022/7/19 19:26, Greg KH 写道:
On Sat, Jul 16, 2022 at 10:33:30AM +0800, Baokun Li wrote:
在 2022/7/15 22:10, Greg KH 写道:
On Fri, Jul 15, 2022 at 10:39:28AM +0800, Baokun Li wrote:
This patch and problem analysis is based on v4.19 LTS.
The d3b6f23f7167("ext4: move ext4_fiemap to use iomap framework") patch
is incorporated in v5.7-rc1. This patch avoids this problem by switching
to iomap in ext4_fiemap.

Hulk Robot reported a BUG on stable 4.19.252:
==================================================================
kernel BUG at fs/ext4/extents_status.c:762!
invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 7 PID: 2845 Comm: syz-executor Not tainted 4.19.252 #46
RIP: 0010:ext4_es_cache_extent+0x30e/0x370
[...]
Call Trace:
   ext4_cache_extents+0x238/0x2f0
   ext4_find_extent+0x785/0xa40
   ext4_fiemap+0x36d/0xe90
   do_vfs_ioctl+0x6af/0x1200
[...]
==================================================================

Above issue may happen as follows:
-------------------------------------
             cpu1		    cpu2
_____________________|_____________________
do_vfs_ioctl
   ext4_ioctl
    ext4_ioctl_setflags
     ext4_ind_migrate
                          do_vfs_ioctl
                           ioctl_fiemap
                            ext4_fiemap
                             ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS)
                             ext4_fill_fiemap_extents
      down_write(&EXT4_I(inode)->i_data_sem);
      ext4_ext_check_inode
      ext4_clear_inode_flag(inode, EXT4_INODE_EXTENTS)
      memset(ei->i_data, 0, sizeof(ei->i_data))
      up_write(&EXT4_I(inode)->i_data_sem);
                              down_read(&EXT4_I(inode)->i_data_sem);
                              ext4_find_extent
                               ext4_cache_extents
                                ext4_es_cache_extent
                                 BUG_ON(end < lblk)

We can easily reproduce this problem with the syzkaller testcase:
```
02:37:07 executing program 3:
r0 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x26e1, 0x0)
ioctl$FS_IOC_FSSETXATTR(r0, 0x40086602, &(0x7f0000000080)={0x17e})
mkdirat(0xffffffffffffff9c, &(0x7f00000000c0)='./file1\x00', 0x1ff)
r1 = openat(0xffffffffffffff9c, &(0x7f0000000100)='./file1\x00', 0x0, 0x0)
ioctl$FS_IOC_FIEMAP(r1, 0xc020660b, &(0x7f0000000180)={0x0, 0x1, 0x0, 0xef3, 0x6, []}) (async, rerun: 32)
ioctl$FS_IOC_FSSETXATTR(r1, 0x40086602, &(0x7f0000000140)={0x17e}) (rerun: 32)
```

To solve this issue, we use __generic_block_fiemap() instead of
generic_block_fiemap() and add inode_lock_shared to avoid race condition.

Reported-by: Hulk Robot <hulkci@xxxxxxxxxx>
Signed-off-by: Baokun Li <libaokun1@xxxxxxxxxx>
---
   fs/ext4/extents.c | 15 +++++++++++----
   1 file changed, 11 insertions(+), 4 deletions(-)
What is the git commit id of this change in Linus's tree?

If it is not in Linus's tree, why not?

confused,

greg k-h
.
This patch does not exist in the Linus' tree.

This problem persists until the patch d3b6f23f7167("ext4: move ext4_fiemap
to use iomap framework") is incorporated in v5.7-rc1.
Then why not ask for that change to be added instead?

thanks,

greg k-h
.

If we want to switch to the iomap framework, we need to analyze and integrate about 60 patches.

The workload may be greater than that of solving this problem alone.

Thank you!

Thanks a lot!

--
With Best Regards,
Baokun Li


--
With Best Regards,
Baokun Li




[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux