- 09 11月, 2022 22 次提交
-
-
由 Chen Jun 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5I72Q CVE: NA -------------------------------- Now, sp_mapping.flag is only used to distinguish sp_mapping types. So, 'type' are more suitable. Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Chen Jun 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5I72Q CVE: NA -------------------------------- "TASK_SIZE - MMAP_SHARE_POOL_DVPP_SIZE" is puzzling. MMAP_SHARE_POOL_START = MMAP_SHARE_POOL_END - MMAP_SHARE_POOL_SIZE and MMAP_SHARE_POOL_16G_START = MMAP_SHARE_POOL_END - MMAP_SHARE_POOL_DVPP_SIZE make the memory layout not unintuitive. Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
-
由 Zhou Guanghui 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5PIA6 CVE: NA -------------------------------- Use get_task_mm to avoid the mm being released when the information in mm_struct is used. Signed-off-by: NZhou Guanghui <zhouguanghui1@huawei.com>
-
由 Zhou Guanghui 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5PIA4 CVE: NA -------------------------------- The maximum value of spg_id is checked to ensure that the value of spg_id is within the valid range: SPG_ID_DEFAULT or [SPG_ID_MIN SPG_ID_AUTO) Signed-off-by: NZhou Guanghui <zhouguanghui1@huawei.com>
-
由 Zhou Guanghui 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5PIA0 CVE: NA -------------------------------- The spa is used during the update_mem_usage. In this case, the spa has been released in the case of concurrency (mg_sp_unshare). Signed-off-by: NZhou Guanghui <zhouguanghui1@huawei.com>
-
由 Zhou Guanghui 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5PIA2 CVE: NA -------------------------------- When a process is added to a group, mm->mm_users increases by one. When a process is deleted from a group, mm->mm_users decreases by one. It is not possible to reduce to 0 because this function is preceded by get_task_mm. Signed-off-by: NZhou Guanghui <zhouguanghui1@huawei.com>
-
由 Wang Wensheng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5PD4P CVE: NA -------------------------------- [ 2058.802818][ T290] BUG: KASAN: use-after-free in get_process_sp_res+0x70/0x134 [ 2058.810194][ T290] Read of size 8 at addr ffff00088dc6ab28 by task test_debug_loop/290 [ 2058.820520][ T290] CPU: 5 PID: 290 Comm: test_debug_loop Tainted: G W OE 5.10.0+ #2 [ 2058.829377][ T290] Hardware name: EVB(EP) (DT) [ 2058.833982][ T290] Call trace: [ 2058.837217][ T290] dump_backtrace+0x0/0x30c [ 2058.841660][ T290] show_stack+0x20/0x30 [ 2058.845758][ T290] dump_stack+0x120/0x1b0 [ 2058.850028][ T290] print_address_description.constprop.0+0x2c/0x1fc [ 2058.856555][ T290] __kasan_report+0xfc/0x160 [ 2058.861086][ T290] kasan_report+0x44/0xb0 [ 2058.865356][ T290] __asan_load8+0x94/0xd0 [ 2058.869623][ T290] get_process_sp_res+0x70/0x134 [ 2058.874501][ T290] proc_usage_show+0x1ac/0x304 [ 2058.879208][ T290] seq_read_iter+0x254/0x750 [ 2058.883728][ T290] proc_reg_read_iter+0x100/0x140 [ 2058.888689][ T290] new_sync_read+0x1cc/0x2c0 [ 2058.893215][ T290] vfs_read+0x1f4/0x250 [ 2058.897304][ T290] ksys_read+0xcc/0x170 [ 2058.901399][ T290] __arm64_sys_read+0x4c/0x60 [ 2058.906016][ T290] el0_svc_common.constprop.0+0xb4/0x2a0 [ 2058.911584][ T290] do_el0_svc+0x8c/0xb0 [ 2058.915677][ T290] el0_svc+0x20/0x30 [ 2058.919503][ T290] el0_sync_handler+0xb0/0xbc [ 2058.924114][ T290] el0_sync+0x180/0x1c0 [ 2058.928190][ T290] [ 2058.930444][ T290] Allocated by task 2176: [ 2058.934714][ T290] kasan_save_stack+0x28/0x60 [ 2058.939328][ T290] __kasan_kmalloc.constprop.0+0xc8/0xf0 [ 2058.944909][ T290] kasan_kmalloc+0x10/0x20 [ 2058.949268][ T290] kmem_cache_alloc_trace+0x128/0xabc [ 2058.954577][ T290] create_spg_node+0x58/0x214 [ 2058.959188][ T290] local_group_add_task+0x30/0x14c [ 2058.964231][ T290] init_local_group+0xd0/0x1a0 [ 2058.968936][ T290] sp_init_group_master_locked.part.0+0x19c/0x290 [ 2058.975298][ T290] mg_sp_group_add_task+0x73c/0xdb0 [ 2058.980456][ T290] dev_sp_add_group+0x124/0x2dc [sharepool_dev] [ 2058.986647][ T290] dev_ioctl+0x21c/0x2ec [sharepool_dev] [ 2058.992222][ T290] __arm64_sys_ioctl+0xd8/0x120 [ 2058.997010][ T290] el0_svc_common.constprop.0+0xb4/0x2a0 [ 2059.002572][ T290] do_el0_svc+0x8c/0xb0 [ 2059.006662][ T290] el0_svc+0x20/0x30 [ 2059.010489][ T290] el0_sync_handler+0xb0/0xbc [ 2059.015101][ T290] el0_sync+0x180/0x1c0 [ 2059.019176][ T290] [ 2059.021427][ T290] Freed by task 4125: [ 2059.025343][ T290] kasan_save_stack+0x28/0x60 [ 2059.029949][ T290] kasan_set_track+0x28/0x40 [ 2059.034476][ T290] kasan_set_free_info+0x24/0x50 [ 2059.039347][ T290] __kasan_slab_free+0x104/0x1ac [ 2059.044227][ T290] kasan_slab_free+0x14/0x20 [ 2059.048744][ T290] kfree+0x164/0xb94 [ 2059.052576][ T290] sp_group_post_exit+0xf0/0x980 [ 2059.057448][ T290] mmput.part.0+0xb4/0x220 [ 2059.061790][ T290] mmput+0x2c/0x40 [ 2059.065450][ T290] exit_mm+0x27c/0x3a0 [ 2059.069450][ T290] do_exit+0x2a0/0x790 [ 2059.073448][ T290] do_group_exit+0x64/0x100 [ 2059.077884][ T290] get_signal+0x1fc/0x9fc [ 2059.082144][ T290] do_signal+0x110/0x2cc [ 2059.086320][ T290] do_notify_resume+0x158/0x2b0 [ 2059.091108][ T290] work_pending+0xc/0x6d4 [ 2059.095358][ T290] Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
-
由 Guo Mengqi 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5OE1J CVE: NA -------------------------------- Fix a deadlock indicated below: [ 171.669844] Chain exists of: [ 171.669844] &mm->mmap_lock --> sp_group_sem --> &spg->rw_lock [ 171.669844] [ 171.671469] Possible unsafe locking scenario: [ 171.671469] [ 171.672121] CPU0 CPU1 [ 171.672415] ---- ---- [ 171.672706] lock(&spg->rw_lock); [ 171.673114] lock(sp_group_sem); [ 171.673706] lock(&spg->rw_lock); [ 171.674208] lock(&mm->mmap_lock); [ 171.674863] [ 171.674863] *** DEADLOCK *** sharepool use lock in order: sp_group_sem --> &spg->rw_lock --> mm->mmap_lock However, in sp_check_mmap_addr(), when mm->mmap_lock is held, it requested sp_group_sem, which is: mm->mmap_lock --> sp_group_sem. This causes ABBA problem. This happens in: [ 171.642687] the existing dependency chain (in reverse order) is: [ 171.643745] [ 171.643745] -> #2 (&spg->rw_lock){++++}-{3:3}: [ 171.644639] __lock_acquire+0x6f4/0xc40 [ 171.645189] lock_acquire+0x2f0/0x3c8 [ 171.645631] down_read+0x64/0x2d8 [ 171.646075] proc_usage_by_group+0x50/0x258 (spg->rw_lock) [ 171.646542] idr_for_each+0x6c/0xf0 [ 171.647011] proc_group_usage_show+0x140/0x178 [ 171.647629] seq_read_iter+0xe4/0x498 [ 171.648217] proc_reg_read_iter+0xa8/0xe0 [ 171.648776] new_sync_read+0xfc/0x1a0 [ 171.649002] vfs_read+0x1ac/0x1c8 [ 171.649217] ksys_read+0x74/0xf8 [ 171.649596] __arm64_sys_read+0x24/0x30 [ 171.649934] el0_svc_common.constprop.0+0x8c/0x270 [ 171.650528] do_el0_svc+0x34/0xb8 [ 171.651069] el0_svc+0x1c/0x28 [ 171.651278] el0_sync_handler+0x8c/0xb0 [ 171.651636] el0_sync+0x168/0x180 [ 171.652118] [ 171.652118] -> #1 (sp_group_sem){++++}-{3:3}: [ 171.652692] __lock_acquire+0x6f4/0xc40 [ 171.653059] lock_acquire+0x2f0/0x3c8 [ 171.653303] down_read+0x64/0x2d8 [ 171.653704] mg_is_sharepool_addr+0x184/0x340 (&sp_group_sem) [ 171.654085] sp_check_mmap_addr+0x64/0x108 [ 171.654668] arch_get_unmapped_area_topdown+0x9c/0x528 [ 171.655370] thp_get_unmapped_area+0x54/0x68 [ 171.656170] get_unmapped_area+0x94/0x160 [ 171.656415] __do_mmap_mm+0xd4/0x540 [ 171.656629] do_mmap+0x98/0x648 [ 171.656838] vm_mmap_pgoff+0xc0/0x188 [ 171.657129] vm_mmap+0x6c/0x98 [ 171.657619] elf_map+0xe0/0x118 [ 171.657835] load_elf_binary+0x4ec/0xfd8 [ 171.658103] bprm_execve.part.9+0x3ec/0x840 [ 171.658448] bprm_execve+0x7c/0xb0 [ 171.658919] kernel_execve+0x18c/0x198 [ 171.659500] run_init_process+0xf0/0x108 [ 171.660073] try_to_run_init_process+0x20/0x58 [ 171.660558] kernel_init+0xcc/0x120 [ 171.660862] ret_from_fork+0x10/0x18 [ 171.661273] [ 171.661273] -> #0 (&mm->mmap_lock){++++}-{3:3}: [ 171.661885] check_prev_add+0xa4/0xbd8 [ 171.662229] validate_chain+0xf54/0x14b8 [ 171.662705] __lock_acquire+0x6f4/0xc40 [ 171.663310] lock_acquire+0x2f0/0x3c8 [ 171.663658] down_write+0x60/0x208 [ 171.664179] mg_sp_alloc+0x24c/0x1150 (mm->mmap_lock) [ 171.665245] dev_ioctl+0x1128/0x1fb8 [sharepool_dev] [ 171.665688] __arm64_sys_ioctl+0xb0/0xe8 [ 171.666250] el0_svc_common.constprop.0+0x8c/0x270 [ 171.667255] do_el0_svc+0x34/0xb8 [ 171.667806] el0_svc+0x1c/0x28 [ 171.668249] el0_sync_handler+0x8c/0xb0 [ 171.668661] el0_sync+0x168/0x180 Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
-
由 Guo Mengqi 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5OE1J CVE: NA -------------------------------- The mutex protecting spm_dvpp_list has an ABBA deadlock with spg->rw_lock. Try add a process to a sharepool group and cat /proc/sharepool/spa_stat at the same time will reproduce the problem. Remove spg->rw_lock to avoid this. [ 1101.013480]INFO: task test:3567 blocked for more than 30 seconds. [ 1101.014378] Tainted: G OE 5.10.0+ #45 [ 1101.015707]task:test state:D stack: 0 pid: 3567 [ 1101.016464]Call trace: [ 1101.016736] __switch_to+0xc0/0x128 [ 1101.017082] __schedule+0x3fc/0x898 [ 1101.017626] schedule+0x48/0xd8 [ 1101.017981] schedule_preempt_disabled+0x14/0x20 [ 1101.018519] __mutex_lock.isra.1+0x160/0x638 [ 1101.018899] __mutex_lock_slowpath+0x24/0x30 [ 1101.019291] mutex_lock+0x5c/0x68 [ 1101.019607] sp_mapping_create+0x118/0x1b0 [ 1101.019963] sp_init_group_master_locked.part.9+0x10c/0x288 [ 1101.020356] mg_sp_group_add_task.part.16+0x7dc/0xcd0 [ 1101.020750] mg_sp_group_add_task+0x54/0xd0 [ 1101.021120] dev_ioctl+0x360/0x1e20 [sharepool_dev] [ 1101.022171] __arm64_sys_ioctl+0xb0/0xe8 [ 1101.022695] el0_svc_common.constprop.0+0x88/0x268 [ 1101.023143] do_el0_svc+0x34/0xb8 [ 1101.023487] el0_svc+0x1c/0x28 [ 1101.023775] el0_sync_handler+0x8c/0xb0 [ 1101.024120] el0_sync+0x168/0x180 Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
-
由 Guo Mengqi 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ODCT CVE: NA -------------------------------- When there are a large number of groups in the system, or with a large number of processes in each group, "cat /proc/sharepool/proc_stat" will encounter softlockup before all prints finished. This is because there are too many loops in the callback function. Remove one of the loops to reduce time cost and add a cond_resched() to avoid this. root@buildroot:~/install# cat /proc/sharepool/proc_stat [ 1250.647469] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [cat:309] [ 1250.648610] Modules linked in: sharepool_dev(OE) [ 1250.650795] CPU: 0 PID: 309 Comm: cat Tainted: G OE 5.10.0+ #43 [ 1250.651216] Hardware name: linux,dummy-virt (DT) [ 1250.651721] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) [ 1250.652426] pc : get_process_sp_res+0x40/0x90 [ 1250.652747] lr : proc_usage_by_group+0x158/0x218 ... [ 1250.657903] Call trace: [ 1250.658376] get_process_sp_res+0x40/0x90 [ 1250.658602] proc_usage_by_group+0x158/0x218 [ 1250.658838] idr_for_each+0x6c/0xf0 [ 1250.659027] proc_group_usage_show+0x104/0x120 [ 1250.659263] seq_read_iter+0xe0/0x498 [ 1250.659462] proc_reg_read_iter+0xa8/0xe0 [ 1250.659660] generic_file_splice_read+0xf0/0x1b0 [ 1250.659865] do_splice_to+0x7c/0xd0 [ 1250.660029] splice_direct_to_actor+0xe0/0x2a8 [ 1250.660353] do_splice_direct+0xa4/0xf8 [ 1250.660902] do_sendfile+0x1bc/0x420 [ 1250.661079] __arm64_sys_sendfile64+0x170/0x178 [ 1250.661298] el0_svc_common.constprop.0+0x88/0x268 [ 1250.661505] do_el0_svc+0x34/0xb8 [ 1250.661686] el0_svc+0x1c/0x28 [ 1250.661836] el0_sync_handler+0x8c/0xb0 [ 1250.662033] el0_sync+0x168/0x180 Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
-
由 Guo Mengqi 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5O5RQ CVE: NA -------------------------------- Notice that in sp_unshare_uva(), for authentication check, comparison between current->tgid and spa->applier is well enough. There is no need to check current->mm against spa->mm. Other redundant cases: - find_spg_node_by_spg() will never return NULL in current use context; - spg_info_show() will not come across a group with id 0. Therefore, delete these redundant paths. Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
-
由 Zhang Zekun 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5XQS4 CVE: NA ----------------------------------------------- In function get_process_sp_res(), spg_node can be freed by other process, the access to spg_node->spg can cause kernel panic. Add a pair of read lock to fix this problem. Fix the same problem in proc_sp_group_state(). Fixes: 3d37f8717287 ("[Huawei] mm: sharepool: use built-in-statistics") Signed-off-by: NZhang Zekun <zhangzekun11@huawei.com>
-
由 Guo Mengqi 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5MS48 CVE: NA -------------------------------- Fix two bugs revealed by static check: - Release the mm->mmap_lock when mm->sp_group_master had not been initialized. - Do not add mm to master list if there process add group failed. Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
-
由 Guo Mengqi 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5M3PS CVE: NA -------------------------------- - fix SP_RES value incorrect bug - fix SP_RES_T value incorrect bug - fix pid field uninitialized error in pass-through scenario Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
-
由 Zhang Zekun 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5LY2R CVE: NA ------------------------------------------- Remove the meaningless comment in mg_sp_free() and the fix the bug in mg_sp_group_id_by_pid() parameter check path. Signed-off-by: NZhang Zekun <zhangzekun11@huawei.com>
-
由 Zhang Zekun 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5LY51 CVE: NA ---------------------------------------------- The variable enable_mdc_default_group has been deprecated, thus remove it and the corresponding code. The definition of is_process_in_group() can be ambiguous, thus change the return value type. Signed-off-by: NZhang Zekun <zhangzekun11@huawei.com>
-
由 Zhang Zekun 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5LY4H CVE: NA ----------------------------------------- Remove the sp_device_number, and we don't need 'sp_device_number' to detect the sp_device_number. Instead, we use maco 'MAX_DEVID' to take the place of sp_device_number. Signed-off-by: NZhang Zekun <zhangzekun11@huawei.com>
-
由 Zhang Zekun 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5LY5K CVE: NA ----------------------------------- Remove the unused sp_dev_va_start and sp_dev_va_size, the related code can be removed. Add the dvpp_addr checker in mg_is_sharepool_addr() for current proc. Signed-off-by: NZhang Zekun <zhangzekun11@huawei.com>
-
由 Wang Wensheng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5LHGZ CVE: NA -------------------------------- Delete unused sysctl interfaces in sharepool feature. Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
-
由 Guo Mengqi 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5KSDH CVE: NA -------------------------------- Fix sharepool redundant /proc/sharepool/spa_stat prints when there are multiple groups which are all attached to same sp_mapping. Traverse all dvpp-mappings rather than all groups. Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
-
由 Guo Mengqi 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5K3MH CVE: NA -------------------------------- After refactoring, cat /proc/pid_xx/sp_group will cause kernel panic. Fix this error. Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
-
由 Guo Mengqi 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5KC7C CVE: NA -------------------------------- Most interfaces starting with "sp_" are deprecated, remove them. Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
-
- 08 11月, 2022 8 次提交
-
-
由 Jianglei Nie 提交于
stable inclusion from stable-v5.10.153 commit 6cc0e2afc6a137d45b9523f61a1b1b16a68c9dc0 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5W7B1 CVE: CVE-2022-3542 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.153&id=6cc0e2afc6a137d45b9523f61a1b1b16a68c9dc0 -------------------------------- [ Upstream commit b43f9acb ] bnx2x_tpa_stop() allocates a memory chunk from new_data with bnx2x_frag_alloc(). The new_data should be freed when gets some error. But when "pad + len > fp->rx_buf_size" is true, bnx2x_tpa_stop() returns without releasing the new_data, which will lead to a memory leak. We should free the new_data with bnx2x_frag_free() when "pad + len > fp->rx_buf_size" is true. Fixes: 07b0f009 ("bnx2x: fix possible panic under memory stress") Signed-off-by: NJianglei Nie <niejianglei2021@163.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NRen Zhijie <renzhijie2@huawei.com> Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Linus Torvalds 提交于
stable inclusion from stable-v5.10.148 commit 36b33c63515a93246487691046d18dd37a9f589b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I601VT CVE: CVE-2022-40768 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=36b33c63515a93246487691046d18dd37a9f589b ------------------------------- commit 6022f210 upstream. The passthrough structure is declared off of the stack, so it needs to be set to zero before copied back to userspace to prevent any unintentional data leakage. Switch things to be statically allocated which will fill the unused fields with 0 automatically. Link: https://lore.kernel.org/r/YxrjN3OOw2HHl9tx@kroah.com Cc: stable@kernel.org Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Reported-by: Nhdthky <hdthky0@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLu Jialin <lujialin4@huawei.com> Reviewed-by: NGUO Zihua <guozihua@huawei.com> Reviewed-by: NGONG Ruiqi <gongruiqi1@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Wangming Shao 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5WGEF ------------------------------------------------------------------- Fixed the header file location error. Rectify the missing member and function name errors in the structure. Signed-off-by: NWangming Shao <shaowangming@h-partners.com> Reviewed-by: NYicong Yang <yangyicong@huawei.com> Reviewed-by: NYang Jihong <yangjihong1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @hellotcc This PR add support for bonding on hns roce. **ISSUE** https://gitee.com/openeuler/kernel/issues/I5Z6L8 **TEST** related test log has been attached to the issue Link:https://gitee.com/openeuler/kernel/pulls/219 Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Reviewed-by: Ling Mingqiang <lingmingqiang@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @chenke1978 [Description] The ROH module driver consists of the ROH Core and ROH DRV modules, which work with hardware to implement communication between nodes through HCCS packets. ROH Core is a protocol stack of the ROH architecture. It provides related services for upper layers by invoking operation interfaces provided by the ROH DRV. The ROH DRV implements the lower layer functions of the ROH featureand provides a series of interfaces for operating hardware for the ROH Core. This PR contains the following contents: 1. Support the ROH device ID and complete the initialization of the HNS ROH device in ROH MAC type. 2. Provide the initialization of the ROH cmdq command channel to enable the ROH device to communicate with the IMP. 3. net: hns3: add support for roh ras/rest is userd to prepare for the roh next patch. [Testing] kernel options: CONFIG_ROH=m CONFIG_ROH_HNS=m Test passed with below step: 1. Using a hardware environment that supports ROH, run lspci to check the pci device info , and you can find the device id belonging to ROH: lspci 29:00.0 Class 0200: Device 19e5:a22c (rev 32) 2. Load the following modules in sequence: insmod hnae3.ko insmod hclge.ko insmod hns3.ko insmod roh_core.ko insmod hns-roh-v1.ko There is no error when roh ko is installed, and you will get a success message: "hns3 0000:29:00.0: roh driver init success" 3. Check the sysfs file and confirm that the hns3_0 device file has been generated in the /sys/class/roh/ directory: ls /sys/class/roh/ hns3_0 4. Confirm that the current pci device is in ROH MAC type cat /sys/kernel/debug/hns3/0000:29:00.0/reg/mac | grep type type: ROH 5. In ROH mode, run the ifconfig command to confirm that the network device has been generated normally 6. Uninstall roh_core.ko & hns-roh-v1.ko without any errors Link:https://gitee.com/openeuler/kernel/pulls/224 Reviewed-by: Ling Mingqiang <lingmingqiang@huawei.com> Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @yezengruan To support HCCS bus using in Ascend series accelerators, the SMMU ATOS (a software-accessible Address Translation Operations facility) feature is enabled for a special SMMU aka Agent SMMU in the Ascend accelerator. In the VM scenario, the hypervisor creates Stage1 page table for the Agent SMMU. The Agent SMMU provides an interface for components in accelerator to translate addresses from IPA to PA. This allows the components to DMA on the HCCS bus using PA. The origin SMMU ATOS feature only support translation of only a single group of addresses at a time. Ascend Agent SMMUs use the IMPLEMENTATION DEFINED region to implement translation of max 32 groups of addresses at the same time which can greatly improve the efficiency. Link:https://gitee.com/openeuler/kernel/pulls/165 Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Reviewed-by: Kevin Zhu <zhukeqian1@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 Binfeng Wu 提交于
ascend inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5JSWJ CVE: NA ------------------------------------------------- To support HCCS bus using in Ascend series accelerators, the SMMU ATOS (a software-accessible Address Translation Operations facility) feature is enabled for a special SMMU aka Agent SMMU in the Ascend accelerator. In the VM scenario, the hypervisor creates Stage1 page table for the Agent SMMU. The Agent SMMU provides an interface for components in accelerator to translate addresses from IPA to PA. This allows the components to DMA on the HCCS bus using PA. The origin SMMU ATOS feature only support translation of only a single group of addresses at a time. Ascend Agent SMMUs use the IMPLEMENTATION DEFINED region to implement translation of max 32 groups of addresses at the same time which can greatly improve the efficiency. Reviewed-by: NYingtai Xie <xieyingtai@huawei.com> Reviewed-by: NXiaoyang Xu <xuxiaoyang2@huawei.com> Signed-off-by: NBinfeng Wu <wubinfeng@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Signed-off-by: Nyezengruan <yezengruan@huawei.com>
-
由 Ke Chen 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5WKYW ----------------------------------------------------------------------- Each ROH device has its own cmdq interface, which includes send queue CSQ and receive queue CRQ. These commands are used to obtain the resources of the ROH device from IMP and implement related configurations. This patch adds the support of IMP command interface to the ROH driver, include: 1. initialize the roh command queue resource 2. manage the roh command queue descriptors 3. provide the cmdq send operation APIs Signed-off-by: NKe Chen <chenke54@huawei.com> Reviewed-by: NGang Zhang <gang.zhang@huawei.com> Reviewed-by: NYefeng Yan <yanyefeng@huawei.com> Reviewed-by: NJingchao Dai <daijingchao1@huawei.com> Reviewed-by: NJian Shen <shenjian15@huawei.com>
-
- 07 11月, 2022 10 次提交
-
-
由 Shung-Hsi Yu 提交于
maillist inclusion category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5WLXN CVE: CVE-2022-3606 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/tools/lib/bpf/libbpf.c?h=next-20221024&id=d0d382f95a9270dcf803539d6781d6bd67e3f5b2 -------------------------------- When there are no program sections, obj->programs is left unallocated, and find_prog_by_sec_insn()'s search lands on &obj->programs[0] == NULL, and will cause null-pointer dereference in the following access to prog->sec_idx. Guard the search with obj->nr_programs similar to what's being done in __bpf_program__iter() to prevent null-pointer access from happening. Fixes: db2b8b06 ("libbpf: Support CO-RE relocations for multi-prog sections") Signed-off-by: NShung-Hsi Yu <shung-hsi.yu@suse.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20221012022353.7350-4-shung-hsi.yu@suse.comSigned-off-by: NPu Lehui <pulehui@huawei.com> Reviewed-by: NKuohai Xu <xukuohai@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Ye Bin 提交于
mainline inclusion from mainline-v6.1-rc2 commit 2db96217 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ZI04 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.1-rc3&id=2db96217e7e515071726ca4ec791742c4202a1b2 -------------------------------- As previous commit, 'blk_trace_cleanup' will stop block trace if block trace's state is 'Blktrace_running'. So remove unnessary stop block trace in 'blk_trace_shutdown'. Signed-off-by: NYe Bin <yebin10@huawei.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20221019033602.752383-4-yebin@huaweicloud.comSigned-off-by: NJens Axboe <axboe@kernel.dk> conflicts: kernel/trace/blktrace.c Signed-off-by: NYe Bin <yebin10@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Ye Bin 提交于
mainline inclusion from mainline-v6.1-rc2 commit dcd1a59c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ZI04 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.1-rc3&id=dcd1a59c62dc49da75539213611156d6db50ab5d -------------------------------- When test as follows: step1: ioctl(sda, BLKTRACESETUP, &arg) step2: ioctl(sda, BLKTRACESTART, NULL) step3: ioctl(sda, BLKTRACETEARDOWN, NULL) step4: ioctl(sda, BLKTRACESETUP, &arg) Got issue as follows: debugfs: File 'dropped' in directory 'sda' already present! debugfs: File 'msg' in directory 'sda' already present! debugfs: File 'trace0' in directory 'sda' already present! And also find syzkaller report issue like "KASAN: use-after-free Read in relay_switch_subbuf" "https://syzkaller.appspot.com/bug?id=13849f0d9b1b818b087341691be6cc3ac6a6bfb7" If remove block trace without stop(BLKTRACESTOP) block trace, '__blk_trace_remove' will just set 'q->blk_trace' with NULL. However, debugfs file isn't removed, so will report file already present when call BLKTRACESETUP. static int __blk_trace_remove(struct request_queue *q) { struct blk_trace *bt; bt = rcu_replace_pointer(q->blk_trace, NULL, lockdep_is_held(&q->debugfs_mutex)); if (!bt) return -EINVAL; if (bt->trace_state != Blktrace_running) blk_trace_cleanup(q, bt); return 0; } If do test as follows: step1: ioctl(sda, BLKTRACESETUP, &arg) step2: ioctl(sda, BLKTRACESTART, NULL) step3: ioctl(sda, BLKTRACETEARDOWN, NULL) step4: remove sda There will remove debugfs directory which will remove recursively all file under directory. >> blk_release_queue >> debugfs_remove_recursive(q->debugfs_dir) So all files which created in 'do_blk_trace_setup' are removed, and 'dentry->d_inode' is NULL. But 'q->blk_trace' is still in 'running_trace_lock', 'trace_note_tsk' will traverse 'running_trace_lock' all nodes. >>trace_note_tsk >> trace_note >> relay_reserve >> relay_switch_subbuf >> d_inode(buf->dentry)->i_size To solve above issues, reference commit '5afedf67', call 'blk_trace_cleanup' unconditionally in '__blk_trace_remove' and first stop block trace in 'blk_trace_cleanup'. Signed-off-by: NYe Bin <yebin10@huawei.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20221019033602.752383-3-yebin@huaweicloud.comSigned-off-by: NJens Axboe <axboe@kernel.dk> conflicts: kernel/trace/blktrace.c Signed-off-by: NYe Bin <yebin@huaweicloud.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Ye Bin 提交于
mainline inclusion from mainline-v6.1-rc2 commit 60a9bb90 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ZI04 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.1-rc3&id=60a9bb9048f9e95029df10a9bc346f6b066c593c -------------------------------- Introduce 'blk_trace_{start,stop}' helper. No functional changed. Signed-off-by: NYe Bin <yebin10@huawei.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20221019033602.752383-2-yebin@huaweicloud.comSigned-off-by: NJens Axboe <axboe@kernel.dk> conflicts: kernel/trace/blktrace.c Signed-off-by: NYe Bin <yebin@huaweicloud.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Ye Bin 提交于
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>
-
由 Ziyang Xuan 提交于
maillist inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5Z86E CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=363a5328f4b0 -------------------------------- Recently, we got two syzkaller problems because of oversize packet when napi frags enabled. One of the problems is because the first seg size of the iov_iter from user space is very big, it is 2147479538 which is bigger than the threshold value for bail out early in __alloc_pages(). And skb->pfmemalloc is true, __kmalloc_reserve() would use pfmemalloc reserves without __GFP_NOWARN flag. Thus we got a warning as following: ======================================================== WARNING: CPU: 1 PID: 17965 at mm/page_alloc.c:5295 __alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295 ... Call trace: __alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295 __alloc_pages_node include/linux/gfp.h:550 [inline] alloc_pages_node include/linux/gfp.h:564 [inline] kmalloc_large_node+0x94/0x350 mm/slub.c:4038 __kmalloc_node_track_caller+0x620/0x8e4 mm/slub.c:4545 __kmalloc_reserve.constprop.0+0x1e4/0x2b0 net/core/skbuff.c:151 pskb_expand_head+0x130/0x8b0 net/core/skbuff.c:1654 __skb_grow include/linux/skbuff.h:2779 [inline] tun_napi_alloc_frags+0x144/0x610 drivers/net/tun.c:1477 tun_get_user+0x31c/0x2010 drivers/net/tun.c:1835 tun_chr_write_iter+0x98/0x100 drivers/net/tun.c:2036 The other problem is because odd IPv6 packets without NEXTHDR_NONE extension header and have big packet length, it is 2127925 which is bigger than ETH_MAX_MTU(65535). After ipv6_gso_pull_exthdrs() in ipv6_gro_receive(), network_header offset and transport_header offset are all bigger than U16_MAX. That would trigger skb->network_header and skb->transport_header overflow error, because they are all '__u16' type. Eventually, it would affect the value for __skb_push(skb, value), and make it be a big value. After __skb_push() in ipv6_gro_receive(), skb->data would less than skb->head, an out of bounds memory bug occurred. That would trigger the problem as following: ================================================================== BUG: KASAN: use-after-free in eth_type_trans+0x100/0x260 ... Call trace: dump_backtrace+0xd8/0x130 show_stack+0x1c/0x50 dump_stack_lvl+0x64/0x7c print_address_description.constprop.0+0xbc/0x2e8 print_report+0x100/0x1e4 kasan_report+0x80/0x120 __asan_load8+0x78/0xa0 eth_type_trans+0x100/0x260 napi_gro_frags+0x164/0x550 tun_get_user+0xda4/0x1270 tun_chr_write_iter+0x74/0x130 do_iter_readv_writev+0x130/0x1ec do_iter_write+0xbc/0x1e0 vfs_writev+0x13c/0x26c To fix the problems, restrict the packet size less than (ETH_MAX_MTU - NET_SKB_PAD - NET_IP_ALIGN) which has considered reserved skb space in napi_alloc_skb() because transport_header is an offset from skb->head. Add len check in tun_napi_alloc_frags() simply. Fixes: 90e33d45 ("tun: enable napi_gro_frags() for TUN/TAP driver") Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com> Reviewed-by: NEric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20221029094101.1653855-1-william.xuanziyang@huawei.comSigned-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Christoph Hellwig 提交于
mainline inclusion from mainline-v5.11-rc1 commit 2dc691cc category: bugfix bugzilla: 187706,https://gitee.com/openeuler/kernel/issues/I5XEBX CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2dc691cc4ac259f8b5bb0bd8670645af894d30eb ---------------------------------------- Merge nbd_size_set and nbd_size_update into a single function that also updates the nbd_config fields. This new function takes the device size in bytes as the first argument, and the blocksize as the second argument, simplifying the calculations required in most callers. Signed-off-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NJosef Bacik <josef@toxicpanda.com> Signed-off-by: NJens Axboe <axboe@kernel.dk> Conflicts: drivers/block/nbd.c Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Reviewed-by: NYu Kuai <yukuai3@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Christoph Hellwig 提交于
mainline inclusion from mainline-v5.11-rc1 commit 92f93c3a category: bugfix bugzilla: 187706,,https://gitee.com/openeuler/kernel/issues/I5XEBX CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=92f93c3a1bf9dc73181dc6566497d16b690cb576 ---------------------------------------- nbd_size_update is about to acquire a few more callers, so lift the check into the function. Signed-off-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NJosef Bacik <josef@toxicpanda.com> Signed-off-by: NJens Axboe <axboe@kernel.dk> Conflicts: drivers/block/nbd.c [0c98057b ("nbd: Fix use-after-free in pid_show") include first] Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Reviewed-by: NYu Kuai <yukuai3@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Christoph Hellwig 提交于
mainline inclusion from mainline-v5.11-rc1 commit ee4bf648 category: bugfix bugzilla: 187706,https://gitee.com/openeuler/kernel/issues/I5XEBX CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ee4bf648635055d2b76afadaf34236c8b2d852a7 ---------------------------------------- Block driver have no business setting the file system concept of a block size. Signed-off-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NJosef Bacik <josef@toxicpanda.com> Signed-off-by: NJens Axboe <axboe@kernel.dk> conflicts: drivers/block/nbd.c Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Reviewed-by: NYu Kuai <yukuai3@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Luo Meng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5WBQA CVE: NA -------------------------------- This reverts commit 1f9fa07b. Commit 2fe0e281f7ad witch merged by LTS (cifs: fix double free race when mount fails in cifs_get_root()) fixes a double free. However, the previous patch d17abdf7 is not merged. There is no such issue on 5.10 because it will return after cifs_cleanup_volume_info(). Since merge this patch, cifs_cleanup_volume_info() is skipped, leading to a memory leak. Signed-off-by: NLuo Meng <luomeng12@huawei.com> Reviewed-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-