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

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

Support to print rootfs files and tmpfs files that having pages charged
in given memory cgroup. The files infomations can be printed through
interface "memory.memfs_files_info" or printed when OOM is triggered.

In order not to flush memory logs, we limit the maximum number of files
to be printed when oom through interface "max_print_files_in_oom". And
in order to filter out small files, we limit the minimum size of files
that can be printed through interface "size_threshold".
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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>

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>

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>

Ramaxel inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4ZR0O
CVE: NA

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

There are some issues of the driver that cannot be fixed now.
The driver is not good enough for the LTS quality requirements
of openEuler，so remove it.
Signed-off-by: NYanling Song <songyl@ramaxel.com>
Reviewed-by: NYang Gan <yanggan@ramaxel.com>
Acked-by: NXie Xiuqi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

Ramaxel inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4ZR0O
CVE: NA

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

There are some issues of the driver that cannot be fixed now.
The driver is not good enough for the LTS quality requirements of
openEuler，so remove it.
Signed-off-by: NYun Xu <xuyun@ramaxel.com>
Signed-off-by: NYanling Song <songyl@ramaxel.com>
Reviewed-by: NYun Xu <xuyun@ramaxel.com>
Acked-by: NXie Xiuqi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.16-rc4
commit 59f09ae8
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4Z2Z9
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=59f09ae8fac4a990070fc6bdc889d0e0118664ea

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

This trivial function is called ~90,000 times on 256 cpus hosts,
when reading /proc/net/netstat. And this number keeps inflating.

Inlining it saves many cycles.
Signed-off-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NCao Wangbao <caowangbao@huawei.com>
Reviewed-by: NWu Changye <wuchangye@huawei.com>
Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.17-rc5
commit cc8f7fe1
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4Z2IA
CVE: CVE-2022-0494

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

Add __GFP_ZERO flag for alloc_page in function bio_copy_kern to initialize
the buffer of a bio.
Signed-off-by: NHaimin Zhang <tcs.kernel@gmail.com>
Reviewed-by: NChaitanya Kulkarni <kch@nvidia.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20220216084038.15635-1-tcs.kernel@gmail.comSigned-off-by: NJens Axboe <axboe@kernel.dk>

Conflict: commit ce288e05 ("block: remove BLK_BOUNCE_ISA support")
is not backported.
Signed-off-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline
commit ebe48d36
category: bugfix
bugzilla: 186409, https://gitee.com/openeuler/kernel/issues/I4YXSX
CVE: CVE-2022-0886

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

The maximum message size that can be send is bigger than
the  maximum site that skb_page_frag_refill can allocate.
So it is possible to write beyond the allocated buffer.

Fix this by doing a fallback to COW in that case.

v2:

Avoid get get_order() costs as suggested by Linus Torvalds.

Fixes: cac2661c ("esp4: Avoid skb_cow_data whenever possible")
Fixes: 03e2a30f ("esp6: Avoid skb_cow_data whenever possible")
Reported-by: Nvalis <sec@valis.email>
Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: NXu Jia <xujia39@huawei.com>
Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.15-rc1
commit 723783d0
category: bugfix
bugzilla: 186409, https://gitee.com/openeuler/kernel/issues/I4YXSX
CVE: CVE-2022-0886

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

Both SKB_FRAG_PAGE_ORDER are defined to the same value in
net/core/sock.c and drivers/vhost/net.c.

Move the SKB_FRAG_PAGE_ORDER definition to net/core/sock.h,
as both net/core/sock.c and drivers/vhost/net.c include it,
and it seems a reasonable file to put the macro.
Signed-off-by: NYunsheng Lin <linyunsheng@huawei.com>
Acked-by: NJason Wang <jasowang@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NXu Jia <xujia39@huawei.com>
Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

euleros inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4YW86

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

When building with defconfig on arm32, we got a compile error:
./include/linux/page-flags-layout.h:95:2: error: #error "Not enough bits in page flags"
   95 | #error "Not enough bits in page flags"
      |  ^~~~~

Limit PG_reserve_pgflag_0 and PG_reserve_pgflag_1 to compile only on
X86_64 and ARM64 to resolve this issue.

Fixes: afdf2a6c ("kabi: Add reserved page and gfp flags for future extension")
Signed-off-by: Neillon <yezhenyu2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: 46904, https://gitee.com/openeuler/kernel/issues/I4YXOA

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

When building with defconfig on arm32, we got a compile error:
./include/linux/page-flags-layout.h:95:2: error: #error "Not enough bits in page flags"
   95 | #error "Not enough bits in page flags"
      |  ^~~~~

Limit PG_pool to compile only on X86_64 and ARM64 to resolve this issue.
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.17-rc8
commit 0c4bcfde
category: bugfix
bugzilla: 186448, https://gitee.com/openeuler/kernel/issues/I4YS7O
CVE: CVE-2022-1011

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

Because create a new user_pages in fuse_args, to fix kabi change.

Signed-off-by: Zhang Wensheng zhangwensheng5@huawei.com
Reviewed-by: NHou Tao <houtao1@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.17-rc8
commit 0c4bcfde
category: bugfix
bugzilla: 186448, https://gitee.com/openeuler/kernel/issues/I4YS7O
CVE: CVE-2022-1011

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

In FOPEN_DIRECT_IO mode, fuse_file_write_iter() calls
fuse_direct_write_iter(), which normally calls fuse_direct_io(), which then
imports the write buffer with fuse_get_user_pages(), which uses
iov_iter_get_pages() to grab references to userspace pages instead of
actually copying memory.

On the filesystem device side, these pages can then either be read to
userspace (via fuse_dev_read()), or splice()d over into a pipe using
fuse_dev_splice_read() as pipe buffers with &nosteal_pipe_buf_ops.

This is wrong because after fuse_dev_do_read() unlocks the FUSE request,
the userspace filesystem can mark the request as completed, causing write()
to return. At that point, the userspace filesystem should no longer have
access to the pipe buffer.

Fix by copying pages coming from the user address space to new pipe
buffers.
Reported-by: NJann Horn <jannh@google.com>
Fixes: c3021629 ("fuse: support splice() reading from fuse device")
Cc: <stable@vger.kernel.org>
Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
Signed-off-by: NZhang Wensheng <zhangwensheng5@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.17-rc1
commit 722d9484
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4YD3S
CVE: CVE-2022-0185

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

The "PAGE_SIZE - 2 - size" calculation in legacy_parse_param() is an
unsigned type so a large value of "size" results in a high positive
value instead of a negative value as expected.  Fix this by getting rid
of the subtraction.
Signed-off-by: NJamie Hill-Daniel <jamie@hill-daniel.co.uk>
Signed-off-by: NWilliam Liu <willsroot@protonmail.com>
Tested-by: NSalvatore Bonaccorso <carnil@debian.org>
Tested-by: NThadeu Lima de Souza Cascardo <cascardo@canonical.com>
Acked-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NLuo Meng <luomeng12@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.17-rc5
commit e0caaf75
category: bugfix
bugzilla: 186205 https://gitee.com/openeuler/kernel/issues/I4YQRW
CVE: CVE-2022-24448

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

Commit ac795161 (NFSv4: Handle case where the lookup of a directory
fails) [1], part of Linux since 5.17-rc2, introduced a regression, where
a symbolic link on an NFS mount to a directory on another NFS does not
resolve(?) the first time it is accessed:
Reported-by: NPaul Menzel <pmenzel@molgen.mpg.de>
Fixes: ac795161 ("NFSv4: Handle case where the lookup of a directory fails")
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
Tested-by: NDonald Buczek <buczek@molgen.mpg.de>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: NChenXiaoSong <chenxiaosong2@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

blk_mq_realloc_hw_ctxs() will free the 'queue_hw_ctx'(e.g. undate
submit_queues through configfs for null_blk), while it might still be
used from other context(e.g. switch elevator to none):

t1					t2
elevator_switch
 blk_mq_unquiesce_queue
  blk_mq_run_hw_queues
   queue_for_each_hw_ctx
    // assembly code for hctx = (q)->queue_hw_ctx[i]
    mov    0x48(%rbp),%rdx -> read old queue_hw_ctx

					__blk_mq_update_nr_hw_queues
					 blk_mq_realloc_hw_ctxs
					  hctxs = q->queue_hw_ctx
					  q->queue_hw_ctx = new_hctxs
					  kfree(hctxs)
    movslq %ebx,%rax
    mov    (%rdx,%rax,8),%rdi ->uaf

Sicne the queue is freezed in __blk_mq_update_nr_hw_queues(), fix the
problem by protecting 'queue_hw_ctx' through rcu where it can be accessed
without grabbing 'q_usage_counter'.
Signed-off-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NMing Lei <ming.lei@redhat.com>
Signed-off-by: NZhang Wensheng <zhangwensheng5@huawei.com>
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

In case of BLK_MQ_F_BLOCKING, per-hctx srcu is used to protect dispatch
critical area. But the current process is not aware when memory of srcu
allocation failed in blk_mq_alloc_hctx, which will leads to illegal
address BUG. Add return value validation to avoid this problem.
Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

Patch ("hugetlb: address ref count racing in prep_compound_gigantic_page") add
a check of ref count in prep_compound_gigantic_page. We will call this function
in dynamic hugetlb feature too, so we should initialize subpages before calling
prep_compound_gigantic_page to satisfy the change.
Further, the input of prep_compound_gigantic_page should be a group of pages
rather than compound page, so clear the properties related to compound page.
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

Patch ("mm: hugetlb: fix a race between freeing and dissolving the page") add
PageHugeFreed to check whether a page is freed in hugetlb.
Patch ("hugetlb: convert PageHugeFreed to HPageFreed flag") convert it to
HPageFreed. We need to clear it when alloc hugepage from hugetlb to and set it
when free hugepage back to hugetlb.
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

We do not support dynamic combination of 1G hugepages dynamicly as this can
result in a significant performance loss. We suggest to configure the number of
hugepages immediately after creating a dynamic hugetlb pool rather than modify
them dynamicly while some processes are runing.
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

Do not release the lock after merging all pages, otherwise some other process
may allocate the pages, and then some pages can't be put back to hugetlb.
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

When all processes in the memory cgroup are finished, some memory may still be
occupied such as file cache. Use mem_cgroup_force_empty to reclaim these pages
that charged in the memory cgroup before merging all pages.
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

Use check_new_page to check the page to be allocated.
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

For 1G huge pages, the struct page of each subpages may be discontinuous, but
pfn must be continuous, so it's better to traverse subpages using pfn rathan
than struct page.
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

Referring to alloc_buddy_huge_page function, replace prep_compound_page
with prep_new_page which is more appropriate because it's the opposite of
free_pages_prepare.
And initialize page->mapping for huge pages as they are initialized in
free_huge_page too.
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

The hugepages may still remain PG_uptodate flags when freed. When splitting
hugepage to pages, the flag is not clear. This causes the page to be allocated
with PG_uptodate flags and user may read incorrect datas.

In order to solve this problem and similar problems, add free_pages_prepares()
to clear page when splitting pages to small pool.
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

Phytium inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I41AUQ
CVE: NA

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

Fix the issue that interrupts are concentrated in one cpu
for Phytium S2500 server.
Signed-off-by: NMao HongBo <maohongbo@phytium.com.cn>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I3BNT6
CVE: NA

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

We can get a crash when disconnecting the iSCSI session,
the call trace like this:

  [ffff00002a00fb70] kfree at ffff00000830e224
  [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4
  [ffff00002a00fbd0] device_del at ffff0000086b6a98
  [ffff00002a00fc50] device_unregister at ffff0000086b6d58
  [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c
  [ffff00002a00fca0] scsi_remove_device at ffff000008706134
  [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4
  [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0
  [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4
  [ffff00002a00fdb0] process_one_work at ffff00000810f35c
  [ffff00002a00fe00] worker_thread at ffff00000810f648
  [ffff00002a00fe70] kthread at ffff000008116e98

In ses_intf_add, components count could be 0, and kcalloc 0 size scomp,
but not saved in edev->component[i].scratch

In this situation, edev->component[0].scratch is an invalid pointer,
when kfree it in ses_intf_remove_enclosure, a crash like above would happen
The call trace also could be other random cases when kfree cannot catch
the invalid pointer

We should not use edev->component[] array when the components count is 0
We also need check index when use edev->component[] array in
ses_enclosure_data_process

Another fix option is report error and do not attach in ses_intf_add if we
meet a zero component enclosure
Tested-by: NZeng Zhicong <timmyzeng@163.com>
Signed-off-by: NDing Hui <dinghui@sangfor.com.cn>
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.16-rc6
commit 9c5d89bc
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4Y3UC

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

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

Since commit ac10be5c ("arm64: Use common
of_kexec_alloc_and_setup_fdt()"), smatch reports the following warning:

  arch/arm64/kernel/machine_kexec_file.c:152 load_other_segments()
  warn: missing error code 'ret'

Return code is not set to an error code in load_other_segments() when
of_kexec_alloc_and_setup_fdt() call returns a NULL dtb. This results
in status success (return code set to 0) being returned from
load_other_segments().

Set return code to -EINVAL if of_kexec_alloc_and_setup_fdt() returns
NULL dtb.
Signed-off-by: NLakshmi Ramasubramanian <nramas@linux.microsoft.com>
Reported-by: Nkernel test robot <lkp@intel.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Fixes: ac10be5c ("arm64: Use common of_kexec_alloc_and_setup_fdt()")
Link: https://lore.kernel.org/r/20211210010121.101823-1-nramas@linux.microsoft.comSigned-off-by: NWill Deacon <will@kernel.org>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NLi Huafei <lihuafei1@huawei.com>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.11-rc1
commit c11faf32
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4Y3CE?from=project-issue
CVE: NA

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

In metacopy case, we should use ovl_inode_realdata() instead of
ovl_inode_real() to get real inode which has data, so that
we can get correct information of extentes in ->fiemap operation.
Signed-off-by: NChengguang Xu <cgxu519@mykernel.net>
Reviewed-by: NAmir Goldstein <amir73il@gmail.com>
Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
Signed-off-by: NZheng Liang <zhengliang6@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.14-rc2
commit d08c84e0
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4Y3D0

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

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

In fedora rawhide the PTHREAD_STACK_MIN define may end up expanded to a
sysconf() call, and that will return 'long int', breaking the build:

    45 fedora:rawhide                : FAIL gcc version 11.1.1 20210623 (Red Hat 11.1.1-6) (GCC)
      builtin-sched.c: In function 'create_tasks':
      /git/perf-5.14.0-rc1/tools/include/linux/kernel.h:43:24: error: comparison of distinct pointer types lacks a cast [-Werror]
         43 |         (void) (&_max1 == &_max2);              \
            |                        ^~
      builtin-sched.c:673:34: note: in expansion of macro 'max'
        673 |                         (size_t) max(16 * 1024, PTHREAD_STACK_MIN));
            |                                  ^~~
      cc1: all warnings being treated as errors

  $ grep __sysconf /usr/include/*/*.h
  /usr/include/bits/pthread_stack_min-dynamic.h:extern long int __sysconf (int __name) __THROW;
  /usr/include/bits/pthread_stack_min-dynamic.h:#   define PTHREAD_STACK_MIN __sysconf (__SC_THREAD_STACK_MIN_VALUE)
  /usr/include/bits/time.h:extern long int __sysconf (int);
  /usr/include/bits/time.h:# define CLK_TCK ((__clock_t) __sysconf (2))	/* 2 is _SC_CLK_TCK */
  $

So cast it to int to cope with that.
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NZou Wei <zou_wei@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

maillist inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4XWBS

Reference: https://lore.kernel.org/all/20210524172433.015b3b6b@xhacker.debian/

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

Jisheng Zhang has another way of saving memory, we combine his two patches into
one and made some adaptations with dynamic kfence objects.

Description of the original patch:

Some architectures may want to allocate the __kfence_pool differently
for example, allocate the __kfence_pool earlier before paging_init().
We also delay the memset() to kfence_init_pool().

KFENCE requires linear map to be mapped at page granularity, so that
it is possible to protect/unprotect single pages in the KFENCE pool.
Currently if KFENCE is enabled, arm64 maps all pages at page
granularity, it seems overkilled. In fact, we only need to map the
pages in KFENCE pool itself at page granularity. We acchieve this goal
by allocating KFENCE pool before paging_init() so we know the KFENCE
pool address, then we take care to map the pool at page granularity
during map_mem().
Signed-off-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

This reverts commit d3d0ca13

We found that this patch may lead to a TLB conflicts abort. This may results by
the changes from block<->table mappings. This problem may have something to do
with the Break-Before-Make sequence rule but not yet clear.
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

Patch "kfence: Add a module parameter to adjust kfence objects"
enable dynamic configuration of the number of KFENCE guarded
objects, but the size of alloc_covered is not the same with the
original kfence. This is because const_ilog2 is just valid for
a constant, and KFENCE_NR_OBJECTS is not a constant when enabling
dynamic configuration.

This difference between original kfence will lead to a confusion
loggic in the process of skipping covered path. In a arm64 machine,
the following panic is observed.

  Call trace:
   __kfence_alloc+0x378/0x780
   kmem_cache_alloc+0x204/0x614
   getname_kernel+0x38/0xf4
   filp_open+0x2c/0x6c
   populate_rootfs+0xcc/0x174
   do_one_initcall+0xac/0x20c
   kernel_init_freeable+0x380/0x3c8
   kernel_init+0x18/0xf0
   ret_from_fork+0x10/0x18
  Code: 54000080 a9400381 f9000420 f9000001 (f900039c)
  ---[ end trace 814fe40d608e1b74 ]---
  Kernel panic - not syncing: TLB conflict abort: Fatal exception

To fix this, ilog2 is used to replace const_ilog2 when enable
dynamic configuration of KFENCE guarded objects.

Fixes: 901b983c ("kfence: Add a module parameter to adjust kfence objects")
Signed-off-by: NPeng Liu <liupeng256@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.17-rc3
commit f26d0433
category: bugfix
bugzilla: 186383 https://gitee.com/openeuler/kernel/issues/I4X1AI?from=project-issue
CVE: NA

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

When an admin enables audit at early boot via the "audit=1" kernel
command line the audit queue behavior is slightly different; the
audit subsystem goes to greater lengths to avoid dropping records,
which unfortunately can result in problems when the audit daemon is
forcibly stopped for an extended period of time.

This patch makes a number of changes designed to improve the audit
queuing behavior so that leaving the audit daemon in a stopped state
for an extended period does not cause a significant impact to the
system.

- kauditd_send_queue() is now limited to looping through the
  passed queue only once per call.  This not only prevents the
  function from looping indefinitely when records are returned
  to the current queue, it also allows any recovery handling in
  kauditd_thread() to take place when kauditd_send_queue()
  returns.

- Transient netlink send errors seen as -EAGAIN now cause the
  record to be returned to the retry queue instead of going to
  the hold queue.  The intention of the hold queue is to store,
  perhaps for an extended period of time, the events which led
  up to the audit daemon going offline.  The retry queue remains
  a temporary queue intended to protect against transient issues
  between the kernel and the audit daemon.

- The retry queue is now limited by the audit_backlog_limit
  setting, the same as the other queues.  This allows admins
  to bound the size of all of the audit queues on the system.

- kauditd_rehold_skb() now returns records to the end of the
  hold queue to ensure ordering is preserved in the face of
  recent changes to kauditd_send_queue().

Cc: stable@vger.kernel.org
Fixes: 5b52330b ("audit: fix auditd/kernel connection state tracking")
Fixes: f4b3ee3c ("audit: improve robustness of the audit queue handling")
Reported-by: NGaosheng Cui <cuigaosheng1@huawei.com>
Tested-by: NGaosheng Cui <cuigaosheng1@huawei.com>
Reviewed-by: NRichard Guy Briggs <rgb@redhat.com>
Signed-off-by: NPaul Moore <paul@paul-moore.com>
Signed-off-by: NCui GaoSheng <cuigaosheng1@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: 186383 https://gitee.com/openeuler/kernel/issues/I4X1AI?from=project-issue
CVE: NA

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

This reverts commit fcfdde9c.
Signed-off-by: NCui GaoSheng <cuigaosheng1@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

virt inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4VZPC
CVE: NA

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

Commit 63042c58 ("KVM: arm64: Add interface to support vCPU
preempted check") introduced paravirt spinlock operations, as pv_lock_ops
was exported via EXPORT_SYMBOL(), while the pv_ops structure containing
the pv lock operations is exported via EXPORT_SYMBOL_GPL().

Change that by using EXPORT_SYMBOL(pv_ops) for arm/arm64, as with the x86
architecture changes, the following:
https://lore.kernel.org/all/20181029150116.25372-1-jgross@suse.com/T/#u

Fixes: 63042c58 ("KVM: arm64: Add interface to support vCPU preempted
check")
Signed-off-by: Nyezengruan <yezengruan@huawei.com>
Reviewed-by: NKeqian Zhu <zhukeqian1@huawei.com>
Acked-by: NXie Xiuqi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

The check for control character shouldn't be added when import a
binary digest list.
Signed-off-by: Nshenxiangwei <shenxiangwei1@huawei.com>
Reviewed-by: NLu Huaxin <luhuaxin1@huawei.com>
Reviewed-by: NRoberto Sassu <roberto.sassu@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: bugfix
bugzilla: 4472 https://gitee.com/openeuler/kernel/issues/I4O2ZZ

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

When rx_buff is greater than 2, the driver will alloc for more than 1
page of memory for network rx, but the __GFP_COMP gfp flag is not set,
resulting in the following call trace:

CPU: 3 PID: 494041 Comm: ping Kdump: loaded Tainted: G        W  OE     4.19.90-2106.3.0.0095.oe1.x86_64 #1
Hardware name: Huawei Technologies Co., Ltd. RH2288H V3/BC11HGSA0, BIOS 5.15 05/21/2019
RIP: 0010:copy_page_to_iter+0x154/0x310
Code: 31 b8 00 10 00 00 f7 c6 00 80 00 00 74 07 0f b6 49 51 48 d3 e0 48 39 c2 0f 86 ed fe ff ff 48 c7 c7 30
RSP: 0018:ffffbd6907d03bd8 EFLAGS: 00010286
RAX: 0000000000000024 RBX: ffffe0ffee5b3000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff9edbbfcd6858 RDI: ffff9edbbfcd6858
RBP: 0000000000000001 R08: 000000000001574a R09: 0000000000000004
R10: 000000000000004e R11: 0000000000000001 R12: ffffbd6907d03ed0
R13: 0000000000002100 R14: 0000000000000030 R15: 0000000000000000
FS:  00007f9d37244dc0(0000) GS:ffff9edbbfcc0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffe0e715f80 CR3: 000000203c018005 CR4: 00000000001606e0
Call Trace:
 skb_copy_datagram_iter+0x16c/0x2a0
 raw_recvmsg+0xd0/0x1f0
 inet_recvmsg+0x5b/0xd0
 ____sys_recvmsg+0x95/0x160
 ? import_iovec+0x37/0xd0
 ? copy_msghdr_from_user+0x5c/0x90
 ___sys_recvmsg+0x8c/0xd0
 ? __audit_syscall_exit+0x228/0x290
 ? kretprobe_trampoline+0x25/0x50
 ? __sys_recvmsg+0x5b/0xa0
 __sys_recvmsg+0x5b/0xa0
 do_syscall_64+0x5f/0x240
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

Use 'dev_alloc_pages' instead of calling ’alloc_pages_node‘ directly.
Signed-off-by: NChiqijun <chiqijun@huawei.com>
Reviewed-by: NWangxiaoyun <cloud.wangxiaoyun@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>