net: mana: HWC memory after a failed DESTROY_HWC

net: mana: HWC memory after a failed DESTROY_HWC

[Yuho Choi]

Hi Haiyang, Dexuan,

I have a question about the HWC teardown in mana_hwc_destroy_channel()
(drivers/net/ethernet/microsoft/mana/hw_channel.c, v7.4-rc1).

The function sends DESTROY_HWC but does not check the result, and then
frees the HWC queues and message buffers:

	if (gc->max_num_cqs > 0) {
		mana_smc_teardown_hwc(&gc->shm_channel, false);
		gc->max_num_cqs = 0;
	}

	if (hwc->txq)
		mana_hwc_destroy_wq(hwc, hwc->txq);
	...

mana_smc_teardown_hwc() itself says that waiting for the response "is
required to ensure hardware invalidates MST entries before software
frees memory". So I wonder what happens when the teardown fails, i.e.
when the PF returns an error (-EPROTO) or does not answer in time
(-ETIMEDOUT):

1. Can the hardware still write EQEs, CQEs or HWC responses to these
   pages after the driver has freed them?

2. Or is the function always reset in that case, so that nothing can
   reach the memory anymore? One case I have in mind is
   mana_serv_reset(), which calls mana_gd_suspend() while the HWC is
   not responding, so the teardown there may often fail.

If (1) is possible, I have a patch ready that keeps the HWC rings and
message buffers allocated when the teardown fails, leaking a few pages
instead of freeing memory the hardware may still use, and I would be
glad to send it. If (2) always holds, there is nothing to fix and I
will drop it.

This came from code inspection as part of ongoing, not yet published
research, and I have not reproduced it. I used an LLM to help with the
analysis and this mail.

Thanks,
Yuho