https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237921
Bjoern A. Zeeb <b...@freebsd.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |b...@freebsd.org
Status|Open |In Progress
--- Comment #9 from Bjoern A. Zeeb <b...@freebsd.org> ---
(In reply to Yusuf Khan from comment #8)
I cannot follow the logic.
wpi_free_tx_ring() is called from device detach (ignoring the attach error
path); the mbuf/ring descriptor will not be used beyond that function anymore
at that stage so there is no need to set it to NULL anymore. That would just
be a NOP.
If there's still a reference to a ni at that stage, then other cleanup hasn't
worked at the beginning of wpi_detach(). There should be no more ni; in fact
that should also be no more mbuf attached on the TX ring so I would even
question if that code path is ever taken.
This function is basically doing the opposite of wpi_alloc_tx_ring().
wpi_reset_tx_ring() on the contrary leaves all resources in place and only
cleans up any outstanding transations and resets the ring to default values;
this happens in wpi_hw_stop(). And then the resources will be re-used again
after wpi_parent() goes through the bringup part again (a VAP/wlan interface is
brought up again).
So let me ask what lead to the original assumption that there may be a memory
leak and a possible use-after-free.
If you indeed believe that, I would love to know the code path which can
trigger it.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
