提交 · 204ebcf9c82e88e672ae57255460724a5ab9d869 · openeuler / Kernel

07 4月, 2022 6 次提交

net: hns3: refine the process when PF set VF VLAN · 204ebcf9

由 Jian Shen 提交于 4月 07, 2022

mainline inclusion
from mainline-net-5.17
commit 190cd8a7
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4YXIM
CVE: NA

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

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

Currently, when PF set VF VLAN, it sends notify mailbox to VF
if VF alive. VF stop its traffic, and send request mailbox
to PF, then PF updates VF VLAN. It's a bit complex. If VF is
killed before sending request, PF will not set VF VLAN without
any log.

This patch refines the process, PF can set VF VLAN direclty,
and then notify the VF. If VF is resetting at that time, the
notify may be dropped, so VF should query it after reset finished.

Fixes: 92f11ea1 ("net: hns3: fix set port based VLAN issue for VF")
Signed-off-by: NJian Shen <shenjian15@huawei.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

204ebcf9

net: hns3: add vlan list lock to protect vlan list · fb52925e

由 Jian Shen 提交于 4月 07, 2022

mainline inclusion
from mainline-net-5.17
commit 1932a624
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4YXIM
CVE: NA

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

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

When adding port base VLAN, vf VLAN need to remove from HW and modify
the vlan state in vf VLAN list as false. If the periodicity task is
freeing the same node, it may cause "use after free" error.
This patch adds a vlan list lock to protect the vlan list.

Fixes: c6075b19 ("net: hns3: Record VF vlan tables")
Signed-off-by: NJian Shen <shenjian15@huawei.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

fb52925e

net: hns3: fix port base vlan add fail when concurrent with reset · 7ad76564

由 Jian Shen 提交于 4月 07, 2022

mainline inclusion
from mainline-net-5.17
commit c0f46de3
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4YXIM
CVE: NA

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

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

Currently, Port base vlan is initiated by PF and configured to its VFs,
by using command "ip link set <pf name> vf <vf id> vlan <vlan id>".
When a global reset was triggered, the hardware vlan table and the soft
recorded vlan information will be cleared by PF, and restored them until
VFs were ready. There is a short time window between the table had been
cleared and before table restored. If configured a new port base vlan tag
at this moment, driver will check the soft recorded vlan information,
and find there hasn't the old tag in it, which causing a warning print.

Due to the port base vlan is managed by PF, so the VFs's port base vlan
restoring should be handled by PF when PF was ready.

This patch fixes it.

Fixes: 039ba863 ("net: hns3: optimize the filter table entries handling when resetting")
Signed-off-by: NJian Shen <shenjian15@huawei.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

7ad76564

net: hns3: fix bug when PF set the duplicate MAC address for VFs · ef960788

由 Jian Shen 提交于 4月 07, 2022

mainline inclusion
from mainline-net-5.17
commit ccb18f05
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4YXIM
CVE: NA

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

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

If the MAC address A is configured to vport A and then vport B. The MAC
address of vport A in the hardware becomes invalid. If the address of
vport A is changed to MAC address B, the driver needs to delete the MAC
address A of vport A. Due to the MAC address A of vport A has become
invalid in the hardware entry, so "-ENOENT" is returned. In this case, the
"used_umv_size" value recorded in driver is not updated. As a result, the
MAC entry status of the software is inconsistent with that of the hardware.

Therefore, the driver updates the umv size even if the MAC entry cannot be
found. Ensure that the software and hardware status is consistent.

Fixes: ee4bcd3b ("net: hns3: refactor the MAC address configure")
Signed-off-by: NJian Shen <shenjian15@huawei.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

ef960788

net: hns3: handle empty unknown interrupt for VF · 6c39d623

由 Yufeng Mo 提交于 4月 07, 2022

mainline inclusion
from mainline-net-5.17
commit 2f61353c
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4YXIM
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=2f61353cd2f789a4229b6f5c1c24a40a613357bb

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

Since some interrupt states may be cleared by hardware, the driver
may receive an empty interrupt. Currently, the VF driver directly
disables the vector0 interrupt in this case. As a result, the VF
is unavailable. Therefore, the vector0 interrupt should be enabled
in this case.

Fixes: b90fcc5b ("net: hns3: add reset handling for VF when doing Core/Global/IMP reset")
Signed-off-by: NYufeng Mo <moyufeng@huawei.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

6c39d623

net: hns3: fix race condition in debugfs · db0eec48

由 Yufeng Mo 提交于 4月 07, 2022

mainline inclusion
from mainline-net-5.17
commit 6dde452b
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4YXIM
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=6dde452bceca3f2ed2b33bc46a16ff5682a03a2e

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

When multiple threads concurrently access the debugfs content, data
and pointer exceptions may occur. Therefore, mutex lock protection is
added for debugfs.

Fixes: 5e69ea7e ("net: hns3: refactor the debugfs process")
Signed-off-by: NYufeng Mo <moyufeng@huawei.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

db0eec48

27 3月, 2022 1 次提交

net/spnic: Remove spnic driver. · e39e10f0

由 Yanling Song 提交于 3月 27, 2022

Ramaxel inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4ZR0O
CVE: NA

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

There are some issues of the driver that cannot be fixed now.
The driver is not good enough for the LTS quality requirements
of openEuler，so remove it.
Signed-off-by: NYanling Song <songyl@ramaxel.com>
Reviewed-by: NYang Gan <yanggan@ramaxel.com>
Acked-by: NXie Xiuqi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

e39e10f0

11 3月, 2022 3 次提交

net/hinic: Fix call trace when the rx_buff module parameter is grater than 2 · 04edfc4f

由 Chiqijun 提交于 3月 11, 2022

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

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

When rx_buff is greater than 2, the driver will alloc for more than 1
page of memory for network rx, but the __GFP_COMP gfp flag is not set,
resulting in the following call trace:

CPU: 3 PID: 494041 Comm: ping Kdump: loaded Tainted: G        W  OE     4.19.90-2106.3.0.0095.oe1.x86_64 #1
Hardware name: Huawei Technologies Co., Ltd. RH2288H V3/BC11HGSA0, BIOS 5.15 05/21/2019
RIP: 0010:copy_page_to_iter+0x154/0x310
Code: 31 b8 00 10 00 00 f7 c6 00 80 00 00 74 07 0f b6 49 51 48 d3 e0 48 39 c2 0f 86 ed fe ff ff 48 c7 c7 30
RSP: 0018:ffffbd6907d03bd8 EFLAGS: 00010286
RAX: 0000000000000024 RBX: ffffe0ffee5b3000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff9edbbfcd6858 RDI: ffff9edbbfcd6858
RBP: 0000000000000001 R08: 000000000001574a R09: 0000000000000004
R10: 000000000000004e R11: 0000000000000001 R12: ffffbd6907d03ed0
R13: 0000000000002100 R14: 0000000000000030 R15: 0000000000000000
FS:  00007f9d37244dc0(0000) GS:ffff9edbbfcc0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffe0e715f80 CR3: 000000203c018005 CR4: 00000000001606e0
Call Trace:
 skb_copy_datagram_iter+0x16c/0x2a0
 raw_recvmsg+0xd0/0x1f0
 inet_recvmsg+0x5b/0xd0
 ____sys_recvmsg+0x95/0x160
 ? import_iovec+0x37/0xd0
 ? copy_msghdr_from_user+0x5c/0x90
 ___sys_recvmsg+0x8c/0xd0
 ? __audit_syscall_exit+0x228/0x290
 ? kretprobe_trampoline+0x25/0x50
 ? __sys_recvmsg+0x5b/0xa0
 __sys_recvmsg+0x5b/0xa0
 do_syscall_64+0x5f/0x240
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

Use 'dev_alloc_pages' instead of calling ’alloc_pages_node‘ directly.
Signed-off-by: NChiqijun <chiqijun@huawei.com>
Reviewed-by: NWangxiaoyun <cloud.wangxiaoyun@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

04edfc4f

net/hinic: Fix null pointer dereference in hinic_physical_port_id · 98541cfd

由 Chiqijun 提交于 3月 11, 2022

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

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

The hinic driver currently generates a NULL pointer dereference
when performing the hinicadm tool command during device probe.
This is because the hinicadm process accesses the NULL hwif
pointer in the hwdev which have not been allocated in probe.

Fix this by checking the initialization state of device before
accessing it.
Signed-off-by: NChiqijun <chiqijun@huawei.com>
Reviewed-by: NWangxiaoyun <cloud.wangxiaoyun@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

98541cfd

net/hinic: Fix double free issue · a8052325

由 Chiqijun 提交于 3月 10, 2022

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

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

When hinic_remove is executed concurrently, chip_node is double freed.
Signed-off-by: NChiqijun <chiqijun@huawei.com>
Reviewed-by: NWangxiaoyun <cloud.wangxiaoyun@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

a8052325

08 3月, 2022 1 次提交

bpf: Replace PTR_TO_XXX_OR_NULL with PTR_TO_XXX | PTR_MAYBE_NULL · 3dae5870

由 Hao Luo 提交于 3月 08, 2022

mainline inclusion
from mainline-v5.17-rc1
commit c25b2ae1
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4WRPV
CVE: CVE-2022-0500

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

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

We have introduced a new type to make bpf_reg composable, by
allocating bits in the type to represent flags.

One of the flags is PTR_MAYBE_NULL which indicates a pointer
may be NULL. This patch switches the qualified reg_types to
use this flag. The reg_types changed in this patch include:

1. PTR_TO_MAP_VALUE_OR_NULL
2. PTR_TO_SOCKET_OR_NULL
3. PTR_TO_SOCK_COMMON_OR_NULL
4. PTR_TO_TCP_SOCK_OR_NULL
5. PTR_TO_BTF_ID_OR_NULL
6. PTR_TO_MEM_OR_NULL
7. PTR_TO_RDONLY_BUF_OR_NULL
8. PTR_TO_RDWR_BUF_OR_NULL
Signed-off-by: NHao Luo <haoluo@google.com>
Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/r/20211217003152.48334-5-haoluo@google.com
Conflicts:
	include/linux/bpf.h
	include/linux/bpf_verifier.h
	kernel/bpf/verifier.c
Signed-off-by: NPu Lehui <pulehui@huawei.com>
Reviewed-by: NKuohai Xu <xukuohai@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

3dae5870

02 3月, 2022 1 次提交

drivers: hooks: add bonding driver vendor hooks · b88ceab5

由 Wei Yongjun 提交于 3月 02, 2022

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

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

Allow vendor modules to attach bonding driver hooks. This
patch introduce vendor_bond_check_dev_link hook.

Usage:

  static void vendor_foo(void *data, const struct bonding *bond,
  		       const struct slave *slave, int *state)
  {
          pr_info("%s\n", __func__);
  }

  static int __init vendor_bond_init(void)
  {
  	return register_trace_vendor_bond_check_dev_link(&vendor_foo, NULL);
  }

  static void __exit vendor_bond_exit(void)
  {
  	unregister_trace_vendor_bond_check_dev_link(&vendor_foo, NULL);
  }

  module_init(vendor_bond_init);
  module_exit(vendor_bond_exit);
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Reviewed-by: NZhang Jialin <zhangjialin11@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

b88ceab5

23 2月, 2022 6 次提交

bonding: force carrier update when releasing slave · c204a7a4

由 Zhang Changzhong 提交于 2月 23, 2022

mainline inclusion
from mainline-v5.17-rc5
commit a6ab75ce
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4UV5G
CVE: NA

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

In __bond_release_one(), bond_set_carrier() is only called when bond
device has no slave. Therefore, if we remove the up slave from a master
with two slaves and keep the down slave, the master will remain up.

Fix this by moving bond_set_carrier() out of if (!bond_has_slaves(bond))
statement.

Reproducer:
$ insmod bonding.ko mode=0 miimon=100 max_bonds=2
$ ifconfig bond0 up
$ ifenslave bond0 eth0 eth1
$ ifconfig eth0 down
$ ifenslave -d bond0 eth1
$ cat /proc/net/bonding/bond0

Fixes: ff59c456 ("[PATCH] bonding: support carrier state for master")
Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com>
Acked-by: NJay Vosburgh <jay.vosburgh@canonical.com>
Link: https://lore.kernel.org/r/1645021088-38370-1-git-send-email-zhangchangzhong@huawei.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com>
Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

c204a7a4

net/spnic: Reduce the timeout of the channel between driver and firmware · 82a493e3