提交 · a1816ee09a141ccd5227c2225b37a626546ead39 · openeuler / Kernel

14 6月, 2023 6 次提交

gfs2: Don't deref jdesc in evict · a1816ee0

由 Bob Peterson 提交于 6月 14, 2023

mainline inclusion
from mainline-v6.4-rc2
commit 504a10d9
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7CXJL
CVE: CVE-2023-3212

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

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

On corrupt gfs2 file systems the evict code can try to reference the
journal descriptor structure, jdesc, after it has been freed and set to
NULL. The sequence of events is:

init_journal()
...
fail_jindex:
   gfs2_jindex_free(sdp); <------frees journals, sets jdesc = NULL
      if (gfs2_holder_initialized(&ji_gh))
         gfs2_glock_dq_uninit(&ji_gh);
fail:
   iput(sdp->sd_jindex); <--references jdesc in evict_linked_inode
      evict()
         gfs2_evict_inode()
            evict_linked_inode()
               ret = gfs2_trans_begin(sdp, 0, sdp->sd_jdesc->jd_blocks);
<------references the now freed/zeroed sd_jdesc pointer.

The call to gfs2_trans_begin is done because the truncate_inode_pages
call can cause gfs2 events that require a transaction, such as removing
journaled data (jdata) blocks from the journal.

This patch fixes the problem by adding a check for sdp->sd_jdesc to
function gfs2_evict_inode. In theory, this should only happen to corrupt
gfs2 file systems, when gfs2 detects the problem, reports it, then tries
to evict all the system inodes it has read in up to that point.
Reported-by: NYang Lan <lanyang0908@gmail.com>
Signed-off-by: NBob Peterson <rpeterso@redhat.com>
Signed-off-by: NAndreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: NZhaoLong Wang <wangzhaolong1@huawei.com>

Conflicts:
        fs/gfs2/super.c

a1816ee0

!1071 [sync] PR-1069: support ACPI for MPAM 2.0 · 0e6a6ad6

由 openeuler-ci-bot 提交于 6月 14, 2023

Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1069 
 
PR sync from:  Yu Liao <liaoyu15@huawei.com>
 https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/CQNKMRKUYC4EDBYHOMD6CXZQPZEJBMFY/ 
This patch series support ACPI for MPAM 2.0.

v5: fix unused variable warning.

v4: add PPTT null check to prevent NULL pointer deference.


Erik Kaneda (1):
  ACPICA: ACPI 6.4: PPTT: add new version of subtable type 1

Hesham Almatary (1):
  ACPICA: Add support for Arm's MPAM ACPI table version 2

Yu Liao (2):
  ACPI / PPTT: Find PPTT processor node by cache id
  ACPI/MPAM: Adapt to Arm's MPAM ACPI table version 2


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

Reviewed-by: Wang ShaoBo <bobo.shaobowang@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>

0e6a6ad6

!1023 spi: dw: Add support for 32-bits max xfer size · a61f7e3c

由 openeuler-ci-bot 提交于 6月 14, 2023

Merge Pull Request from: @lujunhuaHW 
 
The Synopsis DesignWare DW_apb_ssi specifications version 3.23 onward
define a 32-bits maximum transfer size synthesis parameter
(SSI_MAX_XFER_SIZE=32) in addition to the legacy 16-bits configuration
(SSI_MAX_XFER_SIZE=16) for SPI controllers. When SSI_MAX_XFER_SIZE=32,
the layout of the ctrlr0 register changes, moving the data frame format
field from bits [3..0] to bits [16..20], and the RX/TX FIFO word size
can be up to 32-bits.

To support this new format, introduce the DW SPI capability flag
DW_SPI_CAP_DFS32 to indicate that a controller is configured with
SSI_MAX_XFER_SIZE=32. Since SSI_MAX_XFER_SIZE is a controller synthesis
parameter not accessible through a register, the detection of this
parameter value is done in spi_hw_init() by writing and reading the
ctrlr0 register and testing the value of bits [3..0]. These bits are
ignored (unchanged) for SSI_MAX_XFER_SIZE=16, allowing the detection.
If a DFS32 capable SPI controller is detected, the new field dfs_offset
in struct dw_spi is set to SPI_DFS32_OFFSET (16).

dw_spi_update_config() is modified to set the data frame size field at
the correct position is the CTRLR0 register, as indicated by the
dfs_offset field of the dw_spi structure.

The DW_SPI_CAP_DFS32 flag is also unconditionally set for SPI slave
controllers, e.g. controllers that have the DW_SPI_CAP_DWC_SSI
capability flag set. However, for these ssi controllers, the dfs_offset
field is set to 0 as before (as per specifications).

Finally, for any controller with the DW_SPI_CAP_DFS32 capability flag
set, dw_spi_add_host() extends the value of bits_per_word_mask from
16-bits to 32-bits. dw_reader() and dw_writer() are also modified to
handle 32-bits iTX/RX FIFO words.
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1023 

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

a61f7e3c

!1075 [sync] PR-1042: xfrm: Reinject transport-mode packets through workqueue · f4a055cc

由 openeuler-ci-bot 提交于 6月 14, 2023

Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1042 
 
PR sync from:  Liu Jian <liujian56@huawei.com>
 https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/XZRFZY2DDUQG3YGA4NRUPJDCHSZ77ENA/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1075 

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

f4a055cc

!991 genirq: Increase the number of IRQ descriptors · d37ad37e

由 openeuler-ci-bot 提交于 6月 14, 2023

Merge Pull Request from: @did-you-collect-the-wool-today 
 
virt inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7BQMW
CVE: NA

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

The deafault value of NR_IRQS is not sufficient to support GICv4.1
features and ~56K LPIs. This parameter would be too small for certain
server platforms where it has many IO devices and is capable of
direct injection of vSGI and vLPI features.

Currently, maximum of 64 + 8192 (IRQ_BITMAP_BITS) IRQ descriptors
are allowed. The vCPU creation fails after reaching count ~400 with
kvm-arm.vgic_v4_enable=1.

This patch increases NR_IRQS to 1^19 to cover 56K LPIs and 262144
vSGIs (16vPEs x 16).

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

Tips: Tish is a temporary fix[1], but it has been able to solve the
problem. The latest upstream version[2] depends on the 'maple tree',
which is inappropriately introduced to the current kernel.

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

Another Tips: According to Chao Liu and Chang Liao's suggestion,
modifying IRQ_BITMAP_BITS can achieve the same effect with less
impact. Compared with solution[2], solution[1] has a disadvantage:
the memory foot print increases as the number of VMs increases.

Link: https://lore.kernel.org/linux-arm-kernel/20230104023738.1258925-1-sdonthineni@nvidia.com/ [1]
Link: https://lore.kernel.org/all/20230519134902.1495562-1-sdonthineni@nvidia.com/#t [2]
Signed-off-by: NShanker Donthineni <sdonthineni@nvidia.com>
Signed-off-by: NChao Liu <liuchao173@huawei.com>
Signed-off-by: NChang Liao <liaochang1@huawei.com>
Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com> 
 
Link:https://gitee.com/openeuler/kernel/pulls/991 

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

d37ad37e

!1115 userswap bugfix · d2e17ab3

由 openeuler-ci-bot 提交于 6月 14, 2023

Merge Pull Request from: @ci-robot 
 
PR sync from:  Peng Zhang <zhangpeng362@huawei.com>
 https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/GRJWIT22G2QJFYJL64FIBD6E7V5TTDY5/ 
From: ZhangPeng <zhangpeng362@huawei.com>

Fix Fuzz test BUG_ON and failure to swap out large memory. Two userswap
bugfixes synchronized from hulk5.10.

ZhangPeng (2):
  userswap: fix BUG_ON in userfaultfd_release()
  userswap: fix kmalloc ENOMEM failed for a large memory


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

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

d2e17ab3

13 6月, 2023 9 次提交

!1113 net: hns3: refactor hclge_mac_link_status_wait and add wait until mac link down · 73539a5e

由 openeuler-ci-bot 提交于 6月 13, 2023

Merge Pull Request from: @svishen 
 
This pull Requests refactor hclge_mac_link_status_wait and add wait until mac link down

issue:
https://gitee.com/openeuler/kernel/issues/I7D6IP 
 
Link:https://gitee.com/openeuler/kernel/pulls/1113 

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

73539a5e

!1084 LoongArch: fix wrong 7a1000 int_clear register write · c77f4455

由 openeuler-ci-bot 提交于 6月 13, 2023

Merge Pull Request from: @Hongchen_Zhang 
 
7A1000 int_clear register should be write 64bit aligned. 
 
Link:https://gitee.com/openeuler/kernel/pulls/1084 

Reviewed-by: Guo Dongtai <guodongtai@kylinos.cn> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>

c77f4455

!1083 LoongArch: fix system hang caused by 2k500 bmc driver · e1c4614e

由 openeuler-ci-bot 提交于 6月 13, 2023

Merge Pull Request from: @Hongchen_Zhang 
 
when we test the 2k500 bmc,the system hang when send the following command:
[loongson@localhost ~]# ipmi mc reset cold

After apply this PR,the problem disappeared. 
 
Link:https://gitee.com/openeuler/kernel/pulls/1083 

Reviewed-by: Guo Dongtai <guodongtai@kylinos.cn> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>

e1c4614e

userswap: fix kmalloc ENOMEM failed for a large memory · 6935faf1

由 ZhangPeng 提交于 6月 13, 2023

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

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

If the swapped-out memory is large, such as tens of gigabytes, we will
allocate a large management structure, which may be tens of megabytes or
hundreds of megabytes. So if we use kmalloc to allocate management
structures it may fail.
Fix this by changing kmalloc to kvzalloc and kfree to kvfree.
Signed-off-by: NZhangPeng <zhangpeng362@huawei.com>

6935faf1

userswap: fix BUG_ON in userfaultfd_release() · 9f98927f

由 ZhangPeng 提交于 6月 13, 2023

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

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

In some features of userfaultfd, vma->vm_userfaultfd_ctx.ctx may be NULL
but VM_USWAP is not cleared. No longer check whether vma->vm_flags has
VM_USWAP. Just remove the flag.
Signed-off-by: NZhangPeng <zhangpeng362@huawei.com>

9f98927f

net: hns3: add wait until mac link down · 072e8c4b

由 Jie Wang 提交于 6月 06, 2023

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

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

In some configure flow of hns3 driver, for example, change mtu, it will
disable MAC through firmware before configuration. But firmware disables
MAC asynchronously. The rx traffic may be not stopped in this case.

So fixes it by waiting until mac link is down.

Fixes: a9775bb6 ("net: hns3: fix set and get link ksettings issue")
Signed-off-by: NJie Wang <wangjie125@huawei.com>

072e8c4b

net: hns3: refactor hclge_mac_link_status_wait for interface reuse · 2661a2cb

由 Jie Wang 提交于 6月 08, 2023

driver inclusion
category: cleanup
bugzilla: https://gitee.com/openeuler/kernel/issues/I7D6IP
CVE: NA

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

Some nic configurations could only be performed after link is down. So this
patch refactor this API for reuse.
Signed-off-by: NJie Wang <wangjie125@huawei.com>

2661a2cb

!1089 power: supply: bq24190: Fix use after free bug in bq24190_remove due to race condition · d8a73976

由 openeuler-ci-bot 提交于 6月 13, 2023

Merge Pull Request from: @ci-robot 
 
PR sync from:  Zhao Wenhui <zhaowenhui8@huawei.com>
 https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/FTJHXWWTIUDTIGLFJ4DL6XSYWRZEPLE4/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1089 

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

d8a73976

!1090 fs/ntfs3: Check fields while reading · a93f466a

由 openeuler-ci-bot 提交于 6月 13, 2023

Merge Pull Request from: @ci-robot 
 
PR sync from:  ZhaoLong Wang <wangzhaolong1@huawei.com>
 https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/VQ5QP4GZFTJCMRJ3WK33W5A5SSQR2MY7/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1090 

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

a93f466a

12 6月, 2023 5 次提交

fs/ntfs3: Check fields while reading · 9fc58dcc

由 Konstantin Komarov 提交于 6月 12, 2023

mainline inclusion
from mainline-v6.2-rc1
commit 0e8235d2
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I79X84
CVE: CVE-2022-48502

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

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

Added new functions index_hdr_check and index_buf_check.
Now we check all stuff for correctness while reading from disk.
Also fixed bug with stale nfs data.
Reported-by: Nvan fantasy <g1042620637@gmail.com>
Signed-off-by: NKonstantin Komarov <almaz.alexandrovich@paragon-software.com>
Signed-off-by: NZhaoLong Wang <wangzhaolong1@huawei.com>

Conflicts:
	fs/ntfs3/inode.c
	fs/ntfs3/xattr.c

9fc58dcc

genirq: Increase the number of IRQ descriptors · 3596cc5a

由 Kunkun Jiang 提交于 6月 07, 2023

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

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

The deafault value of NR_IRQS is not sufficient to support GICv4.1
features and ~56K LPIs. This parameter would be too small for certain
server platforms where it has many IO devices and is capable of
direct injection of vSGI and vLPI features.

Currently, maximum of 64 + 8192 (IRQ_BITMAP_BITS) IRQ descriptors
are allowed. The vCPU creation fails after reaching count ~400 with
kvm-arm.vgic_v4_enable=1.

This patch increases NR_IRQS to 1^19 to cover 56K LPIs and 262144
vSGIs (16vPEs x 16).

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

Tips: This is a temporary fix[1], but it has been able to solve the
problem. The latest upstream version[2] depends on the 'maple tree',
which is inappropriately introduced to the current kernel.

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

Another Tips: According to Chao Liu and Chang Liao's suggestion,
modifying IRQ_BITMAP_BITS can achieve the same effect with less
impact. Compared with solution[2], solution[1] has a disadvantage:
the memory foot print increases as the number of VMs increases.

Link: https://lore.kernel.org/linux-arm-kernel/20230104023738.1258925-1-sdonthineni@nvidia.com/ [1]
Link: https://lore.kernel.org/all/20230519134902.1495562-1-sdonthineni@nvidia.com/#t [2]
Signed-off-by: NShanker Donthineni <sdonthineni@nvidia.com>
Signed-off-by: NChao Liu <liuchao173@huawei.com>
Signed-off-by: NChang Liao <liaochang1@huawei.com>
Signed-off-by: NKunkun Jiang <jiangkunkun@huawei.com>

3596cc5a

power: supply: bq24190: Fix use after free bug in bq24190_remove due to race condition · 085b94ff

由 Zheng Wang 提交于 6月 12, 2023

stable inclusion
from stable-v5.10.177
commit 2b346876b93168541a45551d5f9abd1d26102e89
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7781Q
CVE: CVE-2023-33288

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

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

[ Upstream commit 47c29d69 ]

In bq24190_probe, &bdi->input_current_limit_work is bound
with bq24190_input_current_limit_work. When external power
changed, it will call bq24190_charger_external_power_changed
 to start the work.

If we remove the module which will call bq24190_remove to make
cleanup, there may be a unfinished work. The possible
sequence is as follows:

CPU0                  CPUc1

                    |bq24190_input_current_limit_work
bq24190_remove      |
power_supply_unregister  |
device_unregister   |
power_supply_dev_release|
kfree(psy)          |
                    |
                    | power_supply_get_property_from_supplier
                    |   //use

Fix it by finishing the work before cleanup in the bq24190_remove

Fixes: 97774672 ("power_supply: Initialize changed_work before calling device_add")
Signed-off-by: NZheng Wang <zyytlz.wz@163.com>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>

 Conflicts:
	drivers/power/supply/bq24190_charger.c
Signed-off-by: NZhao Wenhui <zhaowenhui8@huawei.com>

085b94ff

irqchip/loongson-pch-pic: 7a1000 int_clear reg must use 64bit write. · 3b5bcd2a

由 Chong Qiao 提交于 6月 07, 2023

LoongArch inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7BUJN

--------------------------------
Signed-off-by: NChong Qiao <qiaochong@loongson.cn>
Signed-off-by: NHongchen Zhang <zhanghongchen@loongson.cn>

3b5bcd2a

ipmi_si: ls2k500 kcs driver add wait bmc reboot done and rebind support. · b140ebe3

由 Chong Qiao 提交于 6月 08, 2023

LoongArch inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7CPCD

--------------------------------
Signed-off-by: NChong Qiao <qiaochong@loongson.cn>
Signed-off-by: NHongchen Zhang <zhanghongchen@loongson.cn>

b140ebe3

09 6月, 2023 8 次提交

xfrm: Reinject transport-mode packets through workqueue · 71576946

由 Liu Jian 提交于 6月 08, 2023

mainline inclusion
from mainline-v6.1-rc1
commit 4f492066
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5K0NK
CVE: NA

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

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

The following warning is displayed when the tcp6-multi-diffip11 stress
test case of the LTP test suite is tested:

watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ns-tcpserver:48198]
CPU: 0 PID: 48198 Comm: ns-tcpserver Kdump: loaded Not tainted 6.0.0-rc6+ #39
Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : des3_ede_encrypt+0x27c/0x460 [libdes]
lr : 0x3f
sp : ffff80000ceaa1b0
x29: ffff80000ceaa1b0 x28: ffff0000df056100 x27: ffff0000e51e5280
x26: ffff80004df75030 x25: ffff0000e51e4600 x24: 000000000000003b
x23: 0000000000802080 x22: 000000000000003d x21: 0000000000000038
x20: 0000000080000020 x19: 000000000000000a x18: 0000000000000033
x17: ffff0000e51e4780 x16: ffff80004e2d1448 x15: ffff80004e2d1248
x14: ffff0000e51e4680 x13: ffff80004e2d1348 x12: ffff80004e2d1548
x11: ffff80004e2d1848 x10: ffff80004e2d1648 x9 : ffff80004e2d1748
x8 : ffff80004e2d1948 x7 : 000000000bcaf83d x6 : 000000000000001b
x5 : ffff80004e2d1048 x4 : 00000000761bf3bf x3 : 000000007f1dd0a3
x2 : ffff0000e51e4780 x1 : ffff0000e3b9a2f8 x0 : 00000000db44e872
Call trace:
 des3_ede_encrypt+0x27c/0x460 [libdes]
 crypto_des3_ede_encrypt+0x1c/0x30 [des_generic]
 crypto_cbc_encrypt+0x148/0x190
 crypto_skcipher_encrypt+0x2c/0x40
 crypto_authenc_encrypt+0xc8/0xfc [authenc]
 crypto_aead_encrypt+0x2c/0x40
 echainiv_encrypt+0x144/0x1a0 [echainiv]
 crypto_aead_encrypt+0x2c/0x40
 esp6_output_tail+0x1c8/0x5d0 [esp6]
 esp6_output+0x120/0x278 [esp6]
 xfrm_output_one+0x458/0x4ec
 xfrm_output_resume+0x6c/0x1f0
 xfrm_output+0xac/0x4ac
 __xfrm6_output+0x130/0x270
 xfrm6_output+0x60/0xec
 ip6_xmit+0x2ec/0x5bc
 inet6_csk_xmit+0xbc/0x10c
 __tcp_transmit_skb+0x460/0x8c0
 tcp_write_xmit+0x348/0x890
 __tcp_push_pending_frames+0x44/0x110
 tcp_rcv_established+0x3c8/0x720
 tcp_v6_do_rcv+0xdc/0x4a0
 tcp_v6_rcv+0xc24/0xcb0
 ip6_protocol_deliver_rcu+0xf0/0x574
 ip6_input_finish+0x48/0x7c
 ip6_input+0x48/0xc0
 ip6_rcv_finish+0x80/0x9c
 xfrm_trans_reinject+0xb0/0xf4
 tasklet_action_common.constprop.0+0xf8/0x134
 tasklet_action+0x30/0x3c
 __do_softirq+0x128/0x368
 do_softirq+0xb4/0xc0
 __local_bh_enable_ip+0xb0/0xb4
 put_cpu_fpsimd_context+0x40/0x70
 kernel_neon_end+0x20/0x40
 sha1_base_do_update.constprop.0.isra.0+0x11c/0x140 [sha1_ce]
 sha1_ce_finup+0x94/0x110 [sha1_ce]
 crypto_shash_finup+0x34/0xc0
 hmac_finup+0x48/0xe0
 crypto_shash_finup+0x34/0xc0
 shash_digest_unaligned+0x74/0x90
 crypto_shash_digest+0x4c/0x9c
 shash_ahash_digest+0xc8/0xf0
 shash_async_digest+0x28/0x34
 crypto_ahash_digest+0x48/0xcc
 crypto_authenc_genicv+0x88/0xcc [authenc]
 crypto_authenc_encrypt+0xd8/0xfc [authenc]
 crypto_aead_encrypt+0x2c/0x40
 echainiv_encrypt+0x144/0x1a0 [echainiv]
 crypto_aead_encrypt+0x2c/0x40
 esp6_output_tail+0x1c8/0x5d0 [esp6]
 esp6_output+0x120/0x278 [esp6]
 xfrm_output_one+0x458/0x4ec
 xfrm_output_resume+0x6c/0x1f0
 xfrm_output+0xac/0x4ac
 __xfrm6_output+0x130/0x270
 xfrm6_output+0x60/0xec
 ip6_xmit+0x2ec/0x5bc
 inet6_csk_xmit+0xbc/0x10c
 __tcp_transmit_skb+0x460/0x8c0
 tcp_write_xmit+0x348/0x890
 __tcp_push_pending_frames+0x44/0x110
 tcp_push+0xb4/0x14c
 tcp_sendmsg_locked+0x71c/0xb64
 tcp_sendmsg+0x40/0x6c
 inet6_sendmsg+0x4c/0x80
 sock_sendmsg+0x5c/0x6c
 __sys_sendto+0x128/0x15c
 __arm64_sys_sendto+0x30/0x40
 invoke_syscall+0x50/0x120
 el0_svc_common.constprop.0+0x170/0x194
 do_el0_svc+0x38/0x4c
 el0_svc+0x28/0xe0
 el0t_64_sync_handler+0xbc/0x13c
 el0t_64_sync+0x180/0x184

Get softirq info by bcc tool:
./softirqs -NT 10
Tracing soft irq event time... Hit Ctrl-C to end.

15:34:34
SOFTIRQ          TOTAL_nsecs
block                 158990
timer               20030920
sched               46577080
net_rx             676746820
tasklet           9906067650

15:34:45
SOFTIRQ          TOTAL_nsecs
block                  86100
sched               38849790
net_rx             676532470
timer             1163848790
tasklet           9409019620

15:34:55
SOFTIRQ          TOTAL_nsecs
sched               58078450
net_rx             475156720
timer              533832410
tasklet           9431333300

The tasklet software interrupt takes too much time. Therefore, the
xfrm_trans_reinject executor is changed from tasklet to workqueue. Add add
spin lock to protect the queue. This reduces the processing flow of the
tcp_sendmsg function in this scenario.

Fixes: acf568ee ("xfrm: Reinject transport-mode packets through tasklet")
Signed-off-by: NLiu Jian <liujian56@huawei.com>
Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>

Conflicts:
	net/xfrm/xfrm_input.c
Signed-off-by: NLiu Jian <liujian56@huawei.com>
(cherry picked from commit 12093737)

71576946

ACPI/MPAM: Adapt to Arm's MPAM ACPI table version 2 · f4e900a6

由 Yu Liao 提交于 6月 09, 2023

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

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

Support ACPI for MPAM 2.0 [1]. Compatible with MPAM ACPI 1.0 by reading
ACPI revision.

[1] https://developer.arm.com/documentation/den0065/latestSigned-off-by: NYu Liao <liaoyu15@huawei.com>
(cherry picked from commit 6a2cb7bc)

f4e900a6

ACPI / PPTT: Find PPTT processor node by cache id · 05df0bc5

由 Yu Liao 提交于 6月 09, 2023

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

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

The MPAM table identifies caches by id, but the driver also wants to know
the processor node.

Add a helper that walks every possible cache, until it finds the one
identified by id, then return processor node.
Signed-off-by: NYu Liao <liaoyu15@huawei.com>
(cherry picked from commit 534ad2fc)

05df0bc5

ACPICA: ACPI 6.4: PPTT: add new version of subtable type 1 · a60c622d

由 Erik Kaneda 提交于 6月 09, 2023

mainline inclusion
from mainline-v5.13-rc1
commit 5e2e86c0
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I77UDW
CVE: NA

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

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

This commit squashes the following:

ACPICA commit 475c5e89f8f701ccdfee6ca567e33c854ecd6c9e
ACPICA commit 82cf78ac175a4b7d8842c5b786be24031c817cfd

This new subtable is only valid for PPTT version 3.

Elyes fixed a misspelled identifier in this commit.

Link: https://github.com/acpica/acpica/commit/475c5e89
Link: https://github.com/acpica/acpica/commit/82cf78acSigned-off-by: NElyes HAOUAS <ehaouas@noos.fr>
Signed-off-by: NErik Kaneda <erik.kaneda@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NYu Liao <liaoyu15@huawei.com>
(cherry picked from commit d6512433)

a60c622d

ACPICA: Add support for Arm's MPAM ACPI table version 2 · 50a00ef6

由 Hesham Almatary 提交于 6月 09, 2023

mainline inclusion
from mainline-v6.4-rc1
commit 47920aae
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I77UDW
CVE: NA

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

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

ACPICA commit 005e24bcaa6e4c7db327b4f81fb63b2715aac7e6

Complies with ACPI for Memory System Resource Partitioning and
Monitoring 2.0 [1]. Document number: DEN0065, as of December 2022.

Support for all types of MPAM resources. No support yet for:
1) MPAM PCC Interface Type
2) The optional Resource-specific data per MSC node, introduced in v2 of the
MPAM ACPI spec.

[1] https://developer.arm.com/documentation/den0065/latest

Link: https://github.com/acpica/acpica/commit/005e24bcSigned-off-by: NHesham Almatary <hesham.almatary@huawei.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Conflicts:
	include/acpi/actbl2.h
Signed-off-by: NYu Liao <liaoyu15@huawei.com>
(cherry picked from commit 6143a624)

50a00ef6

xfrm: Reinject transport-mode packets through workqueue · ee6cbb75

由 Liu Jian 提交于 6月 08, 2023

mainline inclusion
from mainline-v6.1-rc1
commit 4f492066
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5K0NK
CVE: NA

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

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

The following warning is displayed when the tcp6-multi-diffip11 stress
test case of the LTP test suite is tested:

watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ns-tcpserver:48198]
CPU: 0 PID: 48198 Comm: ns-tcpserver Kdump: loaded Not tainted 6.0.0-rc6+ #39
Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : des3_ede_encrypt+0x27c/0x460 [libdes]
lr : 0x3f
sp : ffff80000ceaa1b0
x29: ffff80000ceaa1b0 x28: ffff0000df056100 x27: ffff0000e51e5280
x26: ffff80004df75030 x25: ffff0000e51e4600 x24: 000000000000003b
x23: 0000000000802080 x22: 000000000000003d x21: 0000000000000038
x20: 0000000080000020 x19: 000000000000000a x18: 0000000000000033
x17: ffff0000e51e4780 x16: ffff80004e2d1448 x15: ffff80004e2d1248
x14: ffff0000e51e4680 x13: ffff80004e2d1348 x12: ffff80004e2d1548
x11: ffff80004e2d1848 x10: ffff80004e2d1648 x9 : ffff80004e2d1748
x8 : ffff80004e2d1948 x7 : 000000000bcaf83d x6 : 000000000000001b
x5 : ffff80004e2d1048 x4 : 00000000761bf3bf x3 : 000000007f1dd0a3
x2 : ffff0000e51e4780 x1 : ffff0000e3b9a2f8 x0 : 00000000db44e872
Call trace:
 des3_ede_encrypt+0x27c/0x460 [libdes]
 crypto_des3_ede_encrypt+0x1c/0x30 [des_generic]
 crypto_cbc_encrypt+0x148/0x190
 crypto_skcipher_encrypt+0x2c/0x40
 crypto_authenc_encrypt+0xc8/0xfc [authenc]
 crypto_aead_encrypt+0x2c/0x40
 echainiv_encrypt+0x144/0x1a0 [echainiv]
 crypto_aead_encrypt+0x2c/0x40
 esp6_output_tail+0x1c8/0x5d0 [esp6]
 esp6_output+0x120/0x278 [esp6]
 xfrm_output_one+0x458/0x4ec
 xfrm_output_resume+0x6c/0x1f0
 xfrm_output+0xac/0x4ac
 __xfrm6_output+0x130/0x270
 xfrm6_output+0x60/0xec
 ip6_xmit+0x2ec/0x5bc
 inet6_csk_xmit+0xbc/0x10c
 __tcp_transmit_skb+0x460/0x8c0
 tcp_write_xmit+0x348/0x890
 __tcp_push_pending_frames+0x44/0x110
 tcp_rcv_established+0x3c8/0x720
 tcp_v6_do_rcv+0xdc/0x4a0
 tcp_v6_rcv+0xc24/0xcb0
 ip6_protocol_deliver_rcu+0xf0/0x574
 ip6_input_finish+0x48/0x7c
 ip6_input+0x48/0xc0
 ip6_rcv_finish+0x80/0x9c
 xfrm_trans_reinject+0xb0/0xf4
 tasklet_action_common.constprop.0+0xf8/0x134
 tasklet_action+0x30/0x3c
 __do_softirq+0x128/0x368
 do_softirq+0xb4/0xc0
 __local_bh_enable_ip+0xb0/0xb4
 put_cpu_fpsimd_context+0x40/0x70
 kernel_neon_end+0x20/0x40
 sha1_base_do_update.constprop.0.isra.0+0x11c/0x140 [sha1_ce]
 sha1_ce_finup+0x94/0x110 [sha1_ce]
 crypto_shash_finup+0x34/0xc0
 hmac_finup+0x48/0xe0
 crypto_shash_finup+0x34/0xc0
 shash_digest_unaligned+0x74/0x90
 crypto_shash_digest+0x4c/0x9c
 shash_ahash_digest+0xc8/0xf0
 shash_async_digest+0x28/0x34
 crypto_ahash_digest+0x48/0xcc
 crypto_authenc_genicv+0x88/0xcc [authenc]
 crypto_authenc_encrypt+0xd8/0xfc [authenc]
 crypto_aead_encrypt+0x2c/0x40
 echainiv_encrypt+0x144/0x1a0 [echainiv]
 crypto_aead_encrypt+0x2c/0x40
 esp6_output_tail+0x1c8/0x5d0 [esp6]
 esp6_output+0x120/0x278 [esp6]
 xfrm_output_one+0x458/0x4ec
 xfrm_output_resume+0x6c/0x1f0
 xfrm_output+0xac/0x4ac
 __xfrm6_output+0x130/0x270
 xfrm6_output+0x60/0xec
 ip6_xmit+0x2ec/0x5bc
 inet6_csk_xmit+0xbc/0x10c
 __tcp_transmit_skb+0x460/0x8c0
 tcp_write_xmit+0x348/0x890
 __tcp_push_pending_frames+0x44/0x110
 tcp_push+0xb4/0x14c
 tcp_sendmsg_locked+0x71c/0xb64
 tcp_sendmsg+0x40/0x6c
 inet6_sendmsg+0x4c/0x80
 sock_sendmsg+0x5c/0x6c
 __sys_sendto+0x128/0x15c
 __arm64_sys_sendto+0x30/0x40
 invoke_syscall+0x50/0x120
 el0_svc_common.constprop.0+0x170/0x194
 do_el0_svc+0x38/0x4c
 el0_svc+0x28/0xe0
 el0t_64_sync_handler+0xbc/0x13c
 el0t_64_sync+0x180/0x184

Get softirq info by bcc tool:
./softirqs -NT 10
Tracing soft irq event time... Hit Ctrl-C to end.

15:34:34
SOFTIRQ          TOTAL_nsecs
block                 158990
timer               20030920
sched               46577080
net_rx             676746820
tasklet           9906067650

15:34:45
SOFTIRQ          TOTAL_nsecs
block                  86100
sched               38849790
net_rx             676532470
timer             1163848790
tasklet           9409019620

15:34:55
SOFTIRQ          TOTAL_nsecs
sched               58078450
net_rx             475156720
timer              533832410
tasklet           9431333300

The tasklet software interrupt takes too much time. Therefore, the
xfrm_trans_reinject executor is changed from tasklet to workqueue. Add add
spin lock to protect the queue. This reduces the processing flow of the
tcp_sendmsg function in this scenario.

Fixes: acf568ee ("xfrm: Reinject transport-mode packets through tasklet")
Signed-off-by: NLiu Jian <liujian56@huawei.com>
Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>

Conflicts:
	net/xfrm/xfrm_input.c
Signed-off-by: NLiu Jian <liujian56@huawei.com>
(cherry picked from commit 12093737)

ee6cbb75

!1004 [sync] PR-993: Clean up for RDMA/HNS · 238c6bbb

由 openeuler-ci-bot 提交于 6月 09, 2023

Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/993 
 
https://gitee.com/openeuler/kernel/issues/I7A4LC 
 
Link:https://gitee.com/openeuler/kernel/pulls/1004 

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

238c6bbb

!1028 fs: hfsplus: fix UAF issue in hfsplus_put_super · 95b9421e

由 openeuler-ci-bot 提交于 6月 09, 2023

Merge Pull Request from: @ci-robot 
 
PR sync from:  Long Li <leo.lilong@huawei.com>
 https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/SDZSQIDVZ6KO6663MZWABIKABBLHZOUS/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1028 

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

95b9421e

08 6月, 2023 12 次提交

!1027 scripts: Fix issue of module signing with openssl 3.x · a59ed522

由 openeuler-ci-bot 提交于 6月 08, 2023

Merge Pull Request from: @HuaxinLuGitee 
 
The SM2 signature for module signing is only supported
with openEuler openssl 1.1.1. Fix the compile option to
avoid compilation failure with openssl 3.x. 
 
Link:https://gitee.com/openeuler/kernel/pulls/1027 

Reviewed-by: Zhu Jianwei <zhujianwei7@huawei.com> 
Signed-off-by: Zhu Jianwei <zhujianwei7@huawei.com>

a59ed522

!1007 perf: hns3: add event suppport for ROH and default use hardware event 0 as group leader event · 63c8f4b4

由 openeuler-ci-bot 提交于 6月 08, 2023

Merge Pull Request from: @svishen 
 
This pull request add ROH event and default use hardware event 0 as group leader event

(1)perf: hns3: add event suppport for ROH
(2)perf: hns3: default use hardware event 0 as group leader event

issue:
https://gitee.com/openeuler/kernel/issues/I7BY7T 
 
Link:https://gitee.com/openeuler/kernel/pulls/1007 

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

63c8f4b4

!1032 bugfix the lost interruption problem after live migration · b10f5eaa

由 openeuler-ci-bot 提交于 6月 08, 2023

Merge Pull Request from: @xiao_jiang_shui 
 
The problem of service interruption and loss may be triggered during
live migration. In order to ensure normal business, it is necessary to
resend an interrupt in the live migration driver.

And in the QM service driver, it is guaranteed that the retransmission
interrupt can be received normally.

issue: https://gitee.com/openeuler/kernel/issues/I7BTMW 
 
Link:https://gitee.com/openeuler/kernel/pulls/1032 

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

b10f5eaa

!1019 drivers/perf: hisi: Don't migrate perf to the CPU going to teardown · eab20e19

由 openeuler-ci-bot 提交于 6月 08, 2023

Merge Pull Request from: @hejunhao3 
 
The driver needs to migrate the perf context if the current using CPU going
to teardown. By the time calling the cpuhp::teardown() callback the
cpu_online_mask() hasn't updated yet and still includes the CPU going to
teardown. In current driver's implementation we may migrate the context
to the teardown CPU and leads to the below calltrace:

...
[ 368.104662][ T932] task:cpuhp/0 state:D stack: 0 pid: 15 ppid: 2 flags:0x00000008
[ 368.113699][ T932] Call trace:
[ 368.116834][ T932] __switch_to+0x7c/0xbc
[ 368.120924][ T932] __schedule+0x338/0x6f0
[ 368.125098][ T932] schedule+0x50/0xe0
[ 368.128926][ T932] schedule_preempt_disabled+0x18/0x24
[ 368.134229][ T932] __mutex_lock.constprop.0+0x1d4/0x5dc
[ 368.139617][ T932] __mutex_lock_slowpath+0x1c/0x30
[ 368.144573][ T932] mutex_lock+0x50/0x60
[ 368.148579][ T932] perf_pmu_migrate_context+0x84/0x2b0
[ 368.153884][ T932] hisi_pcie_pmu_offline_cpu+0x90/0xe0 [hisi_pcie_pmu]
[ 368.160579][ T932] cpuhp_invoke_callback+0x2a0/0x650
[ 368.165707][ T932] cpuhp_thread_fun+0xe4/0x190
[ 368.170316][ T932] smpboot_thread_fn+0x15c/0x1a0
[ 368.175099][ T932] kthread+0x108/0x13c
[ 368.179012][ T932] ret_from_fork+0x10/0x18
...

Use function cpumask_any_but() to find one correct active cpu to fixes
this issue. 
 
Link:https://gitee.com/openeuler/kernel/pulls/1019 

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

eab20e19

vfio/migration: bugfix lost interruption after live migration · a60b29d3

由 Longfang Liu 提交于 6月 08, 2023

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

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

During repeated live migration. There may be a problem with missing
interrupts. In this case, re-send the doorbell on the migration end.
Let QM report an interrupt again, and migrate the interrupt to the
destination together.
Thereby preventing the problem of interrupt loss.

fixec: a0464f0b ("vfio/hisilicon: add acc live migration driver")
Signed-off-by: NLongfang Liu <liulongfang@huawei.com>
Signed-off-by: NJiangShui Yang <yangjiangshui@h-partners.com>

a60b29d3

crypto: hisilicon/qm - fix EQ/AEQ interrupt issue · 24a30ee7

由 Longfang Liu 提交于 6月 08, 2023

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

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

During a live migration operation. In order to prevent the problem
of EQ/AEQ interrupt loss. Migration driver will trigger an EQ/AEQ
doorbell at the end of the migration.
This operation may cause a double interrupt of EQ/AEQ. In order
to ensure that the interrupt processing is normal. The interrupt
handling of EQ/AEQ needs to be updated to prevent interrupt
duplication.

fixec: a0464f0b ("vfio/hisilicon: add acc live migration driver")
Signed-off-by: NLongfang Liu <liulongfang@huawei.com>
Signed-off-by: NJiangShui Yang <yangjiangshui@h-partners.com>

24a30ee7

fs: hfsplus: fix UAF issue in hfsplus_put_super · 028ba66e

由 Dongliang Mu 提交于 6月 08, 2023

stable inclusion
from stable-v5.10.167
commit ef7d71d7bd57b8b7fe514e459927696c1c6d1047
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I79LIO
CVE: CVE-2023-2985

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=ef7d71d7bd57b8b7fe514e459927696c1c6d1047

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

commit 07db5e24 upstream.

The current hfsplus_put_super first calls hfs_btree_close on
sbi->ext_tree, then invokes iput on sbi->hidden_dir, resulting in an
use-after-free issue in hfsplus_release_folio.

As shown in hfsplus_fill_super, the error handling code also calls iput
before hfs_btree_close.

To fix this error, we move all iput calls before hfsplus_btree_close.

Note that this patch is tested on Syzbot.

Link: https://lkml.kernel.org/r/20230226124948.3175736-1-mudongliangabcd@gmail.com
Reported-by: syzbot+57e3e98f7e3b80f64d56@syzkaller.appspotmail.com
Tested-by: NDongliang Mu <mudongliangabcd@gmail.com>
Signed-off-by: NDongliang Mu <mudongliangabcd@gmail.com>
Cc: Bart Van Assche <bvanassche@acm.org>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLong Li <leo.lilong@huawei.com>
Reviewed-by: NYang Erkun <yangerkun@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>

028ba66e

!978 io_uring: fix the problem of running · f54cc993

由 openeuler-ci-bot 提交于 6月 08, 2023

Merge Pull Request from: @ci-robot 
 
PR sync from:  Li Lingfeng <lilingfeng3@huawei.com>
 https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/DP5GHDF7ULWL52W5DGYZWS6HBE5WJ52E/ 
patch1: arch: setup PF_IO_WORKER threads like PF_KTHREAD
  pre patch of patch4
patch2: arch: ensure parisc/powerpc handle PF_IO_WORKER in copy_thread()
  fix patch of patch1
patch3: kernel: don't call do_exit() for PF_IO_WORKER threads
  fix the segfault
patch4: x86/process: setup io_threads more like normal user space
threads
  allow io worker to exit

Jens Axboe (3):
  arch: setup PF_IO_WORKER threads like PF_KTHREAD
  arch: ensure parisc/powerpc handle PF_IO_WORKER in copy_thread()
  kernel: don't call do_exit() for PF_IO_WORKER threads

Stefan Metzmacher (1):
  x86/process: setup io_threads more like normal user space threads


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

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

f54cc993

spi: dw: Add support for 32-bits max xfer size · b80ba107

由 Damien Le Moal 提交于 12月 06, 2020

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

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

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

The Synopsis DesignWare DW_apb_ssi specifications version 3.23 onward
define a 32-bits maximum transfer size synthesis parameter
(SSI_MAX_XFER_SIZE=32) in addition to the legacy 16-bits configuration
(SSI_MAX_XFER_SIZE=16) for SPI controllers. When SSI_MAX_XFER_SIZE=32,
the layout of the ctrlr0 register changes, moving the data frame format
field from bits [3..0] to bits [16..20], and the RX/TX FIFO word size
can be up to 32-bits.

To support this new format, introduce the DW SPI capability flag
DW_SPI_CAP_DFS32 to indicate that a controller is configured with
SSI_MAX_XFER_SIZE=32. Since SSI_MAX_XFER_SIZE is a controller synthesis
parameter not accessible through a register, the detection of this
parameter value is done in spi_hw_init() by writing and reading the
ctrlr0 register and testing the value of bits [3..0]. These bits are
ignored (unchanged) for SSI_MAX_XFER_SIZE=16, allowing the detection.
If a DFS32 capable SPI controller is detected, the new field dfs_offset
in struct dw_spi is set to SPI_DFS32_OFFSET (16).

dw_spi_update_config() is modified to set the data frame size field at
the correct position is the CTRLR0 register, as indicated by the
dfs_offset field of the dw_spi structure.

The DW_SPI_CAP_DFS32 flag is also unconditionally set for SPI slave
controllers, e.g. controllers that have the DW_SPI_CAP_DWC_SSI
capability flag set. However, for these ssi controllers, the dfs_offset
field is set to 0 as before (as per specifications).

Finally, for any controller with the DW_SPI_CAP_DFS32 capability flag
set, dw_spi_add_host() extends the value of bits_per_word_mask from
16-bits to 32-bits. dw_reader() and dw_writer() are also modified to
handle 32-bits iTX/RX FIFO words.
Suggested-by: NSean Anderson <seanga2@gmail.com>
Signed-off-by: NDamien Le Moal <damien.lemoal@wdc.com>
Acked-by: NSerge Semin <fancer.lancer@gmail.com>
Link: https://lore.kernel.org/r/20201206011817.11700-3-damien.lemoal@wdc.comSigned-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: Nhuangfangrun <huangfangrun1@h-partners.com>

b80ba107

!1003 roh: Fix ROH multi-BD cmdq issue · dd7d9ef1

由 openeuler-ci-bot 提交于 6月 08, 2023

Merge Pull Request from: @chenke1978 
 
When the ROH CMDQ processes multiple BDs, the operations are inconsistent
with those in the UM manual. As a result, the CMDQ parses unexpected return
values, interrupts the CMDQ processing process, and the ROH MIB statistics
query may fail.

This patch fix the process method of roh cmdq multiple BDs. 
 
Link:https://gitee.com/openeuler/kernel/pulls/1003 

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

dd7d9ef1

drivers/perf: hisi: Don't migrate perf to the CPU going to teardown · 37b891ca

由 Junhao He 提交于 6月 08, 2023

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

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

The driver needs to migrate the perf context if the current using CPU going
to teardown. By the time calling the cpuhp::teardown() callback the
cpu_online_mask() hasn't updated yet and still includes the CPU going to
teardown. In current driver's implementation we may migrate the context
to the teardown CPU and leads to the below calltrace:

...
[  368.104662][  T932] task:cpuhp/0         state:D stack:    0 pid:   15 ppid:     2 flags:0x00000008
[  368.113699][  T932] Call trace:
[  368.116834][  T932]  __switch_to+0x7c/0xbc
[  368.120924][  T932]  __schedule+0x338/0x6f0
[  368.125098][  T932]  schedule+0x50/0xe0
[  368.128926][  T932]  schedule_preempt_disabled+0x18/0x24
[  368.134229][  T932]  __mutex_lock.constprop.0+0x1d4/0x5dc
[  368.139617][  T932]  __mutex_lock_slowpath+0x1c/0x30
[  368.144573][  T932]  mutex_lock+0x50/0x60
[  368.148579][  T932]  perf_pmu_migrate_context+0x84/0x2b0
[  368.153884][  T932]  hisi_pcie_pmu_offline_cpu+0x90/0xe0 [hisi_pcie_pmu]
[  368.160579][  T932]  cpuhp_invoke_callback+0x2a0/0x650
[  368.165707][  T932]  cpuhp_thread_fun+0xe4/0x190
[  368.170316][  T932]  smpboot_thread_fn+0x15c/0x1a0
[  368.175099][  T932]  kthread+0x108/0x13c
[  368.179012][  T932]  ret_from_fork+0x10/0x18
...

Use function cpumask_any_but() to find one correct active cpu to fixes
this issue.

Fixes: 8404b0fb ("drivers/perf: hisi: Add driver for HiSilicon PCIe PMU")
Signed-off-by: NJunhao He <hejunhao3@huawei.com>

37b891ca

!944 nbd: get config_lock before sock_shutdown · 97f71cc8

由 openeuler-ci-bot 提交于 6月 08, 2023

Merge Pull Request from: @ci-robot 
 
PR sync from:  Zhong Jinghua <zhongjinghua@huawei.com>
 https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/SH7IMWAMZDZBA352XEQZ4WD6CFY3EGCW/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/944 

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

97f71cc8

openeuler / Kernel 大约 1 年 前同步成功

openeuler / Kernel
大约 1 年前同步成功