Merge Pull Request from: @ci-robot 
 
PR sync from: Liu Jian <liujian56@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/OU22IIXYWUCYAU6Z4EMLHBK3CNL4JAZK/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1140 

Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I7DNAP
CVE: N/A

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

add sample sockmap code for redis
Signed-off-by: NLiu Jian <liujian56@huawei.com>

Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1115 
 
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/1126 

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

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>
(cherry picked from commit 6935faf1)

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>
(cherry picked from commit 9f98927f)

Merge Pull Request from: @ci-robot 
 
PR sync from:  Liu Jian <liujian56@huawei.com>
 https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/GBQRSP7JMB5AKFHWXXI74KBSVWJZESEQ/ 
add one bpf helper function for redissockmap

Liu Jian (2):
  net: add bpf_is_local_ipaddr bpf helper function
  net: let sockops can use bpf_get_current_comm()


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

Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

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

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

Let sockops can use bpf_get_current_comm().
Signed-off-by: NLiu Jian <liujian56@huawei.com>

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

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

Some network acceleration solutions, such as sockmap, are valid only for
internal packets of the local host. The bpf_is_local_ipaddr() bpf helper
function is added so that the ebpf program can determine whether a packet
is an internal packet of the local host.
Signed-off-by: NLiu Jian <liujian56@huawei.com>

!1105 [sync] PR-1089:  power: supply: bq24190: Fix use after free bug in bq24190_remove due to race condition

Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1089 
 
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/1105 

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

Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1090 
 
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/1110 

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

!1119 [openEuler-22.03-LTS-SP2] net: hns3: refactor hclge_mac_link_status_wait and add wait until mac link down

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/1119 

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

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>

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>

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
(cherry picked from commit 9fc58dcc)

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>
(cherry picked from commit 085b94ff)

Merge Pull Request from: @did-you-collect-the-wool-today 
 
In probe_vendor_drivers, all registered vendor drivers are traversed.
This is not a good idea. If a vendor driver is not implemented well
enough, it may cause the system to panic. Use the vendor id and
device id to select a proper driver.
The acc live migration driver needs to be adapted. 
 
Link:https://gitee.com/openeuler/kernel/pulls/1093 

Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

Merge Pull Request from: @cj-xiaocai 
 
When enabled GICv4.1 in hip09, there are some invalid vPE configurations in
configuration table for some situations, which will cause some vSGI
interrupts lost.
To fix the issue, need to send vinvall command after vmovp.
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1085 

Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

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

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

When enabled GICv4.1 in hip09, there are some invalid vPE configurations in
configuration table for some situations, which will cause some vSGI
interrupts lost.
To fix the issue, need to send vinvall command after vmovp.
Signed-off-by: NNianyao Tang <tangnianyao@huawei.com>
Signed-off-by: NXiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: NCaiJian <caijian11@h-partners.com>

Merge Pull Request from: @zhangjialin11 
 
Only one page is allocated to the collection table.
Recalculate the page number of collection table based on the number of CPUs. 
 
Link:https://gitee.com/openeuler/kernel/pulls/1095 

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

Merge Pull Request from: @ci-robot 
 
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/1081 

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

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

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

Only one page is allocated to the collection table.
Recalculate the page number of collection table based on the number of
CPUs.
Signed-off-by: Nwangwudi <wangwudi@hisilicon.com>

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

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

In probe_vendor_drivers, all registered vendor drivers are traversed.
This is not a good idea. If a vendor driver is not implemented well
enough, it may cause the system to panic. Use the vendor id and
device id to select a proper driver.

The acc live migration driver needs to be adapted.
Signed-off-by: NLongfang Liu <liulongfang@huawei.com>
Signed-off-by: NKunkun Jiang <jiangkunkun@huawei.com>

Merge Pull Request from: @ci-robot 
 
PR sync from:  Wei Li <liwei391@huawei.com>
 https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/J4QNVBAATO5YYR4XQ6PLJNMFVEF6SNPX/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1077 

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

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: 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: Kunkun Jiang <jiangkunkun@huawei.com> 
 
Link:https://gitee.com/openeuler/kernel/pulls/1087 

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

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>

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>

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>

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>

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>

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>

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

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>

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

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>

Merge Pull Request from: @lujunhuaHW 
 
The controller may be shared with other port, for example the firmware.
Handle the interrupt from other sources will cause crash since some
data are not initialized. So only handle the interrupt of the driver's
transfer and discard others. 
 
Link:https://gitee.com/openeuler/kernel/pulls/1063 

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

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

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

When doing "cat /proc/interrupts" after qxl.ko is unloaded, an oops occurs:

BUG: unable to handle page fault for address: ffffffffc0274769
PGD 2a0d067 P4D 2a0d067 PUD 2a0f067 PMD 103f39067 PTE 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 6 PID: 246 Comm: cat Not tainted 6.1.0-rc2 #24
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:string_nocheck+0x34/0x50
Code: 66 85 c0 74 3c 83 e8 01 4c 8d 5c 07 01 31 c0 eb 19 49 39 fa 76 03 44 88 07 48 83 c7
RSP: 0018:ffffc90000893bb8 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffffc90000893c50 RCX: ffff0a00ffffff04
RDX: ffffffffc0274769 RSI: ffff888102812000 RDI: ffff88810281133e
RBP: ffff888102812000 R08: ffffffff823fa5e6 R09: 0000000000000007
R10: ffff888102812000 R11: ffff88820281133d R12: ffffffffc0274769
R13: ffff0a00ffffff04 R14: 0000000000000cc4 R15: ffffffff823276b4
FS:  000000000214f8c0(0000) GS:ffff88842fd80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffc0274769 CR3: 00000001025c4005 CR4: 0000000000770ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 <TASK>
 string+0x46/0x60
 vsnprintf+0x27a/0x4f0
 seq_vprintf+0x34/0x50
 seq_printf+0x53/0x70
 ? seq_read_iter+0x365/0x450
 show_interrupts+0x259/0x330
 seq_read_iter+0x2a3/0x450
 proc_reg_read_iter+0x47/0x70
 generic_file_splice_read+0x94/0x160
 splice_direct_to_actor+0xb0/0x230
 ? do_splice_direct+0xd0/0xd0
 do_splice_direct+0x8b/0xd0
 do_sendfile+0x345/0x4f0
 __x64_sys_sendfile64+0xa1/0xc0
 do_syscall_64+0x38/0x90
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x4bb0ce
Code: c3 0f 1f 00 4c 89 d2 4c 89 c6 e9 bd fd ff ff 0f 1f 44 00 00 31 c0 c3 0f 1f 44 00 00
RSP: 002b:00007ffd99dc3fb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
RAX: ffffffffffffffda RBX: 0000000001000000 RCX: 00000000004bb0ce
RDX: 0000000000000000 RSI: 0000000000000003 RDI: 0000000000000001
RBP: 0000000000000001 R08: 000000000068f240 R09: 0000000001000000
R10: 0000000001000000 R11: 0000000000000246 R12: 0000000000000003
R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
 </TASK>

It seems that qxl doesn't free the interrupt it requests during unload,
fix this by adding the missing free_irq().

Fixes: f64122c1 ("drm: add new QXL driver. (v1.4)")
Signed-off-by: NWei Li <liwei391@huawei.com>

Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1028 
 
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/1059 

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

Merge Pull Request from: @ci-robot 
 
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/1042 

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

Merge Pull Request from: @ci-robot 
 
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/1069 

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

Merge Pull Request from: @xiao_jiang_shui 
 
Fix some reset problem for accelerator drivers.

Weili Qian (5):
crypto: hisilicon/qm - flush all work before driver removed.
crypto: hisilicon/hpre - enable sva error interrupt event
crypto: hisilicon/qm - remove duplicate assignment and release
crypto: hisilicon/qm - disable same error report before resetting
crypto: hisilicon/qm - disable error report before flr 
 
Link:https://gitee.com/openeuler/kernel/pulls/1070 

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