Age | Commit message (Collapse) | Author | Files | Lines |
|
Add helper for set iavf aq request AVF_FLAG_AQ_* and immediately
schedule watchdog_task. Helper will be used in cases where it is
necessary to run aq requests asap
Signed-off-by: Petr Oros <poros@redhat.com>
Co-developed-by: Michal Schmidt <mschmidt@redhat.com>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Co-developed-by: Ivan Vecera <ivecera@redhat.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
Prevent schedule operations for adminq during device remove and when
__IAVF_IN_REMOVE_TASK flag is set. Currently, the iavf_down function
adds operations for adminq that shouldn't be processed when the device
is in the __IAVF_REMOVE state.
Reproduction:
echo 4 > /sys/bus/pci/devices/0000:17:00.0/sriov_numvfs
ip link set dev ens1f0 vf 0 trust on
ip link set dev ens1f0 vf 1 trust on
ip link set dev ens1f0 vf 2 trust on
ip link set dev ens1f0 vf 3 trust on
ip link set dev ens1f0 vf 0 mac 00:22:33:44:55:66
ip link set dev ens1f0 vf 1 mac 00:22:33:44:55:67
ip link set dev ens1f0 vf 2 mac 00:22:33:44:55:68
ip link set dev ens1f0 vf 3 mac 00:22:33:44:55:69
echo 0000:17:02.0 > /sys/bus/pci/devices/0000\:17\:02.0/driver/unbind
echo 0000:17:02.1 > /sys/bus/pci/devices/0000\:17\:02.1/driver/unbind
echo 0000:17:02.2 > /sys/bus/pci/devices/0000\:17\:02.2/driver/unbind
echo 0000:17:02.3 > /sys/bus/pci/devices/0000\:17\:02.3/driver/unbind
sleep 10
echo 0000:17:02.0 > /sys/bus/pci/drivers/iavf/bind
echo 0000:17:02.1 > /sys/bus/pci/drivers/iavf/bind
echo 0000:17:02.2 > /sys/bus/pci/drivers/iavf/bind
echo 0000:17:02.3 > /sys/bus/pci/drivers/iavf/bind
modprobe vfio-pci
echo 8086 154c > /sys/bus/pci/drivers/vfio-pci/new_id
qemu-system-x86_64 -accel kvm -m 4096 -cpu host \
-drive file=centos9.qcow2,if=none,id=virtio-disk0 \
-device virtio-blk-pci,drive=virtio-disk0,bootindex=0 -smp 4 \
-device vfio-pci,host=17:02.0 -net none \
-device vfio-pci,host=17:02.1 -net none \
-device vfio-pci,host=17:02.2 -net none \
-device vfio-pci,host=17:02.3 -net none \
-daemonize -vnc :5
Current result:
There is a probability that the mac of VF in guest is inconsistent with
it in host
Expected result:
When passthrough NIC VF to guest, the VF in guest should always get
the same mac as it in host.
Fixes: 14756b2ae265 ("iavf: Fix __IAVF_RESETTING state usage")
Signed-off-by: Radoslaw Tyl <radoslawx.tyl@intel.com>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
Lengths of SG pointers are kept in the following order in
the SG entries in hardware.
63 48|47 32|31 16|15 0
-----------------------------------------
| Len 0 | Len 1 | Len 2 | Len 3 |
-----------------------------------------
| Ptr 0 |
-----------------------------------------
| Ptr 1 |
-----------------------------------------
| Ptr 2 |
-----------------------------------------
| Ptr 3 |
-----------------------------------------
Dma pointers have to be unmapped based on their
respective lengths given in this format.
Fixes: 37d79d059606 ("octeon_ep: add Tx/Rx processing and interrupt support")
Signed-off-by: Shinas Rasheed <srasheed@marvell.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Alex reported that running ssh over IPv6 does not work with
Thunderbolt/USB4 networking driver. The reason for that is that driver
should call skb_is_gso() before calling skb_is_gso_v6(), and it should
not return false after calculates the checksum successfully. This probably
was a copy paste error from the original driver where it was done properly.
Reported-by: Alex Balcanquall <alex@alexbal.com>
Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable")
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The driver can now use PTP if enabled but fails to link built-in
if PTP is a loadable module:
aarch64-linux-ld: drivers/net/ethernet/ti/icssg/icss_iep.o: in function `icss_iep_get_ptp_clock_idx':
icss_iep.c:(.text+0x200): undefined reference to `ptp_clock_index'
Add the usual dependency to avoid this.
Fixes: 186734c158865 ("net: ti: icssg-prueth: add packet timestamping and ptp support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: MD Danish Anwar <danishanwar@ti.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Inject fault while probing kunit-example-test.ko, the duprule which
is allocated by kzalloc in vcap_dup_rule() of
test_vcap_xn_rule_creator() is not freed, and it cause the memory leaks
below. Use vcap_del_rule() to free them as other functions do it.
unreferenced object 0xffff6eb4846f6180 (size 192):
comm "kunit_try_catch", pid 405, jiffies 4294895522 (age 880.004s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 0a 00 00 00 f4 01 00 00 .'..............
00 00 00 00 00 00 00 00 98 61 6f 84 b4 6e ff ff .........ao..n..
backtrace:
[<00000000f1b5b86e>] slab_post_alloc_hook+0xb8/0x368
[<00000000c56cdd9a>] __kmem_cache_alloc_node+0x174/0x290
[<0000000046ef1b64>] kmalloc_trace+0x40/0x164
[<000000008565145b>] vcap_dup_rule+0x38/0x210
[<00000000bd9e1f12>] vcap_add_rule+0x29c/0x32c
[<0000000070a539b1>] test_vcap_xn_rule_creator.constprop.43+0x120/0x330
[<00000000d2ac4ccb>] vcap_api_rule_insert_in_order_test+0xa4/0x114
[<000000000f88f9cb>] kunit_try_run_case+0x50/0xac
[<00000000e848de5a>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000058a88b6b>] kthread+0x124/0x130
[<00000000891cf28a>] ret_from_fork+0x10/0x20
unreferenced object 0xffff6eb4846f6240 (size 192):
comm "kunit_try_catch", pid 405, jiffies 4294895524 (age 879.996s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 14 00 00 00 90 01 00 00 .'..............
00 00 00 00 00 00 00 00 58 62 6f 84 b4 6e ff ff ........Xbo..n..
backtrace:
[<00000000f1b5b86e>] slab_post_alloc_hook+0xb8/0x368
[<00000000c56cdd9a>] __kmem_cache_alloc_node+0x174/0x290
[<0000000046ef1b64>] kmalloc_trace+0x40/0x164
[<000000008565145b>] vcap_dup_rule+0x38/0x210
[<00000000bd9e1f12>] vcap_add_rule+0x29c/0x32c
[<0000000070a539b1>] test_vcap_xn_rule_creator.constprop.43+0x120/0x330
[<0000000052e6ad35>] vcap_api_rule_insert_in_order_test+0xbc/0x114
[<000000000f88f9cb>] kunit_try_run_case+0x50/0xac
[<00000000e848de5a>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000058a88b6b>] kthread+0x124/0x130
[<00000000891cf28a>] ret_from_fork+0x10/0x20
unreferenced object 0xffff6eb4846f6300 (size 192):
comm "kunit_try_catch", pid 405, jiffies 4294895524 (age 879.996s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 1e 00 00 00 2c 01 00 00 .'..........,...
00 00 00 00 00 00 00 00 18 63 6f 84 b4 6e ff ff .........co..n..
backtrace:
[<00000000f1b5b86e>] slab_post_alloc_hook+0xb8/0x368
[<00000000c56cdd9a>] __kmem_cache_alloc_node+0x174/0x290
[<0000000046ef1b64>] kmalloc_trace+0x40/0x164
[<000000008565145b>] vcap_dup_rule+0x38/0x210
[<00000000bd9e1f12>] vcap_add_rule+0x29c/0x32c
[<0000000070a539b1>] test_vcap_xn_rule_creator.constprop.43+0x120/0x330
[<000000001b0895d4>] vcap_api_rule_insert_in_order_test+0xd4/0x114
[<000000000f88f9cb>] kunit_try_run_case+0x50/0xac
[<00000000e848de5a>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000058a88b6b>] kthread+0x124/0x130
[<00000000891cf28a>] ret_from_fork+0x10/0x20
unreferenced object 0xffff6eb4846f63c0 (size 192):
comm "kunit_try_catch", pid 405, jiffies 4294895524 (age 880.012s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 28 00 00 00 c8 00 00 00 .'......(.......
00 00 00 00 00 00 00 00 d8 63 6f 84 b4 6e ff ff .........co..n..
backtrace:
[<00000000f1b5b86e>] slab_post_alloc_hook+0xb8/0x368
[<00000000c56cdd9a>] __kmem_cache_alloc_node+0x174/0x290
[<0000000046ef1b64>] kmalloc_trace+0x40/0x164
[<000000008565145b>] vcap_dup_rule+0x38/0x210
[<00000000bd9e1f12>] vcap_add_rule+0x29c/0x32c
[<0000000070a539b1>] test_vcap_xn_rule_creator.constprop.43+0x120/0x330
[<00000000134c151f>] vcap_api_rule_insert_in_order_test+0xec/0x114
[<000000000f88f9cb>] kunit_try_run_case+0x50/0xac
[<00000000e848de5a>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000058a88b6b>] kthread+0x124/0x130
[<00000000891cf28a>] ret_from_fork+0x10/0x20
unreferenced object 0xffff6eb4845fc180 (size 192):
comm "kunit_try_catch", pid 407, jiffies 4294895527 (age 880.000s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 14 00 00 00 c8 00 00 00 .'..............
00 00 00 00 00 00 00 00 98 c1 5f 84 b4 6e ff ff .........._..n..
backtrace:
[<00000000f1b5b86e>] slab_post_alloc_hook+0xb8/0x368
[<00000000c56cdd9a>] __kmem_cache_alloc_node+0x174/0x290
[<0000000046ef1b64>] kmalloc_trace+0x40/0x164
[<000000008565145b>] vcap_dup_rule+0x38/0x210
[<00000000bd9e1f12>] vcap_add_rule+0x29c/0x32c
[<0000000070a539b1>] test_vcap_xn_rule_creator.constprop.43+0x120/0x330
[<00000000fa5f64d3>] vcap_api_rule_insert_reverse_order_test+0xc8/0x600
[<000000000f88f9cb>] kunit_try_run_case+0x50/0xac
[<00000000e848de5a>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000058a88b6b>] kthread+0x124/0x130
[<00000000891cf28a>] ret_from_fork+0x10/0x20
unreferenced object 0xffff6eb4845fc240 (size 192):
comm "kunit_try_catch", pid 407, jiffies 4294895527 (age 880.000s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 1e 00 00 00 2c 01 00 00 .'..........,...
00 00 00 00 00 00 00 00 58 c2 5f 84 b4 6e ff ff ........X._..n..
backtrace:
[<00000000f1b5b86e>] slab_post_alloc_hook+0xb8/0x368
[<00000000c56cdd9a>] __kmem_cache_alloc_node+0x174/0x290
[<0000000046ef1b64>] kmalloc_trace+0x40/0x164
[<000000008565145b>] vcap_dup_rule+0x38/0x210
[<00000000453dcd80>] vcap_add_rule+0x134/0x32c
[<0000000070a539b1>] test_vcap_xn_rule_creator.constprop.43+0x120/0x330
[<00000000a7db42de>] vcap_api_rule_insert_reverse_order_test+0x108/0x600
[<000000000f88f9cb>] kunit_try_run_case+0x50/0xac
[<00000000e848de5a>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000058a88b6b>] kthread+0x124/0x130
[<00000000891cf28a>] ret_from_fork+0x10/0x20
unreferenced object 0xffff6eb4845fc300 (size 192):
comm "kunit_try_catch", pid 407, jiffies 4294895527 (age 880.000s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 28 00 00 00 90 01 00 00 .'......(.......
00 00 00 00 00 00 00 00 18 c3 5f 84 b4 6e ff ff .........._..n..
backtrace:
[<00000000f1b5b86e>] slab_post_alloc_hook+0xb8/0x368
[<00000000c56cdd9a>] __kmem_cache_alloc_node+0x174/0x290
[<0000000046ef1b64>] kmalloc_trace+0x40/0x164
[<000000008565145b>] vcap_dup_rule+0x38/0x210
[<00000000453dcd80>] vcap_add_rule+0x134/0x32c
[<0000000070a539b1>] test_vcap_xn_rule_creator.constprop.43+0x120/0x330
[<00000000ea416c94>] vcap_api_rule_insert_reverse_order_test+0x150/0x600
[<000000000f88f9cb>] kunit_try_run_case+0x50/0xac
[<00000000e848de5a>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000058a88b6b>] kthread+0x124/0x130
[<00000000891cf28a>] ret_from_fork+0x10/0x20
unreferenced object 0xffff6eb4845fc3c0 (size 192):
comm "kunit_try_catch", pid 407, jiffies 4294895527 (age 880.020s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 32 00 00 00 f4 01 00 00 .'......2.......
00 00 00 00 00 00 00 00 d8 c3 5f 84 b4 6e ff ff .........._..n..
backtrace:
[<00000000f1b5b86e>] slab_post_alloc_hook+0xb8/0x368
[<00000000c56cdd9a>] __kmem_cache_alloc_node+0x174/0x290
[<0000000046ef1b64>] kmalloc_trace+0x40/0x164
[<000000008565145b>] vcap_dup_rule+0x38/0x210
[<00000000453dcd80>] vcap_add_rule+0x134/0x32c
[<0000000070a539b1>] test_vcap_xn_rule_creator.constprop.43+0x120/0x330
[<00000000764a39b4>] vcap_api_rule_insert_reverse_order_test+0x198/0x600
[<000000000f88f9cb>] kunit_try_run_case+0x50/0xac
[<00000000e848de5a>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000058a88b6b>] kthread+0x124/0x130
[<00000000891cf28a>] ret_from_fork+0x10/0x20
unreferenced object 0xffff6eb484cd4240 (size 192):
comm "kunit_try_catch", pid 413, jiffies 4294895543 (age 879.956s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 1e 00 00 00 2c 01 00 00 .'..........,...
00 00 00 00 00 00 00 00 58 42 cd 84 b4 6e ff ff ........XB...n..
backtrace:
[<00000000f1b5b86e>] slab_post_alloc_hook+0xb8/0x368
[<00000000c56cdd9a>] __kmem_cache_alloc_node+0x174/0x290
[<0000000046ef1b64>] kmalloc_trace+0x40/0x164
[<000000008565145b>] vcap_dup_rule+0x38/0x210
[<00000000bd9e1f12>] vcap_add_rule+0x29c/0x32c
[<0000000070a539b1>] test_vcap_xn_rule_creator.constprop.43+0x120/0x330
[<0000000023976dd4>] vcap_api_rule_remove_in_front_test+0x158/0x658
[<000000000f88f9cb>] kunit_try_run_case+0x50/0xac
[<00000000e848de5a>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000058a88b6b>] kthread+0x124/0x130
[<00000000891cf28a>] ret_from_fork+0x10/0x20
unreferenced object 0xffff6eb484cd4300 (size 192):
comm "kunit_try_catch", pid 413, jiffies 4294895543 (age 879.956s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 28 00 00 00 c8 00 00 00 .'......(.......
00 00 00 00 00 00 00 00 18 43 cd 84 b4 6e ff ff .........C...n..
backtrace:
[<00000000f1b5b86e>] slab_post_alloc_hook+0xb8/0x368
[<00000000c56cdd9a>] __kmem_cache_alloc_node+0x174/0x290
[<0000000046ef1b64>] kmalloc_trace+0x40/0x164
[<000000008565145b>] vcap_dup_rule+0x38/0x210
[<00000000bd9e1f12>] vcap_add_rule+0x29c/0x32c
[<0000000070a539b1>] test_vcap_xn_rule_creator.constprop.43+0x120/0x330
[<000000000b4760ff>] vcap_api_rule_remove_in_front_test+0x170/0x658
[<000000000f88f9cb>] kunit_try_run_case+0x50/0xac
[<00000000e848de5a>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000058a88b6b>] kthread+0x124/0x130
[<00000000891cf28a>] ret_from_fork+0x10/0x20
Fixes: dccc30cc4906 ("net: microchip: sparx5: Add KUNIT test of counters and sorted rules")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Inject fault while probing kunit-example-test.ko, the rule which
is allocated by kzalloc in vcap_alloc_rule(), the field which is
allocated by kzalloc in vcap_rule_add_action() and
vcap_rule_add_key() is not freed, and it cause the memory leaks
below. Use vcap_free_rule() to free them as other drivers do it.
And since the return rule of test_vcap_xn_rule_creator() is not
used, remove it and switch to void.
unreferenced object 0xffff058383334240 (size 192):
comm "kunit_try_catch", pid 309, jiffies 4294894222 (age 639.800s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 14 00 00 00 90 01 00 00 .'..............
00 00 00 00 00 00 00 00 00 81 93 84 83 05 ff ff ................
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<00000000648fefae>] vcap_alloc_rule+0x17c/0x26c
[<000000004da16164>] test_vcap_xn_rule_creator.constprop.43+0xac/0x328
[<00000000231b1097>] vcap_api_rule_insert_in_order_test+0xcc/0x184
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0583849380c0 (size 64):
comm "kunit_try_catch", pid 309, jiffies 4294894222 (age 639.800s)
hex dump (first 32 bytes):
40 81 93 84 83 05 ff ff 68 42 33 83 83 05 ff ff @.......hB3.....
22 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 "...............
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<00000000ee41df9e>] vcap_rule_add_action+0x104/0x178
[<000000001cc1bb38>] test_vcap_xn_rule_creator.constprop.43+0xd8/0x328
[<00000000231b1097>] vcap_api_rule_insert_in_order_test+0xcc/0x184
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff058384938100 (size 64):
comm "kunit_try_catch", pid 309, jiffies 4294894222 (age 639.800s)
hex dump (first 32 bytes):
80 81 93 84 83 05 ff ff 58 42 33 83 83 05 ff ff ........XB3.....
7d 00 00 00 01 00 00 00 02 00 00 00 ff 00 00 00 }...............
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<0000000043c78991>] vcap_rule_add_key+0x104/0x180
[<00000000ba73cfbe>] vcap_add_type_keyfield+0xfc/0x128
[<000000002b00f7df>] vcap_val_rule+0x274/0x3e8
[<00000000e67d2ff5>] test_vcap_xn_rule_creator.constprop.43+0xf0/0x328
[<00000000231b1097>] vcap_api_rule_insert_in_order_test+0xcc/0x184
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0583833b6240 (size 192):
comm "kunit_try_catch", pid 311, jiffies 4294894225 (age 639.844s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 1e 00 00 00 2c 01 00 00 .'..........,...
00 00 00 00 00 00 00 00 40 91 8f 84 83 05 ff ff ........@.......
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<00000000648fefae>] vcap_alloc_rule+0x17c/0x26c
[<000000004da16164>] test_vcap_xn_rule_creator.constprop.43+0xac/0x328
[<00000000509de3f4>] vcap_api_rule_insert_reverse_order_test+0x10c/0x654
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0583848f9100 (size 64):
comm "kunit_try_catch", pid 311, jiffies 4294894225 (age 639.844s)
hex dump (first 32 bytes):
80 91 8f 84 83 05 ff ff 68 62 3b 83 83 05 ff ff ........hb;.....
22 00 00 00 01 00 00 00 00 00 00 00 a5 b4 ff ff "...............
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<00000000ee41df9e>] vcap_rule_add_action+0x104/0x178
[<000000001cc1bb38>] test_vcap_xn_rule_creator.constprop.43+0xd8/0x328
[<00000000509de3f4>] vcap_api_rule_insert_reverse_order_test+0x10c/0x654
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0583848f9140 (size 64):
comm "kunit_try_catch", pid 311, jiffies 4294894225 (age 639.844s)
hex dump (first 32 bytes):
c0 91 8f 84 83 05 ff ff 58 62 3b 83 83 05 ff ff ........Xb;.....
7d 00 00 00 01 00 00 00 02 00 00 00 ff 00 00 00 }...............
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<0000000043c78991>] vcap_rule_add_key+0x104/0x180
[<00000000ba73cfbe>] vcap_add_type_keyfield+0xfc/0x128
[<000000002b00f7df>] vcap_val_rule+0x274/0x3e8
[<00000000e67d2ff5>] test_vcap_xn_rule_creator.constprop.43+0xf0/0x328
[<00000000509de3f4>] vcap_api_rule_insert_reverse_order_test+0x10c/0x654
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff05838264e0c0 (size 192):
comm "kunit_try_catch", pid 313, jiffies 4294894230 (age 639.864s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 0a 00 00 00 f4 01 00 00 .'..............
00 00 00 00 00 00 00 00 40 3a 97 84 83 05 ff ff ........@:......
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<00000000648fefae>] vcap_alloc_rule+0x17c/0x26c
[<000000004da16164>] test_vcap_xn_rule_creator.constprop.43+0xac/0x328
[<00000000a29794d8>] vcap_api_rule_remove_at_end_test+0xbc/0xb48
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff058384973a80 (size 64):
comm "kunit_try_catch", pid 313, jiffies 4294894230 (age 639.864s)
hex dump (first 32 bytes):
e8 e0 64 82 83 05 ff ff e8 e0 64 82 83 05 ff ff ..d.......d.....
22 00 00 00 01 00 00 00 00 00 00 00 00 80 ff ff "...............
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<00000000ee41df9e>] vcap_rule_add_action+0x104/0x178
[<000000001cc1bb38>] test_vcap_xn_rule_creator.constprop.43+0xd8/0x328
[<00000000a29794d8>] vcap_api_rule_remove_at_end_test+0xbc/0xb48
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff058384973a40 (size 64):
comm "kunit_try_catch", pid 313, jiffies 4294894230 (age 639.880s)
hex dump (first 32 bytes):
80 39 97 84 83 05 ff ff d8 e0 64 82 83 05 ff ff .9........d.....
7d 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 }...............
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<0000000043c78991>] vcap_rule_add_key+0x104/0x180
[<0000000094335477>] vcap_add_type_keyfield+0xbc/0x128
[<000000002b00f7df>] vcap_val_rule+0x274/0x3e8
[<00000000e67d2ff5>] test_vcap_xn_rule_creator.constprop.43+0xf0/0x328
[<00000000a29794d8>] vcap_api_rule_remove_at_end_test+0xbc/0xb48
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0583832fa240 (size 192):
comm "kunit_try_catch", pid 315, jiffies 4294894233 (age 639.920s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 14 00 00 00 90 01 00 00 .'..............
00 00 00 00 00 00 00 00 00 a1 8b 84 83 05 ff ff ................
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<00000000648fefae>] vcap_alloc_rule+0x17c/0x26c
[<000000004da16164>] test_vcap_xn_rule_creator.constprop.43+0xac/0x328
[<00000000be638a45>] vcap_api_rule_remove_in_middle_test+0xc4/0xb80
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0583848ba0c0 (size 64):
comm "kunit_try_catch", pid 315, jiffies 4294894233 (age 639.920s)
hex dump (first 32 bytes):
40 a1 8b 84 83 05 ff ff 68 a2 2f 83 83 05 ff ff @.......h./.....
22 00 00 00 01 00 00 00 00 00 00 00 00 80 ff ff "...............
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<00000000ee41df9e>] vcap_rule_add_action+0x104/0x178
[<000000001cc1bb38>] test_vcap_xn_rule_creator.constprop.43+0xd8/0x328
[<00000000be638a45>] vcap_api_rule_remove_in_middle_test+0xc4/0xb80
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0583848ba100 (size 64):
comm "kunit_try_catch", pid 315, jiffies 4294894233 (age 639.920s)
hex dump (first 32 bytes):
80 a1 8b 84 83 05 ff ff 58 a2 2f 83 83 05 ff ff ........X./.....
7d 00 00 00 01 00 00 00 02 00 00 00 ff 00 00 00 }...............
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<0000000043c78991>] vcap_rule_add_key+0x104/0x180
[<00000000ba73cfbe>] vcap_add_type_keyfield+0xfc/0x128
[<000000002b00f7df>] vcap_val_rule+0x274/0x3e8
[<00000000e67d2ff5>] test_vcap_xn_rule_creator.constprop.43+0xf0/0x328
[<00000000be638a45>] vcap_api_rule_remove_in_middle_test+0xc4/0xb80
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0583827d2180 (size 192):
comm "kunit_try_catch", pid 317, jiffies 4294894238 (age 639.956s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 14 00 00 00 90 01 00 00 .'..............
00 00 00 00 00 00 00 00 00 e1 06 83 83 05 ff ff ................
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<00000000648fefae>] vcap_alloc_rule+0x17c/0x26c
[<000000004da16164>] test_vcap_xn_rule_creator.constprop.43+0xac/0x328
[<00000000e1ed8350>] vcap_api_rule_remove_in_front_test+0x144/0x6c0
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff05838306e0c0 (size 64):
comm "kunit_try_catch", pid 317, jiffies 4294894238 (age 639.956s)
hex dump (first 32 bytes):
40 e1 06 83 83 05 ff ff a8 21 7d 82 83 05 ff ff @........!}.....
22 00 00 00 01 00 00 00 00 00 00 00 00 80 ff ff "...............
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<00000000ee41df9e>] vcap_rule_add_action+0x104/0x178
[<000000001cc1bb38>] test_vcap_xn_rule_creator.constprop.43+0xd8/0x328
[<00000000e1ed8350>] vcap_api_rule_remove_in_front_test+0x144/0x6c0
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
unreferenced object 0xffff05838306e180 (size 64):
comm "kunit_try_catch", pid 317, jiffies 4294894238 (age 639.968s)
hex dump (first 32 bytes):
98 21 7d 82 83 05 ff ff 00 e1 06 83 83 05 ff ff .!}.............
67 00 00 00 00 00 00 00 01 01 00 00 ff 00 00 00 g...............
backtrace:
[<000000008585a8f7>] slab_post_alloc_hook+0xb8/0x368
[<00000000795eba12>] __kmem_cache_alloc_node+0x174/0x290
[<0000000061886991>] kmalloc_trace+0x40/0x164
[<0000000043c78991>] vcap_rule_add_key+0x104/0x180
[<000000006ce4945d>] test_add_def_fields+0x84/0x8c
[<00000000507e0ab6>] vcap_val_rule+0x294/0x3e8
[<00000000e67d2ff5>] test_vcap_xn_rule_creator.constprop.43+0xf0/0x328
[<00000000e1ed8350>] vcap_api_rule_remove_in_front_test+0x144/0x6c0
[<00000000548b559e>] kunit_try_run_case+0x50/0xac
[<00000000663f0105>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<00000000e646f120>] kthread+0x124/0x130
[<000000005257599e>] ret_from_fork+0x10/0x20
Fixes: dccc30cc4906 ("net: microchip: sparx5: Add KUNIT test of counters and sorted rules")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202309090950.uOTEKQq3-lkp@intel.com/
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Inject fault while probing kunit-example-test.ko, the duprule which
is allocated in vcap_dup_rule() and the vcap enabled port which
is allocated in vcap_enable() of vcap_enable_lookups in
vcap_api_encode_rule_test() is not freed, and it cause the memory
leaks below.
Use vcap_enable_lookups() with false arg to free the vcap enabled
port as other drivers do it. And use vcap_del_rule() to
free the duprule.
unreferenced object 0xffff677a0278bb00 (size 64):
comm "kunit_try_catch", pid 388, jiffies 4294895987 (age 1101.840s)
hex dump (first 32 bytes):
18 bd a5 82 00 80 ff ff 18 bd a5 82 00 80 ff ff ................
40 fe c8 0e be c6 ff ff 00 00 00 00 00 00 00 00 @...............
backtrace:
[<000000007d53023a>] slab_post_alloc_hook+0xb8/0x368
[<0000000076e3f654>] __kmem_cache_alloc_node+0x174/0x290
[<0000000034d76721>] kmalloc_trace+0x40/0x164
[<00000000013380a5>] vcap_enable_lookups+0x1c8/0x70c
[<00000000bbec496b>] vcap_api_encode_rule_test+0x2f8/0xb18
[<000000002c2bfb7b>] kunit_try_run_case+0x50/0xac
[<00000000ff74642b>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<000000004af845ca>] kthread+0x124/0x130
[<0000000038a000ca>] ret_from_fork+0x10/0x20
unreferenced object 0xffff677a027803c0 (size 192):
comm "kunit_try_catch", pid 388, jiffies 4294895988 (age 1101.836s)
hex dump (first 32 bytes):
00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d...
00 00 00 00 00 00 00 00 d8 03 78 02 7a 67 ff ff ..........x.zg..
backtrace:
[<000000007d53023a>] slab_post_alloc_hook+0xb8/0x368
[<0000000076e3f654>] __kmem_cache_alloc_node+0x174/0x290
[<0000000034d76721>] kmalloc_trace+0x40/0x164
[<00000000c1010131>] vcap_dup_rule+0x34/0x14c
[<00000000d43c54a4>] vcap_add_rule+0x29c/0x32c
[<0000000073f1c26d>] vcap_api_encode_rule_test+0x304/0xb18
[<000000002c2bfb7b>] kunit_try_run_case+0x50/0xac
[<00000000ff74642b>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<000000004af845ca>] kthread+0x124/0x130
[<0000000038a000ca>] ret_from_fork+0x10/0x20
Fixes: c956b9b318d9 ("net: microchip: sparx5: Adding KUNIT tests of key/action values in VCAP API")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Inject fault while probing kunit-example-test.ko, the field which
is allocated by kzalloc in vcap_rule_add_action() of
vcap_rule_add_action_bit/u32() is not freed, and it cause
the memory leaks below.
unreferenced object 0xffff0276c496b300 (size 64):
comm "kunit_try_catch", pid 286, jiffies 4294894224 (age 920.072s)
hex dump (first 32 bytes):
68 3c 62 82 00 80 ff ff 68 3c 62 82 00 80 ff ff h<b.....h<b.....
3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <...............
backtrace:
[<0000000028f08898>] slab_post_alloc_hook+0xb8/0x368
[<00000000514b9b37>] __kmem_cache_alloc_node+0x174/0x290
[<000000004620684a>] kmalloc_trace+0x40/0x164
[<000000008b41c84d>] vcap_rule_add_action+0x104/0x178
[<00000000ae66c16c>] vcap_api_rule_add_actionvalue_test+0xa4/0x990
[<00000000fcc5326c>] kunit_try_run_case+0x50/0xac
[<00000000f5f45b20>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000026284079>] kthread+0x124/0x130
[<0000000024d4a996>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0276c496b2c0 (size 64):
comm "kunit_try_catch", pid 286, jiffies 4294894224 (age 920.072s)
hex dump (first 32 bytes):
68 3c 62 82 00 80 ff ff 68 3c 62 82 00 80 ff ff h<b.....h<b.....
3c 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 <...............
backtrace:
[<0000000028f08898>] slab_post_alloc_hook+0xb8/0x368
[<00000000514b9b37>] __kmem_cache_alloc_node+0x174/0x290
[<000000004620684a>] kmalloc_trace+0x40/0x164
[<000000008b41c84d>] vcap_rule_add_action+0x104/0x178
[<00000000607782aa>] vcap_api_rule_add_actionvalue_test+0x100/0x990
[<00000000fcc5326c>] kunit_try_run_case+0x50/0xac
[<00000000f5f45b20>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000026284079>] kthread+0x124/0x130
[<0000000024d4a996>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0276c496b280 (size 64):
comm "kunit_try_catch", pid 286, jiffies 4294894224 (age 920.072s)
hex dump (first 32 bytes):
68 3c 62 82 00 80 ff ff 68 3c 62 82 00 80 ff ff h<b.....h<b.....
3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <...............
backtrace:
[<0000000028f08898>] slab_post_alloc_hook+0xb8/0x368
[<00000000514b9b37>] __kmem_cache_alloc_node+0x174/0x290
[<000000004620684a>] kmalloc_trace+0x40/0x164
[<000000008b41c84d>] vcap_rule_add_action+0x104/0x178
[<000000004e640602>] vcap_api_rule_add_actionvalue_test+0x15c/0x990
[<00000000fcc5326c>] kunit_try_run_case+0x50/0xac
[<00000000f5f45b20>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000026284079>] kthread+0x124/0x130
[<0000000024d4a996>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0276c496b240 (size 64):
comm "kunit_try_catch", pid 286, jiffies 4294894224 (age 920.092s)
hex dump (first 32 bytes):
68 3c 62 82 00 80 ff ff 68 3c 62 82 00 80 ff ff h<b.....h<b.....
5a 00 00 00 01 00 00 00 32 54 76 98 00 00 00 00 Z.......2Tv.....
backtrace:
[<0000000028f08898>] slab_post_alloc_hook+0xb8/0x368
[<00000000514b9b37>] __kmem_cache_alloc_node+0x174/0x290
[<000000004620684a>] kmalloc_trace+0x40/0x164
[<000000008b41c84d>] vcap_rule_add_action+0x104/0x178
[<0000000011141bf8>] vcap_api_rule_add_actionvalue_test+0x1bc/0x990
[<00000000fcc5326c>] kunit_try_run_case+0x50/0xac
[<00000000f5f45b20>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000026284079>] kthread+0x124/0x130
[<0000000024d4a996>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0276c496b200 (size 64):
comm "kunit_try_catch", pid 286, jiffies 4294894224 (age 920.092s)
hex dump (first 32 bytes):
68 3c 62 82 00 80 ff ff 68 3c 62 82 00 80 ff ff h<b.....h<b.....
28 00 00 00 01 00 00 00 dd cc bb aa 00 00 00 00 (...............
backtrace:
[<0000000028f08898>] slab_post_alloc_hook+0xb8/0x368
[<00000000514b9b37>] __kmem_cache_alloc_node+0x174/0x290
[<000000004620684a>] kmalloc_trace+0x40/0x164
[<000000008b41c84d>] vcap_rule_add_action+0x104/0x178
[<00000000d5ed3088>] vcap_api_rule_add_actionvalue_test+0x22c/0x990
[<00000000fcc5326c>] kunit_try_run_case+0x50/0xac
[<00000000f5f45b20>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000026284079>] kthread+0x124/0x130
[<0000000024d4a996>] ret_from_fork+0x10/0x20
Fixes: c956b9b318d9 ("net: microchip: sparx5: Adding KUNIT tests of key/action values in VCAP API")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Inject fault while probing kunit-example-test.ko, the field which
is allocated by kzalloc in vcap_rule_add_key() of
vcap_rule_add_key_bit/u32/u128() is not freed, and it cause
the memory leaks below.
unreferenced object 0xffff0276c14b7240 (size 64):
comm "kunit_try_catch", pid 284, jiffies 4294894220 (age 920.072s)
hex dump (first 32 bytes):
28 3c 61 82 00 80 ff ff 28 3c 61 82 00 80 ff ff (<a.....(<a.....
67 00 00 00 00 00 00 00 00 01 37 2b af ab ff ff g.........7+....
backtrace:
[<0000000028f08898>] slab_post_alloc_hook+0xb8/0x368
[<00000000514b9b37>] __kmem_cache_alloc_node+0x174/0x290
[<000000004620684a>] kmalloc_trace+0x40/0x164
[<0000000059ad6bcd>] vcap_rule_add_key+0x104/0x180
[<00000000ff8002d3>] vcap_api_rule_add_keyvalue_test+0x100/0xba8
[<00000000fcc5326c>] kunit_try_run_case+0x50/0xac
[<00000000f5f45b20>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000026284079>] kthread+0x124/0x130
[<0000000024d4a996>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0276c14b7280 (size 64):
comm "kunit_try_catch", pid 284, jiffies 4294894221 (age 920.068s)
hex dump (first 32 bytes):
28 3c 61 82 00 80 ff ff 28 3c 61 82 00 80 ff ff (<a.....(<a.....
67 00 00 00 00 00 00 00 01 01 37 2b af ab ff ff g.........7+....
backtrace:
[<0000000028f08898>] slab_post_alloc_hook+0xb8/0x368
[<00000000514b9b37>] __kmem_cache_alloc_node+0x174/0x290
[<000000004620684a>] kmalloc_trace+0x40/0x164
[<0000000059ad6bcd>] vcap_rule_add_key+0x104/0x180
[<00000000f5ac9dc7>] vcap_api_rule_add_keyvalue_test+0x168/0xba8
[<00000000fcc5326c>] kunit_try_run_case+0x50/0xac
[<00000000f5f45b20>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000026284079>] kthread+0x124/0x130
[<0000000024d4a996>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0276c14b72c0 (size 64):
comm "kunit_try_catch", pid 284, jiffies 4294894221 (age 920.068s)
hex dump (first 32 bytes):
28 3c 61 82 00 80 ff ff 28 3c 61 82 00 80 ff ff (<a.....(<a.....
67 00 00 00 00 00 00 00 00 00 37 2b af ab ff ff g.........7+....
backtrace:
[<0000000028f08898>] slab_post_alloc_hook+0xb8/0x368
[<00000000514b9b37>] __kmem_cache_alloc_node+0x174/0x290
[<000000004620684a>] kmalloc_trace+0x40/0x164
[<0000000059ad6bcd>] vcap_rule_add_key+0x104/0x180
[<00000000c918ae7f>] vcap_api_rule_add_keyvalue_test+0x1d0/0xba8
[<00000000fcc5326c>] kunit_try_run_case+0x50/0xac
[<00000000f5f45b20>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000026284079>] kthread+0x124/0x130
[<0000000024d4a996>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0276c14b7300 (size 64):
comm "kunit_try_catch", pid 284, jiffies 4294894221 (age 920.084s)
hex dump (first 32 bytes):
28 3c 61 82 00 80 ff ff 28 3c 61 82 00 80 ff ff (<a.....(<a.....
7d 00 00 00 01 00 00 00 32 54 76 98 ab ff 00 ff }.......2Tv.....
backtrace:
[<0000000028f08898>] slab_post_alloc_hook+0xb8/0x368
[<00000000514b9b37>] __kmem_cache_alloc_node+0x174/0x290
[<000000004620684a>] kmalloc_trace+0x40/0x164
[<0000000059ad6bcd>] vcap_rule_add_key+0x104/0x180
[<0000000003352814>] vcap_api_rule_add_keyvalue_test+0x240/0xba8
[<00000000fcc5326c>] kunit_try_run_case+0x50/0xac
[<00000000f5f45b20>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000026284079>] kthread+0x124/0x130
[<0000000024d4a996>] ret_from_fork+0x10/0x20
unreferenced object 0xffff0276c14b7340 (size 64):
comm "kunit_try_catch", pid 284, jiffies 4294894221 (age 920.084s)
hex dump (first 32 bytes):
28 3c 61 82 00 80 ff ff 28 3c 61 82 00 80 ff ff (<a.....(<a.....
51 00 00 00 07 00 00 00 17 26 35 44 63 62 71 00 Q........&5Dcbq.
backtrace:
[<0000000028f08898>] slab_post_alloc_hook+0xb8/0x368
[<00000000514b9b37>] __kmem_cache_alloc_node+0x174/0x290
[<000000004620684a>] kmalloc_trace+0x40/0x164
[<0000000059ad6bcd>] vcap_rule_add_key+0x104/0x180
[<000000001516f109>] vcap_api_rule_add_keyvalue_test+0x2cc/0xba8
[<00000000fcc5326c>] kunit_try_run_case+0x50/0xac
[<00000000f5f45b20>] kunit_generic_run_threadfn_adapter+0x20/0x2c
[<0000000026284079>] kthread+0x124/0x130
[<0000000024d4a996>] ret_from_fork+0x10/0x20
Fixes: c956b9b318d9 ("net: microchip: sparx5: Adding KUNIT tests of key/action values in VCAP API")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Add spin lock protection for irq {un}mask registers' control.
After napi_complete_done() and this protection were applied,
a lot of redundant interrupts no longer occur.
For example: when "iperf3 -c <ipaddr> -R" on R-Car S4-8 Spider
Before the patches are applied: about 800,000 times happened
After the patches were applied: about 100,000 times happened
Fixes: 3590918b5d07 ("net: ethernet: renesas: Add support for "Ethernet Switch"")
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Fix unmasking irq condition by using napi_complete_done(). Otherwise,
redundant interrupts happen.
Fixes: 3590918b5d07 ("net: ethernet: renesas: Add support for "Ethernet Switch"")
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
After commit 50f303496d92 ("igb: Enable SR-IOV after reinit"), removing
the igb module could hang or crash (depending on the machine) when the
module has been loaded with the max_vfs parameter set to some value != 0.
In case of one test machine with a dual port 82580, this hang occurred:
[ 232.480687] igb 0000:41:00.1: removed PHC on enp65s0f1
[ 233.093257] igb 0000:41:00.1: IOV Disabled
[ 233.329969] pcieport 0000:40:01.0: AER: Multiple Uncorrected (Non-Fatal) err0
[ 233.340302] igb 0000:41:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fata)
[ 233.352248] igb 0000:41:00.0: device [8086:1516] error status/mask=00100000
[ 233.361088] igb 0000:41:00.0: [20] UnsupReq (First)
[ 233.368183] igb 0000:41:00.0: AER: TLP Header: 40000001 0000040f cdbfc00c c
[ 233.376846] igb 0000:41:00.1: PCIe Bus Error: severity=Uncorrected (Non-Fata)
[ 233.388779] igb 0000:41:00.1: device [8086:1516] error status/mask=00100000
[ 233.397629] igb 0000:41:00.1: [20] UnsupReq (First)
[ 233.404736] igb 0000:41:00.1: AER: TLP Header: 40000001 0000040f cdbfc00c c
[ 233.538214] pci 0000:41:00.1: AER: can't recover (no error_detected callback)
[ 233.538401] igb 0000:41:00.0: removed PHC on enp65s0f0
[ 233.546197] pcieport 0000:40:01.0: AER: device recovery failed
[ 234.157244] igb 0000:41:00.0: IOV Disabled
[ 371.619705] INFO: task irq/35-aerdrv:257 blocked for more than 122 seconds.
[ 371.627489] Not tainted 6.4.0-dirty #2
[ 371.632257] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this.
[ 371.641000] task:irq/35-aerdrv state:D stack:0 pid:257 ppid:2 f0
[ 371.650330] Call Trace:
[ 371.653061] <TASK>
[ 371.655407] __schedule+0x20e/0x660
[ 371.659313] schedule+0x5a/0xd0
[ 371.662824] schedule_preempt_disabled+0x11/0x20
[ 371.667983] __mutex_lock.constprop.0+0x372/0x6c0
[ 371.673237] ? __pfx_aer_root_reset+0x10/0x10
[ 371.678105] report_error_detected+0x25/0x1c0
[ 371.682974] ? __pfx_report_normal_detected+0x10/0x10
[ 371.688618] pci_walk_bus+0x72/0x90
[ 371.692519] pcie_do_recovery+0xb2/0x330
[ 371.696899] aer_process_err_devices+0x117/0x170
[ 371.702055] aer_isr+0x1c0/0x1e0
[ 371.705661] ? __set_cpus_allowed_ptr+0x54/0xa0
[ 371.710723] ? __pfx_irq_thread_fn+0x10/0x10
[ 371.715496] irq_thread_fn+0x20/0x60
[ 371.719491] irq_thread+0xe6/0x1b0
[ 371.723291] ? __pfx_irq_thread_dtor+0x10/0x10
[ 371.728255] ? __pfx_irq_thread+0x10/0x10
[ 371.732731] kthread+0xe2/0x110
[ 371.736243] ? __pfx_kthread+0x10/0x10
[ 371.740430] ret_from_fork+0x2c/0x50
[ 371.744428] </TASK>
The reproducer was a simple script:
#!/bin/sh
for i in `seq 1 5`; do
modprobe -rv igb
modprobe -v igb max_vfs=1
sleep 1
modprobe -rv igb
done
It turned out that this could only be reproduce on 82580 (quad and
dual-port), but not on 82576, i350 and i210. Further debugging showed
that igb_enable_sriov()'s call to pci_enable_sriov() is failing, because
dev->is_physfn is 0 on 82580.
Prior to commit 50f303496d92 ("igb: Enable SR-IOV after reinit"),
igb_enable_sriov() jumped into the "err_out" cleanup branch. After this
commit it only returned the error code.
So the cleanup didn't take place, and the incorrect VF setup in the
igb_adapter structure fooled the igb driver into assuming that VFs have
been set up where no VF actually existed.
Fix this problem by cleaning up again if pci_enable_sriov() fails.
Fixes: 50f303496d92 ("igb: Enable SR-IOV after reinit")
Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The commit in fixes introduced flags to control the status of hardware
configuration while processing packets. At the same time another structure
is used to provide configuration of timestamper to user-space applications.
The way it was coded makes this structures go out of sync easily. The
repro is easy for 82599 chips:
[root@hostname ~]# hwstamp_ctl -i eth0 -r 12 -t 1
current settings:
tx_type 0
rx_filter 0
new settings:
tx_type 1
rx_filter 12
The eth0 device is properly configured to timestamp any PTPv2 events.
[root@hostname ~]# hwstamp_ctl -i eth0 -r 1 -t 1
current settings:
tx_type 1
rx_filter 12
SIOCSHWTSTAMP failed: Numerical result out of range
The requested time stamping mode is not supported by the hardware.
The error is properly returned because HW doesn't support all packets
timestamping. But the adapter->flags is cleared of timestamp flags
even though no HW configuration was done. From that point no RX timestamps
are received by user-space application. But configuration shows good
values:
[root@hostname ~]# hwstamp_ctl -i eth0
current settings:
tx_type 1
rx_filter 12
Fix the issue by applying new flags only when the HW was actually
configured.
Fixes: a9763f3cb54c ("ixgbe: Update PTP to support X550EM_x devices")
Signed-off-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
There's an early return in veth_set_features() if the device is in a down
state, which leads to the XDP feature flags not being updated when enabling
GRO while the device is down. Which in turn leads to XDP_REDIRECT not
working, because the redirect code now checks the flags.
Fix this by updating the feature flags after bringing the device up.
Before this patch:
NETDEV_XDP_ACT_BASIC: yes
NETDEV_XDP_ACT_REDIRECT: yes
NETDEV_XDP_ACT_NDO_XMIT: no
NETDEV_XDP_ACT_XSK_ZEROCOPY: no
NETDEV_XDP_ACT_HW_OFFLOAD: no
NETDEV_XDP_ACT_RX_SG: yes
NETDEV_XDP_ACT_NDO_XMIT_SG: no
After this patch:
NETDEV_XDP_ACT_BASIC: yes
NETDEV_XDP_ACT_REDIRECT: yes
NETDEV_XDP_ACT_NDO_XMIT: yes
NETDEV_XDP_ACT_XSK_ZEROCOPY: no
NETDEV_XDP_ACT_HW_OFFLOAD: no
NETDEV_XDP_ACT_RX_SG: yes
NETDEV_XDP_ACT_NDO_XMIT_SG: yes
Fixes: fccca038f300 ("veth: take into account device reconfiguration for xdp_features flag")
Fixes: 66c0e13ad236 ("drivers: net: turn on XDP features")
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/r/20230911135826.722295-1-toke@redhat.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
macb_set_tx_clk() is called under a spinlock but itself calls clk_set_rate()
which can sleep. This results in:
| BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580
| pps pps1: new PPS source ptp1
| in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 40, name: kworker/u4:3
| preempt_count: 1, expected: 0
| RCU nest depth: 0, expected: 0
| 4 locks held by kworker/u4:3/40:
| #0: ffff000003409148
| macb ff0c0000.ethernet: gem-ptp-timer ptp clock registered.
| ((wq_completion)events_power_efficient){+.+.}-{0:0}, at: process_one_work+0x14c/0x51c
| #1: ffff8000833cbdd8 ((work_completion)(&pl->resolve)){+.+.}-{0:0}, at: process_one_work+0x14c/0x51c
| #2: ffff000004f01578 (&pl->state_mutex){+.+.}-{4:4}, at: phylink_resolve+0x44/0x4e8
| #3: ffff000004f06f50 (&bp->lock){....}-{3:3}, at: macb_mac_link_up+0x40/0x2ac
| irq event stamp: 113998
| hardirqs last enabled at (113997): [<ffff800080e8503c>] _raw_spin_unlock_irq+0x30/0x64
| hardirqs last disabled at (113998): [<ffff800080e84478>] _raw_spin_lock_irqsave+0xac/0xc8
| softirqs last enabled at (113608): [<ffff800080010630>] __do_softirq+0x430/0x4e4
| softirqs last disabled at (113597): [<ffff80008001614c>] ____do_softirq+0x10/0x1c
| CPU: 0 PID: 40 Comm: kworker/u4:3 Not tainted 6.5.0-11717-g9355ce8b2f50-dirty #368
| Hardware name: ... ZynqMP ... (DT)
| Workqueue: events_power_efficient phylink_resolve
| Call trace:
| dump_backtrace+0x98/0xf0
| show_stack+0x18/0x24
| dump_stack_lvl+0x60/0xac
| dump_stack+0x18/0x24
| __might_resched+0x144/0x24c
| __might_sleep+0x48/0x98
| __mutex_lock+0x58/0x7b0
| mutex_lock_nested+0x24/0x30
| clk_prepare_lock+0x4c/0xa8
| clk_set_rate+0x24/0x8c
| macb_mac_link_up+0x25c/0x2ac
| phylink_resolve+0x178/0x4e8
| process_one_work+0x1ec/0x51c
| worker_thread+0x1ec/0x3e4
| kthread+0x120/0x124
| ret_from_fork+0x10/0x20
The obvious fix is to move the call to macb_set_tx_clk() out of the
protected area. This seems safe as rx and tx are both disabled anyway at
this point.
It is however not entirely clear what the spinlock shall protect. It
could be the read-modify-write access to the NCFGR register, but this
is accessed in macb_set_rx_mode() and macb_set_rxcsum_feature() as well
without holding the spinlock. It could also be the register accesses
done in mog_init_rings() or macb_init_buffers(), but again these
functions are called without holding the spinlock in macb_hresp_error_task().
The locking seems fishy in this driver and it might deserve another look
before this patch is applied.
Fixes: 633e98a711ac0 ("net: macb: use resolved link config in mac_link_up()")
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.kernel.org/r/20230908112913.1701766-1-s.hauer@pengutronix.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
MT7988 SoC support 3 NICs. Fix pse_port configuration in
mtk_flow_set_output_device routine if the traffic is offloaded to eth2.
Rely on mtk_pse_port definitions.
Fixes: 88efedf517e6 ("net: ethernet: mtk_eth_soc: enable nft hw flowtable_offload for MT7988 SoC")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Variable dma_addr in function mtk_poll_rx can be uninitialized on
some of the error paths. In practise this doesn't matter, even random
data present in uninitialized stack memory can safely be used in the
way it happens in the error path.
However, in order to make Smatch happy make sure the variable is
always initialized.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
According to the document of napi, there is no rx process when the
budget is 0. Therefore, r8152_poll() has to return 0 directly when the
budget is equal to 0.
Fixes: d2187f8e4454 ("r8152: divide the tx and rx bottom functions")
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Currently, when we add the first sja1105 port to a bridge with
vlan_filtering 1, then we sometimes see this output:
sja1105 spi2.2: port 4 failed to read back entry for be:79:b4:9e:9e:96 vid 3088: -ENOENT
sja1105 spi2.2: Reset switch and programmed static config. Reason: VLAN filtering
sja1105 spi2.2: port 0 failed to add be:79:b4:9e:9e:96 vid 0 to fdb: -2
It is because sja1105_fdb_add() runs from the dsa_owq which is no longer
serialized with switch resets since it dropped the rtnl_lock() in the
blamed commit.
Either performing the FDB accesses before the reset, or after the reset,
is equally fine, because sja1105_static_fdb_change() backs up those
changes in the static config, but FDB access during reset isn't ok.
Make sja1105_static_config_reload() take the fdb_lock to fix that.
Fixes: 0faf890fc519 ("net: dsa: drop rtnl_lock from dsa_slave_switchdev_event_work")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
sja1105_fdb_add() runs from the dsa_owq, and sja1105_port_mcast_flood()
runs from switchdev_deferred_process_work(). Prior to the blamed commit,
they used to be indirectly serialized through the rtnl_lock(), which
no longer holds true because dsa_owq dropped that.
So, it is now possible that we traverse the static config BLK_IDX_L2_LOOKUP
elements concurrently compared to when we change them, in
sja1105_static_fdb_change(). That is not ideal, since it might result in
data corruption.
Introduce a mutex which serializes accesses to the hardware FDB and to
the static config elements for the L2 Address Lookup table.
I can't find a good reason to add locking around sja1105_fdb_dump().
I'll add it later if needed.
Fixes: 0faf890fc519 ("net: dsa: drop rtnl_lock from dsa_slave_switchdev_event_work")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
entry
The commit cited in Fixes: did 2 things: it refactored the read-back
polling from sja1105_dynamic_config_read() into a new function,
sja1105_dynamic_config_wait_complete(), and it called that from
sja1105_dynamic_config_write() too.
What is problematic is the refactoring.
The refactored code from sja1105_dynamic_config_poll_valid() works like
the previous one, but the problem is that it uses another packed_buf[]
SPI buffer, and there was code at the end of sja1105_dynamic_config_read()
which was relying on the read-back packed_buf[]:
/* Don't dereference possibly NULL pointer - maybe caller
* only wanted to see whether the entry existed or not.
*/
if (entry)
ops->entry_packing(packed_buf, entry, UNPACK);
After the change, the packed_buf[] that this code sees is no longer the
entry read back from hardware, but the original entry that the caller
passed to the sja1105_dynamic_config_read(), packed into this buffer.
This difference is the most notable with the SJA1105_SEARCH uses from
sja1105pqrs_fdb_add() - used for both fdb and mdb. There, we have logic
added by commit 728db843df88 ("net: dsa: sja1105: ignore the FDB entry
for unknown multicast when adding a new address") to figure out whether
the address we're trying to add matches on any existing hardware entry,
with the exception of the catch-all multicast address.
That logic was broken, because with sja1105_dynamic_config_read() not
working properly, it doesn't return us the entry read back from
hardware, but the entry that we passed to it. And, since for multicast,
a match will always exist, it will tell us that any mdb entry already
exists at index=0 L2 Address Lookup table. It is index=0 because the
caller doesn't know the index - it wants to find it out, and
sja1105_dynamic_config_read() does:
if (index < 0) { // SJA1105_SEARCH
/* Avoid copying a signed negative number to an u64 */
cmd.index = 0; // <- this
cmd.search = true;
} else {
cmd.index = index;
cmd.search = false;
}
So, to the caller of sja1105_dynamic_config_read(), the returned info
looks entirely legit, and it will add all mdb entries to FDB index 0.
There, they will always overwrite each other (not to mention,
potentially they can also overwrite a pre-existing bridge fdb entry),
and the user-visible impact will be that only the last mdb entry will be
forwarded as it should. The others won't (will be flooded or dropped,
depending on the egress flood settings).
Fixing is a bit more complicated, and involves either passing the same
packed_buf[] to sja1105_dynamic_config_wait_complete(), or moving all
the extra processing on the packed_buf[] to
sja1105_dynamic_config_wait_complete(). I've opted for the latter,
because it makes sja1105_dynamic_config_wait_complete() a bit more
self-contained.
Fixes: df405910ab9f ("net: dsa: sja1105: wait for dynamic config command completion on writes too")
Reported-by: Yanan Yang <yanan.yang@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
sja1105_dynamic_config_poll_valid()
Currently, sja1105_dynamic_config_wait_complete() returns either 0 or
-ETIMEDOUT, because it just looks at the read_poll_timeout() return code.
There will be future changes which move some more checks to
sja1105_dynamic_config_poll_valid(). It is important that we propagate
their exact return code (-ENOENT, -EINVAL), because callers of
sja1105_dynamic_config_read() depend on them.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Commit 4d9423549501 ("net: dsa: sja1105: offload bridge port flags to
device") has partially hidden some multicast entries from showing up in
the "bridge fdb show" output, but it wasn't enough. Addresses which are
added through "bridge mdb add" still show up. Hide them all.
Fixes: 291d1e72b756 ("net: dsa: sja1105: Add support for FDB and MDB management")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Currently, when a new fdb entry is added (with both ports of the
ADIN2111 bridged), the driver configures the MAC filters for the wrong
port, which results in the forwarding being done by the host, and not
actually hardware offloaded.
The ADIN2111 offloads the forwarding by setting filters on the
destination MAC address of incoming frames. Based on these, they may be
routed to the other port. Thus, if a frame has to be forwarded from port
1 to port 2, the required configuration for the ADDR_FILT_UPRn register
should set the APPLY2PORT1 bit (instead of APPLY2PORT2, as it's
currently the case).
Fixes: bc93e19d088b ("net: ethernet: adi: Add ADIN1110 support")
Signed-off-by: Ciprian Regus <ciprian.regus@analog.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
mtk_hwlro_get_fdir_all()
rule_locs is allocated in ethtool_get_rxnfc and the size is determined by
rule_cnt from user space. So rule_cnt needs to be check before using
rule_locs to avoid NULL pointer dereference.
Fixes: 7aab747e5563 ("net: ethernet: mediatek: add ethtool functions to configure RX flows of HW LRO")
Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
rules is allocated in ethtool_get_rxnfc and the size is determined by
rule_cnt from user space. So rule_cnt needs to be check before using
rules to avoid OOB writing or NULL pointer dereference.
Fixes: 90b509b39ac9 ("net: mvpp2: cls: Add Classification offload support")
Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
Reviewed-by: Marcin Wojtas <mw@semihalf.com>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
rule_locs is allocated in ethtool_get_rxnfc and the size is determined by
rule_cnt from user space. So rule_cnt needs to be check before using
rule_locs to avoid OOB writing or NULL pointer dereference.
Fixes: c5d511c49587 ("net: bcmasp: Add support for wake on net filters")
Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Setting ethtool -C eth0 tx-usecs 0 is supposed to disable the use of the
coalescing timer but currently it gets programmed with zero delay
instead.
Disable the use of the coalescing timer if tx-usecs is zero by
preventing it from being restarted. Note that to keep things simple we
don't start/stop the timer when the coalescing settings are changed, but
just let that happen on the next transmit or timer expiry.
Fixes: 8fce33317023 ("net: stmmac: Rework coalesce timer and fix multi-queue races")
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The access to page pool `cache' array and the `count' variable
is not locked. Page pool cache access is fine as long as there
is only one consumer per pool.
octeontx2 driver fills in rx buffers from page pool in NAPI context.
If system is stressed and could not allocate buffers, refiiling work
will be delegated to a delayed workqueue. This means that there are
two cosumers to the page pool cache.
Either workqueue or IRQ/NAPI can be run on other CPU. This will lead
to lock less access, hence corruption of cache pool indexes.
To fix this issue, NAPI is rescheduled from workqueue context to refill
rx buffers.
Fixes: b2e3406a38f0 ("octeontx2-pf: Add support for page pool")
Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Inject fault When select CONFIG_VCAP_KUNIT_TEST, the below memory leak
occurs. If kzalloc() for duprule succeeds, but the following
kmemdup() fails, the duprule, ckf and caf memory will be leaked. So kfree
them in the error path.
unreferenced object 0xffff122744c50600 (size 192):
comm "kunit_try_catch", pid 346, jiffies 4294896122 (age 911.812s)
hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 1e 00 00 00 2c 01 00 00 .'..........,...
00 00 00 00 00 00 00 00 18 06 c5 44 27 12 ff ff ...........D'...
backtrace:
[<00000000394b0db8>] __kmem_cache_alloc_node+0x274/0x2f8
[<0000000001bedc67>] kmalloc_trace+0x38/0x88
[<00000000b0612f98>] vcap_dup_rule+0x50/0x460
[<000000005d2d3aca>] vcap_add_rule+0x8cc/0x1038
[<00000000eef9d0f8>] test_vcap_xn_rule_creator.constprop.0.isra.0+0x238/0x494
[<00000000cbda607b>] vcap_api_rule_remove_in_front_test+0x1ac/0x698
[<00000000c8766299>] kunit_try_run_case+0xe0/0x20c
[<00000000c4fe9186>] kunit_generic_run_threadfn_adapter+0x50/0x94
[<00000000f6864acf>] kthread+0x2e8/0x374
[<0000000022e639b3>] ret_from_fork+0x10/0x20
Fixes: 814e7693207f ("net: microchip: vcap api: Add a storage state to a VCAP rule")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
for_each_available_child_of_node performs an of_node_get
on each iteration, so a break out of the loop requires an
of_node_put.
This was done using the Coccinelle semantic patch
iterators/for_each_child.cocci
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Pull networking updates from Jakub Kicinski:
"Including fixes from netfilter and bpf.
Current release - regressions:
- eth: stmmac: fix failure to probe without MAC interface specified
Current release - new code bugs:
- docs: netlink: fix missing classic_netlink doc reference
Previous releases - regressions:
- deal with integer overflows in kmalloc_reserve()
- use sk_forward_alloc_get() in sk_get_meminfo()
- bpf_sk_storage: fix the missing uncharge in sk_omem_alloc
- fib: avoid warn splat in flow dissector after packet mangling
- skb_segment: call zero copy functions before using skbuff frags
- eth: sfc: check for zero length in EF10 RX prefix
Previous releases - always broken:
- af_unix: fix msg_controllen test in scm_pidfd_recv() for
MSG_CMSG_COMPAT
- xsk: fix xsk_build_skb() dereferencing possible ERR_PTR()
- netfilter:
- nft_exthdr: fix non-linear header modification
- xt_u32, xt_sctp: validate user space input
- nftables: exthdr: fix 4-byte stack OOB write
- nfnetlink_osf: avoid OOB read
- one more fix for the garbage collection work from last release
- igmp: limit igmpv3_newpack() packet size to IP_MAX_MTU
- bpf, sockmap: fix preempt_rt splat when using raw_spin_lock_t
- handshake: fix null-deref in handshake_nl_done_doit()
- ip: ignore dst hint for multipath routes to ensure packets are
hashed across the nexthops
- phy: micrel:
- correct bit assignments for cable test errata
- disable EEE according to the KSZ9477 errata
Misc:
- docs/bpf: document compile-once-run-everywhere (CO-RE) relocations
- Revert "net: macsec: preserve ingress frame ordering", it appears
to have been developed against an older kernel, problem doesn't
exist upstream"
* tag 'net-6.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (95 commits)
net: enetc: distinguish error from valid pointers in enetc_fixup_clear_rss_rfs()
Revert "net: team: do not use dynamic lockdep key"
net: hns3: remove GSO partial feature bit
net: hns3: fix the port information display when sfp is absent
net: hns3: fix invalid mutex between tc qdisc and dcb ets command issue
net: hns3: fix debugfs concurrency issue between kfree buffer and read
net: hns3: fix byte order conversion issue in hclge_dbg_fd_tcam_read()
net: hns3: Support query tx timeout threshold by debugfs
net: hns3: fix tx timeout issue
net: phy: Provide Module 4 KSZ9477 errata (DS80000754C)
netfilter: nf_tables: Unbreak audit log reset
netfilter: ipset: add the missing IP_SET_HASH_WITH_NET0 macro for ip_set_hash_netportnet.c
netfilter: nft_set_rbtree: skip sync GC for new elements in this transaction
netfilter: nf_tables: uapi: Describe NFTA_RULE_CHAIN_ID
netfilter: nfnetlink_osf: avoid OOB read
netfilter: nftables: exthdr: fix 4-byte stack OOB write
selftests/bpf: Check bpf_sk_storage has uncharged sk_omem_alloc
bpf: bpf_sk_storage: Fix the missing uncharge in sk_omem_alloc
bpf: bpf_sk_storage: Fix invalid wait context lockdep report
s390/bpf: Pass through tail call counter in trampolines
...
|
|
enetc_psi_create() returns an ERR_PTR() or a valid station interface
pointer, but checking for the non-NULL quality of the return code blurs
that difference away. So if enetc_psi_create() fails, we call
enetc_psi_destroy() when we shouldn't. This will likely result in
crashes, since enetc_psi_create() cleans up everything after itself when
it returns an ERR_PTR().
Fixes: f0168042a212 ("net: enetc: reimplement RFS/RSS memory clearing as PCI quirk")
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/netdev/582183ef-e03b-402b-8e2d-6d9bb3c83bd9@moroto.mountain/
Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://lore.kernel.org/r/20230906141609.247579-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
This reverts commit 39285e124edbc752331e98ace37cc141a6a3747a.
Looks like the change has unintended consequences in exposing
objects before they are initialized. Let's drop this patch
and try again in net-next.
Reported-by: syzbot+44ae022028805f4600fc@syzkaller.appspotmail.com
Fixes: 39285e124edb ("net: team: do not use dynamic lockdep key")
Link: https://lore.kernel.org/all/20230907103124.6adb7256@kernel.org/
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
HNS3 NIC does not support GSO partial packets segmentation. Actually tunnel
packets for example NvGRE packets segment offload and checksum offload is
already supported. There is no need to keep gso partial feature bit. So
this patch removes it.
Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
Signed-off-by: Jie Wang <wangjie125@huawei.com>
Signed-off-by: Jijie Shao <shaojijie@huawei.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
When sfp is absent or unidentified, the port type should be
displayed as PORT_OTHERS, rather than PORT_FIBRE.
Fixes: 88d10bd6f730 ("net: hns3: add support for multiple media type")
Signed-off-by: Yisen Zhuang <yisen.zhuang@huawei.com>
Signed-off-by: Jijie Shao <shaojijie@huawei.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
We hope that tc qdisc and dcb ets commands can not be used crosswise.
If we want to use any of the commands to configure tc,
We must use the other command to clear the existing configuration.
However, when we configure a single tc with tc qdisc,
we can still configure it with dcb ets.
Because we use mqprio_active as the tag of tc qdisc configuration,
but with dcb ets, we do not check mqprio_active.
This patch fix this issue by check mqprio_active before
executing the dcb ets command. and add dcb_ets_active to
replace HCLGE_FLAG_DCB_ENABLE and HCLGE_FLAG_MQPRIO_ENABLE
at the hclge layer,
Fixes: cacde272dd00 ("net: hns3: Add hclge_dcb module for the support of DCB feature")
Signed-off-by: Jijie Shao <shaojijie@huawei.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Now in hns3_dbg_uninit(), there may be concurrency between
kfree buffer and read, it may result in memory error.
Moving debugfs_remove_recursive() in front of kfree buffer to ensure
they don't happen at the same time.
Fixes: 5e69ea7ee2a6 ("net: hns3: refactor the debugfs process")
Signed-off-by: Hao Chen <chenhao418@huawei.com>
Signed-off-by: Jijie Shao <shaojijie@huawei.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
req1->tcam_data is defined as "u8 tcam_data[8]", and we convert it as
(u32 *) without considerring byte order conversion,
it may result in printing wrong data for tcam_data.
Convert tcam_data to (__le32 *) first to fix it.
Fixes: b5a0b70d77b9 ("net: hns3: refactor dump fd tcam of debugfs")
Signed-off-by: Hao Chen <chenhao418@huawei.com>
Signed-off-by: Jijie Shao <shaojijie@huawei.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
support query tx timeout threshold by debugfs
Signed-off-by: Jijie Shao <shaojijie@huawei.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Currently, the driver knocks the ring doorbell before updating
the ring->last_to_use in tx flow. if the hardware transmiting
packet and napi poll scheduling are fast enough, it may get
the old ring->last_to_use in drivers' napi poll.
In this case, the driver will think the tx is not completed, and
return directly without clear the flag __QUEUE_STATE_STACK_XOFF,
which may cause tx timeout.
Fixes: 20d06ca2679c ("net: hns3: optimize the tx clean process")
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Jijie Shao <shaojijie@huawei.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The KSZ9477 errata points out (in 'Module 4') the link up/down problems
when EEE (Energy Efficient Ethernet) is enabled in the device to which
the KSZ9477 tries to auto negotiate.
The suggested workaround is to clear advertisement of EEE for PHYs in
this chip driver.
To avoid regressions with other switch ICs the new MICREL_NO_EEE flag
has been introduced.
Moreover, the in-register disablement of MMD_DEVICE_ID_EEE_ADV.MMD_EEE_ADV
MMD register is removed, as this code is both; now executed too late
(after previous rework of the PHY and DSA for KSZ switches) and not
required as setting all members of eee_broken_modes bit field prevents
the KSZ9477 from advertising EEE.
Fixes: 69d3b36ca045 ("net: dsa: microchip: enable EEE support") # for KSZ9477
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Tested-by: Oleksij Rempel <o.rempel@pengutronix.de> # Confirmed disabled EEE with oscilloscope.
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://lore.kernel.org/r/20230905093315.784052-1-lukma@denx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The blamed commit left this delta behind:
struct sja1105_cbs_entry {
- u64 port;
- u64 prio;
+ u64 port; /* Not used for SJA1110 */
+ u64 prio; /* Not used for SJA1110 */
u64 credit_hi;
u64 credit_lo;
u64 send_slope;
u64 idle_slope;
};
but did not actually implement tc-cbs offload fully for the new switch.
The offload is accepted, but it doesn't work.
The difference compared to earlier switch generations is that now, the
table of CBS shapers is sparse, because there are many more shapers, so
the mapping between a {port, prio} and a table index is static, rather
than requiring us to store the port and prio into the sja1105_cbs_entry.
So, the problem is that the code programs the CBS shaper parameters at a
dynamic table index which is incorrect.
All that needs to be done for SJA1110 CBS shapers to work is to bypass
the logic which allocates shapers in a dense manner, as for SJA1105, and
use the fixed mapping instead.
Fixes: 3e77e59bf8cf ("net: dsa: sja1105: add support for the SJA1110 switch family")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
After running command [2] too many times in a row:
[1] $ tc qdisc add dev sw2p0 root handle 1: mqprio num_tc 8 \
map 0 1 2 3 4 5 6 7 queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0
[2] $ tc qdisc replace dev sw2p0 parent 1:1 cbs offload 1 \
idleslope 120000 sendslope -880000 locredit -1320 hicredit 180
(aka more than priv->info->num_cbs_shapers times)
we start seeing the following error message:
Error: Specified device failed to setup cbs hardware offload.
This comes from the fact that ndo_setup_tc(TC_SETUP_QDISC_CBS) presents
the same API for the qdisc create and replace cases, and the sja1105
driver fails to distinguish between the 2. Thus, it always thinks that
it must allocate the same shaper for a {port, queue} pair, when it may
instead have to replace an existing one.
Fixes: 4d7525085a9b ("net: dsa: sja1105: offload the Credit-Based Shaper qdisc")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
More careful measurement of the tc-cbs bandwidth shows that the stream
bandwidth (effectively idleslope) increases, there is a larger and
larger discrepancy between the rate limit obtained by the software
Qdisc, and the rate limit obtained by its offloaded counterpart.
The discrepancy becomes so large, that e.g. at an idleslope of 40000
(40Mbps), the offloaded cbs does not actually rate limit anything, and
traffic will pass at line rate through a 100 Mbps port.
The reason for the discrepancy is that the hardware documentation I've
been following is incorrect. UM11040.pdf (for SJA1105P/Q/R/S) states
about IDLE_SLOPE that it is "the rate (in unit of bytes/sec) at which
the credit counter is increased".
Cross-checking with UM10944.pdf (for SJA1105E/T) and UM11107.pdf
(for SJA1110), the wording is different: "This field specifies the
value, in bytes per second times link speed, by which the credit counter
is increased".
So there's an extra scaling for link speed that the driver is currently
not accounting for, and apparently (empirically), that link speed is
expressed in Kbps.
I've pondered whether to pollute the sja1105_mac_link_up()
implementation with CBS shaper reprogramming, but I don't think it is
worth it. IMO, the UAPI exposed by tc-cbs requires user space to
recalculate the sendslope anyway, since the formula for that depends on
port_transmit_rate (see man tc-cbs), which is not an invariant from tc's
perspective.
So we use the offload->sendslope and offload->idleslope to deduce the
original port_transmit_rate from the CBS formula, and use that value to
scale the offload->sendslope and offload->idleslope to values that the
hardware understands.
Some numerical data points:
40Mbps stream, max interfering frame size 1500, port speed 100M
---------------------------------------------------------------
tc-cbs parameters:
idleslope 40000 sendslope -60000 locredit -900 hicredit 600
which result in hardware values:
Before (doesn't work) After (works)
credit_hi 600 600
credit_lo 900 900
send_slope 7500000 75
idle_slope 5000000 50
40Mbps stream, max interfering frame size 1500, port speed 1G
-------------------------------------------------------------
tc-cbs parameters:
idleslope 40000 sendslope -960000 locredit -1440 hicredit 60
which result in hardware values:
Before (doesn't work) After (works)
credit_hi 60 60
credit_lo 1440 1440
send_slope 120000000 120
idle_slope 5000000 5
5.12Mbps stream, max interfering frame size 1522, port speed 100M
-----------------------------------------------------------------
tc-cbs parameters:
idleslope 5120 sendslope -94880 locredit -1444 hicredit 77
which result in hardware values:
Before (doesn't work) After (works)
credit_hi 77 77
credit_lo 1444 1444
send_slope 11860000 118
idle_slope 640000 6
Tested on SJA1105T, SJA1105S and SJA1110A, at 1Gbps and 100Mbps.
Fixes: 4d7525085a9b ("net: dsa: sja1105: offload the Credit-Based Shaper qdisc")
Reported-by: Yanan Yang <yanan.yang@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue
Tony Nguyen says:
====================
Change MIN_TXD and MIN_RXD to allow set rx/tx value between 64 and 80
Olga Zaborska says:
Change the minimum value of RX/TX descriptors to 64 to enable setting the rx/tx
value between 64 and 80. All igb, igbvf and igc devices can use as low as 64
descriptors.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
ACL flow table is required in switchdev mode when metadata is enabled,
driver creates such table when loading each vport. However, not every
vport is loaded in switchdev mode. Such as ECPF if it's the eswitch manager.
In this case, ACL flow table is still needed.
To make it modularized, create ACL flow table for eswitch manager as
default and skip such operations when loading manager vport.
Also, there is no need to load the eswitch manager vport in switchdev mode.
This means there is no need to load it on regular connect-x HCAs where
the PF is the eswitch manager. This will avoid creating duplicate ACL
flow table for host PF vport.
Fixes: 29bcb6e4fe70 ("net/mlx5e: E-Switch, Use metadata for vport matching in send-to-vport rules")
Fixes: eb8e9fae0a22 ("mlx5/core: E-Switch, Allocate ECPF vport if it's an eswitch manager")
Fixes: 5019833d661f ("net/mlx5: E-switch, Introduce helper function to enable/disable vports")
Signed-off-by: Bodong Wang <bodong@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In the cited commit, the mirred devices are recorded and checked while
parsing the actions. In order to avoid system crash, the duplicate
action in a single rule is not allowed.
But the rule is actually break down into several FTEs in different
tables, for either mirroring, or the specified types of actions which
use post action infrastructure.
It will reject certain action list by mistake, for example:
actions:enp8s0f0_1,set(ipv4(ttl=63)),enp8s0f0_0,enp8s0f0_1.
Here the rule is split to two FTEs because of pedit action.
To fix this issue, when parsing the rule actions, reset if_count to
clear the mirred devices array if the rule is split to multiple
FTEs, and then the duplicate checking is restarted.
Fixes: 554fe75c1b3f ("net/mlx5e: Avoid duplicating rule destinations")
Signed-off-by: Jianbo Liu <jianbol@nvidia.com>
Reviewed-by: Vlad Buslov <vladbu@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
team interface has used a dynamic lockdep key to avoid false-positive
lockdep deadlock detection. Virtual interfaces such as team usually
have their own lock for protecting private data.
These interfaces can be nested.
team0
|
team1
Each interface's lock is actually different(team0->lock and team1->lock).
So,
mutex_lock(&team0->lock);
mutex_lock(&team1->lock);
mutex_unlock(&team1->lock);
mutex_unlock(&team0->lock);
The above case is absolutely safe. But lockdep warns about deadlock.
Because the lockdep understands these two locks are same. This is a
false-positive lockdep warning.
So, in order to avoid this problem, the team interfaces started to use
dynamic lockdep key. The false-positive problem was fixed, but it
introduced a new problem.
When the new team virtual interface is created, it registers a dynamic
lockdep key(creates dynamic lockdep key) and uses it. But there is the
limitation of the number of lockdep keys.
So, If so many team interfaces are created, it consumes all lockdep keys.
Then, the lockdep stops to work and warns about it.
In order to fix this problem, team interfaces use the subclass instead
of the dynamic key. So, when a new team interface is created, it doesn't
register(create) a new lockdep, but uses existed subclass key instead.
It is already used by the bonding interface for a similar case.
As the bonding interface does, the subclass variable is the same as
the 'dev->nested_level'. This variable indicates the depth in the stacked
interface graph.
The 'dev->nested_level' is protected by RTNL and RCU.
So, 'mutex_lock_nested()' for 'team->lock' requires RTNL or RCU.
In the current code, 'team->lock' is usually acquired under RTNL, there is
no problem with using 'dev->nested_level'.
The 'team_nl_team_get()' and The 'lb_stats_refresh()' functions acquire
'team->lock' without RTNL.
But these don't iterate their own ports nested so they don't need nested
lock.
Reproducer:
for i in {0..1000}
do
ip link add team$i type team
ip link add dummy$i master team$i type dummy
ip link set dummy$i up
ip link set team$i up
done
Splat looks like:
BUG: MAX_LOCKDEP_ENTRIES too low!
turning off the locking correctness validator.
Please attach the output of /proc/lock_stat to the bug report
CPU: 0 PID: 4104 Comm: ip Not tainted 6.5.0-rc7+ #45
Call Trace:
<TASK>
dump_stack_lvl+0x64/0xb0
add_lock_to_list+0x30d/0x5e0
check_prev_add+0x73a/0x23a0
...
sock_def_readable+0xfe/0x4f0
netlink_broadcast+0x76b/0xac0
nlmsg_notify+0x69/0x1d0
dev_open+0xed/0x130
...
Reported-by: syzbot+9bbbacfbf1e04d5221f7@syzkaller.appspotmail.com
Fixes: 369f61bee0f5 ("team: fix nested locking lockdep warning")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|