Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH net v3 1/2] enic: retain admin-channel DMA until queues stop
@ 2026-10-30 22:40 netdev-bot+sashiko
  0 siblings, 0 replies; 2+ messages in thread
From: netdev-bot+sashiko @ 2026-10-30 22:40 UTC (permalink / raw)
  To: satishkh
  Cc: netdev, sebaddel, aradhana, rfaucett, andrew+netdev, davem,
	edumazet, kuba, pabeni

Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider.

Critical: 0 · High: 0 (1) · Medium: 1 · Low: 1

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] enic_remove() now holds rtnl_lock() across the V2 VF PF-
  unregister handshake and enic_admin_channel_close(), not just across…
- [Low] A failed VF re-registration in enic_admin_chan_reopen() can leave
  enic->vf_registered true after the channel has been closed.

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but the patch
  touches the exact line: when enic_open() fails inside enic_reset() or…

--

enic: retain admin-channel DMA until queues stop

This patch tracks the admin channel as DOWN, LIVE or QUARANTINED. When the
admin WQ/RQ cannot be shown to have stopped, it keeps the admin DMA graph
instead of freeing it. The reset workers and the probe/remove paths are
changed so they refuse to reopen or free a quarantined channel, and removal
holds RTNL while it detaches the netdev and closes the channel.

> diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
> index 6b5824f45a14c..5a1621599c5f5 100644
> --- a/drivers/net/ethernet/cisco/enic/enic_main.c
> +++ b/drivers/net/ethernet/cisco/enic/enic_main.c

[ ... ]

> @@ -2287,7 +2309,8 @@ static void enic_reset(struct work_struct *work)
>  	enic_dev_set_ig_vlan_rewrite_mode(enic);
>  	enic_ext_cq(enic);
>  
> -	enic_open(enic->netdev);
> +	if (enic_open(enic->netdev))
> +		goto reset_out;

[Severity: High]
This is a pre-existing issue and not introduced by this patch, but this
line is being touched: what state is the netdev left in when enic_open()
fails here?

By this point enic_stop() has already called napi_disable() on every NAPI
and has called enic_free_intr(). enic_open() can then fail in
enic_request_intr(), page_pool_create(), the RQ fill or enic_dev_enable().
Its unwind disables the NAPIs it enabled and calls enic_free_intr() again.
__LINK_STATE_START and IFF_UP stay set the whole time.

enic_free_intr() also never clears msix[i].requested:

	case VNIC_DEV_INTR_MODE_MSIX:
		for (i = 0; i < enic->intr_count; i++)
			if (enic->msix[i].requested)
				free_irq(enic->msix_entry[i].vector,
					enic->msix[i].devid);

Any of these would then run enic_stop() again over the released
resources: a later ip link set down, the new dev_close() in the quarantine
branch of a later reset, or unregister_netdev() from enic_remove():

enic_stop()
    napi_disable(&enic->napi[i])    <- already disabled
    ...
    enic_free_intr(enic)            <- vectors already freed

Can the second napi_disable() loop forever in napi_disable_locked() while
RTNL is held? NAPIF_STATE_SCHED and NAPIF_STATE_NPSVC are still set from
the first disable. The repeated free_irq() calls would also WARN.

enic_tx_hang_reset() has the same sequence, with the same new
goto reset_out after a failed enic_open().

>  
>  	/* Re-establish the admin/MBOX channel after the data path is back up.
>  	 * It was fully torn down by enic_admin_channel_close() above;
> @@ -2296,12 +2319,17 @@ static void enic_reset(struct work_struct *work)
>  	 */
>  	if (enic_has_admin_chan(enic))
>  		enic_admin_chan_reopen(enic);
> +	if (enic_is_sriov_vf_v2(enic) &&
> +	    enic_admin_channel_is_quarantined(enic))
> +		dev_close(enic->netdev);

[Severity: Low]
Can vf_registered stay true after enic_admin_chan_reopen() closes the
channel because re-registration failed?

The commit message says:

  "Clear local VF registration after draining channel replies, including
  when recovery exits early."

The clears added to enic_reset() and enic_tx_hang_reset() run before the
reopen. The failure path inside enic_admin_chan_reopen() does not clear the
flag afterwards:

		err = enic_mbox_vf_register(enic);
		if (err) {
			netdev_err(...);
			enic_admin_channel_close(enic);
		}

enic_mbox_send_msg_id() publishes mbox_expected_reply and
mbox_expected_msg_num before it rings the doorbell. It then polls the WQ CQ
for up to 5 s while holding only mbox_lock. During that window,
admin_msg_work can accept a REGISTER_REPLY in enic_mbox_vf_handle_reply():

		case ENIC_MBOX_VF_REGISTER_REPLY:
			WRITE_ONCE(enic->vf_registered, true);

If the sender still sees no WQ completion, it returns -ETIMEDOUT. That
error comes back through enic_mbox_vf_register(), and the channel is closed
with vf_registered still set.

enic_remove() later sees vf_registered and calls enic_mbox_vf_unregister().
That call fails with -ENODEV because mbox_send_disabled is set, and remove
logs "Failed to unregister from PF".

Should vf_registered also be cleared after the enic_admin_channel_close()
calls in enic_admin_chan_reopen()?

[ ... ]

> @@ -3397,6 +3454,8 @@ static void enic_remove(struct pci_dev *pdev)
>  		disable_work_sync(&enic->reset);
>  		disable_work_sync(&enic->tx_hang_reset);
>  		disable_work_sync(&enic->change_mtu_work);
> +		rtnl_lock();
> +		netif_device_detach(netdev);
>  
>  		/* Close the admin channel and unregister from the PF before
>  		 * unregister_netdev() to prevent a late PF notification from
> @@ -3413,6 +3472,7 @@ static void enic_remove(struct pci_dev *pdev)
>  			}
>  			enic_admin_channel_close(enic);
>  		}
> +		rtnl_unlock();

[Severity: Medium]
Is RTNL held here for longer than it needs to be?

The new RTNL section covers the whole V2 VF unregister handshake and the
channel close:

enic_remove()
  rtnl_lock()
  enic_mbox_vf_unregister()
    enic_mbox_send_msg_id()           <- WQ CQ poll, up to 5 s
    enic_mbox_wait_reply(enic, 3000)  <- up to 3 s
  enic_admin_channel_close()
    enic_admin_qp_type_set(enic, QP_DISABLE)
    enic_admin_wq_disable()           <- 500 ms, retried on -ETIMEDOUT
    enic_admin_rq_disable()           <- 2 x 500 ms, retried on -ETIMEDOUT
  rtnl_unlock()

The new admin helpers poll with:

	return read_poll_timeout(ioread32, running, !running, 10, 500000,
				 false, &wq->ctrl->running);

These replace the earlier vnic_wq_disable()/vnic_rq_disable() polls of
about 10 ms.

This patch targets the case where the admin queues don't stop or the PF
doesn't respond. In that case, could removing the VF stall every RTNL user
for roughly 8 to 11 seconds? The same longer queue polls now also run under
RTNL and mbox_lock in enic_reset() and enic_tx_hang_reset().

The reset works are already disabled at this point. After rtnl_unlock(),
both enic_open() and the core check netif_device_present(). Would holding
RTNL only around netif_device_detach() be enough to keep a concurrent open
out?

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261027-b4-enic-dma-vf-index-net-generic-first-v1-20261010-v3-0-ba237ed71241%40cisco.com

^ permalink raw reply	[flat|nested] 2+ messages in thread
* [PATCH net v3 0/2] enic: retain admin DMA resources and identify V2 VFs
@ 2026-10-27 15:15 Satish Kharat
  2026-10-27 15:15 ` [PATCH net v3 1/2] enic: retain admin-channel DMA until queues stop Satish Kharat
  0 siblings, 1 reply; 2+ messages in thread
From: Satish Kharat @ 2026-10-27 15:15 UTC (permalink / raw)
  To: netdev
  Cc: Sesidhar Baddela, Aravind Dhanasekaran, Reese Faucette,
	Satish Kharat, Andrew Lunn, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni

Fix premature freeing of admin-channel buffers and set the correct V2 VF
source ID in mailbox messages. This is v3 of the two-patch admin-only
series. The generic datapath quarantine proposal withdrawn in v2 remains
out of scope, including its page-pool/device lifetime problem.

The first patch releases the admin WQ/RQ/CQ allocation only after both
complete queue-disable helpers succeed. Give both queues a first attempt,
then retry once only a helper which timed out. The 500 ms polling bound
is local to admin shutdown, and both RQ disable/check passes are preserved.
Ordinary datapath and DEVCMD2 queue timeouts are unchanged. Admin receive
buffers are driver-owned mappings, not page-pool pages returned later
from the networking stack.

Keep PCI bus mastering enabled during runtime admin quarantine so command
transport and ordinary teardown can continue. An affected V2 VF is closed
and cannot reopen while its control channel is quarantined. Serialize
removal against open and skip admin reopen after a failed datapath open.
Clear local VF registration after channel replies have been drained so
an early recovery exit cannot leave stale registration state.

Removal makes a final direct admin queue check. If it still fails, finish
normal generic teardown and attempt CMD_CLOSE before final containment. Retain
the inert owner and unresolved DMA targets rather than free memory the
device might still reference. This intentionally leaves allocations and
a BAR reservation behind. It blocks ordinary reprobe while the PCI device
remains enumerated; PCI remove/rescan is not a supported recovery method.
A PCI-device reference keeps the reservation name valid, but does not
preserve IOMMU attachment or establish that DMA stopped. No IRQ, work or
other CPU callback may enter retained objects after module unload. DMA
debugging can report pending allocations. Reboot is the supported recovery.

The second patch requires DEVCMD2 for SR-IOV V2 and obtains the VF source
index from CMD_SRIOV_STATS_GET. A deployed async PF compares that source
against the CQ-derived sender. After QP enable, obtain and validate the ID
while receive interrupts remain masked. Publish send readiness before
unmasking, so queued notifications can be processed and acknowledged with
a valid source. Sends remain disabled until the ID is valid, using the
existing send gate. Notification handling does not rely on PF retransmission.

Keep the statistics target persistent and observe command completion
separately from firmware status. A later blocking QP or close result
fences earlier statistics DMA, including an error result. A pre-post
failure, posted timeout or NOWAIT posting does not establish completion.
This command ordering does not replace admin queue-stop proof.

Sashiko's feedback prompted this audit. The pre-existing failed-reset
reopen lifecycle and generic queue-disable error paths remain separate
follow-up work; this revision does not claim to fix them. Source review
and testing were assisted by LLM tools. The author is responsible for
the submitted changes.

Validation:

- V3 passed build and static checks at both patch boundaries. Sparse
  reported the same existing diagnostics as the public base.
- Full functional and interoperability tests passed with Cisco VIC PFs
  and V2 VFs, including a nonzero VF and all four combinations of the
  development ENIC and deployed async PF/VF drivers. Traffic covered
  bidirectional ICMP, TCP, UDP and jumbo frames.
- Tests covered station/address/filter and administrative-MAC policy
  changes, concurrent address updates and reopen, and multiple module
  reload, ring resize, interface reopen and VF destroy/recreate cycles.
- A test-only mailbox-send failure exercised reset recovery. The real
  send completed before the failure was injected; recovery restored
  traffic, and the uninstrumented candidate then reloaded successfully.
- Focused V3 tests verified queued PF notification delivery after VF-ID
  discovery, discovery-failure cleanup and statistics-buffer cleanup
  after a completed close. Fault injection let real DMA complete.
- Earlier fault-injection tests covered admin queue retry, quarantine,
  final removal cleanup and terminal retention. They let the real queues
  stop; they did not reproduce a physically stuck queue.

The functional and interoperability tests included later VF/PF feature
patches. These two fixes alone do not enable in-tree PF SR-IOV support.
Physical device removal was not tested; a physical DMA-engine failure
was not reproduced.

Signed-off-by: Satish Kharat <satishkh@cisco.com>
---
Changes in v3:
- Use observed blocking CMD_CLOSE completion, including an error result,
  to fence earlier statistics DMA in probe unwind and removal.
- Obtain the VF source ID after QP enable but before receive interrupts
  are unmasked, and permit sends before delivering queued notifications.
  Use the existing send gate instead of a redundant invalid-ID check.
- Validate delayed notifications, discovery failures and completed-close
  cleanup on a VF.
- Rerun the full functional suite and all four PF/VF driver pairings
  with the v3 fixes in the later VF/PF feature compositions.
- Clear local VF registration after channel close in both reset workers.
- Correct comments and explain quarantine, recovery and retention limits.
- Link to v2: https://patch.msgid.link/20261022-b4-enic-dma-vf-index-net-generic-first-v1-20261010-v2-0-8db19b4a714e@cisco.com

Changes in v2:
- Withdraw v1 patch 1's generic datapath quarantine proposal. Rewrite v1
  patch 2 as the first patch here, followed by the VF mailbox-source fix.
- Keep the admin buffers' lifetime separate from generic page pools and
  notification teardown. Keep bus mastering enabled at runtime.
- Bound longer polling to the two admin queues, preserve both RQ passes,
  and retry only a complete disable helper returning -ETIMEDOUT.
- Serialize remove/open and skip admin reopen after datapath-open failure.
- Observe DEVCMD2 transport completion independently of command success,
  including a completed QP error, without treating pre-post errors or
  NOWAIT posting as a fence.
- Clarify final remove recheck, terminal retention and reprobe limits.
- Link to v1: https://patch.msgid.link/20261016-b4-enic-dma-vf-index-net-generic-first-v1-20261010-v1-0-d27b55f69883@cisco.com

Cc: Andrew Lunn <andrew+netdev@lunn.ch>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@kernel.org>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>

---
Satish Kharat (2):
      enic: retain admin-channel DMA until queues stop
      enic: require DEVCMD2 and set the V2 VF mailbox source

 drivers/net/ethernet/cisco/enic/enic.h        |  22 ++-
 drivers/net/ethernet/cisco/enic/enic_admin.c  | 247 +++++++++++++++++++++-----
 drivers/net/ethernet/cisco/enic/enic_admin.h  |   4 +-
 drivers/net/ethernet/cisco/enic/enic_dev.c    |  44 +++++
 drivers/net/ethernet/cisco/enic/enic_dev.h    |   3 +
 drivers/net/ethernet/cisco/enic/enic_main.c   | 111 +++++++++++-
 drivers/net/ethernet/cisco/enic/enic_mbox.c   |  13 +-
 drivers/net/ethernet/cisco/enic/vnic_dev.c    |  85 ++++++++-
 drivers/net/ethernet/cisco/enic/vnic_dev.h    |  15 ++
 drivers/net/ethernet/cisco/enic/vnic_devcmd.h |  34 ++++
 10 files changed, 511 insertions(+), 67 deletions(-)
---
base-commit: 0df412012a26389582b120844d098e1e961f10a6
change-id: 20261010-b4-enic-dma-vf-index-net-generic-first-v1-20261010-d9abf4510335

Best regards,
--  
Satish Kharat <satishkh@cisco.com>


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-10-30 22:40 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-30 22:40 [PATCH net v3 1/2] enic: retain admin-channel DMA until queues stop netdev-bot+sashiko
  -- strict thread matches above, loose matches on Subject: below --
2026-10-27 15:15 [PATCH net v3 0/2] enic: retain admin DMA resources and identify V2 VFs Satish Kharat
2026-10-27 15:15 ` [PATCH net v3 1/2] enic: retain admin-channel DMA until queues stop Satish Kharat

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox