mainline inclusion
from mainline-v6.4-rc1
commit 6d7cb549
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I74FG3
CVE: CVE-2023-32255

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6d7cb549c2ca20e1f07593f15e936fd54b763028

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

If client send session setup request with unknown NTLMSSP message type,
session that does not included channel can be created. It will cause
session memleak. because ksmbd_sessions_deregister() does not destroy
session if channel is not included. This patch return error response if
client send the request unknown NTLMSSP message type.

Cc: stable@vger.kernel.org
Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-20593
Signed-off-by: NNamjae Jeon <linkinjeon@kernel.org>
Signed-off-by: NSteve French <stfrench@microsoft.com>
Signed-off-by: NZhaoLong Wang <wangzhaolong1@huawei.com>

Merge Pull Request from: @ci-robot 
 
PR sync from: Liu Shixin <liushixin2@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/5RIDEB6A7NBTUWJUHQL6MOC4ZUD2N323/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1246 

Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @ci-robot 
 
PR sync from: Liu Shixin <liushixin2@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/NL3WSSDH4CG2P2J6NDYTGUIS3A4PSEFY/ 
Fix two bugfix of hugetlb:
1) Invalid use of nr_online_nodes;
2) Inconsistency between 1G hugepage and 2M hugepage.

Peng Liu (2):
  hugetlb: fix wrong use of nr_online_nodes
  hugetlb: fix hugepages_setup when deal with pernode


-- 
2.25.1
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1245 

Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @ci-robot 
 
PR sync from: Tong Tiangen <tongtiangen@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/6SPGFOOWI5JQIZEOAPQCWFRHCMH4UUGY/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1242 

Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

mainline inclusion
from mainline-v6.2-rc1
commit 11aad263
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6SROX
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=11aad2631bf74b3c811dee76154702aab855a323

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

Today with `hugetlb_free_vmemmap=on` the struct page memory that is freed
back to page allocator is as following: for a 2M hugetlb page it will reuse
the first 4K vmemmap page to remap the remaining 7 vmemmap pages, and for a
1G hugetlb it will remap the remaining 4095 vmemmap pages. Essentially,
that means that it breaks the first 4K of a potentially contiguous chunk of
memory of 32K (for 2M hugetlb pages) or 16M (for 1G hugetlb pages). For
this reason the memory that it's free back to page allocator cannot be used
for hugetlb to allocate huge pages of the same size, but rather only of a
smaller huge page size:

Trying to assign a 64G node to hugetlb (on a 128G 2node guest, each node
having 64G):

* Before allocation:
Free pages count per migrate type at order       0      1      2      3
4      5      6      7      8      9     10
...
Node    0, zone   Normal, type      Movable    340    100     32     15
1      2      0      0      0      1  15558

$ echo 32768 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
$ cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
 31987

* After:

Node    0, zone   Normal, type      Movable  30893  32006  31515      7
0      0      0      0      0      0      0

Notice how the memory freed back are put back into 4K / 8K / 16K page
pools. And it allocates a total of 31987 pages (63974M).

To fix this behaviour rather than remapping second vmemmap page (thus
breaking the contiguous block of memory backing the struct pages)
repopulate the first vmemmap page with a new one. We allocate and copy
from the currently mapped vmemmap page, and then remap it later on.
The same algorithm works if there's a pre initialized walk::reuse_page
and the head page doesn't need to be skipped and instead we remap it
when the @addr being changed is the @reuse_addr.

The new head page is allocated in vmemmap_remap_free() given that on
restore there's no need for functional change. Note that, because right
now one hugepage is remapped at a time, thus only one free 4K page at a
time is needed to remap the head page. Should it fail to allocate said
new page, it reuses the one that's already mapped just like before. As a
result, for every 64G of contiguous hugepages it can give back 1G more
of contiguous memory per 64G, while needing in total 128M new 4K pages
(for 2M hugetlb) or 256k (for 1G hugetlb).

After the changes, try to assign a 64G node to hugetlb (on a 128G 2node
guest, each node with 64G):

* Before allocation
Free pages count per migrate type at order       0      1      2      3
4      5      6      7      8      9     10
...
Node    0, zone   Normal, type      Movable      1      1      1      0
0      1      0      0      1      1  15564

$ echo 32768  > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
$ cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
32394

* After:

Node    0, zone   Normal, type      Movable      0     50     97    108
96     81     70     46     18      0      0

In the example above, 407 more hugeltb 2M pages are allocated i.e. 814M out
of the 32394 (64788M) allocated. So the memory freed back is indeed being
used back in hugetlb and there's no massive order-0..order-2 pages
accumulated unused.

[joao.m.martins@oracle.com: v3]
  Link: https://lkml.kernel.org/r/20221109200623.96867-1-joao.m.martins@oracle.com
[joao.m.martins@oracle.com: add smp_wmb() to ensure page contents are visible prior to PTE write]
  Link: https://lkml.kernel.org/r/20221110121214.6297-1-joao.m.martins@oracle.com
Link: https://lkml.kernel.org/r/20221107153922.77094-1-joao.m.martins@oracle.comSigned-off-by: NJoao Martins <joao.m.martins@oracle.com>
Reviewed-by: NMuchun Song <songmuchun@bytedance.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Conflicts:
	mm/hugetlb_vmemmap.c
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>

mainline inclusion
from mainline-v5.19-rc1
commit f87442f4
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6OWV4
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f87442f407af80dac4dc81c8a7772b71b36b2e09

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

Hugepages can be specified to pernode since "hugetlbfs: extend the
definition of hugepages parameter to support node allocation", but the
following problem is observed.

Confusing behavior is observed when both 1G and 2M hugepage is set
after "numa=off".
 cmdline hugepage settings:
  hugepagesz=1G hugepages=0:3,1:3
  hugepagesz=2M hugepages=0:1024,1:1024
 results:
  HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
  HugeTLB registered 2.00 MiB page size, pre-allocated 1024 pages

Furthermore, confusing behavior can be also observed when an invalid node
behind a valid node.  To fix this, never allocate any typical hugepage
when an invalid parameter is received.

Link: https://lkml.kernel.org/r/20220413032915.251254-3-liupeng256@huawei.com
Fixes: b5389086 ("hugetlbfs: extend the definition of hugepages parameter to support node allocation")
Signed-off-by: NPeng Liu <liupeng256@huawei.com>
Reviewed-by: NMike Kravetz <mike.kravetz@oracle.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Liu Yuntao <liuyuntao10@huawei.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Zhenguo Yao <yaozhenguo1@gmail.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>

mainline inclusion
from mainline-v5.19-rc1
commit 0a7a0f6f
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6OWV4
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0a7a0f6f7f3679c906fc55e3805c1d5e2c566f55

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

Patch series "hugetlb: Fix some incorrect behavior", v3.

This series fix three bugs of hugetlb:
1) Invalid use of nr_online_nodes;
2) Inconsistency between 1G hugepage and 2M hugepage;
3) Useless information in dmesg.

This patch (of 4):

Certain systems are designed to have sparse/discontiguous nodes.  In this
case, nr_online_nodes can not be used to walk through numa node.  Also, a
valid node may be greater than nr_online_nodes.

However, in hugetlb, it is assumed that nodes are contiguous.

For sparse/discontiguous nodes, the current code may treat a valid node
as invalid, and will fail to allocate all hugepages on a valid node that
"nid >= nr_online_nodes".

As David suggested:

	if (tmp >= nr_online_nodes)
		goto invalid;

Just imagine node 0 and node 2 are online, and node 1 is offline.
Assuming that "node < 2" is valid is wrong.

Recheck all the places that use nr_online_nodes, and repair them one by
one.

[liupeng256@huawei.com: v4]
  Link: https://lkml.kernel.org/r/20220416103526.3287348-1-liupeng256@huawei.com
Link: https://lkml.kernel.org/r/20220413032915.251254-1-liupeng256@huawei.com
Link: https://lkml.kernel.org/r/20220413032915.251254-2-liupeng256@huawei.com
Fixes: 4178158e ("hugetlbfs: fix issue of preallocation of gigantic pages can't work")
Fixes: b5389086 ("hugetlbfs: extend the definition of hugepages parameter to support node allocation")
Fixes: e79ce983 ("hugetlbfs: fix a truncation issue in hugepages parameter")
Fixes: f9317f77 ("hugetlb: clean up potential spectre issue warnings")
Signed-off-by: NPeng Liu <liupeng256@huawei.com>
Suggested-by: NDavid Hildenbrand <david@redhat.com>
Reviewed-by: NBaolin Wang <baolin.wang@linux.alibaba.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: NDavidlohr Bueso <dave@stgolabs.net>
Reviewed-by: NMike Kravetz <mike.kravetz@oracle.com>
Acked-by: NDavid Hildenbrand <david@redhat.com>
Cc: Zhenguo Yao <yaozhenguo1@gmail.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Liu Yuntao <liuyuntao10@huawei.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Conflicts:
	mm/hugetlb.c
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>

Merge Pull Request from: @ci-robot 
 
PR sync from: Hui Tang <tanghui20@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/YBGT2EBOTBD7PFWTPX3DX74QNLLTRRVR/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1217 

Reviewed-by: Zucheng Zheng <zhengzucheng@huawei.com> 
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

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

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

On Hisilicon LINXICORE9100 cores, sharing tlb entries on two cores when
TTBRx.CNP=1 differs from the standard ARM core. This causes issues when tlb
entries sharing between CPU cores. Avoid these issues by disabling CNP
feature for Hisilicon LINXICORE9100 cores.
Signed-off-by: NTong Tiangen <tongtiangen@huawei.com>

Merge Pull Request from: @ci-robot 
 
PR sync from: Zhang Zekun <zhangzekun11@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/OQE3GDKPH36NAFWPS5QAOYB7RBEGMMIE/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1223 

Reviewed-by: Weilong Chen <chenweilong@huawei.com> 
Reviewed-by: Hanjun Guo <guohanjun@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @ci-robot 
 
PR sync from: "GONG, Ruiqi" <gongruiqi1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/2UQWQFUDJJ3AA4KWKXEAZSYYXWTLW3UM/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1181 

Reviewed-by: sanglipeng <sanglipeng1@jd.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @ci-robot 
 
PR sync from: Wupeng Ma <mawupeng1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/HO6QXFWOBWOT6QFQ3P5VMHCBDUJXVKCI/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1220 

Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @ci-robot 
 
PR sync from: Wupeng Ma <mawupeng1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/DBYQ7YX2NZXNZFVXLHOUZRNTPCMRY75Q/ 
From: Ma Wupeng <mawupeng1@huawei.com>

Fix memory reliable related issues.

Ma Wupeng (3):
  mm: mem_reliable: Fix reliable page counter mismatch problem
  mm: mem_reliable: Update reliable page counter to zero if underflows
  efi: Disable mirror feature during crashkernel


-- 
2.25.1
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1191 

Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @ci-robot 
 
PR sync from: Wupeng Ma <mawupeng1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/JDE2LDXAOHQR2RGYUMOGCZOLNJGVO7EW/ 
From: Ma Wupeng <mawupeng1@huawei.com>

1. fix memleak with efi_fake_mem
2. disable efi_fake_mem support by default for arm64

Ma Wupeng (2):
  efi: Fix UAF for arm64 when enable efi_fake_mem
  config: Disable EFI_FAKE_MEMMAP support for arm64 by default


-- 
2.25.1
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1194 

Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @ci-robot 
 
PR sync from: Liu Shixin <liushixin2@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/LB3KEGYTHZN2JVMAZADIFG73PYZUD2RV/ 
This series patches add swap control for memory cgroup. Patch[2] add page
type in memory.reclaim interface to support reclaim anon pages. Patch[4]
add memory.force_swapin interface to support swap back pages proactively.
Patch[5] add memory.swap.max interface to limit usage of swap for memory
cgroup. Patch[6-7] add memory.swapfile interface to limit available swap
device for memory cgroup.

v2->v3: Enable memcg swap qos for x86_64 and arm64 by default.
v1->v2: Rebase on the latest version and fix merge conflicts.

Liu Shixin (7):
  memcg: add page type to memory.reclaim interface
  memcg: introduce memcg swap qos feature
  memcg: introduce per-memcg swapin interface
  memcg: add restrict to swap to cgroup1
  mm/swapfile: introduce per-memcg swapfile control
  mm: swap_slots: add per-type slot cache
  config: enable memcg swap qos for x86_64 and arm64 by default

Yosry Ahmed (1):
  mm: vmpressure: don't count proactive reclaim in vmpressure


-- 
2.25.1
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1228 

Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @ci-robot 
 
PR sync from: Zheng Zengkai <zhengzengkai@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/523BXW5DZPQ2JZPS3ZS4NBZ6GCRCWCWW/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1227 

Reviewed-by: Jason Zeng <jason.zeng@intel.com> 
Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

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

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

Support memcg swap qos by default on x86_64 and arm64 platforms.
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>

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

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

Since we support per-memcg swapfile control, we need per-type slot
cache to optimize performance. To reduce memory waste, allocate per-type
slot cache when enable feature or online the corresponding swap device.
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>

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

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

With memory.swapfile interface, the avail swap device can be limit for
memcg. The acceptable parameters are 'all', 'none' and valid swap device.
Usage:
	echo /dev/zram0 > memory.swapfile

If the swap device is offline, the swapfile will be fallback to 'none'.
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>

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

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

The memsw can't limit the usage of swap space. Add memory.swap.max
interface to limit the difference value of memsw.usage and memory.usage.
Since a page may occupy both swap entry and a swap cache page, this value
is not exactly equal to swap.usage.
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>

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

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

Add a new per-memcg swapin interface to load data into memory in advance
to improve access efficiency.
Usage:
	# echo 0 > memory.force_swapin
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>

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

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

Introduce memcg swap qos including subsequent sub-features.
Add CONFIG_MEMCG_SWAP_QOS and static key memcg_swap_qos_key.
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>

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

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

Add anon/file to memory.reclaim interface to limit only reclaim one type
pages. The lru algorithm can reclaim cold pages and balance between file
and anon. But it didn't consider the speed of backend device. For example,
if there is zram device, reclaim anon pages might has less impact on
performance. So extend memory.reclaim interface to reclaim one type pages.
Usage:
	"echo <size> type=anon > memory.reclaim"
	"echo <size> type=file > memory.reclaim"

Also compatible with the previous format.
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>

mainline inclusion
from mainline-v6.0-rc1
commit 73b73bac
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I7CGGT
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=73b73bac90d97400e29e585c678c4d0ebfd2680d

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

memory.reclaim is a cgroup v2 interface that allows users to proactively
reclaim memory from a memcg, without real memory pressure.  Reclaim
operations invoke vmpressure, which is used: (a) To notify userspace of
reclaim efficiency in cgroup v1, and (b) As a signal for a memcg being
under memory pressure for networking (see
mem_cgroup_under_socket_pressure()).

For (a), vmpressure notifications in v1 are not affected by this change
since memory.reclaim is a v2 feature.

For (b), the effects of the vmpressure signal (according to Shakeel [1])
are as follows:
1. Reducing send and receive buffers of the current socket.
2. May drop packets on the rx path.
3. May throttle current thread on the tx path.

Since proactive reclaim is invoked directly by userspace, not by memory
pressure, it makes sense not to throttle networking.  Hence, this change
makes sure that proactive reclaim caused by memory.reclaim does not
trigger vmpressure.

[1] https://lore.kernel.org/lkml/CALvZod68WdrXEmBpOkadhB5GPYmCXaDZzXH=yyGOCAjFRn4NDQ@mail.gmail.com/

[yosryahmed@google.com: update documentation]
  Link: https://lkml.kernel.org/r/20220721173015.2643248-1-yosryahmed@google.com
Link: https://lkml.kernel.org/r/20220714064918.2576464-1-yosryahmed@google.comSigned-off-by: NYosry Ahmed <yosryahmed@google.com>
Acked-by: NShakeel Butt <shakeelb@google.com>
Acked-by: NMichal Hocko <mhocko@suse.com>
Acked-by: NDavid Rientjes <rientjes@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: David Hildenbrand <david@redhat.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: NeilBrown <neilb@suse.de>
Cc: Alistair Popple <apopple@nvidia.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Peter Xu <peterx@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5RQLJ

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

5a2451f1 ("x86/fpu: Avoid kabi change caused by struct fpu") will
lead to performance degradation of libmicro pthread_create testcase.
Assuming that no 3rd party driver will reach into struct fpu,
replace kabi fix macro from KABI_DEPRECATE to KABI_BROKEN_REMOVE
for element "union fpregs_state state" of struct fpu.
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

Merge Pull Request from: @ci-robot 
 
PR sync from: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/OUV33PGH22SGOMA622E2MXOQEGDVIIGV/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1221 

Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

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

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

In fio test with iodepth=256 with allowd cpus to 0-255, we observe a
serve performance decrease. The statistic of cache hit rate are
relatively low. Here are some statistics about the iova_cpu_rcahe of
all cpus:

iova alloc order		0	1	2	3	4	5
----------------------------------------------------------------------
average cpu_rcache hit rate	0.9941	0.7408	0.8109	0.8854	0.9082	0.8887

Jobs: 12 (f=12): [R(12)][20.0%][r=1091MiB/s][r=279k IOPS][eta 00m:28s]
Jobs: 12 (f=12): [R(12)][22.2%][r=1426MiB/s][r=365k IOPS][eta 00m:28s]
Jobs: 12 (f=12): [R(12)][25.0%][r=1607MiB/s][r=411k IOPS][eta 00m:27s]
Jobs: 12 (f=12): [R(12)][27.8%][r=1501MiB/s][r=384k IOPS][eta 00m:26s]
Jobs: 12 (f=12): [R(12)][30.6%][r=1486MiB/s][r=380k IOPS][eta 00m:25s]
Jobs: 12 (f=12): [R(12)][33.3%][r=1393MiB/s][r=357k IOPS][eta 00m:24s]
Jobs: 12 (f=12): [R(12)][36.1%][r=1550MiB/s][r=397k IOPS][eta 00m:23s]
Jobs: 12 (f=12): [R(12)][38.9%][r=1485MiB/s][r=380k IOPS][eta 00m:22s]

The under lying hisi sas driver has 16 thread irqs to free iova, but
these irq call back function will only free iovas on 16 certain cpus(cpu{0,
16,32...,240}). For example, thread irq which smp affinity is 0-15, will
only free iova on cpu 0. However, the driver will alloc iova on all
cpus(cpu{0-255}), cpus without free iova in local cpu_rcache need to get
free iovas from iova_rcache->depot. The current size of
iova_rcache->depot max size is 32, and it seems to be too small for 256
users (16 cpus will put iovas to iova_rcache->depot and 240 cpus will
try to get iova from it). Set iova_rcache->depot to 128 can fix the
performance issue, and the performance can return to normal.

iova alloc order		0	1	2	3	4	5
----------------------------------------------------------------------
average cpu_rcache hit rate	0.9925	0.9736	0.9789	0.9867	0.9889	0.9906

Jobs: 12 (f=12): [R(12)][12.9%][r=7526MiB/s][r=1927k IOPS][eta 04m:30s]
Jobs: 12 (f=12): [R(12)][13.2%][r=7527MiB/s][r=1927k IOPS][eta 04m:29s]
Jobs: 12 (f=12): [R(12)][13.5%][r=7529MiB/s][r=1927k IOPS][eta 04m:28s]
Jobs: 12 (f=12): [R(12)][13.9%][r=7531MiB/s][r=1928k IOPS][eta 04m:27s]
Jobs: 12 (f=12): [R(12)][14.2%][r=7529MiB/s][r=1928k IOPS][eta 04m:26s]
Jobs: 12 (f=12): [R(12)][14.5%][r=7528MiB/s][r=1927k IOPS][eta 04m:25s]
Jobs: 12 (f=12): [R(12)][14.8%][r=7527MiB/s][r=1927k IOPS][eta 04m:24s]
Jobs: 12 (f=12): [R(12)][15.2%][r=7525MiB/s][r=1926k IOPS][eta 04m:23s]
Signed-off-by: NZhang Zekun <zhangzekun11@huawei.com>

stable inclusion
from stable-v5.10.180
commit de19d02d734ef29f5dbd2c12fe810fa960ecd83f
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7EDZ3
CVE: CVE-2023-35829

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=de19d02d734ef29f5dbd2c12fe810fa960ecd83f

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

[ Upstream commit 3228cec2 ]

In rkvdec_probe, rkvdec->watchdog_work is bound with
rkvdec_watchdog_func. Then rkvdec_vp9_run may
be called to start the work.

If we remove the module which will call rkvdec_remove
 to make cleanup, there may be a unfinished work.
 The possible sequence is as follows, which will
 cause a typical UAF bug.

Fix it by canceling the work before cleanup in rkvdec_remove.

CPU0                  CPU1

                    |rkvdec_watchdog_func
rkvdec_remove       |
 rkvdec_v4l2_cleanup|
  v4l2_m2m_release  |
    kfree(m2m_dev); |
                    |
                    | v4l2_m2m_get_curr_priv
                    |   m2m_dev->curr_ctx //use

Fixes: cd33c830 ("media: rkvdec: Add the rkvdec driver")
Signed-off-by: NZheng Wang <zyytlz.wz@163.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com>

mainline inclusion
from mainline-v5.11-rc1
commit 8dc4bb58
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7F3HQ
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8dc4bb58a146655eb057247d7c9d19e73928715b

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

virtio-mem soon wants to use offline_and_remove_memory() memory that
exceeds a single Linux memory block (memory_block_size_bytes()). Let's
remove that restriction.

Let's remember the old state and try to restore that if anything goes
wrong. While re-onlining can, in general, fail, it's highly unlikely to
happen (usually only when a notifier fails to allocate memory, and these
are rather rare).

This will be used by virtio-mem to offline+remove memory ranges that are
bigger than a single memory block - for example, with a device block
size of 1 GiB (e.g., gigantic pages in the hypervisor) and a Linux memory
block size of 128MB.

While we could compress the state into 2 bit, using 8 bit is much
easier.

This handling is similar, but different to acpi_scan_try_to_offline():

a) We don't try to offline twice. I am not sure if this CONFIG_MEMCG
optimization is still relevant - it should only apply to ZONE_NORMAL
(where we have no guarantees). If relevant, we can always add it.

b) acpi_scan_try_to_offline() simply onlines all memory in case
something goes wrong. It doesn't restore previous online type. Let's do
that, so we won't overwrite what e.g., user space configured.
Reviewed-by: NWei Yang <richard.weiyang@linux.alibaba.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Wei Yang <richard.weiyang@linux.alibaba.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid Hildenbrand <david@redhat.com>
Link: https://lore.kernel.org/r/20201112133815.13332-28-david@redhat.comSigned-off-by: NMichael S. Tsirkin <mst@redhat.com>
Acked-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7FJB5

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

A warn may be triggered during reboot, as follows:

reboot
  ->kernel_restart
    ->machine_restart
      ->smp_send_stop --- ipi handler set_cpu_online(cpu, false)

balance_callback
-> __balance_callback
  ->push_rt_task
    -> find_lock_lowest_rq  --- offline cpu in vec->mask not be cleared
      -> find_lowest_rq
        -> cpupri_find
          -> cpupri_find_fitness
            -> __cpupri_find [cpumask_and(..., vec->mask)]
    -> set_task_cpu(next_task, lowest_rq->cpu) --- WARN_ON(!oneline(cpu)

So add !cpu_online(lowest_rq->cpu) check before set_task_cpu().
The fix does not completely fix the problem, since cpu_online_mask may
be cleared after check.

Fixes: 4ff9083b ("sched/core: WARN() when migrating to an offline CPU")
Signed-off-by: NHui Tang <tanghui20@huawei.com>

Merge Pull Request from: @ci-robot 
 
PR sync from: Yang Yingliang <yangyingliang@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/ORBGDUHLI4PUVZY5HOH6SBYHKAHHCELI/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1196 

Reviewed-by: zhangyi (F) <yi.zhang@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @ci-robot 
 
PR sync from: Zhong Jinghua <zhongjinghua@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/4GPNRNM6BTL377CSMFTAKUUAS34YECTL/ 
nbd: validate the block size in nbd_set_size

Christoph Hellwig (1):
  nbd: validate the block size in nbd_set_size

Zhong Jinghua (1):
  nbd: fix incomplete validation of ioctl arg


-- 
2.31.1
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1185 

Reviewed-by: Hou Tao <houtao1@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @Hongchen_Zhang 
 
cleanup swiotlb bakcup buffer related code,not used now. 
 
Link:https://gitee.com/openeuler/kernel/pulls/1148 

Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @ci-robot 
 
PR sync from: Liu Shixin <liushixin2@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/XR7NP7IV7MBMBYASGLC3ZEO7URQ2IHV7/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1190 

Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

hulk inclusion
category: performance
bugzilla: https://gitee.com/openeuler/kernel/issues/I7F4XV

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

The tmp variable is used to copy_to_user(), it has better
performance if the address accesseed by ldp instruction
is 16 bytes aligned on arm64.

The performance of nginx test is improved after this patch:
http "Connection: close"	1.11%
http "Connection: keep-alive"	2.11%
https "Connection: close"	1.56%
https "Connection: keep-alive"	0.18%
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

Merge Pull Request from: @xiao_jiang_shui 
 
When the current HiSilicon USB xhci controller formats the faulty
U disk, it will trigger a controller exception error. This will
cause errors in the control logic of the xhci controller and
driver software. In the end, all USB devices on the xhci controller
cannot be used.

By introducing a noop command operation, restore the logic of the
xhci controller and driver software, and restore all USB devices
on the xhci controller to normal.

issue：https://gitee.com/openeuler/kernel/issues/I7DZ8S 
 
Link:https://gitee.com/openeuler/kernel/pulls/1159 

Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

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

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

EFI_FAKE_MEMMAP is used specific memory range by updating original
(firmware provided) EFI memmap. This can only be used for debug
propose. Disable it by default.
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>

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

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

Efi fake mem support for arm64 is introduced for debug propose
only. However efi_memmap_init_late in arm_enable_runtime_services
will free this memory which will lead to UAF on efi.memmap.map.

In order to slove this, clear efi.memmap.flags to skip free.
Since efi map is never freed in arm64, this will not lead to
memroy leak.
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>

Merge Pull Request from: @ci-robot 
 
PR sync from: Chen Zhongjin <chenzhongjin@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/7SX6VMPGMA422BLUDHM6SXV5PQWXROF3/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1178 

Reviewed-by: Xu Kuohai <xukuohai@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

hulk inclusion
category: cleanup
bugzilla: https://gitee.com/openeuler/kernel/issues/I6WKXZ
CVE: NA

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

If system have no mirrored memory or use crashkernel.high while
kernelcore=mirror is enabled in cmdline, during crashkernel,
there will be limited mirrored memory and this usually lead to
OOM.

To solve this problem, disable mirror feature during crashkernel.
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>