| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
[ Upstream commit a49d2a2c37a6252c41cbdd505f9d1c58d5a3817a ]
The max_adj field in ptp_clock_info tells userspace how much the PHC
clock frequency can be adjusted. ptp4l reads this and will never request
a correction larger than max_adj.
On both sparx5 and lan969x the clock offset may never converge because
the servo needs a frequency correction larger than the current max_adj
of 200000 (200 ppm) allows. The servo rails at the max and the offset
stays in the tens of microseconds.
The hardware has no inherent max adjustment limit; frequency correction
is done by writing a 64-bit clock period increment to CLK_PER_CFG, and
the register has plenty of range. The 200000 value was just an overly
conservative software limit. The max_adj is shared between sparx5 and
lan969x, and the increased value is safe for both.
Fix this by increasing max_adj to 10000000 (10000 ppm), giving the
servo sufficient headroom.
Fixes: 0933bd04047c ("net: sparx5: Add support for ptp clocks")
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260212-sparx5-ptp-max-adj-v2-v1-1-06b200e50ce3@microchip.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 6c28aa8dfdf24f554d4c5d4ff7d723a95360d94a ]
DWRR (Deficit Weighted Round Robin) scheduling distributes bandwidth
across traffic classes based on per-queue cost values, where lower cost
means higher bandwidth share.
The SPX5_DWRR_COST_MAX constant is 63 (6 bits) but the hardware
register field HSCH_DWRR_ENTRY_DWRR_COST is GENMASK(24, 20), only
5 bits wide (max 31). This causes sparx5_weight_to_hw_cost() to
compute cost values that silently overflow via FIELD_PREP, resulting
in incorrect scheduling weights.
Set SPX5_DWRR_COST_MAX to 31 to match the hardware register width.
Fixes: 211225428d65 ("net: microchip: sparx5: add support for offloading ets qdisc")
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260210-sparx5-fix-dwrr-cost-max-v1-1-58fbdbc25652@microchip.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 8a8f3f4991761a70834fe6719d09e9fd338a766e upstream.
The driver allocates ring elements using GFP_DMA flags. There is
no dependency from LAN743x hardware on memory allocation should be
in DMA_ZONE. Hence modifying the flags to use only GFP_ATOMIC. This
is consistent with other callers of lan743x_rx_init_ring_element().
Reported-by: Zhang, Liyin(CN) <Liyin.Zhang.CN@windriver.com>
Signed-off-by: Thangaraj Samynathan <thangaraj.s@microchip.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250415044509.6695-1-thangaraj.s@microchip.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 9780f535f8e0f20b4632b5a173ead71aa8f095d2 ]
To initialize the taprio block in lan966x, it is required to configure
the register REVISIT_DLY. The purpose of this register is to set the
delay before revisit the next gate and the value of this register depends
on the system clock. The problem is that the we calculated wrong the value
of the system clock period in picoseconds. The actual system clock is
~165.617754MHZ and this correspond to a period of 6038 pico seconds and
not 15125 as currently set.
Fixes: e462b2717380b4 ("net: lan966x: Add offload support for taprio")
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20251121061411.810571-1-horatiu.vultur@microchip.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 0216721ce71252f60d89af49c8dff613358058d3 ]
The following warning was seen when we try to connect using ssh to the device.
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:575
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 104, name: dropbear
preempt_count: 1, expected: 0
INFO: lockdep is turned off.
CPU: 0 UID: 0 PID: 104 Comm: dropbear Tainted: G W 6.18.0-rc2-00399-g6f1ab1b109b9-dirty #530 NONE
Tainted: [W]=WARN
Hardware name: Generic DT based system
Call trace:
unwind_backtrace from show_stack+0x10/0x14
show_stack from dump_stack_lvl+0x7c/0xac
dump_stack_lvl from __might_resched+0x16c/0x2b0
__might_resched from __mutex_lock+0x64/0xd34
__mutex_lock from mutex_lock_nested+0x1c/0x24
mutex_lock_nested from lan966x_stats_get+0x5c/0x558
lan966x_stats_get from dev_get_stats+0x40/0x43c
dev_get_stats from dev_seq_printf_stats+0x3c/0x184
dev_seq_printf_stats from dev_seq_show+0x10/0x30
dev_seq_show from seq_read_iter+0x350/0x4ec
seq_read_iter from seq_read+0xfc/0x194
seq_read from proc_reg_read+0xac/0x100
proc_reg_read from vfs_read+0xb0/0x2b0
vfs_read from ksys_read+0x6c/0xec
ksys_read from ret_fast_syscall+0x0/0x1c
Exception stack(0xf0b11fa8 to 0xf0b11ff0)
1fa0: 00000001 00001000 00000008 be9048d8 00001000 00000001
1fc0: 00000001 00001000 00000008 00000003 be905920 0000001e 00000000 00000001
1fe0: 0005404c be9048c0 00018684 b6ec2cd8
It seems that we are using a mutex in a atomic context which is wrong.
Change the mutex with a spinlock.
Fixes: 12c2d0a5b8e2 ("net: lan966x: add ethtool configuration and statistics")
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20251105074955.1766792-1-horatiu.vultur@microchip.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 6287982aa54946449bccff3e6488d3a15e458392 ]
LAN969x switchdev support depends on the SparX-5 core,so make it selectable
for ARCH_LAN969X.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Reviewed-by: Daniel Machon <daniel.machon@microchip.com>
Link: https://patch.msgid.link/20250917110106.55219-1-robert.marko@sartura.hr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
lan743x_ptp_io_event_clock_get()
[ Upstream commit e353b0854d3a1a31cb061df8d022fbfea53a0f24 ]
Before calling lan743x_ptp_io_event_clock_get(), the 'channel' value
is checked against the maximum value of PCI11X1X_PTP_IO_MAX_CHANNELS(8).
This seems correct and aligns with the PTP interrupt status register
(PTP_INT_STS) specifications.
However, lan743x_ptp_io_event_clock_get() writes to ptp->extts[] with
only LAN743X_PTP_N_EXTTS(4) elements, using channel as an index:
lan743x_ptp_io_event_clock_get(..., u8 channel,...)
{
...
/* Update Local timestamp */
extts = &ptp->extts[channel];
extts->ts.tv_sec = sec;
...
}
To avoid an out-of-bounds write and utilize all the supported GPIO
inputs, set LAN743X_PTP_N_EXTTS to 8.
Detected using the static analysis tool - Svace.
Fixes: 60942c397af6 ("net: lan743x: Add support for PTP-IO Event Input External Timestamp (extts)")
Signed-off-by: Alexey Kodanev <aleksei.kodanev@bell-sw.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Acked-by: Rengarajan S <rengarajan.s@microchip.com>
Link: https://patch.msgid.link/20250616113743.36284-1-aleksei.kodanev@bell-sw.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit b1de3c0df7abc41dc41862c0b08386411f2799d7 ]
The PTP_CMD_CTL is a self clearing register which controls the PTP clock
values. In the current implementation driver waits for a duration of 20
sec in case of HW failure to clear the PTP_CMD_CTL register bit. This
timeout of 20 sec is very long to recognize a HW failure, as it is
typically cleared in one clock(<16ns). Hence reducing the timeout to 1 sec
would be sufficient to conclude if there is any HW failure observed. The
usleep_range will sleep somewhere between 1 msec to 20 msec for each
iteration. By setting the PTP_CMD_CTL_TIMEOUT_CNT to 50 the max timeout
is extended to 1 sec.
Signed-off-by: Rengarajan S <rengarajan.s@microchip.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://lore.kernel.org/r/20240502050300.38689-1-rengarajan.s@microchip.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Stable-dep-of: e353b0854d3a ("net: lan743x: fix potential out-of-bounds write in lan743x_ptp_io_event_clock_get()")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 3b9935586a9b54d2da27901b830d3cf46ad66a1e ]
Maximum OTP and EEPROM size for hearthstone PCI1xxxx devices are 8 Kb
and 64 Kb respectively. Adjust max size definitions and return correct
EEPROM length based on device. Also prevent out-of-bound read/write.
Signed-off-by: Rengarajan S <rengarajan.s@microchip.com>
Link: https://patch.msgid.link/20250523173326.18509-1-rengarajan.s@microchip.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 27eab4c644236a9324084a70fe79e511cbd07393 ]
When running these commands on DUT (and similar at the other end)
ip link set dev eth0 up
ip link add link eth0 name eth0.10 type vlan id 10
ip addr add 10.0.0.1/24 dev eth0.10
ip link set dev eth0.10 up
ping 10.0.0.2
The ping will fail.
The reason why is failing is because, the network interfaces for lan966x
have a flag saying that the HW can insert the vlan tags into the
frames(NETIF_F_HW_VLAN_CTAG_TX). Meaning that the frames that are
transmitted don't have the vlan tag inside the skb data, but they have
it inside the skb. We already get that vlan tag and put it in the IFH
but the problem is that we don't configure the HW to rewrite the frame
when the interface is in host mode.
The fix consists in actually configuring the HW to insert the vlan tag
if it is different than 0.
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Fixes: 6d2c186afa5d ("net: lan966x: Add vlan support.")
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Link: https://patch.msgid.link/20250528093619.3738998-1-horatiu.vultur@microchip.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 68927eb52d0af04863584930db06075d2610e194 ]
rename the function to lan743x_hw_reset_phy to better describe it
operation.
Fixes: 23f0703c125be ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Thangaraj Samynathan <thangaraj.s@microchip.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20250526053048.287095-2-thangaraj.s@microchip.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 57ee9584fd8606deef66d7b65fa4dcf94f6843aa ]
When enabling 1-step timestamping for ptp frames that are over udpv4 or
udpv6 then the inserted timestamp is added at the wrong offset in the
frame, meaning that will modify the frame at the wrong place, so the
frame will be malformed.
To fix this, the HW needs to know which kind of frame it is to know
where to insert the timestamp. For that there is a field in the IFH that
says the PDU_TYPE, which can be NONE which is the default value,
IPV4 or IPV6. Therefore make sure to set the PDU_TYPE so the HW knows
where to insert the timestamp.
Like I mention before the issue is not seen with L2 frames because by
default the PDU_TYPE has a value of 0, which represents the L2 frames.
Fixes: 77eecf25bd9d2f ("net: lan966x: Update extraction/injection for timestamping")
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Link: https://patch.msgid.link/20250521124159.2713525-1-horatiu.vultur@microchip.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 293e38ff4e4c2ba53f3fd47d8a4a9f0f0414a7a6 ]
SGMII_CTRL register, which specifies the active interface, was not
properly restored when resuming from suspend. This led to incorrect
interface selection after resume particularly in scenarios involving
the FPGA.
To fix this:
- Move the SGMII_CTRL setup out of the probe function.
- Initialize the register in the hardware initialization helper function,
which is called during both device initialization and resume.
This ensures the interface configuration is consistently restored after
suspend/resume cycles.
Fixes: a46d9d37c4f4f ("net: lan743x: Add support for SGMII interface")
Signed-off-by: Thangaraj Samynathan <thangaraj.s@microchip.com>
Link: https://patch.msgid.link/20250516035719.117960-1-thangaraj.s@microchip.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 2d52e2e38b85c8b7bc00dca55c2499f46f8c8198 ]
Always map the `skb` to the LS descriptor. Previously skb was
mapped to EXT descriptor when the number of fragments is zero with
GSO enabled. Mapping the skb to EXT descriptor prevents it from
being freed, leading to a memory leak
Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Thangaraj Samynathan <thangaraj.s@microchip.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20250429052527.10031-1-thangaraj.s@microchip.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit ddd7ba006078a2bef5971b2dc5f8383d47f96207 ]
On port initialization, we configure the maximum frame length accepted
by the receive module associated with the port. This value is currently
written to the MAX_LEN field of the DEV10G_MAC_ENA_CFG register, when in
fact, it should be written to the DEV10G_MAC_MAXLEN_CFG register. Fix
this.
Fixes: 946e7fd5053a ("net: sparx5: add port module support")
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit f004f2e535e2b66ccbf5ac35f8eaadeac70ad7b7 ]
The FDMA handler is responsible for scheduling a NAPI poll, which will
eventually fetch RX packets from the FDMA queue. Currently, the FDMA
handler is run in a threaded context. For some reason, this kills
performance. Admittedly, I did not do a thorough investigation to see
exactly what causes the issue, however, I noticed that in the other
driver utilizing the same FDMA engine, we run the FDMA handler in hard
IRQ context.
Fix this performance issue, by running the FDMA handler in hard IRQ
context, not deferring any work to a thread.
Prior to this change, the RX UDP performance was:
Interval Transfer Bitrate Jitter
0.00-10.20 sec 44.6 MBytes 36.7 Mbits/sec 0.027 ms
After this change, the rx UDP performance is:
Interval Transfer Bitrate Jitter
0.00-9.12 sec 1.01 GBytes 953 Mbits/sec 0.020 ms
Fixes: 10615907e9b5 ("net: sparx5: switchdev: adding frame DMA functionality")
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit f164b296638d1eb1fb1c537e93ab5c8b49966546 ]
VCAP API unit tests fail randomly with errors such as
# vcap_api_iterator_init_test: EXPECTATION FAILED at drivers/net/ethernet/microchip/vcap/vcap_api_kunit.c:387
Expected 134 + 7 == iter.offset, but
134 + 7 == 141 (0x8d)
iter.offset == 17214 (0x433e)
# vcap_api_iterator_init_test: EXPECTATION FAILED at drivers/net/ethernet/microchip/vcap/vcap_api_kunit.c:388
Expected 5 == iter.reg_idx, but
iter.reg_idx == 702 (0x2be)
# vcap_api_iterator_init_test: EXPECTATION FAILED at drivers/net/ethernet/microchip/vcap/vcap_api_kunit.c:389
Expected 11 == iter.reg_bitpos, but
iter.reg_bitpos == 15 (0xf)
# vcap_api_iterator_init_test: pass:0 fail:1 skip:0 total:1
Comments in the code state that "A typegroup table ends with an all-zero
terminator". Add the missing terminators.
Some of the typegroups did have a terminator of ".offset = 0, .width = 0,
.value = 0,". Replace those terminators with "{ }" (no trailing ',') for
consistency and to excplicitly state "this is a terminator".
Fixes: 67d637516fa9 ("net: microchip: sparx5: Adding KUNIT test for the VCAP API")
Cc: Steen Hegelund <steen.hegelund@microchip.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Daniel Machon <daniel.machon@microchip.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20241119213202.2884639-1-linux@roeck-us.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 217a3d98d1e9891a8b1438a27dfbc64ddf01f691 upstream.
Commit a3c1e45156ad ("net: microchip: vcap: Fix use-after-free error in
kunit test") fixed the use-after-free error, but introduced below
memory leaks by removing necessary vcap_free_rule(), add it to fix it.
unreferenced object 0xffffff80ca58b700 (size 192):
comm "kunit_try_catch", pid 1215, jiffies 4294898264
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 00 04 0b cc 80 ff ff ff ................
backtrace (crc 9c09c3fe):
[<0000000052a0be73>] kmemleak_alloc+0x34/0x40
[<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4
[<0000000040a01b8d>] vcap_alloc_rule+0x3cc/0x9c4
[<000000003fe86110>] vcap_api_encode_rule_test+0x1ac/0x16b0
[<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac
[<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec
[<00000000c5d82c9a>] kthread+0x2e8/0x374
[<00000000f4287308>] ret_from_fork+0x10/0x20
unreferenced object 0xffffff80cc0b0400 (size 64):
comm "kunit_try_catch", pid 1215, jiffies 4294898265
hex dump (first 32 bytes):
80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X.....
39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9...............
backtrace (crc daf014e9):
[<0000000052a0be73>] kmemleak_alloc+0x34/0x40
[<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4
[<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528
[<00000000dfdb1e81>] vcap_api_encode_rule_test+0x224/0x16b0
[<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac
[<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec
[<00000000c5d82c9a>] kthread+0x2e8/0x374
[<00000000f4287308>] ret_from_fork+0x10/0x20
unreferenced object 0xffffff80cc0b0700 (size 64):
comm "kunit_try_catch", pid 1215, jiffies 4294898265
hex dump (first 32 bytes):
80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X.....
3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../......
backtrace (crc 8d877792):
[<0000000052a0be73>] kmemleak_alloc+0x34/0x40
[<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4
[<000000006eadfab7>] vcap_rule_add_action+0x2d0/0x52c
[<00000000323475d1>] vcap_api_encode_rule_test+0x4d4/0x16b0
[<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac
[<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec
[<00000000c5d82c9a>] kthread+0x2e8/0x374
[<00000000f4287308>] ret_from_fork+0x10/0x20
unreferenced object 0xffffff80cc0b0900 (size 64):
comm "kunit_try_catch", pid 1215, jiffies 4294898266
hex dump (first 32 bytes):
80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................
7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }...............
backtrace (crc 34181e56):
[<0000000052a0be73>] kmemleak_alloc+0x34/0x40
[<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4
[<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528
[<00000000991e3564>] vcap_val_rule+0xcf0/0x13e8
[<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0
[<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac
[<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec
[<00000000c5d82c9a>] kthread+0x2e8/0x374
[<00000000f4287308>] ret_from_fork+0x10/0x20
unreferenced object 0xffffff80cc0b0980 (size 64):
comm "kunit_try_catch", pid 1215, jiffies 4294898266
hex dump (first 32 bytes):
18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X.............
67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t.....
backtrace (crc 275fd9be):
[<0000000052a0be73>] kmemleak_alloc+0x34/0x40
[<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4
[<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528
[<000000001396a1a2>] test_add_def_fields+0xb0/0x100
[<000000006e7621f0>] vcap_val_rule+0xa98/0x13e8
[<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0
[<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac
[<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec
[<00000000c5d82c9a>] kthread+0x2e8/0x374
[<00000000f4287308>] ret_from_fork+0x10/0x20
......
Cc: stable@vger.kernel.org
Fixes: a3c1e45156ad ("net: microchip: vcap: Fix use-after-free error in kunit test")
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Link: https://patch.msgid.link/20241014121922.1280583-1-ruanjinjie@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 151ac45348afc5b56baa584c7cd4876addf461ff ]
Bit 270-271 are occasionally unexpectedly set by the hardware. This issue
was observed with 10G SFPs causing huge time errors (> 30ms) in PTP. Only
30 bits are needed for the nanosecond part of the timestamp, clear 2 most
significant bits before extracting timestamp from the internal frame
header.
Fixes: 70dfe25cd866 ("net: sparx5: Update extraction/injection for timestamping")
Signed-off-by: Aakash Menon <aakash.menon@protempis.com>
Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit a3c1e45156ad39f225cd7ddae0f81230a3b1e657 upstream.
This is a clear use-after-free error. We remove it, and rely on checking
the return code of vcap_del_rule.
Reported-by: Dan Carpenter <error27@gmail.com>
Closes: https://lore.kernel.org/kernel-janitors/7bffefc6-219a-4f71-baa0-ad4526e5c198@kili.mountain/
Fixes: c956b9b318d9 ("net: microchip: sparx5: Adding KUNIT tests of key/action values in VCAP API")
Signed-off-by: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 8c248cd836014339498486f14f435c0e344183a7 ]
Prevent options not supported by the PHY from being requested to it by the MAC
Whenever a WOL option is supported by both, the PHY is given priority
since that usually leads to better power savings.
Fixes: e9e13b6adc33 ("lan743x: fix for potential NULL pointer dereference with bare card")
Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microchip.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 7725363936a88351b71495774c1e0e852ae4cdca ]
When Wake-on-LAN (WoL) is active and the system is in suspend mode, triggering
a system event can wake the system from sleep, which may block the data path.
To restore normal data path functionality after waking, disable all wake-up
events. Furthermore, clear all Write 1 to Clear (W1C) status bits by writing
1's to them.
Fixes: 4d94282afd95 ("lan743x: Add power management support")
Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microchip.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit eda40be3a5ff3fdce513d2bcfeaca8cc16cf962a ]
Lan966x is adding ptp traps to redirect the ptp frames to the CPU such
that the HW will not forward these frames anywhere. The issue is that in
case ptp is not enabled and the timestamping source is et to
HWTSTAMP_SOURCE_NETDEV then these traps would not be removed on the
error path.
Fix this by removing the traps in this case as they are not needed.
Fixes: 54e1ed69c40a ("net: lan966x: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set()")
Suggested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Link: https://lore.kernel.org/r/20240517135808.3025435-1-horatiu.vultur@microchip.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 99975ad644c7836414183fa7be4f883a4fb2bf64 upstream.
A debugfs directory entry is create early during probe(). This entry is
not removed on error path leading to some "already present" issues in
case of EPROBE_DEFER.
Create this entry later in the probe() code to avoid the need to change
many 'return' in 'goto' and add the removal in the already present error
path.
Fixes: 942814840127 ("net: lan966x: Add VCAP debugFS support")
Cc: <stable@vger.kernel.org>
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 68aba00483c7c4102429bcdfdece7289a8ab5c8e ]
I noticed that only 3 out of the 4 input bits were used,
mt.key->flags & FLOW_DIS_IS_FRAGMENT was never checked.
In order to avoid a complicated maze, I converted it to
use a 16 byte mapping table.
As shown in the table below the old heuristics doesn't
always do the right thing, ie. when FLOW_DIS_IS_FRAGMENT=1/1
then it used to only match follow-up fragment packets.
Here are all the combinations, and their resulting new/old
VCAP key/mask filter:
/- FLOW_DIS_IS_FRAGMENT (key/mask)
| /- FLOW_DIS_FIRST_FRAG (key/mask)
| | /-- new VCAP fragment (key/mask)
v v v v- old VCAP fragment (key/mask)
0/0 0/0 -/- -/- impossible (due to entry cond. on mask)
0/0 0/1 -/- 0/3 !! invalid (can't match non-fragment + follow-up frag)
0/0 1/0 -/- -/- impossible (key > mask)
0/0 1/1 1/3 1/3 first fragment
0/1 0/0 0/3 3/3 !! not fragmented
0/1 0/1 0/3 3/3 !! not fragmented (+ not first fragment)
0/1 1/0 -/- -/- impossible (key > mask)
0/1 1/1 -/- 1/3 !! invalid (non-fragment and first frag)
1/0 0/0 -/- -/- impossible (key > mask)
1/0 0/1 -/- -/- impossible (key > mask)
1/0 1/0 -/- -/- impossible (key > mask)
1/0 1/1 -/- -/- impossible (key > mask)
1/1 0/0 1/1 3/3 !! some fragment
1/1 0/1 3/3 3/3 follow-up fragment
1/1 1/0 -/- -/- impossible (key > mask)
1/1 1/1 1/3 1/3 first fragment
In the datasheet the VCAP fragment values are documented as:
0 = no fragment
1 = initial fragment
2 = suspicious fragment
3 = valid follow-up fragment
Result: 3 combinations match the old behavior,
3 combinations have been corrected,
2 combinations are now invalid, and fail,
8 combinations are impossible.
It should now be aligned with how FLOW_DIS_IS_FRAGMENT
and FLOW_DIS_FIRST_FRAG is set in __skb_flow_dissect() in
net/core/flow_dissector.c
Since the VCAP fragment values are not a bitfield, we have
to ignore the suspicious fragment value, eg. when matching
on any kind of fragment with FLOW_DIS_IS_FRAGMENT=1/1.
Only compile tested, and logic tested in userspace, as I
unfortunately don't have access to this switch chip (yet).
Fixes: d6c2964db3fe ("net: microchip: sparx5: Adding more tc flower keys for the IS2 VCAP")
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com>
Tested-by: Daniel Machon <daniel.machon@microchip.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://lore.kernel.org/r/20240411111321.114095-1-ast@fiberby.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 33623113a48ea906f1955cbf71094f6aa4462e8f ]
The wrong port config is being used if the PCS is reconfigured. Fix this
by correctly using the new config instead of the old one.
Fixes: 946e7fd5053a ("net: sparx5: add port module support")
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://lore.kernel.org/r/20240409-link-mode-reconfiguration-fix-v2-1-db6a507f3627@microchip.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit e4a58989f5c839316ac63675e8800b9eed7dbe96 ]
PCI11x1x Rev B0 devices might drop packets when receiving back to back frames
at 2.5G link speed. Change the B0 Rev device's Receive filtering Engine FIFO
threshold parameter from its hardware default of 4 to 3 dwords to prevent the
problem. Rev C0 and later hardware already defaults to 3 dwords.
Fixes: bb4f6bffe33c ("net: lan743x: Add PCI11010 / PCI11414 device IDs")
Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microchip.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://lore.kernel.org/r/20240326065805.686128-1-Raju.Lakkaraju@microchip.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 89d72d4125e94aa3c2140fedd97ce07ba9e37674 ]
Based on the static analyzis of the code it looks like when an entry
from the MAC table was removed, the entry was still used after being
freed. More precise the vid of the mac_entry was used after calling
devm_kfree on the mac_entry.
The fix consists in first using the vid of the mac_entry to delete the
entry from the HW and after that to free it.
Fixes: b37a1bae742f ("net: sparx5: add mactable support")
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://lore.kernel.org/r/20240301080608.3053468-1-horatiu.vultur@microchip.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 603ead96582d85903baec2d55f021b8dac5c25d2 ]
Both registers used when doing manual injection or fdma injection are
shared between all the net devices of the switch. It was noticed that
when having two process which each of them trying to inject frames on
different ethernet ports, that the HW started to behave strange, by
sending out more frames then expected. When doing fdma injection it is
required to set the frame in the DCB and then make sure that the next
pointer of the last DCB is invalid. But because there is no locks for
this, then easily this pointer between the DCB can be broken and then it
would create a loop of DCBs. And that means that the HW will
continuously transmit these frames in a loop. Until the SW will break
this loop.
Therefore to fix this issue, add a spin lock for when accessing the
registers for manual or fdma injection.
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Reviewed-by: Daniel Machon <daniel.machon@microchip.com>
Fixes: f3cad2611a77 ("net: sparx5: add hostmode with phylink support")
Link: https://lore.kernel.org/r/20240219080043.1561014-1-horatiu.vultur@microchip.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 15faa1f67ab405d47789d4702f587ec7df7ef03e ]
There is a crash when adding one of the lan966x interfaces under a lag
interface. The issue can be reproduced like this:
ip link add name bond0 type bond miimon 100 mode balance-xor
ip link set dev eth0 master bond0
The reason is because when adding a interface under the lag it would go
through all the ports and try to figure out which other ports are under
that lag interface. And the issue is that lan966x can have ports that are
NULL pointer as they are not probed. So then iterating over these ports
it would just crash as they are NULL pointers.
The fix consists in actually checking for NULL pointers before accessing
something from the ports. Like we do in other places.
Fixes: cabc9d49333d ("net: lan966x: Add lag support for lan966x")
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://lore.kernel.org/r/20240206123054.3052966-1-horatiu.vultur@microchip.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 62b4248105353e7d1debd30ca5c57ec5e5f28e35 ]
In case the interface between the MAC and the PHY is SGMII, then the bit
GIGA_MODE on the MAC side needs to be set regardless of the speed at
which it is running.
Fixes: d28d6d2e37d1 ("net: lan966x: add port module support")
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
Since FIXED_PHY depends on PHYLIB, PHYLIB needs to be set to avoid
a kconfig warning:
WARNING: unmet direct dependencies detected for FIXED_PHY
Depends on [n]: NETDEVICES [=y] && PHYLIB [=n]
Selected by [y]:
- LAN743X [=y] && NETDEVICES [=y] && ETHERNET [=y] && NET_VENDOR_MICROCHIP [=y] && PCI [=y] && PTP_1588_CLOCK_OPTIONAL [=y]
Fixes: 73c4d1b307ae ("net: lan743x: select FIXED_PHY")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kernel test robot <lkp@intel.com>
Closes: lore.kernel.org/r/202309261802.JPbRHwti-lkp@intel.com
Cc: Bryan Whitehead <bryan.whitehead@microchip.com>
Cc: UNGLinuxDriver@microchip.com
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Simon Horman <horms@kernel.org> # build-tested
Link: https://lore.kernel.org/r/20231002193544.14529-1-rdunlap@infradead.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
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>
|
|
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>
|
|
Commit 264a9c5c9dff ("net: sparx5: Remove unused GLAG handling in PGID")
removed sparx5_pgid_alloc_glag() but not its declaration.
Commit 27d293cceee5 ("net: microchip: sparx5: Add support for rule count by cookie")
removed vcap_rule_iter() but not its declaration.
Commit 8beef08f4618 ("net: microchip: sparx5: Adding initial VCAP API support")
declared but never implemented vcap_api_set_client().
Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://lore.kernel.org/r/20230821135556.43224-1-yuehaibing@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
fixed_phy_register() returns -EPROBE_DEFER, -EINVAL and -EBUSY,
etc, in addition to -EIO. The Best practice is to return these
error codes with PTR_ERR().
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
As Simon Horman suggests, update vcap_get_rule() to always
return an ERR_PTR() and update the error detection conditions to
use IS_ERR(), so use IS_ERR() to check the return value.
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
Suggested-by: Simon Horman <horms@kernel.org>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
As Simon Horman suggests, update vcap_get_rule() to always
return an ERR_PTR() and update the error detection conditions to
use IS_ERR(), so use IS_ERR() to fix the return value issue.
Fixes: 72df3489fb10 ("net: lan966x: Add ptp trap rules")
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
Suggested-by: Simon Horman <horms@kernel.org>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
As Simon Horman suggests, update vcap_get_rule() to always
return an ERR_PTR() and update the error detection conditions to
use IS_ERR(), which would be more cleaner in this case.
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
Suggested-by: Simon Horman <horms@kernel.org>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Split types and pure function declarations from page_pool.h
and add them in page_page/types.h, so that C sources can
include page_pool.h and headers should generally only include
page_pool/types.h as suggested by jakub.
Rename page_pool.h to page_pool/helpers.h to have both in
one place.
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Suggested-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
Link: https://lore.kernel.org/r/20230804180529.2483231-2-aleksander.lobakin@intel.com
[Jakub: change microsoft/mana, fix kdoc paths in Documentation]
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Since platform_get_irq_byname() never returned zero, so it need not to
check whether it returned zero, it returned -EINVAL or -ENXIO when
failed, so we replace the return error code with the result it returned.
Signed-off-by: Zhu Wang <wangzhu9@huawei.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
There is a warning reported by coccinelle:
./drivers/net/ethernet/microchip/vcap/vcap_api.c:2399:9-16: WARNING:
ERR_CAST can be used with ri
Use ERR_CAST instead of ERR_PTR + PTR_ERR to simplify the
conversion process.
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next
Martin KaFai Lau says:
====================
pull-request: bpf-next 2023-08-03
We've added 54 non-merge commits during the last 10 day(s) which contain
a total of 84 files changed, 4026 insertions(+), 562 deletions(-).
The main changes are:
1) Add SO_REUSEPORT support for TC bpf_sk_assign from Lorenz Bauer,
Daniel Borkmann
2) Support new insns from cpu v4 from Yonghong Song
3) Non-atomically allocate freelist during prefill from YiFei Zhu
4) Support defragmenting IPv(4|6) packets in BPF from Daniel Xu
5) Add tracepoint to xdp attaching failure from Leon Hwang
6) struct netdev_rx_queue and xdp.h reshuffling to reduce
rebuild time from Jakub Kicinski
* tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (54 commits)
net: invert the netdevice.h vs xdp.h dependency
net: move struct netdev_rx_queue out of netdevice.h
eth: add missing xdp.h includes in drivers
selftests/bpf: Add testcase for xdp attaching failure tracepoint
bpf, xdp: Add tracepoint to xdp attaching failure
selftests/bpf: fix static assert compilation issue for test_cls_*.c
bpf: fix bpf_probe_read_kernel prototype mismatch
riscv, bpf: Adapt bpf trampoline to optimized riscv ftrace framework
libbpf: fix typos in Makefile
tracing: bpf: use struct trace_entry in struct syscall_tp_t
bpf, devmap: Remove unused dtab field from bpf_dtab_netdev
bpf, cpumap: Remove unused cmap field from bpf_cpu_map_entry
netfilter: bpf: Only define get_proto_defrag_hook() if necessary
bpf: Fix an array-index-out-of-bounds issue in disasm.c
net: remove duplicate INDIRECT_CALLABLE_DECLARE of udp[6]_ehashfn
docs/bpf: Fix malformed documentation
bpf: selftests: Add defrag selftests
bpf: selftests: Support custom type and proto for client sockets
bpf: selftests: Support not connecting client socket
netfilter: bpf: Support BPF_F_NETFILTER_IP_DEFRAG in netfilter link
...
====================
Link: https://lore.kernel.org/r/20230803174845.825419-1-martin.lau@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Handful of drivers currently expect to get xdp.h by virtue
of including netdevice.h. This will soon no longer be the case
so add explicit includes.
Reviewed-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Gerhard Engleder <gerhard@engleder-embedded.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Acked-by: Jesper Dangaard Brouer <hawk@kernel.org>
Link: https://lore.kernel.org/r/20230803010230.1755386-2-kuba@kernel.org
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
|
|
drivers
It is desirable that the new .ndo_hwtstamp_set() API gives more
uniformity, less overhead and future flexibility w.r.t. the PHY
timestamping behavior.
Currently there are some drivers which allow PHY timestamping through
the procedure mentioned in Documentation/networking/timestamping.rst.
They don't do anything locally if phy_has_hwtstamp() is set, except for
lan966x which installs PTP packet traps.
Centralize that behavior in a new dev_set_hwtstamp_phylib() code
function, which calls either phy_mii_ioctl() for the phylib PHY,
or .ndo_hwtstamp_set() of the netdev, based on a single policy
(currently simplistic: phy_has_hwtstamp()).
Any driver converted to .ndo_hwtstamp_set() will automatically opt into
the centralized phylib timestamping policy. Unconverted drivers still
get to choose whether they let the PHY handle timestamping or not.
Netdev drivers with integrated PHY drivers that don't use phylib
presumably don't set dev->phydev, and those will always see
HWTSTAMP_SOURCE_NETDEV requests even when converted. The timestamping
policy will remain 100% up to them.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Link: https://lore.kernel.org/r/20230801142824.1772134-13-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The hardware timestamping through ndo_eth_ioctl() is going away.
Convert the lan966x driver to the new API before that can be removed.
After removing the timestamping logic from lan966x_port_ioctl(), the
rest is equivalent to phy_do_ioctl().
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Link: https://lore.kernel.org/r/20230801142824.1772134-10-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
