On 2020/12/1 17:46, Jason A. Donenfeld wrote:
Hi Yang, On Tue, Dec 1, 2020 at 10:31 AM Yang Yingliang <[email protected]> wrote:After commit cf124db566e6 ("net: Fix inconsistent teardown and..."), priv_destruct() doesn't call free_netdev() in driver, we use dev->needs_free_netdev to indicate whether free_netdev() should be called on release path. This patch remove free_netdev() from priv_destructor() and set dev->needs_free_netdev to true.For now, nack. I remember when cf124db566e6 came out and carefully looking at the construction of device.c in WireGuard. priv_destructor is only assigned after register_device, with the various error paths in wg_newlink responsible for cleaning up other earlier failures, and trying to move to needs_free_netdev would have introduced more complexity in this particular case, if my memory serves. I do not think there's a memory leak here, and I worry about too hastily changing the state machine "just because". In other words, could you point out how to generate a memory leak? If you're correct, then we can start dissecting and refactoring this. But off the bat, I'm not sure I'm exactly seeing whatever you're seeing.
Yes, I missed that priv_destructor is only assigned after register_netdevice(),
so, it will not lead a double free in my patch#2, so this patch can be dropped and
send v3.
Jason .
