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

--------

Export "memory.events" and "memory.events.local" from cgroupv2 to
cgroupv1.

There are some differences between v2 and v1:

1)events of MEMCG_OOM_GROUP_KILL is not included in cgroupv1. Because,
there is no member of memory.oom.group.

2)events of MEMCG_MAX is represented with "limit_in_bytes" in cgroupv1 instead
of memory.max

3)event of oom_kill is include in memory.oom_control. make oom_kill include
its descendants' events and add oom_kill_local include its oom_kill event only.
Signed-off-by: NLu Jialin <lujialin4@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-net-5.17
commit ad0ecaef
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4YXIM
CVE: NA

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

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

Currently, function hclge_mdio_read() will return 0 if during reset(the
cmd state will be set to disable).

If use general phy driver, the phy_state_machine() will update phy speed
every second in function genphy_read_status_fixed() when PHY is set to
autoneg off, no matter of link down or link up.

If phy driver happens to read BMCR register during reset, phy speed will
be updated to 10Mpbs as BMCR register value is 0. So it may call phy can
not link up if previous speed is not 10Mpbs.

To fix this problem, function hclge_mdio_read() should return -EBUSY if
the cmd state is disable. So does function hclge_mdio_write().

Fixes: 1c124938 ("net: hns3: bugfix for hclge_mdio_write and hclge_mdio_read")
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-net-5.17
commit 4d07c593
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4YXIM
CVE: NA

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

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

When pci devices init failed and haven't reinit, priv->ring is
NULL and hns3_set/get_ringparam() will access priv->ring. it
causes call trace.

So, add NULL pointer check for hns3_set/get_ringparam() to
avoid this situation.

Fixes: 5668abda ("net: hns3: add support for set_ringparam")
Signed-off-by: NHao Chen <chenhao288@hisilicon.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-net-5.17
commit f5cd6016
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4YXIM
CVE: NA

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

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

When pci device reset failed, it does uninit operation and priv->ring
is NULL, it causes accessing NULL pointer error.

Add netdev reset check for hns3_set_tunable() to fix it.

Fixes: 99f6b5fb ("net: hns3: use bounce buffer when rx page can not be reused")
Signed-off-by: NHao Chen <chenhao288@hisilicon.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-net-5.17
commit 671cb8cb
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4YXIM
CVE: NA

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

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

After disable sriov, VF still has some config and info need to be
cleaned, which configured by PF. This patch clean the HW config
and SW struct vport->vf_info.

Fixes: fa8d82e8 ("net: hns3: Add support of .sriov_configure in HNS3 driver")
Signed-off-by: Peng Li<lipeng321@huawei.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-net-5.17
commit a89cbb16
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4YXIM
CVE: NA

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

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

Add max order judgement for tx spare buffer to avoid triggering
call trace, print related fail information instead, when user
set tx spare buf size to a large value which causes order
exceeding 10.

Fixes: e445f08a ("net: hns3: add support to set/get tx copybreak buf size via ethtool for hns3 driver")
Signed-off-by: NHao Chen <chenhao288@hisilicon.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-net-5.17
commit 87783721
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4YXIM
CVE: NA

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

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

When use ethtoool set tx copybreak buf size to a large value
which causes order exceeding 10 or memory is not enough,
it causes allocating tx copybreak buffer failed and print
"the active tx spare buf is 0, not enabled tx spare buffer",
however, use --get-tunable parameter query tx copybreak buf
size and it indicates setting value not 0.

So, it's necessary to change the print value from setting
value to 0.

Set kinfo.tx_spare_buf_size to 0 when set tx copybreak buf size failed.

Fixes: e445f08a ("net: hns3: add support to set/get tx copybreak buf size via ethtool for hns3 driver")
Signed-off-by: NHao Chen <chenhao288@hisilicon.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-net-5.17
commit 190cd8a7
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4YXIM
CVE: NA

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

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

Currently, when PF set VF VLAN, it sends notify mailbox to VF
if VF alive. VF stop its traffic, and send request mailbox
to PF, then PF updates VF VLAN. It's a bit complex. If VF is
killed before sending request, PF will not set VF VLAN without
any log.

This patch refines the process, PF can set VF VLAN direclty,
and then notify the VF. If VF is resetting at that time, the
notify may be dropped, so VF should query it after reset finished.

Fixes: 92f11ea1 ("net: hns3: fix set port based VLAN issue for VF")
Signed-off-by: NJian Shen <shenjian15@huawei.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-net-5.17
commit 1932a624
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4YXIM
CVE: NA

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

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

When adding port base VLAN, vf VLAN need to remove from HW and modify
the vlan state in vf VLAN list as false. If the periodicity task is
freeing the same node, it may cause "use after free" error.
This patch adds a vlan list lock to protect the vlan list.

Fixes: c6075b19 ("net: hns3: Record VF vlan tables")
Signed-off-by: NJian Shen <shenjian15@huawei.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-net-5.17
commit c0f46de3
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4YXIM
CVE: NA

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

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

Currently, Port base vlan is initiated by PF and configured to its VFs,
by using command "ip link set <pf name> vf <vf id> vlan <vlan id>".
When a global reset was triggered, the hardware vlan table and the soft
recorded vlan information will be cleared by PF, and restored them until
VFs were ready. There is a short time window between the table had been
cleared and before table restored. If configured a new port base vlan tag
at this moment, driver will check the soft recorded vlan information,
and find there hasn't the old tag in it, which causing a warning print.

Due to the port base vlan is managed by PF, so the VFs's port base vlan
restoring should be handled by PF when PF was ready.

This patch fixes it.

Fixes: 039ba863 ("net: hns3: optimize the filter table entries handling when resetting")
Signed-off-by: NJian Shen <shenjian15@huawei.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-net-5.17
commit ccb18f05
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4YXIM
CVE: NA

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

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

If the MAC address A is configured to vport A and then vport B. The MAC
address of vport A in the hardware becomes invalid. If the address of
vport A is changed to MAC address B, the driver needs to delete the MAC
address A of vport A. Due to the MAC address A of vport A has become
invalid in the hardware entry, so "-ENOENT" is returned. In this case, the
"used_umv_size" value recorded in driver is not updated. As a result, the
MAC entry status of the software is inconsistent with that of the hardware.

Therefore, the driver updates the umv size even if the MAC entry cannot be
found. Ensure that the software and hardware status is consistent.

Fixes: ee4bcd3b ("net: hns3: refactor the MAC address configure")
Signed-off-by: NJian Shen <shenjian15@huawei.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-net-5.17
commit 2f61353c
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4YXIM
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=2f61353cd2f789a4229b6f5c1c24a40a613357bb

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

Since some interrupt states may be cleared by hardware, the driver
may receive an empty interrupt. Currently, the VF driver directly
disables the vector0 interrupt in this case. As a result, the VF
is unavailable. Therefore, the vector0 interrupt should be enabled
in this case.

Fixes: b90fcc5b ("net: hns3: add reset handling for VF when doing Core/Global/IMP reset")
Signed-off-by: NYufeng Mo <moyufeng@huawei.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-net-5.17
commit 6dde452b
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4YXIM
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=6dde452bceca3f2ed2b33bc46a16ff5682a03a2e

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

When multiple threads concurrently access the debugfs content, data
and pointer exceptions may occur. Therefore, mutex lock protection is
added for debugfs.

Fixes: 5e69ea7e ("net: hns3: refactor the debugfs process")
Signed-off-by: NYufeng Mo <moyufeng@huawei.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 48159
CVE: N/A

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

It's better to make the non-upstreamed feature into stand-alone file,
which make us easy to backport mainline patches.

No functional changes.

Cc: Sang Yan <sangyan@huawei.com>
Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: NSang Yan <sangyan@huawei.com>
Reviewed-by: NLiu Shixin <liushixin2@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: 48159
CVE: N/A

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

It's better to make the non-upstreamed feature into stand-alone file,
which make us easy to backport mainline patches.

No functional changes.

Cc: Sang Yan <sangyan@huawei.com>
Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: NSang Yan <sangyan@huawei.com>
Reviewed-by: NLiu Shixin <liushixin2@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: 185988, https://gitee.com/openeuler/kernel/issues/I4YVV3

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

In jffs2_scan_medium,
if `s = kzalloc(sizeof(struct jffs2_summary), GFP_KERNEL);` returns error,
go to "out" to do clear. Null pointer dereference occurs when
`if (s->sum_list_head)` is executed in "out".

Fixes: bf7ba557361f ("[Huawei] jffs2: fix memory leak in jffs2_scan_medium")
Signed-off-by: NBaokun Li <libaokun1@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-5.13-rc1
commit 90f093fa
category: feature
feature: Userspace percpu
bugzilla: https://gitee.com/openeuler/kernel/issues/I4W2BQ
CVE: NA

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

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

For userspace checkpoint and restore (C/R) a way of getting process state
containing RSEQ configuration is needed.

There are two ways this information is going to be used:
 - to re-enable RSEQ for threads which had it enabled before C/R
 - to detect if a thread was in a critical section during C/R

Since C/R preserves TLS memory and addresses RSEQ ABI will be restored
using the address registered before C/R.

Detection whether the thread is in a critical section during C/R is needed
to enforce behavior of RSEQ abort during C/R. Attaching with ptrace()
before registers are dumped itself doesn't cause RSEQ abort.
Restoring the instruction pointer within the critical section is
problematic because rseq_cs may get cleared before the control is passed
to the migrated application code leading to RSEQ invariants not being
preserved. C/R code will use RSEQ ABI address to find the abort handler
to which the instruction pointer needs to be set.

To achieve above goals expose the RSEQ ABI address and the signature value
with the new ptrace request PTRACE_GET_RSEQ_CONFIGURATION.

This new ptrace request can also be used by debuggers so they are aware
of stops within restartable sequences in progress.
Signed-off-by: NPiotr Figiel <figiel@google.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NMichal Miroslaw <emmir@google.com>
Reviewed-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Acked-by: NOleg Nesterov <oleg@redhat.com>
Link: https://lkml.kernel.org/r/20210226135156.1081606-1-figiel@google.comSigned-off-by: NYunfeng Ye <yeyunfeng@huawei.com>
Reviewed-by: NChao Liu <liuchao173@huawei.com>
Reviewed-by: NKuohai Xu <xukuohai@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

enable CONFIG_MEMCG_MEMFS_INFO by default.
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: 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>