Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 09 11月, 2022 28 次提交
    • G
      mm/sharepool: fix potential AA deadlock · d9fb53bf
      由 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>
      d9fb53bf
    • G
      mm/sharepool: delete unused codes · 872ebaa0
      由 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>
      872ebaa0
    • Z
      mm/sharepool: bugfix for 2M U2K · e6a23a8d
      由 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>
      e6a23a8d
    • C
      mm/sharepool: Support alloc ro mapping · d9687e45
      由 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>
      d9687e45
    • C
      mm/sharepool: Extract sp_mapping_find · 60d69023
      由 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>
      60d69023
    • C
      mm/sharepool: replace spg->{dvpp|normal} with spg->mapping[SP_MAPPING_{DVPP|NORMAL}] · 91bc1d52
      由 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>
      91bc1d52
    • C
      mm/sharepool: Rename sp_mapping.flag to sp_mapping.type · ef12ea35
      由 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>
      ef12ea35
    • C
      mm/sharepool: Make the definitions of MMAP_SHARE_POOL_{START|16G_START} more readable · 14cd3fb0
      由 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>
      14cd3fb0
    • Z
      mm/sharepool: Avoid UAF on mm · a151f824
      由 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>
      a151f824
    • Z
      mm/sharepool: Check the maximum value of spg_id · 99b7756c
      由 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>
      99b7756c
    • Z
      mm/sharepool: Avoid UAF on spa · 27d0e771
      由 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>
      27d0e771
    • Z
      mm/sharepool: delete unnecessary judgment · 142bfed2
      由 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>
      142bfed2
    • W
      mm/sharepool: Fix UAF reported by KASAN · 19896d2c
      由 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>
      19896d2c
    • G
      mm/sharepool: fix deadlock in sp_check_mmap_addr · 78c82ea5
      由 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>
      78c82ea5
    • G
      mm/sharepool: fix deadlock in spa_stat_of_mapping_show · 608669b7
      由 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>
      608669b7
    • G
      mm/sharepool: fix softlockup in high pressure use case. · 8b19f5e0
      由 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>
      8b19f5e0
    • G
      mm/sharepool: delete redundant codes · cd65775f
      由 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>
      cd65775f
    • Z
      mm/sharepool: Add a read lock in proc_usage_show() · d5fb0387
      由 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>
      d5fb0387
    • G
      mm/sharepool: fix static code-check errors · de73eb95
      由 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>
      de73eb95
    • G
      mm/sharepool: fix statistics error · 738027fc
      由 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>
      738027fc
    • Z
      mm/sharepool: Remove the comment and fix a bug in mg_sp_group_id_by_pid() · c2e830a7
      由 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>
      c2e830a7
    • Z
      mm/sharepool: Remove enable_mdc_default_group and change the definition of is_process_in_group() · 36ddb7ca
      由 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>
      36ddb7ca
    • Z
      mm/sharepool: Remove sp_device_number_detect function · 5b9c2984
      由 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>
      5b9c2984
    • Z
      mm/sharepool: Remove unused sp_dev_va_start and sp_dev_va_size · 009c8a05
      由 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>
      009c8a05
    • W
      mm/sharepool: Delete unused sysctl interface · 00f8b7c2
      由 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>
      00f8b7c2
    • G
      mm/sharepool: fix dvpp spm redundant print error · efa70a93
      由 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>
      efa70a93
    • G
      mm/sharepool: proc_sp_group_state bugfix · a38909f1
      由 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>
      a38909f1
    • G
      mm/sharepool: remove deprecated interfaces · aa7f4227
      由 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>
      aa7f4227
  3. 08 11月, 2022 8 次提交
  5. 07 11月, 2022 4 次提交