Re: [PATCH 3/3] mac80211: fix VLAN handling with TXQs

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Johannes Berg <johannes@sipsolutions.net> writes:

> On Mon, 2017-09-04 at 16:23 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wrote:
>>=20
>> Hmm, not apart from agreeing with you that it would be better to not
>> drop everything when removing a VLAN. Not sure how often this
>> happens, though (and hence how big of a problem it is). What happens
>> in scenarios where hostapd is setup to automatically generate a bunch
>> of VLANs for every client, for instance?
>
> I'm not sure. However, I think it's less bad than one might guess
> since it really should only affect multicast frames, right? All
> unicast frames should go directly to the per-STA TXQ.

Ah, right, that is the interface txq that is being purged. Gotcha.

But, erm, what happens with unicast traffic sent on the VLAN interface
when it goes down? Shouldn't that be purged from the per-station TXQs as
well?

> Right now, with TXQ, encrypted VLANs are completely broken, so surely
> it's a step in the right direction?

Yeah, fair point ;)

One nit with the patch:

> -	tx.sdata =3D vif_to_sdata(info->control.vif);
> +	if (info->control.vif)
> +		tx.sdata =3D vif_to_sdata(info->control.vif);

Why the conditional assignment? The code below unconditionally
dereferences tx.sdata, so if info->control.vif is null it is going to
crash anyway?

-Toke