- 09 11月, 2022 32 次提交
-
-
由 Zhang Zekun 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5XQS4 CVE: NA ---------------------------------------------- Renaming __insert_sp_area to insert_sp_area. Renaming __find_sp_area_locked to find_sp_area_locked. Fix this by renaming __insert_sp_area to insert_sp_area. Signed-off-by: NZhang Zekun <zhangzekun11@huawei.com>
-
由 Zhang Zekun 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5XQS4 CVE: NA ----------------------------------------- 1. Remove the inline clause before sp_mapping_find(). 2. Do not declare or define reserved identifiers. 3. Add brackets in if, elese/elseif statements. 4. The pointer(*) can't have no spaces neither before nor after it. 5. Use parentheses to specify the sequence of expressions in sp_remap_kva_to_vma(), sp_node_id(), init_local_group(). 6. Besides, change the name of __find_sp_area() to get_sp_area() to represent that this function need not to be called with lock hold and implicit that this function will increase the use_count. Signed-off-by: NZhang Zekun <zhangzekun11@huawei.com>
-
由 Guo Mengqi 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5RO2H CVE: NA -------------------------------- When nr_hugepages is configured, sharepool allocates hugepages first from hugetlb pool, then from buddy system if the pool had been used up. Current page release function treat the buddy system hugepages as hugetlb pages, which caused HugePages_Rsvd to increase improperly. Add a check in page release function: if the page is temporary, do not call hugetlb_unreserve_pages. Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
-
由 Guo Mengqi 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5QQPG CVE: NA -------------------------------- Add a size-0-check in mg_sp_make_share_k2u() to avoid passing 0-size spa to __insert_sp_area(). Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
-
由 Guo Mengqi 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5R0X9 CVE: NA -------------------------------- Fix a AA deadlock caused by nested lock in mg_sp_group_add_task(). Deadlock path: mg_sp_group_add_task() down_write(sp_group_sem) find_or_alloc_sp_group() !spg_valid() sp_group_drop() free_sp_group() -> down_write(sp_group_sem) ---> AA deadlock Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
-
由 Guo Mengqi 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5QETC CVE: NA -------------------------------- sp_make_share_k2u only supports vmalloc address now. Therefore, delete a backup handle case. Also master is guaranteed not be freed until master->node_list is emptied. Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
-
由 Zhou Guanghui 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5PZDX CVE: NA -------------------------------- We could determine if a userspace map is huge-mapped after walking its pagetable. So the uva_align should be calculated again after walking the pagetable if it is huge-mapped. Signed-off-by: NZhou Guanghui <zhouguanghui1@huawei.com>
-
由 Chen Jun 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5I72Q CVE: NA -------------------------------- 1. Split sharepool normal area(8T) to sharepool readonly area(64G) and sharepool normal area(8T - 64G) 2. User programs can not write to the address in sharepool readonly area. 3. Add SP_PROT_FOCUS for sp_alloc. 4. sp_alloc with SP_PROT_RO | SP_PROT_FOCUS returns the virtual address within sharepool readonly area. 5. Other user programs which add into task with write prot can not write the address in sharepool readonly area. Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Chen Jun 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5I72Q CVE: NA -------------------------------- Extract code logic of obtaining sp_mapping by address into a function sp_mapping_find. Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 Chen Jun 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5I72Q CVE: NA -------------------------------- spg->dvpp and spg->normal can be combined into one array. Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
由 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>
-