mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
synced 2026-04-18 19:43:43 -04:00
55a756549ef6479781bc050cd26d19599fb78427
47635 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Remi Pommarel
|
3eef855589 |
net: stmmac: remove unneeded stmmac_poll_controller
Using netconsole netpoll_poll_dev could be called from interrupt context, thus using disable_irq() would cause the following kernel warning with CONFIG_DEBUG_ATOMIC_SLEEP enabled: BUG: sleeping function called from invalid context at kernel/irq/manage.c:137 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 10, name: ksoftirqd/0 CPU: 0 PID: 10 Comm: ksoftirqd/0 Tainted: G W 5.15.42-00075-g816b502b2298-dirty #117 Hardware name: aml (r1) (DT) Call trace: dump_backtrace+0x0/0x270 show_stack+0x14/0x20 dump_stack_lvl+0x8c/0xac dump_stack+0x18/0x30 ___might_sleep+0x150/0x194 __might_sleep+0x64/0xbc synchronize_irq+0x8c/0x150 disable_irq+0x2c/0x40 stmmac_poll_controller+0x140/0x1a0 netpoll_poll_dev+0x6c/0x220 netpoll_send_skb+0x308/0x390 netpoll_send_udp+0x418/0x760 write_msg+0x118/0x140 [netconsole] console_unlock+0x404/0x500 vprintk_emit+0x118/0x250 dev_vprintk_emit+0x19c/0x1cc dev_printk_emit+0x90/0xa8 __dev_printk+0x78/0x9c _dev_warn+0xa4/0xbc ath10k_warn+0xe8/0xf0 [ath10k_core] ath10k_htt_txrx_compl_task+0x790/0x7fc [ath10k_core] ath10k_pci_napi_poll+0x98/0x1f4 [ath10k_pci] __napi_poll+0x58/0x1f4 net_rx_action+0x504/0x590 _stext+0x1b8/0x418 run_ksoftirqd+0x74/0xa4 smpboot_thread_fn+0x210/0x3c0 kthread+0x1fc/0x210 ret_from_fork+0x10/0x20 Since [0] .ndo_poll_controller is only needed if driver doesn't or partially use NAPI. Because stmmac does so, stmmac_poll_controller can be removed fixing the above warning. [0] commit |
||
|
Randy Dunlap
|
566aeed687 |
net: lan743x: also select PHYLIB
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:
|
||
|
Christian Marangi
|
fcdfc46288 |
net: ethernet: mediatek: disable irq before schedule napi
While searching for possible refactor of napi_schedule_prep and
__napi_schedule it was notice that the mtk eth driver disable the
interrupt for rx and tx AFTER napi is scheduled.
While this is a very hard to repro case it might happen to have
situation where the interrupt is disabled and never enabled again as the
napi completes and the interrupt is enabled before.
This is caused by the fact that a napi driven by interrupt expect a
logic with:
1. interrupt received. napi prepared -> interrupt disabled -> napi
scheduled
2. napi triggered. ring cleared -> interrupt enabled -> wait for new
interrupt
To prevent this case, disable the interrupt BEFORE the napi is
scheduled.
Fixes:
|
||
|
Haiyang Zhang
|
a43e8e9ffa |
net: mana: Fix oversized sge0 for GSO packets
Handle the case when GSO SKB linear length is too large.
MANA NIC requires GSO packets to put only the header part to SGE0,
otherwise the TX queue may stop at the HW level.
So, use 2 SGEs for the skb linear part which contains more than the
packet header.
Fixes:
|
||
|
Haiyang Zhang
|
7a54de9265 |
net: mana: Fix the tso_bytes calculation
sizeof(struct hop_jumbo_hdr) is not part of tso_bytes, so remove
the subtraction from header size.
Cc: stable@vger.kernel.org
Fixes:
|
||
|
Haiyang Zhang
|
b2b000069a |
net: mana: Fix TX CQE error handling
For an unknown TX CQE error type (probably from a newer hardware),
still free the SKB, update the queue tail, etc., otherwise the
accounting will be wrong.
Also, TX errors can be triggered by injecting corrupted packets, so
replace the WARN_ONCE to ratelimited error logging.
Cc: stable@vger.kernel.org
Fixes:
|
||
|
Ben Wolsieffer
|
6f195d6b0d |
net: stmmac: dwmac-stm32: fix resume on STM32 MCU
The STM32MP1 keeps clk_rx enabled during suspend, and therefore the
driver does not enable the clock in stm32_dwmac_init() if the device was
suspended. The problem is that this same code runs on STM32 MCUs, which
do disable clk_rx during suspend, causing the clock to never be
re-enabled on resume.
This patch adds a variant flag to indicate that clk_rx remains enabled
during suspend, and uses this to decide whether to enable the clock in
stm32_dwmac_init() if the device was suspended.
This approach fixes this specific bug with limited opportunity for
unintended side-effects, but I have a follow up patch that will refactor
the clock configuration and hopefully make it less error prone.
Fixes:
|
||
|
David Wilder
|
51e7a66666 |
ibmveth: Remove condition to recompute TCP header checksum.
In some OVS environments the TCP pseudo header checksum may need to be
recomputed. Currently this is only done when the interface instance is
configured for "Trunk Mode". We found the issue also occurs in some
Kubernetes environments, these environments do not use "Trunk Mode",
therefor the condition is removed.
Performance tests with this change show only a fractional decrease in
throughput (< 0.2%).
Fixes:
|
||
|
Dan Carpenter
|
f9a1d3216a |
dmaengine: ti: k3-udma-glue: clean up k3_udma_glue_tx_get_irq() return
The k3_udma_glue_tx_get_irq() function currently returns negative error codes on error, zero on error and positive values for success. This complicates life for the callers who need to propagate the error code. Also GCC will not warn about unsigned comparisons when you check: if (unsigned_irq <= 0) All the callers have been fixed now but let's just make this easy going forward. Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Roger Quadros <rogerq@kernel.org> Acked-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> |
||
|
Dan Carpenter
|
a325f174d7 |
net: ti: icssg-prueth: Fix signedness bug in prueth_init_tx_chns()
The "tx_chn->irq" variable is unsigned so the error checking does not
work correctly.
Fixes:
|
||
|
Dan Carpenter
|
37d4f55567 |
net: ethernet: ti: am65-cpsw: Fix error code in am65_cpsw_nuss_init_tx_chns()
This accidentally returns success, but it should return a negative error
code.
Fixes:
|
||
|
Yoshihiro Shimoda
|
a0c55bba0d |
rswitch: Fix PHY station management clock setting
Fix the MPIC.PSMCS value following the programming example in the
section 6.4.2 Management Data Clock (MDC) Setting, Ethernet MAC IP,
S4 Hardware User Manual Rev.1.00.
The value is calculated by
MPIC.PSMCS = clk[MHz] / (MDC frequency[MHz] * 2) - 1
with the input clock frequency from clk_get_rate() and MDC frequency
of 2.5MHz. Otherwise, this driver cannot communicate PHYs on the R-Car
S4 Starter Kit board.
Fixes:
|
||
|
Gustavo A. R. Silva
|
eea03d18af |
qed/red_ll2: Fix undefined behavior bug in struct qed_ll2_info
The flexible structure (a structure that contains a flexible-array member
at the end) `qed_ll2_tx_packet` is nested within the second layer of
`struct qed_ll2_info`:
struct qed_ll2_tx_packet {
...
/* Flexible Array of bds_set determined by max_bds_per_packet */
struct {
struct core_tx_bd *txq_bd;
dma_addr_t tx_frag;
u16 frag_len;
} bds_set[];
};
struct qed_ll2_tx_queue {
...
struct qed_ll2_tx_packet cur_completing_packet;
};
struct qed_ll2_info {
...
struct qed_ll2_tx_queue tx_queue;
struct qed_ll2_cbs cbs;
};
The problem is that member `cbs` in `struct qed_ll2_info` is placed just
after an object of type `struct qed_ll2_tx_queue`, which is in itself
an implicit flexible structure, which by definition ends in a flexible
array member, in this case `bds_set`. This causes an undefined behavior
bug at run-time when dynamic memory is allocated for `bds_set`, which
could lead to a serious issue if `cbs` in `struct qed_ll2_info` is
overwritten by the contents of `bds_set`. Notice that the type of `cbs`
is a structure full of function pointers (and a cookie :) ):
include/linux/qed/qed_ll2_if.h:
107 typedef
108 void (*qed_ll2_complete_rx_packet_cb)(void *cxt,
109 struct qed_ll2_comp_rx_data *data);
110
111 typedef
112 void (*qed_ll2_release_rx_packet_cb)(void *cxt,
113 u8 connection_handle,
114 void *cookie,
115 dma_addr_t rx_buf_addr,
116 bool b_last_packet);
117
118 typedef
119 void (*qed_ll2_complete_tx_packet_cb)(void *cxt,
120 u8 connection_handle,
121 void *cookie,
122 dma_addr_t first_frag_addr,
123 bool b_last_fragment,
124 bool b_last_packet);
125
126 typedef
127 void (*qed_ll2_release_tx_packet_cb)(void *cxt,
128 u8 connection_handle,
129 void *cookie,
130 dma_addr_t first_frag_addr,
131 bool b_last_fragment, bool b_last_packet);
132
133 typedef
134 void (*qed_ll2_slowpath_cb)(void *cxt, u8 connection_handle,
135 u32 opaque_data_0, u32 opaque_data_1);
136
137 struct qed_ll2_cbs {
138 qed_ll2_complete_rx_packet_cb rx_comp_cb;
139 qed_ll2_release_rx_packet_cb rx_release_cb;
140 qed_ll2_complete_tx_packet_cb tx_comp_cb;
141 qed_ll2_release_tx_packet_cb tx_release_cb;
142 qed_ll2_slowpath_cb slowpath_cb;
143 void *cookie;
144 };
Fix this by moving the declaration of `cbs` to the middle of its
containing structure `qed_ll2_info`, preventing it from being
overwritten by the contents of `bds_set` at run-time.
This bug was introduced in 2017, when `bds_set` was converted to a
one-element array, and started to be used as a Variable Length Object
(VLO) at run-time.
Fixes:
|
||
|
Kees Cook
|
6a70e5cbed |
sky2: Make sure there is at least one frag_addr available
In the pathological case of building sky2 with 16k PAGE_SIZE, the
frag_addr[] array would never be used, so the original code was correct
that size should be 0. But the compiler now gets upset with 0 size arrays
in places where it hasn't eliminated the code that might access such an
array (it can't figure out that in this case an rx skb with fragments
would never be created). To keep the compiler happy, make sure there is
at least 1 frag_addr in struct rx_ring_info:
In file included from include/linux/skbuff.h:28,
from include/net/net_namespace.h:43,
from include/linux/netdevice.h:38,
from drivers/net/ethernet/marvell/sky2.c:18:
drivers/net/ethernet/marvell/sky2.c: In function 'sky2_rx_unmap_skb':
include/linux/dma-mapping.h:416:36: warning: array subscript i is outside array bounds of 'dma_addr_t[0]' {aka 'long long unsigned int[]'} [-Warray-bounds=]
416 | #define dma_unmap_page(d, a, s, r) dma_unmap_page_attrs(d, a, s, r, 0)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/marvell/sky2.c:1257:17: note: in expansion of macro 'dma_unmap_page'
1257 | dma_unmap_page(&pdev->dev, re->frag_addr[i],
| ^~~~~~~~~~~~~~
In file included from drivers/net/ethernet/marvell/sky2.c:41:
drivers/net/ethernet/marvell/sky2.h:2198:25: note: while referencing 'frag_addr'
2198 | dma_addr_t frag_addr[ETH_JUMBO_MTU >> PAGE_SHIFT];
| ^~~~~~~~~
With CONFIG_PAGE_SIZE_16KB=y, PAGE_SHIFT == 14, so:
#define ETH_JUMBO_MTU 9000
causes "ETH_JUMBO_MTU >> PAGE_SHIFT" to be 0. Use "?: 1" to solve this build warning.
Cc: Mirko Lindner <mlindner@marvell.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: netdev@vger.kernel.org
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202309191958.UBw1cjXk-lkp@intel.com/
Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
||
|
Clark Wang
|
6b09edc1b3 |
net: stmmac: platform: fix the incorrect parameter
The second parameter of stmmac_pltfr_init() needs the pointer of
"struct plat_stmmacenet_data". So, correct the parameter typo when calling the
function.
Otherwise, it may cause this alignment exception when doing suspend/resume.
[ 49.067201] CPU1 is up
[ 49.135258] Internal error: SP/PC alignment exception: 000000008a000000 [#1] PREEMPT SMP
[ 49.143346] Modules linked in: soc_imx9 crct10dif_ce polyval_ce nvmem_imx_ocotp_fsb_s400 polyval_generic layerscape_edac_mod snd_soc_fsl_asoc_card snd_soc_imx_audmux snd_soc_imx_card snd_soc_wm8962 el_enclave snd_soc_fsl_micfil rtc_pcf2127 rtc_pcf2131 flexcan can_dev snd_soc_fsl_xcvr snd_soc_fsl_sai imx8_media_dev(C) snd_soc_fsl_utils fuse
[ 49.173393] CPU: 0 PID: 565 Comm: sh Tainted: G C 6.5.0-rc4-next-20230804-05047-g5781a6249dae #677
[ 49.183721] Hardware name: NXP i.MX93 11X11 EVK board (DT)
[ 49.189190] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 49.196140] pc : 0x80800052
[ 49.198931] lr : stmmac_pltfr_resume+0x34/0x50
[ 49.203368] sp : ffff800082f8bab0
[ 49.206670] x29: ffff800082f8bab0 x28: ffff0000047d0ec0 x27: ffff80008186c170
[ 49.213794] x26: 0000000b5e4ff1ba x25: ffff800081e5fa74 x24: 0000000000000010
[ 49.220918] x23: ffff800081fe0000 x22: 0000000000000000 x21: 0000000000000000
[ 49.228042] x20: ffff0000001b4010 x19: ffff0000001b4010 x18: 0000000000000006
[ 49.235166] x17: ffff7ffffe007000 x16: ffff800080000000 x15: 0000000000000000
[ 49.242290] x14: 00000000000000fc x13: 0000000000000000 x12: 0000000000000000
[ 49.249414] x11: 0000000000000001 x10: 0000000000000a60 x9 : ffff800082f8b8c0
[ 49.256538] x8 : 0000000000000008 x7 : 0000000000000001 x6 : 000000005f54a200
[ 49.263662] x5 : 0000000001000000 x4 : ffff800081b93680 x3 : ffff800081519be0
[ 49.270786] x2 : 0000000080800052 x1 : 0000000000000000 x0 : ffff0000001b4000
[ 49.277911] Call trace:
[ 49.280346] 0x80800052
[ 49.282781] platform_pm_resume+0x2c/0x68
[ 49.286785] dpm_run_callback.constprop.0+0x74/0x134
[ 49.291742] device_resume+0x88/0x194
[ 49.295391] dpm_resume+0x10c/0x230
[ 49.298866] dpm_resume_end+0x18/0x30
[ 49.302515] suspend_devices_and_enter+0x2b8/0x624
[ 49.307299] pm_suspend+0x1fc/0x348
[ 49.310774] state_store+0x80/0x104
[ 49.314258] kobj_attr_store+0x18/0x2c
[ 49.318002] sysfs_kf_write+0x44/0x54
[ 49.321659] kernfs_fop_write_iter+0x120/0x1ec
[ 49.326088] vfs_write+0x1bc/0x300
[ 49.329485] ksys_write+0x70/0x104
[ 49.332874] __arm64_sys_write+0x1c/0x28
[ 49.336783] invoke_syscall+0x48/0x114
[ 49.340527] el0_svc_common.constprop.0+0xc4/0xe4
[ 49.345224] do_el0_svc+0x38/0x98
[ 49.348526] el0_svc+0x2c/0x84
[ 49.351568] el0t_64_sync_handler+0x100/0x12c
[ 49.355910] el0t_64_sync+0x190/0x194
[ 49.359567] Code: ???????? ???????? ???????? ???????? (????????)
[ 49.365644] ---[ end trace 0000000000000000 ]---
Fixes:
|
||
|
Michal Schmidt
|
c070e51db5 |
ice: always add legacy 32byte RXDID in supported_rxdids
When the PF and VF drivers both support flexible rx descriptors and have
negotiated the VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC capability, the VF driver
queries the PF for the list of supported descriptor formats
(VIRTCHNL_OP_GET_SUPPORTED_RXDIDS). The PF driver is supposed to set the
supported_rxdids bits that correspond to the descriptor formats the
firmware implements. The legacy 32-byte rx desc format is always
supported, even though it is not expressed in GLFLXP_RXDID_FLAGS.
The ice driver does not advertise the legacy 32-byte rx desc support,
which leads to this failure to bring up the VF using the Intel
out-of-tree iavf driver:
iavf 0000:41:01.0: PF does not list support for default Rx descriptor format
...
iavf 0000:41:01.0: PF returned error -5 (VIRTCHNL_STATUS_ERR_PARAM) to our request 6
The in-tree iavf driver does not expose this bug, because it does not
yet implement VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC.
The ice driver must always set the ICE_RXDID_LEGACY_1 bit in
supported_rxdids. The Intel out-of-tree ice driver and the ice driver in
DPDK both do this.
I copied this piece of the code and the comment text from the Intel
out-of-tree driver.
Fixes:
|
||
|
Edward Cree
|
fc21f08375 |
sfc: handle error pointers returned by rhashtable_lookup_get_insert_fast()
Several places in TC offload code assumed that the return from
rhashtable_lookup_get_insert_fast() was always either NULL or a valid
pointer to an existing entry, but in fact that function can return an
error pointer. In that case, perform the usual cleanup of the newly
created entry, then pass up the error, rather than attempting to take a
reference on the old entry.
Fixes:
|
||
|
Muhammad Husaini Zulkifli
|
1703b2e0de |
igc: Expose tx-usecs coalesce setting to user
When users attempt to obtain the coalesce setting using the
ethtool command, current code always returns 0 for tx-usecs.
This is because I225/6 always uses a queue pair setting, hence
tx_coalesce_usecs does not return a value during the
igc_ethtool_get_coalesce() callback process. The pair queue
condition checking in igc_ethtool_get_coalesce() is removed by
this patch so that the user gets information of the value of tx-usecs.
Even if i225/6 is using queue pair setting, there is no harm in
notifying the user of the tx-usecs. The implementation of the current
code may have previously been a copy of the legacy code i210.
Since I225 has the queue pair setting enabled, tx-usecs will always adhere
to the user-set rx-usecs value. An error message will appear when the user
attempts to set the tx-usecs value for the input parameters because,
by default, they should only set the rx-usecs value.
This patch also adds the helper function to get the
previous rx coalesce value similar to tx coalesce.
How to test:
User can get the coalesce value using ethtool command.
Example command:
Get: ethtool -c <interface>
Previous output:
rx-usecs: 3
rx-frames: n/a
rx-usecs-irq: n/a
rx-frames-irq: n/a
tx-usecs: 0
tx-frames: n/a
tx-usecs-irq: n/a
tx-frames-irq: n/a
New output:
rx-usecs: 3
rx-frames: n/a
rx-usecs-irq: n/a
rx-frames-irq: n/a
tx-usecs: 3
tx-frames: n/a
tx-usecs-irq: n/a
tx-frames-irq: n/a
Fixes:
|
||
|
Sebastian Andrzej Siewior
|
70b2b68926 |
octeontx2-pf: Do xdp_do_flush() after redirects.
xdp_do_flush() should be invoked before leaving the NAPI poll function
if XDP-redirect has been performed.
Invoke xdp_do_flush() before leaving NAPI.
Cc: Geetha sowjanya <gakula@marvell.com>
Cc: Subbaraya Sundeep <sbhatta@marvell.com>
Cc: Sunil Goutham <sgoutham@marvell.com>
Cc: hariprasad <hkelam@marvell.com>
Fixes:
|
||
|
Sebastian Andrzej Siewior
|
edc0140cc3 |
bnxt_en: Flush XDP for bnxt_poll_nitroa0()'s NAPI
bnxt_poll_nitroa0() invokes bnxt_rx_pkt() which can run a XDP program
which in turn can return XDP_REDIRECT. bnxt_rx_pkt() is also used by
__bnxt_poll_work() which flushes (xdp_do_flush()) the packets after each
round. bnxt_poll_nitroa0() lacks this feature.
xdp_do_flush() should be invoked before leaving the NAPI callback.
Invoke xdp_do_flush() after a redirect in bnxt_poll_nitroa0() NAPI.
Cc: Michael Chan <michael.chan@broadcom.com>
Fixes:
|
||
|
Sebastian Andrzej Siewior
|
6f411fb5ca |
net: ena: Flush XDP packets on error.
xdp_do_flush() should be invoked before leaving the NAPI poll function
after a XDP-redirect. This is not the case if the driver leaves via
the error path (after having a redirect in one of its previous
iterations).
Invoke xdp_do_flush() also in the error path.
Cc: Arthur Kiyanovski <akiyano@amazon.com>
Cc: David Arinzon <darinzon@amazon.com>
Cc: Noam Dagan <ndagan@amazon.com>
Cc: Saeed Bishara <saeedb@amazon.com>
Cc: Shay Agroskin <shayagr@amazon.com>
Fixes:
|
||
|
Cai Huoqing
|
22b6e7f3d6 |
net: hinic: Fix warning-hinic_set_vlan_fliter() warn: variable dereferenced before check 'hwdev'
'hwdev' is checked too late and hwdev will not be NULL, so remove the check
Fixes:
|
||
|
Jie Wang
|
0770063096 |
net: hns3: add 5ms delay before clear firmware reset irq source
Currently the reset process in hns3 and firmware watchdog init process is
asynchronous. we think firmware watchdog initialization is completed
before hns3 clear the firmware interrupt source. However, firmware
initialization may not complete early.
so we add delay before hns3 clear firmware interrupt source and 5 ms delay
is enough to avoid second firmware reset interrupt.
Fixes:
|
||
|
Jijie Shao
|
1a7be66e46 |
net: hns3: fix fail to delete tc flower rules during reset issue
Firmware does not respond driver commands during reset
Therefore, rule will fail to delete while the firmware is resetting
So, if failed to delete rule, set rule state to TO_DEL,
and the rule will be deleted when periodic task being scheduled.
Fixes:
|
||
|
Jian Shen
|
f2ed304922 |
net: hns3: only enable unicast promisc when mac table full
Currently, the driver will enable unicast promisc for the function
once configure mac address fail. It's unreasonable when the failure
is caused by using same mac address with other functions. So only
enable unicast promisc when mac table full.
Fixes:
|
||
|
Jie Wang
|
f9f6512611 |
net: hns3: fix GRE checksum offload issue
The device_version V3 hardware can't offload the checksum for IP in GRE
packets, but can do it for NvGRE. So default to disable the checksum and
GSO offload for GRE, but keep the ability to enable it when only using
NvGRE.
Fixes:
|
||
|
Jie Wang
|
bd3caddf29 |
net: hns3: add cmdq check for vf periodic service task
When the vf cmdq is disabled, there is no need to keep these task running.
So this patch skip these task when the cmdq is disabled.
Fixes:
|
||
|
Jisheng Zhang
|
8070274b47 |
net: stmmac: fix incorrect rxq|txq_stats reference
commit |
||
|
Gerhard Engleder
|
46589db381 |
tsnep: Fix NAPI polling with budget 0
According to the NAPI documentation networking/napi.rst, Rx specific APIs like page pool and XDP cannot be used at all when budget is 0. skb Tx processing should happen regardless of the budget. Stop NAPI polling after Tx processing and skip Rx processing if budget is 0. Signed-off-by: Gerhard Engleder <gerhard@engleder-embedded.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
||
|
Gerhard Engleder
|
a7f991953d |
tsnep: Fix ethtool channels
According to the NAPI documentation networking/napi.rst, for the ethtool API a channel is a IRQ/NAPI which services queues of a given type. tsnep uses a single IRQ/NAPI instance for every TX/RX queue pair. Therefore, combined channels shall be returned instead of separate tx/rx channels. Signed-off-by: Gerhard Engleder <gerhard@engleder-embedded.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
||
|
Gerhard Engleder
|
ea852c17f5 |
tsnep: Fix NAPI scheduling
According to the NAPI documentation networking/napi.rst, drivers which have to mask interrupts explicitly should use the napi_schedule_prep() and __napi_schedule() calls. No problem seen so far with current implementation. Nevertheless, let's align the implementation with documentation. Signed-off-by: Gerhard Engleder <gerhard@engleder-embedded.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
||
|
David S. Miller
|
802496c9b8 |
Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-
queue Tony Nguyen says: ==================== This series contains updates to iavf and i40e drivers. Radoslaw prevents admin queue operations being added when the driver is being removed for iavf. Petr Oros immediately starts reconfiguration on changes to VLANs on iavf. Ivan Vecera moves reset of VF to occur after port VLAN values are set on i40e. ==================== Signed-off-by: David S. Miller <davem@davemloft.net> |
||
|
Vinicius Costa Gomes
|
cb47b1f679 |
igc: Fix infinite initialization loop with early XDP redirect
When an XDP redirect happens before the link is ready, that
transmission will not finish and will timeout, causing an adapter
reset. If the redirects do not stop, the adapter will not stop
resetting.
Wait for the driver to signal that there's a carrier before allowing
transmissions to proceed.
Previous code was relying that when __IGC_DOWN is cleared, the NIC is
ready to transmit as all the queues are ready, what happens is that
the carrier presence will only be signaled later, after the watchdog
workqueue has a chance to run. And during this interval (between
clearing __IGC_DOWN and the watchdog running) if any transmission
happens the timeout is emitted (detected by igc_tx_timeout()) which
causes the reset, with the potential for the infinite loop.
Fixes:
|
||
|
David Christensen
|
8f6b846b0a |
ionic: fix 16bit math issue when PAGE_SIZE >= 64KB
The ionic device supports a maximum buffer length of 16 bits (see
ionic_rxq_desc or ionic_rxq_sg_elem). When adding new buffers to
the receive rings, the function ionic_rx_fill() uses 16bit math when
calculating the number of pages to allocate for an RX descriptor,
given the interface's MTU setting. If the system PAGE_SIZE >= 64KB,
and the buf_info->page_offset is 0, the remain_len value will never
decrement from the original MTU value and the frag_len value will
always be 0, causing additional pages to be allocated as scatter-
gather elements unnecessarily.
A similar math issue exists in ionic_rx_frags(), but no failures
have been observed here since a 64KB page should not normally
require any scatter-gather elements at any legal Ethernet MTU size.
Fixes:
|
||
|
Ivan Vecera
|
d0d362ffa3 |
i40e: Fix VF VLAN offloading when port VLAN is configured
If port VLAN is configured on a VF then any other VLANs on top of this VF
are broken.
During i40e_ndo_set_vf_port_vlan() call the i40e driver reset the VF and
iavf driver asks PF (using VIRTCHNL_OP_GET_VF_RESOURCES) for VF capabilities
but this reset occurs too early, prior setting of vf->info.pvid field
and because this field can be zero during i40e_vc_get_vf_resources_msg()
then VIRTCHNL_VF_OFFLOAD_VLAN capability is reported to iavf driver.
This is wrong because iavf driver should not report VLAN offloading
capability when port VLAN is configured as i40e does not support QinQ
offloading.
Fix the issue by moving VF reset after setting of vf->port_vlan_id
field.
Without this patch:
$ echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs
$ ip link set enp2s0f0 vf 0 vlan 3
$ ip link set enp2s0f0v0 up
$ ip link add link enp2s0f0v0 name vlan4 type vlan id 4
$ ip link set vlan4 up
...
$ ethtool -k enp2s0f0v0 | grep vlan-offload
rx-vlan-offload: on
tx-vlan-offload: on
$ dmesg -l err | grep iavf
[1292500.742914] iavf 0000:02:02.0: Failed to add VLAN filter, error IAVF_ERR_INVALID_QP_ID
With this patch:
$ echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs
$ ip link set enp2s0f0 vf 0 vlan 3
$ ip link set enp2s0f0v0 up
$ ip link add link enp2s0f0v0 name vlan4 type vlan id 4
$ ip link set vlan4 up
...
$ ethtool -k enp2s0f0v0 | grep vlan-offload
rx-vlan-offload: off [requested on]
tx-vlan-offload: off [requested on]
$ dmesg -l err | grep iavf
Fixes:
|
||
|
Petr Oros
|
5f3d319a24 |
iavf: schedule a request immediately after add/delete vlan
When the iavf driver wants to reconfigure the VLAN filters
(iavf_add_vlan, iavf_del_vlan), it sets a flag in
aq_required:
adapter->aq_required |= IAVF_FLAG_AQ_ADD_VLAN_FILTER;
or:
adapter->aq_required |= IAVF_FLAG_AQ_DEL_VLAN_FILTER;
This is later processed by the watchdog_task, but it runs periodically
every 2 seconds, so it can be a long time before it processes the request.
In the worst case, the interface is unable to receive traffic for more
than 2 seconds for no objective reason.
Fixes:
|
||
|
Petr Oros
|
ed4cad33df |
iavf: add iavf_schedule_aq_request() helper
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> |
||
|
Radoslaw Tyl
|
c8de44b577 |
iavf: do not process adminq tasks when __IAVF_IN_REMOVE_TASK is set
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:
|
||
|
Shinas Rasheed
|
350db8a59e |
octeon_ep: fix tx dma unmap len values in SG
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:
|
||
|
Arnd Bergmann
|
a8f367f7e1 |
net: ti: icssg-prueth: add PTP dependency
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:
|
||
|
Jinjie Ruan
|
2a2dffd911 |
net: microchip: sparx5: Fix possible memory leaks in vcap_api_kunit
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:
|
||
|
Jinjie Ruan
|
20146fa73a |
net: microchip: sparx5: Fix possible memory leaks in test_vcap_xn_rule_creator()
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:
|
||
|
Jinjie Ruan
|
89e3af0277 |
net: microchip: sparx5: Fix possible memory leak in vcap_api_encode_rule_test()
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:
|
||
|
Jinjie Ruan
|
39d0ccc185 |
net: microchip: sparx5: Fix memory leak for vcap_api_rule_add_actionvalue_test()
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:
|
||
|
Jinjie Ruan
|
f037fc9905 |
net: microchip: sparx5: Fix memory leak for vcap_api_rule_add_keyvalue_test()
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:
|
||
|
Yoshihiro Shimoda
|
c4f922e86c |
net: renesas: rswitch: Add spin lock protection for irq {un}mask
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:
|
||
|
Yoshihiro Shimoda
|
e7b1ef2942 |
net: renesas: rswitch: Fix unmasking irq condition
Fix unmasking irq condition by using napi_complete_done(). Otherwise,
redundant interrupts happen.
Fixes:
|
||
|
Corinna Vinschen
|
bc6ed2fa24 |
igb: clean up in all error paths when enabling SR-IOV
After commit |
||
|
Vadim Fedorenko
|
3c44191dd7 |
ixgbe: fix timestamp configuration code
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:
|
||
|
Sascha Hauer
|
403f0e7714 |
net: macb: fix sleep inside spinlock
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:
|