hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5ZHOZ
CVE: NA

--------------------------------

There's issue as follows when do test with memory fault injection:
[localhost]# fsck.ext4 -a image
image: clean, 45595/655360 files, 466841/2621440 blocks
[localhost]# fsck.ext4 -fn image
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -(1457230--1457256)
Fix? no

image: ********** WARNING: Filesystem still has errors **********

image: 45595/655360 files (12.4% non-contiguous), 466841/2621440 blocks

Inject context:
 -----------------------------------------------------------
 Inject function:kmem_cache_alloc (pid:177858) (return: 0)
 Calltrace Context:
 mem_cache_allock+0x73/0xcc
 ext4_mb_new_blocks+0x32e/0x540 [ext4]
 ext4_new_meta_blocks+0xc4/0x110 [ext4]
 ext4_ext_grow_indepth+0x68/0x250 [ext4]
 ext4_ext_create_new_leaf+0xc5/0x120 [ext4]
 ext4_ext_insert_extent+0x1bf/0x670 [ext4]
 ext4_split_extent_at+0x212/0x530 [ext4]
 ext4_split_extent+0x13a/0x1a0 [ext4]
 ext4_ext_handle_unwritten_extents+0x13d/0x240 [ext4]
 ext4_ext_map_blocks+0x459/0x8f0 [ext4]
 ext4_map_blocks+0x18e/0x5a0 [ext4]
 ext4_iomap_alloc+0xb0/0x1b0 [ext4]
 ext4_iomap_begin+0xb0/0x130 [ext4]
 iomap_apply+0x95/0x2e0
 __iomap_dio_rw+0x1cc/0x4b0
 iomap_dio_rw+0xe/0x40
 ext4_dio_write_iter+0x1a9/0x390 [ext4]
 new_sync_write+0x113/0x1b0
 vfs_write+0x1b7/0x250
 ksys_write+0x5f/0xe0
 do_syscall_64+0x33/0x40
 entry_SYSCALL_64_after_hwframe+0x61/0xc6

Compare extent change in journal:
Start:
ee_block      ee_len        ee_start
75            32798         1457227  -> unwritten len=30
308           12            434489
355           5             442492
=>
ee_block      ee_len        ee_start
11            2             951584
74            32769         951647   -> unwritten  len=1
75            32771         1457227  -> unwritten  len=3
211           15            960906
308           12            434489
355           5             442492

Acctually, above issue can repaired by 'fsck -fa'. But file system is 'clean',
'fsck' will not do deep repair.
Obviously, final lost 27 blocks. Above issue may happens as follows:
ext4_split_extent_at
...
err = ext4_ext_insert_extent(handle, inode, ppath, &newex, flags); -> return -ENOMEM
if (err != -ENOSPC && err != -EDQUOT）
	goto out; -> goto 'out' will not fix extent length, will
...
fix_extent_len:
        ex->ee_len = orig_ex.ee_len;
        /*
         * Ignore ext4_ext_dirty return value since we are already in error path
         * and err is a non-zero error code.
         */
        ext4_ext_dirty(handle, inode, path + path->p_depth);
        return err;
out:
        ext4_ext_show_leaf(inode, path);
        return err;
If 'ext4_ext_insert_extent' return '-ENOMEM' which will not fix 'ex->ee_len' by
old length. 'ext4_ext_insert_extent' will trigger extent tree merge, fix like
'ex->ee_len = orig_ex.ee_len' may lead to new issues.
To solve above issue, record error messages when 'ext4_ext_insert_extent' return
'err' not equal '(-ENOSPC && -EDQUOT)'. If filesysten is mounted with 'errors=continue'
as filesystem is not clean 'fsck' will repair issue. If filesystem is mounted with
'errors=remount-ro' filesystem will be remounted by read-only.
Signed-off-by: NYe Bin <yebin10@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>