[PATCH] mac80211: clear lower drv private data on iface removal

[PATCH] mac80211: clear lower drv private data on iface removal

[Arik Nemtsov]

The lower driver might rely on getting zeroed per-vif private memory
when an interface is added. Resetting the memory on removal avoids
adverse affects during recovery, where the interface is added without
being removed.

Signed-off-by: Arik Nemtsov <arik@wizery.com>
---
 net/mac80211/driver-ops.h |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index d3d9fda..4620117 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -183,6 +183,10 @@ static inline void drv_remove_interface(struct ieee80211_local *local,
 	trace_drv_remove_interface(local, sdata);
 	local->ops->remove_interface(&local->hw, &sdata->vif);
 	sdata->flags &= ~IEEE80211_SDATA_IN_DRIVER;
+
+	/* clear driver specific private data */
+	memset(sdata->vif.drv_priv, 0, sdata->local->hw.vif_data_size);
+
 	trace_drv_return_void(local);
 }
 
-- 
1.7.9.5

Re: [PATCH] mac80211: clear lower drv private data on iface removal

[Johannes Berg]

On Thu, 2012-11-08 at 14:37 +0200, Arik Nemtsov wrote:
> The lower driver might rely on getting zeroed per-vif private memory
> when an interface is added. Resetting the memory on removal avoids
> adverse affects during recovery, where the interface is added without
> being removed.

However, it means that data isn't stable across suspend/resume, which
could be desirable to the driver as it may want to have the same
configuration after resuming.

I think we should therefore leave this to the driver, it's obviously
easily implemented as the last step of the driver's ->remove_interface()

johannes

Re: [PATCH] mac80211: clear lower drv private data on iface removal

[Arik Nemtsov]

On Thu, Nov 8, 2012 at 2:43 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Thu, 2012-11-08 at 14:37 +0200, Arik Nemtsov wrote:
>> The lower driver might rely on getting zeroed per-vif private memory
>> when an interface is added. Resetting the memory on removal avoids
>> adverse affects during recovery, where the interface is added without
>> being removed.
>
> However, it means that data isn't stable across suspend/resume, which
> could be desirable to the driver as it may want to have the same
> configuration after resuming.
>
> I think we should therefore leave this to the driver, it's obviously
> easily implemented as the last step of the driver's ->remove_interface()
>

Agreed.