提交 · e893b4ee534db6c3f61434e87510d91ed8b6c0fc · openeuler / Kernel

14 6月, 2023 9 次提交

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 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 2 次提交

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

!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

!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

!920 dm thin: Fix ABBA deadlock by resetting dm_bufio_client · 72b4b819

由 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/XNE65PIJUOQRSLID56LFRUSB3FNDYMGE/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/920 

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

72b4b819

!924 dm: add disk before alloc dax · 4aaed9a4

由 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/KP2DRRZQIPU5IM7FF4GECWSW5466QLFH/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/924 

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

4aaed9a4

perf: hns3: default use hardware event 0 as group leader event. · eebd097b

由 Hao Chen 提交于 5月 19, 2023

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

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

For hns3 pmu events, we use command as below before:
perf stat -g -e hns3_pmu_sicl_0/config=0x00105,global=1/
-e hns3_pmu_sicl_0/config=0x10105,global=1/ -I 1000

We want 0x00105 event and 0x10105 event share a hardware event, but for
kernel 6.2 'commit 5f8f9567 ("perf evlist: Remove group option.")'
remove -g parameter.

So add this patch to set default related event idx as 0 to share
the first hardware event.

Fixes: 66637ab1 ("drivers/perf: hisi: add driver for HNS3 PMU")
Signed-off-by: NHao Chen <chenhao418@huawei.com>

eebd097b

perf: hns3: add event suppport for ROH · 60ceb206

由 Jian Shen 提交于 1月 04, 2023

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

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

Add ROH events support.

Fixes: 66637ab1 ("drivers/perf: hisi: add driver for HNS3 PMU")
Signed-off-by: NJian Shen <shenjian15@huawei.com>

60ceb206

openeuler / Kernel 11 个月 前同步成功

openeuler / Kernel
11 个月前同步成功