提交 · 9cd6f55e9c3313ecd74ee5f5412f19ee0a166e94 · openeuler / Kernel

16 6月, 2023 4 次提交

mm: oom: move memcg_print_bad_task() out of mem_cgroup_scan_tasks() · 9cd6f55e

由 Kang Chen 提交于 4月 16, 2023

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

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

raw call flow:

oom_kill_process
  -> mem_cgroup_scan_tasks(.., .., message)
    -> memcg_print_bad_task(message, ..)

message is "const char*" type, and incorrectly cast to
"oom_control*" type in memcg_print_bad_task.

Fix it by moving memcg_print_bad_task out of mem_cgroup_scan_tasks
and call it in select_bad_process and dump_tasks. Furthermore,
use struct oom_control* directly and remove the useless parm `ret`.
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NKang Chen <void0red@hust.edu.cn>
(cherry picked from commit 789038c7)

9cd6f55e

!1150 EDAC/i10nm: Add Intel Emerald Rapids server support · 2c572019

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

Merge Pull Request from: @youquan_song 
 
EDAC/i10nm: Add Intel Emerald Rapids server support

The Emerald Rapids CPU model uses similar memory controller registers
as Sapphire Rapids server. Add Emerald Rapids CPU model number ID for
EDAC support.

bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I7DZRN

[Testing]
dmesg - check i10nm_edac load 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1150 

Reviewed-by: Jun Tian <jun.j.tian@intel.com> 
Reviewed-by: Jason Zeng <jason.zeng@intel.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>

2c572019

EDAC/i10nm: Add Intel Emerald Rapids server support · 6b1c0854

由 Qiuxu Zhuo 提交于 1月 13, 2023

mainline inclusion
from mainline-v6.3-rc1
commit e4b2bc66
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I7DZRN
CVE: NA

Intel-SIG: commit e4b2bc66 EDAC/i10nm: Add Intel Emerald Rapids server support.
Backport to decode memory error for Intel Emerald Rapids server.

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

The Emerald Rapids CPU model uses similar memory controller registers
as Sapphire Rapids server. Add Emerald Rapids CPU model number ID for
EDAC support.
Tested-by: NLi Zhang <li4.zhang@intel.com>
Signed-off-by: NQiuxu Zhuo <qiuxu.zhuo@intel.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
Link: https://lore.kernel.org/all/20230113032802.41752-1-qiuxu.zhuo@intel.com
[ Youquan Song: amend commit log ]
Signed-off-by: NYouquan Song <youquan.song@intel.com>

6b1c0854

!1136 gfs2: Don't deref jdesc in evict · 195117a2

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

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

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

195117a2

15 6月, 2023 2 次提交

!948 Dependency of Kmesh on Kernel Modification · 02df2e99

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

Merge Pull Request from: @bitcoffee

In the kernel, Kmesh forwards customer requests to actual backend service nodes through Layer 7 orchestration. This capability is per flow. When sending msg for the first time, Kmesh parses user Layer 7 packets and completes orchestration to complete link establishment. This requires that the pseudo link be established in the connect phase and the actual link be established in the sendmsg phase.
Therefore, the following modifications are involved:
1. The ULP framework needs to be supported in the connect phase. The l4 connect function needs to be replaced with the user-defined connect function.
2. After the L4 connect function is invoked, the L3 function can invoke the actual link establishment logic based on the error code and modify the return value of inet_stream_connect at the L3 layer.
3. In the sendmsg message, you can determine whether the delay in link setup is enabled based on the sock status.

Submission Instructions:
1. Add a writeable_tracepoint to modify the return value of __inet_stream_connect in inet_stream_connect.
2. The bpf_defer_connect flag is added to indicate whether the ebpf defer connect delay link establishment logic is enabled.
3. The ULP framework is added to support the ebpf program. The ULP framework can be used in the ebpf program.
4. A call type in sockops is added. This type is used to invoke the ebpf program in the kernel module and identify it when Kmesh delays link establishment.

Link:https://gitee.com/openeuler/kernel/pulls/948

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

02df2e99

!1131 [sync] PR-1081: some backport bugfix for sockmap · 6dc08b44

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

Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1081 
 
PR sync from:  Liu Jian <liujian56@huawei.com>
 https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/24ZK7TI2Q55BY7U53AB2LYQUFTABZR4L/ 
some backport bugfix for sockmap

Cong Wang (1):
  bpf, sock_map: Move cancel_work_sync() out of sock lock

Eric Dumazet (1):
  net: deal with most data-races in sk_wait_event()

Jakub Sitnicki (2):
  bpf, sockmap: Check for any of tcp_bpf_prots when cloning a listener
  bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itself

Pengcheng Yang (3):
  bpf, sockmap: Fix repeated calls to sock_put() when msg has more_data
  bpf, sockmap: Fix missing BPF_F_INGRESS flag when using apply_bytes
  bpf, sockmap: Fix data loss caused by using apply_bytes on ingress
    redirect

Wang Yufen (1):
  bpf, sockmap: Fix the sk->sk_forward_alloc warning of
    sk_stream_kill_queues

zhangmingyi (1):
  bpf: fix bpf_tcp_ingress addr use after free


-- 
2.34.1
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1131 

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

6dc08b44

14 6月, 2023 15 次提交

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

bpf: fix bpf_tcp_ingress addr use after free · 04f26fce

由 zhangmingyi 提交于 6月 11, 2023

euleros inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I545NW
CVE: NA

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

fix a bug in bpf_tcp_ingress(), addr use after free
Signed-off-by: Nzhangmingyi <zhangmingyi5@huawei.com>
Reviewed-by: Nliuxin <liuxin350@huawei.com>
Reviewed-by: Nwuchangye <wuchangye@huawei.com>
Fixes: 8818e269 ("bpf, sockmap: Add sk_rmem_alloc check for sockmap")
Signed-off-by: NLiu Jian <liujian56@huawei.com>
(cherry picked from commit 46613645)

04f26fce

net: deal with most data-races in sk_wait_event() · ac310827

由 Eric Dumazet 提交于 6月 11, 2023

stable inclusion
from stable-v5.10.181
commit 4493914009609d6351b3a41dfe3b0ac5209bd4c6
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I65HYE
CVE: NA

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

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

[ Upstream commit d0ac89f6 ]

__condition is evaluated twice in sk_wait_event() macro.

First invocation is lockless, and reads can race with writes,
as spotted by syzbot.

BUG: KCSAN: data-race in sk_stream_wait_connect / tcp_disconnect

write to 0xffff88812d83d6a0 of 4 bytes by task 9065 on cpu 1:
tcp_disconnect+0x2cd/0xdb0
inet_shutdown+0x19e/0x1f0 net/ipv4/af_inet.c:911
__sys_shutdown_sock net/socket.c:2343 [inline]
__sys_shutdown net/socket.c:2355 [inline]
__do_sys_shutdown net/socket.c:2363 [inline]
__se_sys_shutdown+0xf8/0x140 net/socket.c:2361
__x64_sys_shutdown+0x31/0x40 net/socket.c:2361
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd

read to 0xffff88812d83d6a0 of 4 bytes by task 9040 on cpu 0:
sk_stream_wait_connect+0x1de/0x3a0 net/core/stream.c:75
tcp_sendmsg_locked+0x2e4/0x2120 net/ipv4/tcp.c:1266
tcp_sendmsg+0x30/0x50 net/ipv4/tcp.c:1484
inet6_sendmsg+0x63/0x80 net/ipv6/af_inet6.c:651
sock_sendmsg_nosec net/socket.c:724 [inline]
sock_sendmsg net/socket.c:747 [inline]
__sys_sendto+0x246/0x300 net/socket.c:2142
__do_sys_sendto net/socket.c:2154 [inline]
__se_sys_sendto net/socket.c:2150 [inline]
__x64_sys_sendto+0x78/0x90 net/socket.c:2150
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd

value changed: 0x00000000 -> 0x00000068

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Reported-by: Nsyzbot <syzkaller@googlegroups.com>
Signed-off-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLiu Jian <liujian56@huawei.com>
(cherry picked from commit 7695e960)

ac310827

bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itself · e893b4ee

由 Jakub Sitnicki 提交于 6月 11, 2023

mainline inclusion
from mainline-v6.2-rc7
commit 5b4a79ba
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I65HYE
CVE: NA

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

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

sock_map proto callbacks should never call themselves by design. Protect
against bugs like [1] and break out of the recursive loop to avoid a stack
overflow in favor of a resource leak.

[1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/Suggested-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NJakub Sitnicki <jakub@cloudflare.com>
Acked-by: NJohn Fastabend <john.fastabend@gmail.com>
Link: https://lore.kernel.org/r/20230113-sockmap-fix-v2-1-1e0ee7ac2f90@cloudflare.comSigned-off-by: NAlexei Starovoitov <ast@kernel.org>
Signed-off-by: NLiu Jian <liujian56@huawei.com>
(cherry picked from commit 5a74e1a8)

e893b4ee

bpf, sockmap: Check for any of tcp_bpf_prots when cloning a listener · eb96b4bb

由 Jakub Sitnicki 提交于 6月 11, 2023

stable inclusion
from stable-v5.10.168
commit 9bd6074e1872d22190a8da30e796cbf937d334f0
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6IXN2
CVE: NA

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

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

[ Upstream commit ddce1e09 ]

A listening socket linked to a sockmap has its sk_prot overridden. It
points to one of the struct proto variants in tcp_bpf_prots. The variant
depends on the socket's family and which sockmap programs are attached.

A child socket cloned from a TCP listener initially inherits their sk_prot.
But before cloning is finished, we restore the child's proto to the
listener's original non-tcp_bpf_prots one. This happens in
tcp_create_openreq_child -> tcp_bpf_clone.

Today, in tcp_bpf_clone we detect if the child's proto should be restored
by checking only for the TCP_BPF_BASE proto variant. This is not
correct. The sk_prot of listening socket linked to a sockmap can point to
to any variant in tcp_bpf_prots.

If the listeners sk_prot happens to be not the TCP_BPF_BASE variant, then
the child socket unintentionally is left if the inherited sk_prot by
tcp_bpf_clone.

This leads to issues like infinite recursion on close [1], because the
child state is otherwise not set up for use with tcp_bpf_prot operations.

Adjust the check in tcp_bpf_clone to detect all of tcp_bpf_prots variants.

Note that it wouldn't be sufficient to check the socket state when
overriding the sk_prot in tcp_bpf_update_proto in order to always use the
TCP_BPF_BASE variant for listening sockets. Since commit
b8b8315e ("bpf, sockmap: Remove unhash handler for BPF sockmap usage")
it is possible for a socket to transition to TCP_LISTEN state while already
linked to a sockmap, e.g. connect() -> insert into map ->
connect(AF_UNSPEC) -> listen().

[1]: https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/

Fixes: e8025155 ("tcp_bpf: Don't let child socket inherit parent protocol ops on copy")
Reported-by: syzbot+04c21ed96d861dccc5cd@syzkaller.appspotmail.com
Signed-off-by: NJakub Sitnicki <jakub@cloudflare.com>
Acked-by: NJohn Fastabend <john.fastabend@gmail.com>
Link: https://lore.kernel.org/r/20230113-sockmap-fix-v2-2-1e0ee7ac2f90@cloudflare.comSigned-off-by: NAlexei Starovoitov <ast@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NWang Hai <wanghai38@huawei.com>
Signed-off-by: NLiu Jian <liujian56@huawei.com>
(cherry picked from commit 839eee17)

eb96b4bb

bpf, sockmap: Fix data loss caused by using apply_bytes on ingress redirect · 065c0512

由 Pengcheng Yang 提交于 6月 11, 2023

stable inclusion
from stable-v5.10.163
commit c58df40e3e67fd7603290b5dd24c47cdc1f9ef74
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6AVM6
CVE: NA

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

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

[ Upstream commit 9072931f ]

Use apply_bytes on ingress redirect, when apply_bytes is less than
the length of msg data, some data may be skipped and lost in
bpf_tcp_ingress().

If there is still data in the scatterlist that has not been consumed,
we cannot move the msg iter.

Fixes: 604326b4 ("bpf, sockmap: convert to generic sk_msg interface")
Signed-off-by: NPengcheng Yang <yangpc@wangsu.com>
Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
Acked-by: NJakub Sitnicki <jakub@cloudflare.com>
Link: https://lore.kernel.org/bpf/1669718441-2654-4-git-send-email-yangpc@wangsu.comSigned-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NWang Hai <wanghai38@huawei.com>
Signed-off-by: NLiu Jian <liujian56@huawei.com>
(cherry picked from commit 5a4552f3)

065c0512

bpf, sockmap: Fix missing BPF_F_INGRESS flag when using apply_bytes · 3243954e

由 Pengcheng Yang 提交于 6月 11, 2023

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

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

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

When redirecting, we use sk_msg_to_ingress() to get the BPF_F_INGRESS
flag from the msg->flags. If apply_bytes is used and it is larger than
the current data being processed, sk_psock_msg_verdict() will not be
called when sendmsg() is called again. At this time, the msg->flags is 0,
and we lost the BPF_F_INGRESS flag.

So we need to save the BPF_F_INGRESS flag in sk_psock and use it when
redirection.

Fixes: 8934ce2f ("bpf: sockmap redirect ingress support")
Signed-off-by: NPengcheng Yang <yangpc@wangsu.com>
Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
Acked-by: NJakub Sitnicki <jakub@cloudflare.com>
Link: https://lore.kernel.org/bpf/1669718441-2654-3-git-send-email-yangpc@wangsu.comSigned-off-by: NLiu Jian <liujian56@huawei.com>

Conflicts:
	include/net/tcp.h
(cherry picked from commit b67daf1b)

3243954e

bpf, sockmap: Fix repeated calls to sock_put() when msg has more_data · 745e161e

由 Pengcheng Yang 提交于 6月 11, 2023

stable inclusion
from stable-v5.10.163
commit 28e4a763cd4a2b1a78852216ef4bd7df3a05cec6
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6AVM6
CVE: NA

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

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

[ Upstream commit 7a9841ca ]

In tcp_bpf_send_verdict() redirection, the eval variable is assigned to
__SK_REDIRECT after the apply_bytes data is sent, if msg has more_data,
sock_put() will be called multiple times.

We should reset the eval variable to __SK_NONE every time more_data
starts.

This causes:

IPv4: Attempt to release TCP socket in state 1 00000000b4c925d7
------------[ cut here ]------------
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 5 PID: 4482 at lib/refcount.c:25 refcount_warn_saturate+0x7d/0x110
Modules linked in:
CPU: 5 PID: 4482 Comm: sockhash_bypass Kdump: loaded Not tainted 6.0.0 #1
Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014
Call Trace:
 <TASK>
 __tcp_transmit_skb+0xa1b/0xb90
 ? __alloc_skb+0x8c/0x1a0
 ? __kmalloc_node_track_caller+0x184/0x320
 tcp_write_xmit+0x22a/0x1110
 __tcp_push_pending_frames+0x32/0xf0
 do_tcp_sendpages+0x62d/0x640
 tcp_bpf_push+0xae/0x2c0
 tcp_bpf_sendmsg_redir+0x260/0x410
 ? preempt_count_add+0x70/0xa0
 tcp_bpf_send_verdict+0x386/0x4b0
 tcp_bpf_sendmsg+0x21b/0x3b0
 sock_sendmsg+0x58/0x70
 __sys_sendto+0xfa/0x170
 ? xfd_validate_state+0x1d/0x80
 ? switch_fpu_return+0x59/0xe0
 __x64_sys_sendto+0x24/0x30
 do_syscall_64+0x37/0x90
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Fixes: cd9733f5 ("tcp_bpf: Fix one concurrency problem in the tcp_bpf_send_verdict function")
Signed-off-by: NPengcheng Yang <yangpc@wangsu.com>
Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
Acked-by: NJakub Sitnicki <jakub@cloudflare.com>
Link: https://lore.kernel.org/bpf/1669718441-2654-2-git-send-email-yangpc@wangsu.comSigned-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NWang Hai <wanghai38@huawei.com>
Signed-off-by: NLiu Jian <liujian56@huawei.com>
(cherry picked from commit 48c7aa19)

745e161e

bpf, sock_map: Move cancel_work_sync() out of sock lock · 6b698186

由 Cong Wang 提交于 6月 11, 2023

mainline inclusion
from mainline-v6.1-rc5
commit 8bbabb3f
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I65HYE
CVE: NA

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

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

Stanislav reported a lockdep warning, which is caused by the
cancel_work_sync() called inside sock_map_close(), as analyzed
below by Jakub:

psock->work.func = sk_psock_backlog()
  ACQUIRE psock->work_mutex
    sk_psock_handle_skb()
      skb_send_sock()
        __skb_send_sock()
          sendpage_unlocked()
            kernel_sendpage()
              sock->ops->sendpage = inet_sendpage()
                sk->sk_prot->sendpage = tcp_sendpage()
                  ACQUIRE sk->sk_lock
                    tcp_sendpage_locked()
                  RELEASE sk->sk_lock
  RELEASE psock->work_mutex

sock_map_close()
  ACQUIRE sk->sk_lock
  sk_psock_stop()
    sk_psock_clear_state(psock, SK_PSOCK_TX_ENABLED)
    cancel_work_sync()
      __cancel_work_timer()
        __flush_work()
          // wait for psock->work to finish
  RELEASE sk->sk_lock

We can move the cancel_work_sync() out of the sock lock protection,
but still before saved_close() was called.

Fixes: 799aa7f9 ("skmsg: Avoid lock_sock() in sk_psock_backlog()")
Reported-by: NStanislav Fomichev <sdf@google.com>
Signed-off-by: NCong Wang <cong.wang@bytedance.com>
Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
Tested-by: NJakub Sitnicki <jakub@cloudflare.com>
Acked-by: NJohn Fastabend <john.fastabend@gmail.com>
Acked-by: NJakub Sitnicki <jakub@cloudflare.com>
Link: https://lore.kernel.org/bpf/20221102043417.279409-1-xiyou.wangcong@gmail.com
(cherry picked from commit 8bbabb3f)
Signed-off-by: NLiu Jian <liujian56@huawei.com>

Conflicts:
	net/core/skmsg.c
(cherry picked from commit a4aa9897)

6b698186

bpf, sockmap: Fix the sk->sk_forward_alloc warning of sk_stream_kill_queues · 970f8b82

由 Wang Yufen 提交于 6月 11, 2023

stable inclusion
from stable-v5.10.155
commit cc21dc48a78cc9e5af9a4d039cd456446a6e73ff
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCD
CVE: NA

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

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

[ Upstream commit 8ec95b94 ]

When running `test_sockmap` selftests, the following warning appears:

  WARNING: CPU: 2 PID: 197 at net/core/stream.c:205 sk_stream_kill_queues+0xd3/0xf0
  Call Trace:
  <TASK>
  inet_csk_destroy_sock+0x55/0x110
  tcp_rcv_state_process+0xd28/0x1380
  ? tcp_v4_do_rcv+0x77/0x2c0
  tcp_v4_do_rcv+0x77/0x2c0
  __release_sock+0x106/0x130
  __tcp_close+0x1a7/0x4e0
  tcp_close+0x20/0x70
  inet_release+0x3c/0x80
  __sock_release+0x3a/0xb0
  sock_close+0x14/0x20
  __fput+0xa3/0x260
  task_work_run+0x59/0xb0
  exit_to_user_mode_prepare+0x1b3/0x1c0
  syscall_exit_to_user_mode+0x19/0x50
  do_syscall_64+0x48/0x90
  entry_SYSCALL_64_after_hwframe+0x44/0xae

The root case is in commit 84472b43 ("bpf, sockmap: Fix more uncharged
while msg has more_data"), where I used msg->sg.size to replace the tosend,
causing breakage:

  if (msg->apply_bytes && msg->apply_bytes < tosend)
    tosend = psock->apply_bytes;

Fixes: 84472b43 ("bpf, sockmap: Fix more uncharged while msg has more_data")
Reported-by: NJakub Sitnicki <jakub@cloudflare.com>
Signed-off-by: NWang Yufen <wangyufen@huawei.com>
Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
Acked-by: NJohn Fastabend <john.fastabend@gmail.com>
Acked-by: NJakub Sitnicki <jakub@cloudflare.com>
Link: https://lore.kernel.org/bpf/1667266296-8794-1-git-send-email-wangyufen@huawei.comSigned-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com>
Signed-off-by: NLiu Jian <liujian56@huawei.com>
(cherry picked from commit 86404036)

970f8b82

!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 13 次提交

!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

bpf: Introduces a new state to identify the location of · dacbc5a9

由 bitcoffee 提交于 6月 13, 2023

 the sockops call

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I71USM

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

Currently, a permission status code is required to identify
that the access to the sockops is from the delayed link establishment
scenario. Therefore, "BPF_SOCK_OPS_TCP_DEFFER_CONNECT_CB"
Signed-off-by: Nbitcoffee <liuxin350@huawei.com>

dacbc5a9

ipv4, bpf: Introduced to support the ULP to modify · d5bbce33

由 bitcoffee 提交于 6月 13, 2023

 sockets during setopt

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I71USM

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

Currently, the ebpf program can distinguish sockets according to
the address accessed by the client, and use the ULP framework to
modify the matched sockets to delay link establishment.
Signed-off-by: Nbitcoffee <liuxin350@huawei.com>

d5bbce33

net, bpf: Introduces a new ebpf delay connect flag · 48b25f1c

由 bitcoffee 提交于 6月 13, 2023

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I71USM

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

The bpf_defer_connect bit is added for inet_sock to indicate
whether the current socket is changed to the bpf program to
delay link establishment.
Signed-off-by: Nbitcoffee <liuxin350@huawei.com>

48b25f1c

net, bpf: Add a writeable_tracepoint to inet_stream_connect · aca06275

由 bitcoffee 提交于 6月 13, 2023

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I71USM

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

A trace point is added to the connection process. Theebpf program
can be mounted to modify the return value of the function. This is
mandatory for delaying the establishment of an ebpf link. After
the connection is complete, a message is returned immediately and
no unnecessary operation is performed.
Signed-off-by: Nbitcoffee <liuxin350@huawei.com>

aca06275

!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 1 次提交

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

openeuler / Kernel 10 个月 前同步成功

openeuler / Kernel
10 个月前同步成功