virtio_net: handle unexpected tx completion without panicking

[benhillis]

complete_tx_packet used .unwrap() on the pending packet lookup, which would panic if the backend returned a TxId that was out of range or already completed. Use get_mut().and_then() and log an error instead.

[Copilot]

Pull request overview

Updates virtio_net TX completion handling to avoid panics when the network backend reports an unexpected TxId, improving robustness at the backend/device boundary.

Changes:

• Replace unwrap() on pending_tx_packets lookup with a safe get_mut(...).and_then(...) pattern.
• Log and ignore unexpected TX completions instead of panicking.

[Copilot]

The log message here says "unknown packet", but this branch also triggers when the TxId is in range and the slot is already None (e.g., duplicate completion). Consider distinguishing the cases (out-of-range vs already-completed) and/or including the pending_tx_packets length in the log fields to make debugging misbehaving backends easier.

Suggested change

	let Some(mut tx_packet) = state
	.pending_tx_packets
	.get_mut(id.0 as usize)
	.and_then(|p| p.take())
	else {
	tracing::error!(tx_id = id.0, "unexpected tx completion for unknown packet");
	return Ok(());
	};
	let idx = id.0 as usize;
	let pending_len = state.pending_tx_packets.len();
	let Some(slot) = state.pending_tx_packets.get_mut(idx) else {
	tracing::error!(
	tx_id = id.0,
	tx_index = idx,
	pending_tx_packets_len = pending_len,
	"unexpected tx completion for out-of-range packet"
	);
	return Ok(());
	};
	let Some(mut tx_packet) = slot.take() else {
	tracing::error!(
	tx_id = id.0,
	tx_index = idx,
	pending_tx_packets_len = pending_len,
	"unexpected tx completion for already-completed packet"
	);
	return Ok(());
	};