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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130803190918.GA11976@redhat.com>
Date:	Sat, 3 Aug 2013 21:09:18 +0200
From:	Veaceslav Falico <vfalico@...hat.com>
To:	David Miller <davem@...emloft.net>
Cc:	nikolay@...hat.com, 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 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.
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ