提交 · 5.10.0-22.0.0 · openeuler / Kernel

29 11月, 2021 31 次提交

printk: enable zap_locks on X86 and ARM64 · 31ef67b0

由 Cheng Jian 提交于 11月 29, 2021

hulk inclusion
category: bugfix
bugzilla: 34546, https://gitee.com/openeuler/kernel/issues/I4JKT1
CVE: NA

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

Any architecture that involves an NMI should be treated with caution.
For example, the X86 architecture and ARM64 enabled PSEUDO NMI.
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

31ef67b0

printk: fix potential deadlock in printk() · c8ccc56f

由 Chen Zhou 提交于 11月 29, 2021

hulk inclusion
category: bugfix
bugzilla: 34546, https://gitee.com/openeuler/kernel/issues/I4JKT1
CVE: NA

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

When one cpu panic, the panic cpu send NMI to other cpus, if one of
the non-panic cpus is in printk() and get stopped in function
console_trylock_spinning() before releasing sem->lock, the panic cpu
may spin waiting sem->lock in function console_trylock_spinning().

Reinit console_sem in zap_lock() to fix this.
Signed-off-by: NChen Zhou <chenzhou10@huawei.com>
Reviewed-by: NJian Cheng <cj.chengjian@huawei.com>
Signed-off-by: NChen Zhou <chenzhou10@huawei.com>
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

c8ccc56f

printk/panic: prevent spin waiting in printk() · 721cc05b

由 Chen Zhou 提交于 11月 29, 2021

hulk inclusion
category: bugfix
bugzilla: 41832, https://gitee.com/openeuler/kernel/issues/I4JKT1
CVE: NA

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

When one cpu panic, the panic cpu send NMI to other cpus, if one of
the non-panic cpus is in printk() and get stopped before release
console_waiter, the panic cpu may spin waiting.

Here just release console_waiter directly after all non-panic cpus
get stopped.
Signed-off-by: NChen Zhou <chenzhou10@huawei.com>
Reviewed-by: NJian Cheng <cj.chengjian@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NChen Zhou <chenzhou10@huawei.com>
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

721cc05b

panic/printk: fix zap_lock · 051d7aae

由 Cheng Jian 提交于 11月 29, 2021

hulk inclusion
category: bugfix
bugzilla: 34546, https://gitee.com/openeuler/kernel/issues/I4JKT1
CVE: NA

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

There are two problems with the implementation and use of
zap_lock().

Firstly, This console_sem does not require reinit in zap_lock(),
this is because:

1). printk() itself does try_lock() and skips console handling
when the semaphore is not available.

2). panic() tries to push the messages later in console_flush_on_panic().
It ignores the semaphore. Also most console drivers ignore their
internal locks because oops_in_progress is set by bust_spinlocks().

Secondly, The situation is more complicated when NMI is not used.

1). Non-stopped CPUs are in unknown state, most likely in a busy loop.
Nobody knows whether printk() is repeatedly called in the loop.
When it was called, re-initializing any lock would cause double
unlock and deadlock.

2). It would be possible to add some more hacks. One problem is that
there are two groups of users. One prefer to risk a deadlock and
have a chance to see the messages. Others prefer to always
reach emergency_restart() and reboot the machine.

Fixes: d0dfaa87c2aa ("printk/panic: Avoid deadlock in printk()")
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NChen Zhou <chenzhou10@huawei.com>
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

051d7aae

printk/panic: Avoid deadlock in printk() · 0cc12581

由 Cheng Jian 提交于 11月 29, 2021

hulk inclusion
category: bugfix
bugzilla: 34546, https://gitee.com/openeuler/kernel/issues/I4JKT1
CVE: NA

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

A deadlock caused by logbuf_lock occurs when panic:

	a) Panic CPU is running in non-NMI context
	b) Panic CPU sends out shutdown IPI via NMI vector
	c) One of the CPUs that we bring down via NMI vector holded logbuf_lock
	d) Panic CPU try to hold logbuf_lock, then deadlock occurs.

we try to re-init the logbuf_lock in printk_safe_flush_on_panic()
to avoid deadlock, but it does not work here, because :

Firstly, it is inappropriate to check num_online_cpus() here.
When the CPU bring down via NMI vector, the panic CPU willn't
wait too long for other cores to stop, so when this problem
occurs, num_online_cpus() may be greater than 1.

Secondly, printk_safe_flush_on_panic() is called after panic
notifier callback, so if printk() is called in panic notifier
callback, deadlock will still occurs. Eg, if ftrace_dump_on_oops
is set, we print some debug information, it will try to hold the
logbuf_lock.

To avoid this deadlock, attempt to re-init logbuf_lock from panic
CPU before panic_notifier_list callback,
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NChen Zhou <chenzhou10@huawei.com>
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

0cc12581

lib/clear_user: ensure loop in __arch_clear_user cache-aligned v2 · 66294cf3

由 Cheng Jian 提交于 11月 29, 2021

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4K6CJ
CVE: NA

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

We must ensure that the following four instructions are cache-aligned.
Otherwise, it will cause problems with the performance of libMicro
pread.

1:
        # uao_user_alternative 9f, str, sttr, xzr, x0, 8
        str     xzr, [x0], #8
        nop
        subs    x1, x1, #8
        b.pl    1b

with this patch:

             prc thr   usecs/call      samples   errors cnt/samp     size
pread_z100     1   1      5.88400          807        0 1            102400

The result of pread can range from 5 to 9 depending on  the
alignment performance of this function.
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

66294cf3

mm/cdm: enable CONFIG_COHERENT_DEVICE in openeuler_defconfig · 52dce6f9

由 Lijun Fang 提交于 11月 29, 2021

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

enable CONFIG_COHERENT_DEVICE in openeuler_defconfig
Signed-off-by: NLijun Fang <fanglijun3@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

52dce6f9

mm: Be allowed to alloc CDM node memory for MPOL_BIND · c1434668

由 Lijun Fang 提交于 11月 29, 2021

ascend inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4JMLR
CVE: NA
-----------------

CDM nodes should not be part of mems_allowed, However,
It must be allowed to alloc from CDM node, when mpol->mode was MPOL_BIND.
Signed-off-by: NLijun Fang <fanglijun3@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

c1434668

mm: Add DDR and HBM to nodes by cmdline · a9850de3

由 Lijun Fang 提交于 11月 29, 2021

ascend inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4JMLR
CVE: NA
---------------------

When the kernel boot, we need to determine DDR or HBM,
and add them to nodes by parse cmdline, instead of memory hotplug.
Signed-off-by: NLijun Fang <fanglijun3@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

a9850de3

mm: Change mbind(MPOL_BIND) implementation for CDM nodes · c80f1cb2

由 Anshuman Khandual 提交于 11月 29, 2021

ascend inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4JMLR
CVE: NA
-------------------

CDM nodes need a way of explicit memory allocation mechanism from the user
space. After the previous FALLBACK zonelist rebuilding process changes, the
mbind(MPOL_BIND) based allocation request fails on the CDM node. This is
because allocation requesting local node's FALLBACK zonelist is selected
for further nodemask processing targeted at MPOL_BIND implementation. As
the CDM node's zones are not part of any other regular node's FALLBACK
zonelist, the allocation simply fails without getting any valid zone. The
allocation requesting node is always going to be different than the CDM
node which does not have any CPU. Hence MPOL_MBIND implementation must
choose given CDM node's FALLBACK zonelist instead of the requesting local
node's FALLBACK zonelist. This implements that change.
Signed-off-by: NAnshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: NLijun Fang <fanglijun3@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

c80f1cb2

mm: Ignore cpuset enforcement when allocation flag has __GFP_THISNODE · b49907cc

由 Anshuman Khandual 提交于 11月 29, 2021

ascend inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4JMLR
CVE: NA
-------------------

__GFP_THISNODE specifically asks the memory to be allocated from the given
node. Not all the requests that end up in __alloc_pages_nodemask() are
originated from the process context where cpuset makes more sense. The
current condition enforces cpuset limitation on every allocation whether
originated from process context or not which prevents __GFP_THISNODE
mandated allocations to come from the specified node. In context of the
coherent device memory node which is isolated from all cpuset nodemask
in the system, it prevents the only way of allocation into it which has
been changed with this patch.
Signed-off-by: NAnshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: NLijun Fang <fanglijun3@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

b49907cc

mm: Ignore madvise(MADV_MERGEABLE) request for VM_CDM marked VMAs · 5abfd909

由 Anshuman Khandual 提交于 11月 29, 2021

ascend inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4JMLR
CVE: NA
-------------------

VMA containing CDM memory should be excluded from KSM merging. This change
makes madvise(MADV_MERGEABLE) request on target VMA to be ignored.
Signed-off-by: NAnshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: NLijun Fang <fanglijun3@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

5abfd909

mm: Exclude CDM marked VMAs from auto NUMA · dcb0ac35

由 Anshuman Khandual 提交于 11月 29, 2021

ascend inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4JMLR
CVE: NA
-------------------

Kernel cannot track device memory accesses behind VMAs containing CDM
memory. Hence all the VM_CDM marked VMAs should not be part of the auto
NUMA migration scheme. This patch also adds a new function is_cdm_vma()
to detect any VMA marked with flag VM_CDM.
Signed-off-by: NAnshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: NLijun Fang <fanglijun3@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

dcb0ac35

mm: Exclude CDM nodes from task->mems_allowed and root cpuset · ebde394a

由 Anshuman Khandual 提交于 11月 29, 2021

ascend inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4JMLR
CVE: NA
-------------------

Task struct's mems_allowed element decides the final nodemask from which
memory can be allocated in the task context irrespective any applicable
memory policy. CDM nodes should not be used for user allocations, its one
of the overall requirements of it's isolation. So they should not be part
of any task's mems_allowed nodemask. System RAM nodemask is used instead
of node_states[N_MEMORY] nodemask during mems_allowed initialization and
it's update during memory hotlugs.
Signed-off-by: NAnshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: NLijun Fang <fanglijun3@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

ebde394a

mm: Tag VMA with VM_CDM flag explicitly during mbind(MPOL_BIND) and page fault · 225dda6b

由 Anshuman Khandual 提交于 11月 29, 2021

ascend inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4JMLR
CVE: NA
-------------------

Mark all the applicable VMAs with VM_CDM explicitly during mbind(MPOL_BIND)
call if the user provided nodemask has a CDM node.

Mark the corresponding VMA with VM_CDM flag if the allocated page happens
to be from a CDM node. This can be expensive from performance stand point.
There are multiple checks to avoid an expensive page_to_nid lookup but it
can be optimized further.
Signed-off-by: NAnshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: NLijun Fang <fanglijun3@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

225dda6b

mm: Enable Buddy allocation isolation for CDM nodes · a8cc75dd

由 Anshuman Khandual 提交于 11月 29, 2021

ascend inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4JMLR
CVE: NA
-------------------

This implements allocation isolation for CDM nodes in buddy allocator by
discarding CDM memory zones all the time except in the cases where the gfp
flag has got __GFP_THISNODE or the nodemask contains CDM nodes in cases
where it is non NULL (explicit allocation request in the kernel or user
process MPOL_BIND policy based requests).
Signed-off-by: NAnshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: NLijun Fang <fanglijun3@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

a8cc75dd

mm: Change generic FALLBACK zonelist creation process · 5f387449

由 Anshuman Khandual 提交于 11月 29, 2021

ascend inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4JMLR
CVE: NA
-------------------

Kernel allocation to CDM node has already been prevented by putting it's
entire memory in ZONE_MOVABLE. But the CDM nodes must also be isolated
from implicit allocations happening on the system.

Any isolation seeking CDM node requires isolation from implicit memory
allocations from user space but at the same time there should also have
an explicit way to do the memory allocation.

Platform node's both zonelists are fundamental to where the memory comes
from when there is an allocation request. In order to achieve these two
objectives as stated above, zonelists building process has to change as
both zonelists (i.e FALLBACK and NOFALLBACK) gives access to the node's
memory zones during any kind of memory allocation. The following changes
are implemented in this regard.

* CDM node's zones are not part of any other node's FALLBACK zonelist
* CDM node's FALLBACK list contains it's own memory zones followed by
  all system RAM zones in regular order as before
* CDM node's zones are part of it's own NOFALLBACK zonelist

These above changes ensure the following which in turn isolates the CDM
nodes as desired.

* There wont be any implicit memory allocation ending up in the CDM node
* Only __GFP_THISNODE marked allocations will come from the CDM node
* CDM node memory can be allocated through mbind(MPOL_BIND) interface
* System RAM memory will be used as fallback option in regular order in
  case the CDM memory is insufficient during targted allocation request

Sample zonelist configuration:

[NODE (0)]						RAM
        ZONELIST_FALLBACK (0xc00000000140da00)
                (0) (node 0) (DMA     0xc00000000140c000)
                (1) (node 1) (DMA     0xc000000100000000)
        ZONELIST_NOFALLBACK (0xc000000001411a10)
                (0) (node 0) (DMA     0xc00000000140c000)
[NODE (1)]						RAM
        ZONELIST_FALLBACK (0xc000000100001a00)
                (0) (node 1) (DMA     0xc000000100000000)
                (1) (node 0) (DMA     0xc00000000140c000)
        ZONELIST_NOFALLBACK (0xc000000100005a10)
                (0) (node 1) (DMA     0xc000000100000000)
[NODE (2)]						CDM
        ZONELIST_FALLBACK (0xc000000001427700)
                (0) (node 2) (Movable 0xc000000001427080)
                (1) (node 0) (DMA     0xc00000000140c000)
                (2) (node 1) (DMA     0xc000000100000000)
        ZONELIST_NOFALLBACK (0xc00000000142b710)
                (0) (node 2) (Movable 0xc000000001427080)
[NODE (3)]						CDM
        ZONELIST_FALLBACK (0xc000000001431400)
                (0) (node 3) (Movable 0xc000000001430d80)
                (1) (node 0) (DMA     0xc00000000140c000)
                (2) (node 1) (DMA     0xc000000100000000)
        ZONELIST_NOFALLBACK (0xc000000001435410)
                (0) (node 3) (Movable 0xc000000001430d80)
[NODE (4)]						CDM
        ZONELIST_FALLBACK (0xc00000000143b100)
                (0) (node 4) (Movable 0xc00000000143aa80)
                (1) (node 0) (DMA     0xc00000000140c000)
                (2) (node 1) (DMA     0xc000000100000000)
        ZONELIST_NOFALLBACK (0xc00000000143f110)
                (0) (node 4) (Movable 0xc00000000143aa80)
Signed-off-by: NAnshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: NLijun Fang <fanglijun3@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

5f387449

mm: Define coherent device memory (CDM) node · 4cda25d3

由 Anshuman Khandual 提交于 11月 29, 2021

ascend inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4JMLR
CVE: NA
-------------------

There are certain devices like specialized accelerator, GPU cards, network
cards, FPGA cards etc which might contain onboard memory which is coherent
along with the existing system RAM while being accessed either from the CPU
or from the device. They share some similar properties with that of normal
system RAM but at the same time can also be different with respect to
system RAM.

User applications might be interested in using this kind of coherent device
memory explicitly or implicitly along side the system RAM utilizing all
possible core memory functions like anon mapping (LRU), file mapping (LRU),
page cache (LRU), driver managed (non LRU), HW poisoning, NUMA migrations
etc. To achieve this kind of tight integration with core memory subsystem,
the device onboard coherent memory must be represented as a memory only
NUMA node. At the same time arch must export some kind of a function to
identify of this node as a coherent device memory not any other regular
cpu less memory only NUMA node.

After achieving the integration with core memory subsystem coherent device
memory might still need some special consideration inside the kernel. There
can be a variety of coherent memory nodes with different expectations from
the core kernel memory. But right now only one kind of special treatment is
considered which requires certain isolation.

Now consider the case of a coherent device memory node type which requires
isolation. This kind of coherent memory is onboard an external device
attached to the system through a link where there is always a chance of a
link failure taking down the entire memory node with it. More over the
memory might also have higher chance of ECC failure as compared to the
system RAM. Hence allocation into this kind of coherent memory node should
be regulated. Kernel allocations must not come here. Normal user space
allocations too should not come here implicitly (without user application
knowing about it). This summarizes isolation requirement of certain kind of
coherent device memory node as an example. There can be different kinds of
isolation requirement also.

Some coherent memory devices might not require isolation altogether after
all. Then there might be other coherent memory devices which might require
some other special treatment after being part of core memory representation
. For now, will look into isolation seeking coherent device memory node not
the other ones.

To implement the integration as well as isolation, the coherent memory node
must be present in N_MEMORY and a new N_COHERENT_DEVICE node mask inside
the node_states[] array. During memory hotplug operations, the new nodemask
N_COHERENT_DEVICE is updated along with N_MEMORY for these coherent device
memory nodes. This also creates the following new sysfs based interface to
list down all the coherent memory nodes of the system.

	/sys/devices/system/node/is_cdm_node

Architectures must export function arch_check_node_cdm() which identifies
any coherent device memory node in case they enable CONFIG_COHERENT_DEVICE.
Signed-off-by: NAnshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: NLijun Fang <fanglijun3@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

4cda25d3

fs/dcache.c: avoid softlock since too many negative dentry · c44e1f78

由 yangerkun 提交于 11月 29, 2021

hulk inclusion
category: bugfix
bugzilla: 185805, https://gitee.com/openeuler/kernel/issues/I4JX0L
CVE: NA

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

Parallel thread to add negative dentry under root dir. Sometimes later,
'systemctl daemon-reload' will report softlockup since
__fsnotify_update_child_dentry_flags need update all child under root
dentry without distinguish does it active or not. It will waste so long
time with catching d_lock of root dentry. And other thread try to
spin_lock d_lock will run overtime.

Limit negative dentry under dir can avoid this.
Signed-off-by: Nyangerkun <yangerkun@huawei.com>
Reviewed-by: NMiao Xie <miaoxie@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

Conflicts:
	fs/dcache.c
	include/linux/dcache.h
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

c44e1f78

fs/dcache.c: avoid panic while lockref of dentry overflow · 6a8c6793

由 yangerkun 提交于 11月 29, 2021

hulk inclusion
category: bugfix
bugzilla: 185799, https://gitee.com/openeuler/kernel/issues/I4JWYM
CVE: NA

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

We use lockref for dentry reference without notice that so many negative
dentry under one dir can lead to overflow of lockref. This can lead to
system crash if we do this under root dir.

Since there is not a perfect solution, we just limit max number of
dentry count up to INT_MAX / 2. Also, it will cost a lot of time from
INT_MAX / 2 to INT_MAX, so we no need to do this under protection of
dentry lock.

Also, we limit the FILES_MAX to INT_MAX / 2, since a lot open for
same file can lead to overflow too.

Changelog:
v1->v2: add a function to do check / add a Macro to mean INT_MAX / 2
Signed-off-by: Nyangerkun <yangerkun@huawei.com>
Reviewed-by: NMiao Xie <miaoxie@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

Conflicts:
	fs/dcache.c
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

6a8c6793

ACPI/MPAM: Use acpi_map_pxm_to_node() to get node id for memory node · 0e797399

由 Wang ShaoBo 提交于 11月 29, 2021

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

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

Proximity domain of Memory MSC node cannot be treated as node id for
components' index, we should use acpi_map_pxm_to_node() to get the exact
node id anyway, for instance, after DIE interleaving, we can only use
node id instead, for pxm is discontinuous at this time.
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

0e797399

arm64/mpam: Fix use-after-free in mkdir_resctrl_prepare() · e163ff16

由 Wang ShaoBo 提交于 11月 29, 2021

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4K272
CVE: NA

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

We add label out_free_rdtgrp for handling error branch when it happened
before rmid and closid allocation, in case of reusing rdtgrp after freeing.

Fixes: 0b16164d ("arm64/mpam: Remap reqpartid,pmg to rmid and intpartid to closid")
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

e163ff16

mm/page_cache_limit: add support for droping caches for target node · e56e8310