netdev - Re: [net] net_sched: make dev_trans_start return vlan's real dev trans

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51FD5B78.6000208@redhat.com>
Date:	Sat, 03 Aug 2013 21:35:20 +0200
From:	Nikolay Aleksandrov <nikolay@...hat.com>
To:	Veaceslav Falico <vfalico@...hat.com>
CC:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	fubar@...ibm.com, jhs@...atatu.com
Subject: Re: [net] net_sched: make dev_trans_start return vlan's real dev
 trans_start

On 08/03/2013 09:09 PM, Veaceslav Falico wrote:
> On Sat, Aug 03, 2013 at 11:52:28AM -0700, David Miller wrote:
>> From: Veaceslav Falico <vfalico@...hat.com>
>> Date: Sat, 3 Aug 2013 19:07:33 +0200
>>
>>> On Sat, Aug 03, 2013 at 05:07:51PM +0200, nikolay@...hat.com wrote:
>>> ...snip...
>>>> +    while (is_vlan_dev(dev))
>>>> +        dev = vlan_dev_real_dev(dev);
>>>
>>> While at it - I've checked a few users (mainly network drivers) of
>>> vlan_dev_real_dev(dev) and they all rely on that the return device
>>> would be the *real* device, but not another vlan.
>>
>> Did you find any cases that want the device under the VLAN,
>> whether it is a non-vlan device or not?
> 
> Not really. All of the cases seem to explicitly call it to get a non-vlan
> device, and not the purely 'underlying' one.
> 
> Another point is that they won't work properly with QinQ... cause the
> majority of callers are searching for their own device. Or bonding, as in
> netxen that Nik mentioned. And they will find yet another vlan device.
> 
> So either QinQ isn't really that used or I'm missing something...
> 
>>
>>> So maybe we should move this while loop to vlan_dev_real_dev()
>>> instead?
>>
>> Perhaps.  As per above, we may also need the one-level demux
>> helper too, something like "vlan_dev_slave(dev)".
> 
> I haven't found any usage for it, tbh. Only the vlan code itself might
> benefit from it, but it already uses the vlan_dev_priv(dev)->real_dev, and
> not the vlan_dev_real_dev(), which is used by drivers.
I agree with this. I also can't find users of the one-level variant, so I
think it'd be safe to go ahead and do it.
Just one question in case that we all agree -
Dave should I queue the patches (vlan change & net_sched's dev_trans_start)
for net-next or net would be fine ?

Thanks,
 Nik


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html