diff options
| author | Mingming Cao <mmc@linux.ibm.com> | 2026-10-13 11:29:24 -0700 |
|---|---|---|
| committer | Jakub Kicinski <kuba@kernel.org> | 2026-10-20 15:37:50 -0700 |
| commit | c807573ea58e615339a9c72675c45c157ffe245c (patch) | |
| tree | 0cce6919ddc097417f81f6391ec0dec7583612d4 /tools/lib/python/kdoc/python_version.py | |
| parent | 16abfa871dc840e55f1726408c5994c66a9773e2 (diff) | |
ibmveth: wait for in-flight transmits in ibmveth_close()
ibmveth_close() frees the TX buffers after netif_tx_stop_all_queues(),
which does not wait for an ibmveth_start_xmit() already running on
another CPU. That transmit can copy into a freed buffer and hand PHYP
a stale DMA address.
MTU, csum/TSO and buffer pool changes call ibmveth_close() directly
while traffic flows. ifdown and the reset work go through dev_close(),
which waits for running transmits only when the qdisc has an enqueue
function, so with noqueue they race the same way.
Use netif_tx_disable(), which waits for running transmits.
Found in review of the ibmveth multi-queue RX series and confirmed by
code inspection; the race was not reproduced. Tested on a POWER10 LPAR
with MTU changes during a ping flood, with no warnings. No kernel
selftests cover ibmveth.
Fixes: d6832ca48d8a ("ibmveth: Copy tx skbs into a premapped buffer")
Signed-off-by: Mingming Cao <mmc@linux.ibm.com>
Link: https://patch.msgid.link/20261013182926.30417-8-mmc@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'tools/lib/python/kdoc/python_version.py')
0 files changed, 0 insertions, 0 deletions