提交 · 72e9e214e5f2b7fc25a4b5b535f5656e6934663d · openeuler / Kernel

12 12月, 2022 3 次提交

blk-mq: fix kabi broken due to request_wrapper · 72e9e214

由 Yu Kuai 提交于 12月 12, 2022

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

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

Before commit f60df4a0 ("blk-mq: fix kabi broken in struct
request"), drivers will got cmd address right after request, however,
after this commit, drivers will got cmd address after request_wrapper
instead, which is bigger than request and will cause compatibility
issues.

Fix the problem by placing request_wrapper behind cmd, so that the
cmd address for drivers will stay the same.

Before commit:		|request|cmd|
After commit:		|request|request_wrapper|cmd|
With this patch:	|request|cmd|request_wrapper|

Performance test: arm64 Kunpeng-920 96 core

1) null_blk setup:
modprobe null_blk nr_devices=0 &&
    udevadm settle &&
    cd /sys/kernel/config/nullb &&
    mkdir nullb0 &&
    cd nullb0 &&
    echo 0 > completion_nsec &&
    echo 512 > blocksize &&
    echo 0 > home_node &&
    echo 0 > irqmode &&
    echo 1024 > size &&
    echo 0 > memory_backed &&
    echo 2 > queue_mode &&
	echo 4096 > hw_queue_depth &&
	echo 96 > submit_queues &&
    echo 1 > power

2) fio test script:
[global]
ioengine=libaio
direct=1
numjobs=96
iodepth=32
bs=4k
rw=randwrite
allow_mounted_write=0
time_based
runtime=60
group_reporting=1
ioscheduler=none
cpus_allowed_policy=split
cpus_allowed=0-95

[test]
filename=/dev/nullb0

3) iops test result:

without this patch:	23.9M
with this patch:	24.1M

Fixes: f60df4a0 ("blk-mq: fix kabi broken in struct request")
Signed-off-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

72e9e214

ide-cd: don't clear rq_flags after blk_get_request · d6736127

由 Yu Kuai 提交于 12月 12, 2022

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

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

Prepare to add a flag while initializing request, there are no
functional changes.
Signed-off-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

d6736127

iommu: Fix error handling in probe_acpi_namespace_devices() · 09840ebc

由 Zheng Zengkai 提交于 12月 12, 2022

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

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

Fix smatch error in probe_acpi_namespace_devices().

In probe_acpi_namespace_devices(), if device_to_iommu() returns NULL,
unlock operation is needed before return.

Fixes: d6602228 ("iommu/vt-d:Add support for detecting ACPI device, in RMRR")
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>

09840ebc

09 12月, 2022 8 次提交

!321 net: hns3: fix the HCLGE_OPC_WOL_CFG opcode id for wol and fix the... · 4741bc65

由 openeuler-ci-bot 提交于 12月 09, 2022

!321 net: hns3: fix the HCLGE_OPC_WOL_CFG opcode id for wol and fix the incorrect way to obtain parameters.

Merge Pull Request from: @svishen 
 
(1)The driver should use the supported parameter got from firmware, not from user, to validate the wol mode.
(2)fix the HCLGE_OPC_WOL_CFG opcode id for wol.

issue:
https://gitee.com/openeuler/kernel/issues/I65FSF 
 
Link:https://gitee.com/openeuler/kernel/pulls/321 
Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>

4741bc65

net: hns3: fix the HCLGE_OPC_WOL_CFG opcode id for wol · 987f422a

由 Hao Lan 提交于 12月 09, 2022

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

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

Fix the HCLGE_OPC_WOL_CFG opcode id for wol.

Fixes: c3c5f044 ("net: hns3: support wake on lan configuration and query")
Signed-off-by: NHao Lan <lanhao@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

987f422a

net: hns3: fix getting supported parameter from driver in hclge_set_wol · c92b8f62

由 Hao Lan 提交于 12月 09, 2022

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

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

The driver should use the supported parameter got from firmware,
not from user,to validate the wol mode.

Fixes: c3c5f044 ("net: hns3: support wake on lan configuration and query")
Signed-off-by: NHao Lan <lanhao@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

c92b8f62

!318 net: hns3: This series bugfix for the HNS3 ethernet driver. · 20ca80a7

由 openeuler-ci-bot 提交于 12月 09, 2022

Merge Pull Request from: @svishen 
 
This series includes some bugfix for the HNS3 ethernet driver.
Patch 1# fix incorrect hw rss hash type of rx packet.
Fixes: 79664077 ("net: hns3: support RXD advanced layout")
Fixes: 232fc64b ("net: hns3: Add HW RSS hash information to RX skb")
Fixes: ea485867 ("net: hns3: handle the BD info on the last BD of the packet")

Patch 2# fix return value check bug of rx copybreak.
Fixes: e74a726d ("net: hns3: refactor hns3_nic_reuse_page()")
Fixes: 99f6b5fb ("net: hns3: use bounce buffer when rx page can not be reused")

Patch 3# net: hns3: fix setting incorrect phy link ksettings
for firmware in resetting process
Fixes: f5f2b3e4 ("net: hns3: add support for imp-controlled PHYs")
Fixes: c5ef83cb ("net: hns3: fix for phy_addr error in hclge_mac_mdio_config")
Fixes: 2312e050 ("net: hns3: Fix for deadlock problem occurring when unregistering ae_algo")


issue:
https://gitee.com/openeuler/kernel/issues/I65DT5


Test:
before
```
[root@localhost bin]# ethtool --reset enp53s0f0 all
ETHTOOL_RESET 0xffffffff
[150074.537297][T753377] hns3 0000:35:00.0 enp53s0f0: Setting reset type 6
[150074.539476][T753377] hns3 0000:35:00.0: received reset event, reset type is 6
Components reset:     0xffffffff[150074.542900][T753350] hns3 0000:35:00.0: global reset requested

[150074.546063][    C3] hns3 0000:35:00.0: global reset interrupt
[150074.548914][    C3] hns3 0000:35:00.1: global reset interrupt
[150074.552496][T753303] hns3 0000:35:00.1 enp53s0f1: link down
[root@localhost bin]# [150074.665230][T753303] hns3 0000:35:00.1: prepare wait ok
[150074.850640][T753350] hns3 0000:35:00.0: cleaned 0, need to clean 1
[150074.854640][T753350] hns3 0000:35:00.0: get link status cmd failed -52
[150074.857504][T753350] hns3 0000:35:00.0: failed to get phy link ksetting, ret = -16.
[150074.875240][T753350] hns3 0000:35:00.0 enp53s0f0: link down
[150074.985282][T753350] hns3 0000:35:00.0: prepare wait ok
[150075.093602][T753350] hns3 0000:35:00.0: In reset process RoCE client uninit.
[150075.101975][T753303] hns3 0000:35:00.1: In reset process RoCE client uninit.
[150075.436311][T753303] hns3 0000:35:00.1: Func clear success after reset.
[150075.438800][T753303] hns3 0000:35:00.1: Func clear success after reset.
[150075.441592][T753303] hns3 0000:35:00.1: Func clear success after reset.
[150075.443786][T753303] hns3 0000:35:00.1: Func clear success after reset.
[150075.446365][T753303] hns3 0000:35:00.1: Func clear success after reset.
[150075.447419][T753350] hns3 0000:35:00.0: Func clear success after reset.
[150075.451091][T753350] hns3 0000:35:00.0: Func clear success after reset.
[150075.453474][T753350] hns3 0000:35:00.0: Func clear success after reset.
[150075.455644][T753350] hns3 0000:35:00.0: Func clear success after reset.
[150075.458244][T753350] hns3 0000:35:00.0: Func clear success after reset.
[150076.100055][T753303] hns3 0000:35:00.1: The firmware version is 3.10.3.3
[150076.176640][T753303] hns3 0000:35:00.1: failed to set phy link ksettings, ret = -22.
[150076.180219][T753303] hns3 0000:35:00.1: failed to init tp port, ret = -22
[150076.184130][T753303] hns3 0000:35:00.1: re-schedule reset task(1)
[150076.331566][T753350] hns3 0000:35:00.0: The firmware version is 3.10.3.3
[150076.389714][T753350] hns3 0000:35:00.0: failed to set phy link ksettings, ret = -22.
[150076.392443][T753350] hns3 0000:35:00.0: failed to init tp port, ret = -22
[150076.395624][T753350] hns3 0000:35:00.0: re-schedule reset task(1)
[150076.505410][T753350] hns3 0000:35:00.0: prepare wait ok
[150076.505447][T753303] hns3 0000:35:00.1: prepare wait ok
[150076.505595][T753303] hns3 0000:35:00.1: In reset process RoCE client uninit.
[150076.507203][T753350] hns3 0000:35:00.0: In reset process RoCE client uninit.
[150076.613321][T753303] hns3 0000:35:00.1 enp53s0f1: already uninitialized
[150076.616410][T753303] hns3 0000:35:00.1: The firmware version is 3.10.3.3
[150076.672797][T753303] hns3 0000:35:00.1: failed to set phy link ksettings, ret = -22.
[150076.675727][T753303] hns3 0000:35:00.1: failed to init tp port, ret = -22
[150076.679115][T753303] hns3 0000:35:00.1: re-schedule reset task(2)
[150076.680281][T753350] hns3 0000:35:00.0 enp53s0f0: already uninitialized
[150076.685248][T753350] hns3 0000:35:00.0: The firmware version is 3.10.3.3
[150076.741248][T753350] hns3 0000:35:00.0: failed to set phy link ksettings, ret = -22.
[150076.743891][T753350] hns3 0000:35:00.0: failed to init tp port, ret = -22
[150076.746731][T753350] hns3 0000:35:00.0: re-schedule reset task(2)
[150076.853335][T753303] hns3 0000:35:00.1: prepare wait ok
[150076.855171][T753303] hns3 0000:35:00.1: In reset process RoCE client uninit.
[150076.857620][T753350] hns3 0000:35:00.0: prepare wait ok
[150076.857773][T753350] hns3 0000:35:00.0: In reset process RoCE client uninit.
[150076.965700][T753303] hns3 0000:35:00.1 enp53s0f1: already uninitialized
[150076.969398][T753303] hns3 0000:35:00.1: The firmware version is 3.10.3.3
[150077.028455][T753303] hns3 0000:35:00.1: failed to set phy link ksettings, ret = -22.
[150077.031628][T753303] hns3 0000:35:00.1: failed to init tp port, ret = -22
[150077.034743][T753303] hns3 0000:35:00.1: re-schedule reset task(3)
[150077.034959][T753350] hns3 0000:35:00.0 enp53s0f0: already uninitialized
[150077.040503][T753350] hns3 0000:35:00.0: The firmware version is 3.10.3.3
[150077.097388][T753350] hns3 0000:35:00.0: failed to set phy link ksettings, ret = -22.
[150077.099911][T753350] hns3 0000:35:00.0: failed to init tp port, ret = -22
[150077.102682][T753350] hns3 0000:35:00.0: re-schedule reset task(3)
[150077.209423][T753303] hns3 0000:35:00.1: prepare wait ok
[150077.211246][T753303] hns3 0000:35:00.1: In reset process RoCE client uninit.
[150077.213324][T753350] hns3 0000:35:00.0: prepare wait ok
[150077.213405][T753350] hns3 0000:35:00.0: In reset process RoCE client uninit.
[150077.321889][T753350] hns3 0000:35:00.0 enp53s0f0: already uninitialized
[150077.326240][T753350] hns3 0000:35:00.0: The firmware version is 3.10.3.3
[150077.380433][T753350] hns3 0000:35:00.0: failed to set phy link ksettings, ret = -22.
[150077.383371][T753350] hns3 0000:35:00.0: failed to init tp port, ret = -22
[150077.386465][T753350] hns3 0000:35:00.0: re-schedule reset task(4)
[150077.386647][T753303] hns3 0000:35:00.1 enp53s0f1: already uninitialized
[150077.391998][T753303] hns3 0000:35:00.1: The firmware version is 3.10.3.3
[150077.448488][T753303] hns3 0000:35:00.1: failed to set phy link ksettings, ret = -22.
[150077.451611][T753303] hns3 0000:35:00.1: failed to init tp port, ret = -22
[150077.454382][T753303] hns3 0000:35:00.1: re-schedule reset task(4)
[150077.561306][T753303] hns3 0000:35:00.1: prepare wait ok
[150077.561349][T753350] hns3 0000:35:00.0: prepare wait ok
[150077.561519][T753350] hns3 0000:35:00.0: In reset process RoCE client uninit.
[150077.563110][T753303] hns3 0000:35:00.1: In reset process RoCE client uninit.
[150077.670158][T753350] hns3 0000:35:00.0 enp53s0f0: already uninitialized
[150077.674054][T753350] hns3 0000:35:00.0: The firmware version is 3.10.3.3
[150077.728474][T753350] hns3 0000:35:00.0: failed to set phy link ksettings, ret = -22.
[150077.731156][T753350] hns3 0000:35:00.0: failed to init tp port, ret = -22
[150077.733575][T753350] hns3 0000:35:00.0: re-schedule reset task(5)
[150077.733778][T753303] hns3 0000:35:00.1 enp53s0f1: already uninitialized
[150077.738889][T753303] hns3 0000:35:00.1: The firmware version is 3.10.3.3
[150077.792638][T753303] hns3 0000:35:00.1: failed to set phy link ksettings, ret = -22.
[150077.795669][T753303] hns3 0000:35:00.1: failed to init tp port, ret = -22
[150077.798354][T753303] hns3 0000:35:00.1: re-schedule reset task(5)
[150077.905835][T753350] hns3 0000:35:00.0: prepare wait ok
[150077.907645][T753350] hns3 0000:35:00.0: In reset process RoCE client uninit.
[150077.909440][T753303] hns3 0000:35:00.1: prepare wait ok
[150077.911198][T753303] hns3 0000:35:00.1: In reset process RoCE client uninit.
[150078.018590][T753350] hns3 0000:35:00.0 enp53s0f0: already uninitialized
[150078.022734][T753350] hns3 0000:35:00.0: The firmware version is 3.10.3.3
[150078.076269][T753350] hns3 0000:35:00.0: failed to set phy link ksettings, ret = -22.
[150078.079143][T753350] hns3 0000:35:00.0: failed to init tp port, ret = -22
[150078.081812][T753350] hns3 0000:35:00.0: Reset fail!
[150078.081957][T753303] hns3 0000:35:00.1 enp53s0f1: already uninitialized
[150078.083730][T753350] hns3 0000:35:00.0: dump reset info:
[150078.083730][T753350] PF reset count: 0
[150078.083730][T753350] FLR reset count: 0
[150078.083730][T753350] GLOBAL reset count: 1
[150078.083730][T753350] IMP reset count: 0
[150078.083730][T753350] reset done count: 0
[150078.083730][T753350] HW reset done count: 6
[150078.083730][T753350] reset count: 6
[150078.083730][T753350] reset fail count: 5
[150078.083730][T753350] vector0 interrupt enable status: 0x1
[150078.083730][T753350] reset interrupt source: 0x0
[150078.083730][T753350] reset interrupt status: 0x0
[150078.083730][T753350] RAS interrupt status: 0x0
[150078.083730][T753350] hardware reset status: 0x0
[150078.083730][T753350] handshake status: 0x10080
[150078.083730][T753350] function reset status: 0x0
[150078.083730][T753350] hdev state: 0x802b2
[150078.086765][T753303] hns3 0000:35:00.1: The firmware version is 3.10.3.3
[150078.160671][T753303] hns3 0000:35:00.1: failed to set phy link ksettings, ret = -22.
[150078.163837][T753303] hns3 0000:35:00.1: failed to init tp port, ret = -22
[150078.166346][T753303] hns3 0000:35:00.1: Reset fail!
[150078.168266][T753303] hns3 0000:35:00.1: dump reset info:
[150078.168266][T753303] PF reset count: 0
[150078.168266][T753303] FLR reset count: 0
[150078.168266][T753303] GLOBAL reset count: 1
[150078.168266][T753303] IMP reset count: 0
[150078.168266][T753303] reset done count: 0
[150078.168266][T753303] HW reset done count: 6
[150078.168266][T753303] reset count: 6
[150078.168266][T753303] reset fail count: 5
[150078.168266][T753303] vector0 interrupt enable status: 0x1
[150078.168266][T753303] reset interrupt source: 0x0
[150078.168266][T753303] reset interrupt status: 0x0
[150078.168266][T753303] RAS interrupt status: 0x0
[150078.168266][T753303] hardware reset status: 0x0
[150078.168266][T753303] handshake status: 0x10080
[150078.168266][T753303] function reset status: 0x0
[150078.168266][T753303] hdev state: 0x802b2

[root@localhost bin]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp65s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether e0:00:84:56:4e:38 brd ff:ff:ff:ff:ff:ff
    inet 192.168.60.11/24 scope global enp65s0f0
       valid_lft forever preferred_lft forever
4: enp65s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether e0:00:84:56:4e:39 brd ff:ff:ff:ff:ff:ff
372: enp53s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether ce:04:7a:b4:9a:b1 brd ff:ff:ff:ff:ff:ff
373: enp53s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 42:2f:aa:f3:50:e5 brd ff:ff:ff:ff:ff:ff
[root@localhost bin]#
```
after

```
[root@localhost pll]# ethtool --reset enp53s0f1 all
ETHTOOL_RESET 0xffffffff
[20652.651629][ T2931] hns3 0000:35:00.1 enp53s0f1: Setting reset type 6
Components reset:     0xffffffff
[root@localhost pll]# [20662.722669][    C1] hns3 0000:35:00.1: triggering reset in reset timer
[20662.725095][    C1] hns3 0000:35:00.1: received reset event, reset type is 6
[20662.728231][ T2880] hns3 0000:35:00.1: global reset requested
[20662.730430][    C1] hns3 0000:35:00.0: global reset interrupt
[20662.732888][    C1] hns3 0000:35:00.1: global reset interrupt
[20662.733803][ T2923] hns3 0000:35:00.0 enp53s0f0: link down
[20662.846863][ T2923] hns3 0000:35:00.0: prepare wait ok
[20663.028936][ T2880] hns3 0000:35:00.1: cleaned 0, need to clean 1
[20663.031251][ T2880] hns3 0000:35:00.1: get link status cmd failed -52
[20663.039432][ T2880] hns3 0000:35:00.1 enp53s0f1: link down
[20663.147103][ T2880] hns3 0000:35:00.1: prepare wait ok
[20663.312845][ T2880] hns3 0000:35:00.1: The firmware version is 3.10.3.3
[20664.260637][ T2880] hns3 0000:35:00.1: phc initializes ok!
[20664.404095][ T2880] hns3 0000:35:00.1: Reset done, hclge driver initialization finished.
[20664.536803][ T2923] hns3 0000:35:00.0: The firmware version is 3.10.3.3
[20665.484856][ T2923] hns3 0000:35:00.0: phc initializes ok!
[20665.628249][ T2923] hns3 0000:35:00.0: Reset done, hclge driver initialization finished.
[20665.875837][ T2923] hns3 0000:35:00.0 enp53s0f0: link up
[20665.881068][ T2880] hns3 0000:35:00.1 enp53s0f1: link up
```
 
 
Link:https://gitee.com/openeuler/kernel/pulls/318 
Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>

20ca80a7

!307 arch: mach: add support for 16dv300 series soc. · 4f772737

由 openeuler-ci-bot 提交于 12月 09, 2022

Merge Pull Request from: @mist_tao 
 
As a new-generation smart HD IP camera SOC, Hi3516DV300 
integrates the new-generation ISP, H.265 video compression encoder, 
and high-performance NNIE engine. Hi3516DV300 leads the industry 
in terms of low bit rate, high image quality, intelligent processing and analysis, 
and low power consumption. The soc can be used in the development of face recognition terminals, 
face payment terminals, and security terminals. 

This patchset mainly provide common capabilities for 16dv300 series soc.
1、Add support for 16dv300 machine， including clk driver，defconfig, etc.
2、Add MEIG vendor id to usb serial driver options.
3、Add I2C_M_STOP flag support for hix5hd2 driver.
 
 
Link:https://gitee.com/openeuler/kernel/pulls/307 
Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com> 
Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>

4f772737

net: hns3: fix setting incorrect phy link ksettings for firmware in resetting process · 20c27ab8

由 Guangbin Huang 提交于 11月 14, 2022

mainline inclusion
from mainline-v6.1-rc6
commit 510d7b6a
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I65DT5
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=510d7b6ae842e59ee00d57e5f07ac15131b6d899

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

Currently, if driver is in phy-imp(phy controlled by imp firmware) mode, as
driver did not update phy link ksettings after initialization process or
not update advertising when getting phy link ksettings from firmware, it
may set incorrect phy link ksettings for firmware in resetting process.
So fix it.

Fixes: f5f2b3e4 ("net: hns3: add support for imp-controlled PHYs")
Fixes: c5ef83cb ("net: hns3: fix for phy_addr error in hclge_mac_mdio_config")
Fixes: 2312e050 ("net: hns3: Fix for deadlock problem occurring when unregistering ae_algo")
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NHao Lan <lanhao@huawei.com>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

20c27ab8

net: hns3: fix return value check bug of rx copybreak · 9853e2f6

由 Jie Wang 提交于 11月 14, 2022

mainline inclusion
from mainline-v6.1-rc6
commit 29df7c69
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I65DT5
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=29df7c695ed67a8fa32bb7805bad8fe2a76c1f88

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

The refactoring of rx copybreak modifies the original return logic, which
will make this feature unavailable. So this patch fixes the return logic of
rx copybreak.

Fixes: e74a726d ("net: hns3: refactor hns3_nic_reuse_page()")
Fixes: 99f6b5fb ("net: hns3: use bounce buffer when rx page can not be reused")
Signed-off-by: NJie Wang <wangjie125@huawei.com>
Signed-off-by: NHao Lan <lanhao@huawei.com>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

9853e2f6

net: hns3: fix incorrect hw rss hash type of rx packet · eaed3909

由 Jian Shen 提交于 11月 14, 2022

mainline inclusion
from mainline-v6.1-rc6
commit a56cad69
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I65DT5
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a56cad694767ebdb7d80f27ffc239db46fff64de

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

Currently, the HNS3 driver reports the rss hash type
of each packet based on the rss hash tuples set. It
always reports PKT_HASH_TYPE_L4, without checking the
type of current packet. It's incorrect.
Fixes it by reporting it base on the packet type.

Fixes: 79664077 ("net: hns3: support RXD advanced layout")
Fixes: 232fc64b ("net: hns3: Add HW RSS hash information to RX skb")
Fixes: ea485867 ("net: hns3: handle the BD info on the last BD of the packet")
Signed-off-by: NJian Shen <shenjian15@huawei.com>
Signed-off-by: NHao Lan <lanhao@huawei.com>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

eaed3909

08 12月, 2022 29 次提交

sched: disable sched_autogroup by default · e1c7d892

由 Jialin Zhang 提交于 12月 08, 2022

hulk inclusion
category: performance
bugzilla: 32059, https://gitee.com/openeuler/kernel/issues/I65DOZ
CVE: NA

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

This option optimizes the scheduler for common desktop workloads by
automatically creating and populating task groups.  This separation
of workloads isolates aggressive CPU burners (like build jobs) from
desktop applications.  Task group autogeneration is currently based
upon task session.

We do not need this for mostly server workloads, so just disable by
default. If you need this feature really, just enable it by sysctl:

sysctl -w kernel.sched_autogroup_enabled=1
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

e1c7d892

Revert "add barriers to buffer_uptodate and set_buffer_uptodate" · dbcbd216

由 Li Lingfeng 提交于 12月 08, 2022

hulk inclusion
category: performance
bugzilla: https://gitee.com/openeuler/kernel/issues/I65DCK
CVE: NA

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

This reverts commit 372370dc.

There's no evidence that buffer_uptodate and set_buffer_uptodate are
unreliable without barriers. What's more, this patch result in the
performance deterioration.
Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com>
Reviewed-by: NYang Erkun <yangerkun@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

dbcbd216

Fixed the issue that the macro def_domain_type is repeatedly defined. · 4d648c05

由 Wangming Shao 提交于 12月 08, 2022

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

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

The type error caused by repeated definition of the def_domain_type
macro is fixed.
Signed-off-by: NWangming Shao <shaowangming@h-partners.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

4d648c05

coresight: trbe: remove cpuhp instance node before remove cpuhp state · 35dd9049

由 Yang Shen 提交于 12月 08, 2022

mainline inclusion
from mainline-v6.2-rc1
commit 5fefef85b0d3
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5YCYK
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git/commit/?id=5fefef85b0d3

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

cpuhp_state_add_instance() and cpuhp_state_remove_instance() should
be used in pairs. Or there will lead to the warn on
cpuhp_remove_multi_state() since the cpuhp_step list is not empty.

The following is the error log with 'rmmod coresight-trbe':
Error: Removing state 215 which has instances left.
Call trace:
  __cpuhp_remove_state_cpuslocked+0x144/0x160
  __cpuhp_remove_state+0xac/0x100
  arm_trbe_device_remove+0x2c/0x60 [coresight_trbe]
  platform_remove+0x34/0x70
  device_remove+0x54/0x90
  device_release_driver_internal+0x1e4/0x250
  driver_detach+0x5c/0xb0
  bus_remove_driver+0x64/0xc0
  driver_unregister+0x3c/0x70
  platform_driver_unregister+0x20/0x30
  arm_trbe_exit+0x1c/0x658 [coresight_trbe]
  __arm64_sys_delete_module+0x1ac/0x24c
  invoke_syscall+0x50/0x120
  el0_svc_common.constprop.0+0x58/0x1a0
  do_el0_svc+0x38/0xd0
  el0_svc+0x2c/0xc0
  el0t_64_sync_handler+0x1ac/0x1b0
  el0t_64_sync+0x19c/0x1a0
---[ end trace 0000000000000000 ]---

Fixes: 3fbf7f01 ("coresight: sink: Add TRBE driver")
Signed-off-by: NYang Shen <shenyang39@huawei.com>
Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20221122090355.23533-1-shenyang39@huawei.comSigned-off-by: NJunhao He <hejunhao3@huawei.com>
Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

35dd9049

RDMA/hns: adjust the structure of RoCE bonding driver · 646b97db

由 Junxian Huang 提交于 12月 08, 2022

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

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

This patch deletes some used variables, encapsulates repeated codes in a
new function get_upper_dev_from_ndev and adjusts the structure of
hns_roce_bond_event to make the logic clearer.

Fixes: e62a2027 ("RDMA/hns: support RoCE bonding")
Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

646b97db

RDMA/hns: add constraints for bonding-unsupported situations · 6ba084e0

由 Junxian Huang 提交于 12月 08, 2022

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

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

Applying this patch, RoCE driver will not set bond when NIC sets bond
in a mode not supported for RoCE bonding, with VF slaves or with
slaves from different I/O die.

Fixes: e62a2027 ("RDMA/hns: support RoCE bonding")
Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

6ba084e0

RDMA/hns: fix the error of missing GID in RoCE bonding mode 1 · 4920275a

由 Junxian Huang 提交于 12月 08, 2022

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

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

In the existing hns RoCE code, ib_dev->ops.get_netdev is not set, which
cause that only one slave will be assigned IP-based GID in RoCE bonding
mode 1.

This patch adds hns_roce_get_netdev() and set the function to
ib_dev->ops.get_netdev so that IB-Core can assign GID to different
net device according to the active slave in mode 1.

Fixes: e62a2027 ("RDMA/hns: support RoCE bonding")
Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

4920275a

RDMA/hns: fix possible dead lock when setting RoCE Bonding · b6623fd2

由 Junxian Huang 提交于 12月 08, 2022

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

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

When setting RoCE Bonding, a new hr_dev will be registered as
"hns_bond_xx". In the process, the bonding thread will try to acquire
rtnl_lock() while holding roce_bond_mutex. However, it's possible that
another thread running bond_netdev_notify_work() grabs rtnl_lock() before
the bonding thread, and call the bonding notifier function, in which the
thread will try to acquire roce_bond_mutex, finally leading to a dead lock.

As the event informer notifier_call_chain() will not call the next notifier
function until the current one returns, there is no need to use a mutex in
the bonding notifier function. Thus, remove roce_bond_mutex in
hns_roce_bond_event() and the dead lock can be avoided.

Fixes: e62a2027 ("RDMA/hns: support RoCE bonding")
Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

b6623fd2

drm/i915: fix TLB invalidation for Gen12 video and compute engines · b1d522bd

由 Andrzej Hajda 提交于 12月 08, 2022

stable inclusion
from stable-v5.10.157
commit 86f0082fb9470904b15546726417f28077088fee
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I640L3
CVE: CVE-2022-4139

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.157&id=86f0082fb9470904b15546726417f28077088fee

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

commit 04aa6437 upstream.

In case of Gen12 video and compute engines, TLB_INV registers are masked -
to modify one bit, corresponding bit in upper half of the register must
be enabled, otherwise nothing happens.

CVE: CVE-2022-4139
Suggested-by: NChris Wilson <chris.p.wilson@intel.com>
Signed-off-by: NAndrzej Hajda <andrzej.hajda@intel.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Fixes: 7938d615 ("drm/i915: Flush TLBs before releasing backing store")
Cc: stable@vger.kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NRen Zhijie <renzhijie2@huawei.com>
Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

b1d522bd

fork: Fixed the extended kabi memory is not initialized · 28f6e487

由 Zheng Zucheng 提交于 12月 08, 2022

hulk inclusion
category: bugfix
bugzilla: 18808I3, https://gitee.com/openeuler/kernel/issues/I648XI
CVE: NA

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

If the extended kabi memory is not initialized, maybe has security risks.
Therefore, the extended kabi memory is initialized to NULL in fork process
and initialized by users as required.

Fixes: 5efc447b ("fork: Allocate a new task_struct_resvd object for fork task")
Signed-off-by: NZheng Zucheng <zhengzucheng@huawei.com>
Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

28f6e487

mm/dynamic_hugetlb: fix compound_nr incorrect · a3a6ee2e

由 Liu Shixin 提交于 12月 08, 2022

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

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

Patch 1378a5ee ("mm: store compound_nr as well as compound_order") add
a new member compound_nr in struct page, and use this new member insteal
of compound_order in hugetlb_cgroup_move_parent() to compute the nr_pages.

In free_hugepage_to_hugetlb(), we reset page->mapping to NULL for each
subpage. Since page->mapping and page->compound_nr is union, we reset
page->compound_nr too unexpectly. This will finally result the nr_pages
incorrect in hugetlb_cgroup_move_parent() and can't release hugetlb_cgroup.

Fix this problem by reset page->compound_nr using set_compound_order().
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: Kefeng Wang<wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

a3a6ee2e

mm/shmem: fix shmem_swapin() race with swapoff · c8f1dd00

由 Miaohe Lin 提交于 12月 08, 2022

mainline inclusion
from mainline-v5.14-rc1
commit 2efa33fc
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I645JI
CVE: NA

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

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

When I was investigating the swap code, I found the below possible race
window:

CPU 1                                         CPU 2
-----                                         -----
shmem_swapin
  swap_cluster_readahead
    if (likely(si->flags & (SWP_BLKDEV | SWP_FS_OPS))) {
                                              swapoff
                                                ..
                                                si->swap_file = NULL;
                                                ..
    struct inode *inode = si->swap_file->f_mapping->host;[oops!]

Close this race window by using get/put_swap_device() to guard against
concurrent swapoff.

Link: https://lkml.kernel.org/r/20210426123316.806267-5-linmiaohe@huawei.com
Fixes: 8fd2e0b5 ("mm: swap: check if swap backing device is congested or not")
Signed-off-by: NMiaohe Lin <linmiaohe@huawei.com>
Reviewed-by: N"Huang, Ying" <ying.huang@intel.com>
Cc: Dennis Zhou <dennis@kernel.org>
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Alex Shi <alexs@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NChen Wandun <chenwandun@huawei.com>
Reviewed-by: Kefeng Wang<wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

c8f1dd00

swap: fix do_swap_page() race with swapoff · 504f60d0

由 Miaohe Lin 提交于 12月 08, 2022

mainline inclusion
from mainline-v5.14-rc1
commit 2799e775
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I645JI
CVE: NA

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

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

When I was investigating the swap code, I found the below possible race
window:

CPU 1                                   	CPU 2
-----                                   	-----
do_swap_page
  if (data_race(si->flags & SWP_SYNCHRONOUS_IO)
  swap_readpage
    if (data_race(sis->flags & SWP_FS_OPS)) {
                                        	swapoff
					  	  ..
					  	  p->swap_file = NULL;
					  	  ..
    struct file *swap_file = sis->swap_file;
    struct address_space *mapping = swap_file->f_mapping;[oops!]

Note that for the pages that are swapped in through swap cache, this isn't
an issue. Because the page is locked, and the swap entry will be marked
with SWAP_HAS_CACHE, so swapoff() can not proceed until the page has been
unlocked.

Fix this race by using get/put_swap_device() to guard against concurrent
swapoff.

Link: https://lkml.kernel.org/r/20210426123316.806267-3-linmiaohe@huawei.com
Fixes: 0bcac06f ("mm,swap: skip swapcache for swapin of synchronous device")
Signed-off-by: NMiaohe Lin <linmiaohe@huawei.com>
Reviewed-by: N"Huang, Ying" <ying.huang@intel.com>
Cc: Alex Shi <alexs@kernel.org>
Cc: David Hildenbrand <david@redhat.com>
Cc: Dennis Zhou <dennis@kernel.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Conflicts:
	mm/memory.c
Signed-off-by: NChen Wandun <chenwandun@huawei.com>
Reviewed-by: Kefeng Wang<wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

504f60d0

mm/swapfile: fix broken kabi in swap_info_struct · 46d673d7

由 Chen Wandun 提交于 12月 08, 2022

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

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

This patch fix kabi problem introduced by commit
("mm/swapfile:use percpu_ref to serialize against concurrent swapoff").

Considering swap_info_struct is referenced by pointer and dont use
in third module, so use KABI_EXTEND for two new member variables in
swap_info_struct. Besides, dont remove unused enum value SWP_VALID,
avoid unnecessary undefined alarms.
Signed-off-by: NChen Wandun <chenwandun@huawei.com>
Reviewed-by: Kefeng Wang<wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

46d673d7

mm/swapfile: use percpu_ref to serialize against concurrent swapoff · b95abeb4

由 Miaohe Lin 提交于 12月 08, 2022

mainline inclusion
from mainline-v5.14-rc1
commit 63d8620e
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I645JI
CVE: NA

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

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

Patch series "close various race windows for swap", v6.

When I was investigating the swap code, I found some possible race
windows.  This series aims to fix all these races.  But using current
get/put_swap_device() to guard against concurrent swapoff for
swap_readpage() looks terrible because swap_readpage() may take really
long time.  And to reduce the performance overhead on the hot-path as much
as possible, it appears we can use the percpu_ref to close this race
window(as suggested by Huang, Ying).  The patch 1 adds percpu_ref support
for swap and most of the remaining patches try to use this to close
various race windows.  More details can be found in the respective
changelogs.

This patch (of 4):

Using current get/put_swap_device() to guard against concurrent swapoff
for some swap ops, e.g.  swap_readpage(), looks terrible because they
might take really long time.  This patch adds the percpu_ref support to
serialize against concurrent swapoff(as suggested by Huang, Ying).  Also
we remove the SWP_VALID flag because it's used together with RCU solution.

Link: https://lkml.kernel.org/r/20210426123316.806267-1-linmiaohe@huawei.com
Link: https://lkml.kernel.org/r/20210426123316.806267-2-linmiaohe@huawei.comSigned-off-by: NMiaohe Lin <linmiaohe@huawei.com>
Reviewed-by: N"Huang, Ying" <ying.huang@intel.com>
Cc: Alex Shi <alexs@kernel.org>
Cc: David Hildenbrand <david@redhat.com>
Cc: Dennis Zhou <dennis@kernel.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NChen Wandun <chenwandun@huawei.com>
Reviewed-by: Kefeng Wang<wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

b95abeb4

swapfile: fix soft lockup in scan_swap_map_slots · b2b6c3df

由 Chen Wandun 提交于 12月 08, 2022

mainline inclusion
from mainline-v6.1-rc7
commit de1ccfb6
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I645DG
CVE: NA

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

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

A softlockup occurs in scan free swap slot under huge memory pressure.
The test scenario is: 64 CPU cores, 64GB memory, and 28 zram devices, the
disksize of each zram device is 50MB.

LATENCY_LIMIT is used to prevent softlockups in scan_swap_map_slots(), but
the real loop number would more than LATENCY_LIMIT because of "goto checks
and goto scan" repeatly without decreasing latency limit.

In order to fix it, decrease latency_ration in advance.

There is also a suspicious place that will cause softlockups in
get_swap_pages().  In this function, the "goto start_over" may result in
continuous scanning of the swap partition.  If there is no cond_sched in
scan_swap_map_slots(), it would cause a softlockup (I am not sure about
this).

WARN: soft lockup - CPU#11 stuck for 11s! [kswapd0:466]
CPU: 11 PID: 466 Comm: kswapd@ Kdump: loaded Tainted: G
dump backtrace+0x0/0x1le4
show stack+0x20/@x2c
dump_stack+0xd8/0x140
watchdog print_info+0x48/0x54
watchdog_process_before_softlockup+0x98/0xa0
watchdog_timer_fn+0xlac/0x2d0
hrtimer_rum_queues+0xb0/0x130
hrtimer_interrupt+0x13c/0x3c0
arch_timer_handler_virt+0x3c/0x50
handLe_percpu_devid_irq+0x90/0x1f4
handle domain irq+0x84/0x100
gic_handle_irq+0x88/0x2b0
e11 ira+0xhB/Bx140
scan_swap_map_slots+0x678/0x890
get_swap_pages+0x29c/0x440
get_swap_page+0x120/0x2e0
add_to_swap+UX2U/0XyC
shrink_page_list+0x5d0/0x152c
shrink_inactive_list+0xl6c/Bx500
shrink_lruvec+0x270/0x304

WARN: soft lockup - CPU#32 stuck for 11s! [stress-ng:309915]
watchdog_timer_fn+0x1ac/0x2d0
__run_hrtimer+0x98/0x2a0
__hrtimer_run_queues+0xb0/0x130
hrtimer_interrupt+0x13c/0x3c0
arch_timer_handler_virt+0x3c/0x50
handle_percpu_devid_irq+0x90/0x1f4
__handle_domain_irq+0x84/0x100
gic_handle_irq+0x88/0x2b0
el1_irq+0xb8/0x140
get_swap_pages+0x1e8/0x440
get_swap_page+0x1c8/0x2e0
add_to_swap+0x20/0x9c
shrink_page_list+0x5d0/0x152c
reclaim_pages+0x160/0x310
madvise_cold_or_pageout_pte_range+0x7bc/0xe3c
walk_pmd_range.isra.0+0xac/0x22c
walk_pud_range+0xfc/0x1c0
walk_pgd_range+0x158/0x1b0
__walk_page_range+0x64/0x100
walk_page_range+0x104/0x150

Link: https://lkml.kernel.org/r/20221118133850.3360369-1-chenwandun@huawei.com
Fixes: 048c27fd ("[PATCH] swap: scan_swap_map latency breaks")
Signed-off-by: NChen Wandun <chenwandun@huawei.com>
Reviewed-by: N"Huang, Ying" <ying.huang@intel.com>
Cc: Hugh Dickins <hugh@veritas.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Nanyong Sun <sunnanyong@huawei.com>
Cc: <xialonglong1@huawei.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Conflicts:
	mm/swapfile.c
Signed-off-by: NChen Wandun <chenwandun@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

b2b6c3df

spi: hisi-sfc-v3xx: drop unnecessary ACPI_PTR and related ifendif protection · 73c99647

由 Yicong Yang 提交于 12月 08, 2022

mainline inclusion
from mainline-v5.13-rc1
commit 4a46f886
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I63WDM
CVE: NA

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

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

We use ACPI_PTR() and related ifendif protection for the id table.
This is unnecessary as the struct acpi_device_id is defined in
mod_devicetable.h and doesn't rely on ACPI. The driver doesn't
use any ACPI apis, so it can be compiled in the ACPI=n case
with no warnings.

So remove the ACPI_PTR and related ifendif protection, also
replace the header acpi.h with mod_devicetable.h.
Acked-by: NJohn Garry <john.garry@huawei.com>
Signed-off-by: NYicong Yang <yangyicong@hisilicon.com>
Link: https://lore.kernel.org/r/1618228708-37949-3-git-send-email-yangyicong@hisilicon.comSigned-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NWangming Shao <shaowangming@h-partners.com>
Reviewed-by: NYicong Yang <yangyicong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

73c99647

spi: hisi-sfc-v3xx: fix potential irq race condition · ab2463b2

由 Yicong Yang 提交于 12月 08, 2022

mainline inclusion
from mainline-v5.13-rc1
commit 4c84e42d
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I63WDM
CVE: NA

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

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

We mask the irq when the command completion is timeout. This won't
stop the already running irq handler. Use sychronize_irq() after
we mask the irq, to make sure there is no running handler.
Acked-by: NJohn Garry <john.garry@huawei.com>
Signed-off-by: NYicong Yang <yangyicong@hisilicon.com>
Link: https://lore.kernel.org/r/1618228708-37949-2-git-send-email-yangyicong@hisilicon.comSigned-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NWangming Shao <shaowangming@h-partners.com>
Reviewed-by: NYicong Yang <yangyicong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

ab2463b2

spi: hisi-sfc-v3xx: add address mode check · 012ba5cd

由 Yicong Yang 提交于 12月 08, 2022

mainline inclusion
from mainline-v5.12-rc1
commit 6d2386e3
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I63WDM
CVE: NA

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

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

The address mode is either 3 or 4 for the controller, which is configured
by the firmware and cannot be modified in the OS driver. Get the
firmware configuration and add address mode check in the .supports_op()
to block invalid operations.
Signed-off-by: NYicong Yang <yangyicong@hisilicon.com>
Acked-by: NJohn Garry <john.garry@huawei.com>
Link: https://lore.kernel.org/r/1611740450-47975-3-git-send-email-yangyicong@hisilicon.comSigned-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NWangming Shao <shaowangming@h-partners.com>
Reviewed-by: NYicong Yang <yangyicong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

012ba5cd

spi: hisi-sfc-v3xx: extend version checking compatibility · f36068b8

由 Yicong Yang 提交于 12月 08, 2022

mainline inclusion
from mainline-v5.12-rc1
commit 566c6120
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I63WDM
CVE: NA

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

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

Currently we use concrete version to determine the max_cmd_dword.
New entries should be added for compatible hardwares of new version
or on new platform, otherwise the device will use 16 dwords instead
of 64 even if it supports, which will degrade the performance.
This will decrease the compatibility and the maintainability.

Drop the switch-case statement of the version checking. Only version
less than 0x351 supports maximum 16 command dwords.
Signed-off-by: NYicong Yang <yangyicong@hisilicon.com>
Acked-by: NJohn Garry <john.garry@huawei.com>
Link: https://lore.kernel.org/r/1610526716-14882-1-git-send-email-yangyicong@hisilicon.comSigned-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NWangming Shao <shaowangming@h-partners.com>
Reviewed-by: NYicong Yang <yangyicong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

f36068b8

coresight: ete: Add acpi match id for Hip09 · 4dbe4845

由 Junhao He 提交于 12月 08, 2022

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5YCYK

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

Add the acpi match id for Hip09 ETE
Signed-off-by: NJunhao He <hejunhao3@huawei.com>
Reviewed-by: NLing Mingqiang <lingmingqiang@huawei.com>
Reviewed-by: NYicong Yang <yangyicong@huawei.com>
Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: NYang Shen <shenyang39@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

4dbe4845

coresight: etm4x: Fix accesses to TRCSEQRSTEVR and TRCSEQSTR · c910b99c

由 Junhao He 提交于 12月 08, 2022

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

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

The TRCSEQRSTEVR and TRCSEQSTR register is not implemented if the
TRCIDR5.NUMSEQSTATE == 0. Skip accessing the register in such cases.
Signed-off-by: NJunhao He <hejunhao3@huawei.com>
Reviewed-by: NLing Mingqiang <lingmingqiang@huawei.com>
Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: NYang Shen <shenyang39@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

c910b99c

l2tp: Don't sleep and disable BH under writer-side sk_callback_lock · aabaf7d2

由 Jakub Sitnicki 提交于 12月 08, 2022

mainline inclusion
from mainline-v6.1-rc7
commit af295e85
category: bugfix
bugzilla: 188056, https://gitee.com/src-openeuler/kernel/issues/I62RNU
CVE: CVE-2022-4129

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

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

When holding a reader-writer spin lock we cannot sleep. Calling
setup_udp_tunnel_sock() with write lock held violates this rule, because we
end up calling percpu_down_read(), which might sleep, as syzbot reports
[1]:

 __might_resched.cold+0x222/0x26b kernel/sched/core.c:9890
 percpu_down_read include/linux/percpu-rwsem.h:49 [inline]
 cpus_read_lock+0x1b/0x140 kernel/cpu.c:310
 static_key_slow_inc+0x12/0x20 kernel/jump_label.c:158
 udp_tunnel_encap_enable include/net/udp_tunnel.h:187 [inline]
 setup_udp_tunnel_sock+0x43d/0x550 net/ipv4/udp_tunnel_core.c:81
 l2tp_tunnel_register+0xc51/0x1210 net/l2tp/l2tp_core.c:1509
 pppol2tp_connect+0xcdc/0x1a10 net/l2tp/l2tp_ppp.c:723

Trim the writer-side critical section for sk_callback_lock down to the
minimum, so that it covers only operations on sk_user_data.

Also, when grabbing the sk_callback_lock, we always need to disable BH, as
Eric points out. Failing to do so leads to deadlocks because we acquire
sk_callback_lock in softirq context, which can get stuck waiting on us if:

1) it runs on the same CPU, or

       CPU0
       ----
  lock(clock-AF_INET6);
  <Interrupt>
    lock(clock-AF_INET6);

2) lock ordering leads to priority inversion

       CPU0                    CPU1
       ----                    ----
  lock(clock-AF_INET6);
                               local_irq_disable();
                               lock(&tcp_hashinfo.bhash[i].lock);
                               lock(clock-AF_INET6);
  <Interrupt>
    lock(&tcp_hashinfo.bhash[i].lock);

... as syzbot reports [2,3]. Use the _bh variants for write_(un)lock.

[1] https://lore.kernel.org/netdev/0000000000004e78ec05eda79749@google.com/
[2] https://lore.kernel.org/netdev/000000000000e38b6605eda76f98@google.com/
[3] https://lore.kernel.org/netdev/000000000000dfa31e05eda76f75@google.com/

v2:
- Check and set sk_user_data while holding sk_callback_lock for both
  L2TP encapsulation types (IP and UDP) (Tetsuo)

Cc: Tom Parkin <tparkin@katalix.com>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Fixes: b68777d5 ("l2tp: Serialize access to sk_user_data with sk_callback_lock")
Reported-by: NEric Dumazet <edumazet@google.com>
Reported-by: syzbot+703d9e154b3b58277261@syzkaller.appspotmail.com
Reported-by: syzbot+50680ced9e98a61f7698@syzkaller.appspotmail.com
Reported-by: syzbot+de987172bb74a381879b@syzkaller.appspotmail.com
Signed-off-by: NJakub Sitnicki <jakub@cloudflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NLu Wei <luwei32@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

aabaf7d2

l2tp: Serialize access to sk_user_data with sk_callback_lock · 0cf7ae33

由 Jakub Sitnicki 提交于 12月 08, 2022

mainline inclusion
from mainline-v6.1-rc6
commit b68777d5
category: bugfix
bugzilla: 188056, https://gitee.com/src-openeuler/kernel/issues/I62RNU
CVE: CVE-2022-4129

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

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

sk->sk_user_data has multiple users, which are not compatible with each
other. Writers must synchronize by grabbing the sk->sk_callback_lock.

l2tp currently fails to grab the lock when modifying the underlying tunnel
socket fields. Fix it by adding appropriate locking.

We err on the side of safety and grab the sk_callback_lock also inside the
sk_destruct callback overridden by l2tp, even though there should be no
refs allowing access to the sock at the time when sk_destruct gets called.

v4:
- serialize write to sk_user_data in l2tp sk_destruct

v3:
- switch from sock lock to sk_callback_lock
- document write-protection for sk_user_data

v2:
- update Fixes to point to origin of the bug
- use real names in Reported/Tested-by tags

Cc: Tom Parkin <tparkin@katalix.com>
Fixes: 3557baab ("[L2TP]: PPP over L2TP driver core")
Reported-by: NHaowei Yan <g1042620637@gmail.com>
Signed-off-by: NJakub Sitnicki <jakub@cloudflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NLu Wei <luwei32@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

0cf7ae33

Bluetooth: L2CAP: Fix u8 overflow · a7bf6b62

由 Sungwoo Kim 提交于 12月 08, 2022

maillist inclusion
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I63D3E
CVE: CVE-2022-45934

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ae4569813a6e931258db627cdfe50dfb4f917d5d

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

By keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increases
multiple times and eventually it will wrap around the maximum number
(i.e., 255).
This patch prevents this by adding a boundary check with
L2CAP_MAX_CONF_RSP

Btmon log:
Bluetooth monitor ver 5.64
= Note: Linux version 6.1.0-rc2 (x86_64)                               0.264594
= Note: Bluetooth subsystem version 2.22                               0.264636
@ MGMT Open: btmon (privileged) version 1.22                  {0x0001} 0.272191
= New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0)          [hci0] 13.877604
@ RAW Open: 9496 (privileged) version 2.22                   {0x0002} 13.890741
= Open Index: 00:00:00:00:00:00                                [hci0] 13.900426
(...)
> ACL Data RX: Handle 200 flags 0x00 dlen 1033             #32 [hci0] 14.273106
        invalid packet size (12 != 1033)
        08 00 01 00 02 01 04 00 01 10 ff ff              ............
> ACL Data RX: Handle 200 flags 0x00 dlen 1547             #33 [hci0] 14.273561
        invalid packet size (14 != 1547)
        0a 00 01 00 04 01 06 00 40 00 00 00 00 00        ........@.....
> ACL Data RX: Handle 200 flags 0x00 dlen 2061             #34 [hci0] 14.274390
        invalid packet size (16 != 2061)
        0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04  ........@.......
> ACL Data RX: Handle 200 flags 0x00 dlen 2061             #35 [hci0] 14.274932
        invalid packet size (16 != 2061)
        0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00  ........@.......
= bluetoothd: Bluetooth daemon 5.43                                   14.401828
> ACL Data RX: Handle 200 flags 0x00 dlen 1033             #36 [hci0] 14.275753
        invalid packet size (12 != 1033)
        08 00 01 00 04 01 04 00 40 00 00 00              ........@...
Signed-off-by: NSungwoo Kim <iam@sung-woo.kim>
Signed-off-by: NLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: NBaisong Zhong <zhongbaisong@huawei.com>
Reviewed-by: NLiu Jian <liujian56@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

a7bf6b62

workqueue: fix state-dump console deadlock · 3d01105a

由 Johan Hovold 提交于 12月 08, 2022

mainline inclusion
from mainline-v5.15-rc6
commit 57116ce1
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I61CQ3

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

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

Console drivers often queue work while holding locks also taken in their
console write paths, something which can lead to deadlocks on SMP when
dumping workqueue state (e.g. sysrq-t or on suspend failures).

For serial console drivers this could look like:

	CPU0				CPU1
	----				----

	show_workqueue_state();
	  lock(&pool->lock);		<IRQ>
	  				  lock(&port->lock);
					  schedule_work();
					    lock(&pool->lock);
	  printk();
	    lock(console_owner);
	    lock(&port->lock);

where workqueues are, for example, used to push data to the line
discipline, process break signals and handle modem-status changes. Line
disciplines and serdev drivers can also queue work on write-wakeup
notifications, etc.

Reworking every console driver to avoid queuing work while holding locks
also taken in their write paths would complicate drivers and is neither
desirable or feasible.

Instead use the deferred-printk mechanism to avoid printing while
holding pool locks when dumping workqueue state.

Note that there are a few WARN_ON() assertions in the workqueue code
which could potentially also trigger a deadlock. Hopefully the ongoing
printk rework will provide a general solution for this eventually.

This was originally reported after a lockdep splat when executing
sysrq-t with the imx serial driver.

Fixes: 3494fc30 ("workqueue: dump workqueues on sysrq-t")
Cc: stable@vger.kernel.org	# 4.0
Reported-by: NFabio Estevam <festevam@denx.de>
Tested-by: NFabio Estevam <festevam@denx.de>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Reviewed-by: NJohn Ogness <john.ogness@linutronix.de>
Signed-off-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

3d01105a

preempt/dynamic: Fix typo in macro conditional statement · b2952a9c

由 Zhouyi Zhou 提交于 12月 08, 2022

mainline inclusion
from mainline-v5.12
commit 0c89d87d
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I61CQ3

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

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

Commit 40607ee9 ("preempt/dynamic: Provide irqentry_exit_cond_resched()
static call") tried to provide irqentry_exit_cond_resched() static call
in irqentry_exit, but has a typo in macro conditional statement.

Fixes: 40607ee9 ("preempt/dynamic: Provide irqentry_exit_cond_resched() static call")
Signed-off-by: NZhouyi Zhou <zhouzhouyi@gmail.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20210410073523.5493-1-zhouzhouyi@gmail.comSigned-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

b2952a9c

jump_label: Fix usage in module __init · 5c1c7c8b

由 Peter Zijlstra 提交于 12月 08, 2022

mainline inclusion
from mainline-v5.11-rc1
commit 55d2eba8
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I61CQ3

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

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

When the static_key is part of the module, and the module calls
static_key_inc/enable() from it's __init section *AND* has a
static_branch_*() user in that very same __init section, things go
wobbly.

If the static_key lives outside the module, jump_label_add_module()
would append this module's sites to the key and jump_label_update()
would take the static_key_linked() branch and all would be fine.

If all the sites are outside of __init, then everything will be fine
too.

However, when all is aligned just as described above,
jump_label_update() calls __jump_label_update(.init = false) and we'll
not update sites in __init text.

Fixes: 19483677 ("jump_label: Annotate entries that operate on __init code earlier")
Reported-by: NDexuan Cui <decui@microsoft.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com>
Tested-by: NJessica Yu <jeyu@kernel.org>
Link: https://lkml.kernel.org/r/20201216135435.GV3092@hirez.programming.kicks-ass.netSigned-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

5c1c7c8b

arm64/mpam: update last_cmd_status in parse_cache() and parse_bw() · d329f67f

由 Jialin Zhang 提交于 12月 08, 2022

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

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

Update last_cmd_status to tell the reasons of returning 'Invalid argument'
in parse_cache() and parse_bw().
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

d329f67f

openeuler / Kernel 1 年多 前同步成功

openeuler / Kernel
1 年多前同步成功