Merge Pull Request from: @haochengxie 
 
This PR includes minimum essential patches to enable AMD EPYC Genoa platform.

Issue
Enable AMD EPYC Genoa platform support for openEuler
#I5NGRU

Backporting Patches included
crypto:
3438de03 5.15 crypto: ccp - Add support for new CCP/PSP device ID

hwmon：
2ade8fc6 5.14 x86/amd_nb: Add AMD family 19h model 50h PCI ids (front patch)
c8d0d3fa 5.12 hwmon: (k10temp) Zen3 Ryzen Desktop CPUs support(front patch)
02c9dce4 5.15 hwmon: (k10temp) support Zen3 APUs
128066c8 5.15 hwmon: (k10temp) Add additional missing Zen2 and Zen3 APUs
02a2484c 5.15 hwmon: (k10temp) Don't show Tdie for all Zen/Zen2/Zen3 CPU/APU
0e3f52bb 5.15 hwmon: (k10temp) Rework the temperature offset calculation
25572c81 5.15 hwmon: (k10temp) Add support for yellow carp
23c69b90 5.15 hwmon: (k10temp) Remove residues of current and voltage
f707bcb5 5.17 hwmon: (k10temp) Remove unused definitions
4fb0abfe 5.17 x86/amd_nb: Add AMD Family 19h Models (10h-1Fh) and (A0h-AFh) PCI IDs
3cf90efa 5.17 hwmon: (k10temp) Add support for AMD Family 19h Models 10h-1Fh and A0h-AFh
8bb050cd 5.17 hwmon: (k10temp) Support up to 12 CCDs on AMD Family of processors

EDAC：
f9571124 5.17 EDAC: Add RDDR5 and LRDDR5 memory types
e2be5955 5.17 EDAC/amd64: Add support for AMD Family 19h Models 10h-1Fh and A0h-AFh
75aeaaf2 5.18 EDAC/amd64: Set memory type per DIMM
2151c84e 5.18 EDAC/amd64: Add new register offset support and related changes

MCE:
94a311ce 5.14 x86/MCE/AMD, EDAC/mce_amd: Add new SMCA bank types
5176a93a 5.17 x86/MCE/AMD, EDAC/mce_amd: Add new SMCA bank types
f38ce910 5.16 x86/MCE/AMD: Export smca_get_bank_type symbol
0b746e8c 5.17 x86/MCE/AMD, EDAC/amd64: Move address translation to AMD64 EDAC
91f75eb4 5.17 x86/MCE/AMD, EDAC/mce_amd: Support non-uniform MCA bank type enumeration

kvm Essential:
03ca4589 5.13 KVM: x86: Prevent KVM SVM from loading on kernels with 5-level paging
43e540cc 5.15 KVM: SVM: Add 5-level page table support for SVM
cb0f722a 5.15 KVM: x86/mmu: Support shadowing NPT when 5-level paging is enabled
39150352 5.17 KVM: x86: SVM: move avic definitions from AMD's spec to svm.h
4a204f78 5.18-rc1 KVM: SVM: Allow AVIC support on system w/ physical APIC ID > 255 
 
Link:https://gitee.com/openeuler/kernel/pulls/175 
Reviewed-by: Kevin Zhu <zhukeqian1@huawei.com> 
Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

Merge Pull Request from: @allen-shi 
 
This PR is to add vfio_group_iommu_domain interface to support DLB. Without this patch, OOT DLB kernel driver failed to build with error due to lack of vfio_group_iommu_domain interface support. 

 **Intel-Kernel Issue** 
[#I5BEBU](https://gitee.com/openeuler/intel-kernel/issues/I5BEBU)

 **Test** 
1. Built and run the kernel successfully
2. DLB kernel driver built successfully and insmod dlb2.ko successfully

 **Known Issue** 
N/A

 **Default config change** 
N/A 
 
Link:https://gitee.com/openeuler/kernel/pulls/168 
Reviewed-by: Kevin Zhu <zhukeqian1@huawei.com> 
Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Reviewed-by: Chen Wei <chenwei@xfusion.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

Merge Pull Request from: @leoliu-oc 
 
This driver provides kernel-side support for the Random Number Generator hardware found on Zhaoxin based motherboards.

### Issue
https://gitee.com/openeuler/kernel/issues/I5SMFS

### Test
[zx@openeuler ~]$lsmod | grep zhaoxin_rng

### Known Issue
N/A

### Default config change
CONFIG_HW_RANDOM_ZHAOXIN=m 
 
Link:https://gitee.com/openeuler/kernel/pulls/128 
Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

Merge Pull Request from: @wangwensheng4 
 
[Description]​
Sharepool is used for shared memory between user processes. The main feature is that the processes that share the memory use the same virtual address.
This patch set contains code optimizations and bugfixes for sharepool, including the following scopes:
1. Fix code style warnings;
2. Delete unused interfaces and source line that cannot reach anyway;
3. Optimizations for readability;
4. Bugfix;

[Testing]
CONFIG_ASCEND_FEATURES=y
CONFIG_ASCEND_SHARE_POOL=y
CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED=y or hugevmalloc=on for kernel bootargs
The body for this feature is in mm/sharepool.c and you should supply another modules that could
call its exported symbols to test this feature. 
 
Link:https://gitee.com/openeuler/kernel/pulls/190 
Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

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

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

The address range of dvpp is [start, start + size), the value of
start + size can be out of the address range.
Signed-off-by: NZhou Guanghui <zhouguanghui1@huawei.com>

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

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

If current->flag is set as PF_MEMALLOC, memcgroup will not check
current's allocation against memory use limit, which cause system run
out of memory.

According to
https://lkml.indiana.edu/hypermail/linux/kernel/0911.2/00576.html,
PF_MEMALLOC shall only be used when more memory are sure to be freed as a
result of this allocation.

Do not use PF_MEMALLOC, rather, remove __GFP_RECLAIM from gfp_mask to
ensure no reclaim.
Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>

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

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

When we allocate memory using SP_HUGEPAGE, we would try normal pages when
there was no enough hugepages. The specified numa node information would
get lost when we fallback to normal pages. The result is that we could
allocate memory from other numa node than what we have specified.

The soultion is to rebind the node before retrying.
Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>