提交 · a829370d803a17014c0509be190d926641d34011 · openeuler / Kernel

19 7月, 2022 21 次提交

mm/sharepool: Add a task_struct parameter for sp_get_local_group() · a829370d

由 Wang Wensheng 提交于 7月 19, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5DS9S
CVE: NA

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

sp_get_local_group() could be invoked in kthread, where the current
process isn't the process we want. Add a parameter and let the caller to
avoid this problem.
Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

a829370d

mm/sharepool: Don't check the DVPP address space range before merging · 451822b6

由 Wang Wensheng 提交于 7月 19, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5DS9S
CVE: NA

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

The user doesn't care about the start address of the dvpp range, what
is mattered is that the virtual space tagged DVPP located at in a 16G
range. So we can safely drop the dvpp address space as long as it's
empty during merging process.
Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

451822b6

mm/sharepool: Configure the DVPP range for process · 1e645d0e

由 Wang Wensheng 提交于 7月 19, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5DS9S
CVE: NA

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

Currently the dvpp range is global for each device. And it is
unreasonable after the reconstruction that makes the DVPP mappings
private to each process or group.

This allows to configure the dvpp range for each process.
The dvpp range for each dvpp mapping can only be configured once just
as the old version.
Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

1e645d0e

mm/sharepool: Introduce SPG_NON_DVPP flag for sp_group_add_task · 8e8888e6

由 Wang Wensheng 提交于 7月 19, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5DS9S
CVE: NA

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

When SPG_NOD_DVPP is specified to sp_group_add_task, we don't create a
DVPP mapping for the newly created sp_group. And the new group cannot
support allocating DVPP memory.
Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

8e8888e6

mm/sharepool: Update sp_mapping structure · b632bf41

由 Wang Wensheng 提交于 7月 19, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5DS9S
CVE: NA

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

1. Add a list for sp_mapping to record all the sp_groups attached to it.
2. Initialize the sp_mapping for local_group when it is created. So when
   we add a task to a group, we should merge the dvpp mapping of the
   local group.
3. Every two groups can be merged if and only if at least one of them is
   empty. Then the empty mapping would be dropped and another mapping
   would be attached to the two groups. This need to traverse all the
   groups attached to the mapping.
4. A mapping is considered empty when no spa is allocated from it and
   its address space is default.
Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

b632bf41

mm/sharepool: Clear the initialization of sp-associated structure for a process · 283d8d87

由 Wang Wensheng 提交于 7月 19, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5DS9S
CVE: NA

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

A few structures must have been created when a process want to get into
sharepool subsystem, including allocating sharepool memory, being added
into a spg or doing k2u and so on.

Currently we create those structures just before we actually need them.
For example, we find or create a sp_spa_stat after a successful memory
allocation and before updating the statistical structure. The creation of
a new structure may fail due to oom and we should then reclaim the
memory allocated and revert all the process before. Or we just forget to
do that and a potential memory-leak occurs. This design makes it
confused when we indeed create a structure and we always worry about
potential memory-leak when we changes the code around it.

A better solution is to initialize all that structures at the same time
when a process join in sharepool subsystem. And in future, we will clear
the unnecessary statistical structures.
Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

283d8d87

mm/sharepool: Unify the memory allocation process · 447951e3

由 Wang Wensheng 提交于 7月 19, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5DS9S
CVE: NA

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

There are two types of memory allocated from sharepool: passthrough
memory for DVPP and shared memory. Currently, we branch to different
routines depending on the memory type, both during the allocation and
free process. Since we have already create a local group for passthrough
memory, with just one step ahead, we could drop the redundant branches
in allocation and free process and in all the fallback process when an
error occurs.

Here is the content of this patch:
1. Add erery process to its local group when initilizing its group_master.
2. Avoid to return the local group in find_sp_group_id_by_pid().
3. Delete the redundant branches during allocation and free process.
Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

447951e3

mm/sharepool: Use vm_private_data to store the spa · 331c3817

由 Wang Wensheng 提交于 7月 19, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5DS9S
CVE: NA

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

When we destroy a vma, we first find the spa depending on the
vma->vm_start, during which we should hold the sp_area_lock.
While we store the spa in vma, we can get the spa directly.
Don't worry if the spa exists or if it's to be freed soon, since
we have increaced the refcount for the spa when it's mappend into
a vma.
Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

331c3817

mm/sharepool: Share pool statistics adaption · c7042191

由 Zhou Guanghui 提交于 7月 19, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5DS9S
CVE: NA

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

The management of the address space is adjusted, and the statistical
data processing of the shared pool needs to be adapted.
Signed-off-by: NZhou Guanghui <zhouguanghui1@huawei.com>
Signed-off-by: NZhang Jian <zhangjian210@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

c7042191

mm/sharepool: Release the sp addr based on the id · 7de67bbc

由 Zhou Guanghui 提交于 7月 19, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5DS9S
CVE: NA

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

The address space of the DVPP is managed by group. When releasing
the shared pool memory, you need to find the corresponding address
space based on the ID.
Signed-off-by: NZhou Guanghui <zhouguanghui1@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

7de67bbc

mm/sharepool: Add an interface to obtain an id · 561d77b6

由 Zhou Guanghui 提交于 7月 19, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5DS9S
CVE: NA

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

The DVPP address space is per process or per sharing group.
During sp_free and unshare, you need to know which address
space the current address belongs to.
Signed-off-by: NZhou Guanghui <zhouguanghui1@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

561d77b6

mm/sharepool: Address space management for sp_group · 85d9c2fe

由 Zhou Guanghui 提交于 7月 19, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5DS9S
CVE: NA

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

Separately manage the normal and dvpp address spaces of the
sp_group and set the normal and dvpp address spaces of the
corresponding groups when adding a group, sp_alloc, and k2task.
Signed-off-by: NZhou Guanghui <zhouguanghui1@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

85d9c2fe

mm/sharepool: Create global normal and dvpp mapping · b31f7f28

由 Zhou Guanghui 提交于 7月 19, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5DS9S
CVE: NA

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

struct sp_mapping is used to manage the address space of a shared
pool. During the initialization of the shared pool, normal address
spaces are created to allocate the memory of the current shared pool.
Signed-off-by: NZhou Guanghui <zhouguanghui1@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

b31f7f28

mm/sharepool: Delete single-group mode · 6db68bf8

由 Zhou Guanghui 提交于 7月 19, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5DS9S
CVE: NA

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

The single-group mode has no application scenario. Therefore, the
related branch is deleted.

The boot option "enable_sp_multi_group_mode" does not take effect.
Signed-off-by: NZhou Guanghui <zhouguanghui1@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

6db68bf8

mm/sharepool: Avoid NULL pointer dereference in mg_sp_group_add_task · d722c6b6

由 Yuan Can 提交于 7月 19, 2022

ascend inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5DS9S
CVE: NA

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

create_spg_node() may fail with NULL pointer returened, and in
the out_drop_spg_node path, the NULL pointer will be dereferenced
in free_spg_node().
Signed-off-by: NYuan Can <yuancan@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

d722c6b6

mm/sharepool: Fix using uninitialized sp_flag · ce9fcee1

由 Wang Wensheng 提交于 7月 19, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5DS9S
CVE: NA

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

Add the missing initialization for kc.sp_flag in
sp_make_share_kva_to_spg(). Or a random value would be used in
sp_remap_kva_to_vma().
Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

ce9fcee1

mm/sharepool: Support read-only memory allocation · 022b7bdf

由 Zhou Guanghui 提交于 7月 19, 2022

ascend inclusion
category: Bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5DS9S
CVE: NA

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

When the driver uses the shared pool memory to share the memory
with the user space, the user space is not allowed to operate
this area. This prevents users from damaging sensitive data.

When the sp_alloc and k2u processes apply for private memory,
read-only memory can be applied for.
Signed-off-by: NZhou Guanghui <zhouguanghui1@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

022b7bdf

mm/sharepool: Modify sharepool sp_mmap() page_offset · 5815e08a

由 Guo Mengqi 提交于 7月 19, 2022

ascend inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5DS9S
CVE: NA

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

In sp_mmap(), if use offset = va - MMAP_BASE/DVPP_BASE, then normal
sp_alloc pgoff may have same value with DVPP pgoff, causing DVPP
and sp_alloc mapped to overlapped part of file unexpectedly.

To fix the problem, pass VA value as mmap offset, for in this scenario,
VA value in one task address space will not be same.
Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
Reviewed-by: NDing Tianhong <dingtianhong@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

5815e08a

mm/sharepool: Accept device_id in k2u flags · 8d06b097

由 Wang Wensheng 提交于 7月 19, 2022

ascend inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5DS9S
CVE: NA

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

We use device_id to select the correct dvpp vspace range when SP_DVPP
flag is specified.
Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

8d06b097

mm/sharepool: use rwsem to protect sp group exit · 5cc1b791

由 Guo Mengqi 提交于 7月 19, 2022

ascend inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5DS9S
CVE: NA

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

Fix following situation:

when the last process in a group exits, and a second process tries to add
to this group.

The second process may get a invalid spg. However the group's
use_count is increased by 1, which caused the first process failed to
free the group when it exits. And then second process called
sp_group_drop --> free_sp_group and cause a double request of rwsem.
Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

5cc1b791

mm/sharepool: Allow share THP to kernel · 70ae4a24

由 Wang Wensheng 提交于 7月 19, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5DS9S
CVE: NA

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

This is not used for THP but the user page table is just like THP. The
user alloc hugepages via a special driver and its vma is not marked with
VM_HUGETLB. This commit allow to share those vma to kernel.
Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

70ae4a24

07 6月, 2022 3 次提交

mm/sharepool: Fix sharepool node id invalid when using sp_alloc · d6fa9939

由 Zhang Jian 提交于 6月 07, 2022

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I54IL8
CVE: NA
backport: openEuler-22.03-LTS

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

When passing numa id to sp_alloc, sometimes numa id does not work.
This is because memory policy will change numa id to a preferred one if
memory policy is set. Fix the error by mbind virtual address to desired
numa id.
Signed-off-by: NZhang Jian <zhangjian210@huawei.com>
Signed-off-by: NZhou Guanghui <zhouguanghui1@huawei.com>
Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

d6fa9939

share_pool: Fix ABBA deadlock · 401a2b45

由 Wang Wensheng 提交于 6月 07, 2022

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I54I7W
CVE: NA
backport: openEuler-22.03-LTS

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

There is a ABBA deadlock in the process of sp_group_add_task and
proc_stat_show().

PROCESS A:
sp_group_add_task()        acquire sp_group_sem write lock
    ->sp_init_proc_stat()  acquire sp_spg_stat_sem  write lock
PROCESS B:
proc_stat_show()           acquire sp_spg_stat_sem read lock
    ->idr_proc_stat_cb()   acquire sp_group_sem read lock

Here we choose the simplest way that acquires sp_group_sem and
sp_stat_sem read lock subsequently in proc_stat_show(), since it just
has effect on the process of debug feature.
Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

401a2b45

sharepool: fix hisi oom deadlock · 0ab3b159

由 Guo Mengqi 提交于 6月 07, 2022

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I54I59
CVE: NA
backport: openEuler-22.03-LTS

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

When hisi_oom_notifier_call calls spg_overview_show, it requires the
global rwsem sp_group_sem, which had been held by another process when oomed.
This leads to kernel hungtask. At another position the unecessary sp_group_sem
causes an ABBA deadlock.

    [ 1934.549016] INFO: task klogd:2757 blocked for more than 120 seconds.
    [ 1934.562408] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [ 1934.570231] klogd           D    0  2757   2746 0x00000000
    [ 1934.575707] Call trace:
    [ 1934.578162]  __switch_to+0xe8/0x150
    [ 1934.581648]  __schedule+0x250/0x558
    [ 1934.585133]  schedule+0x30/0xf0
    [ 1934.588267]  rwsem_down_read_failed+0x10c/0x188
    [ 1934.592788]  down_read+0x60/0x68
    [ 1934.596015]  spg_overview_show.part.31+0xc8/0xf8
    [ 1934.600622]  spg_overview_show+0x2c/0x38
    [ 1934.604543]  hisi_oom_notifier_call+0xe8/0x120
    [ 1934.608975]  out_of_memory+0x7c/0x570
    [ 1934.612631]  __alloc_pages_nodemask+0xcfc/0xd98
    [ 1934.617158]  alloc_pages_current+0x88/0xf0
    [ 1934.621246]  __page_cache_alloc+0x8c/0xd8
    [ 1934.625247]  page_cache_alloc_inode+0x48/0x58
    [ 1934.629595]  filemap_fault+0x360/0x8e0
    [ 1934.633341]  ext4_filemap_fault+0x38/0x128
    [ 1934.637431]  __do_fault+0x50/0x218
    [ 1934.640822]  __handle_mm_fault+0x69c/0x9c8
    [ 1934.644909]  handle_mm_fault+0xf8/0x200
    [ 1934.648740]  do_page_fault+0x220/0x508
    [ 1934.652477]  do_translation_fault+0xa8/0xbc
    [ 1934.656652]  do_mem_abort+0x68/0x118
    [ 1934.660216]  do_el0_ia_bp_hardening+0x6c/0xd8
    [ 1934.664565]  el0_ia+0x20/0x24
Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

0ab3b159

07 4月, 2022 3 次提交

share_pool: don't trace the invalid spa address · 92408651

由 Ding Tianhong 提交于 4月 07, 2022

ascend inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4M23J
CVE: NA

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

Don't use the spa's va_start if the spa is not valid.
Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

92408651

mm: share_pool: adjust sp_alloc behavior when coredump · 4e2edb08

由 Guo Mengqi 提交于 4月 07, 2022

ascend inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4MUV2
CVE: NA

when sp_alloc is being executed ont the whole sharepool group,
and one process coredumps, allocation will skip the coredumped process and
continue on the rest processes in the group.
Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

4e2edb08

mm: share_pool: adjust sp_make_share_k2u behavior when coredump · 8957c9d1

由 Guo Mengqi 提交于 4月 07, 2022

ascend inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4MUV2
CVE: NA

when k2u is being executed ont the whole sharepool group,
and one process coredumps, k2u will skip the coredumped process and
continue on the rest processes in the group.
Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

8957c9d1

30 12月, 2021 13 次提交

share_pool: Use sharepool_no_page to alloc hugepage · c533562a