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: <CAGsizzLD=0t_J5m=CdZn8+1j6ZD_Nmz352kydDKDqQKDK5nxSw@mail.gmail.com>
Date:	Tue, 24 Jan 2012 10:07:37 +0100
From:	Štefan Gula <steweg@...t.sk>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Patrick McHardy <kaber@...sh.net>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [patch v2, kernel version 3.2.1] Source mode for macvlan interface

2012/1/24 Eric Dumazet <eric.dumazet@...il.com>:
> Le mardi 24 janvier 2012 à 00:11 +0100, Stefan Gula a écrit :
>> From: Stefan Gula <steweg@...il.com>
>>
>> New mode of macvlan interface called "source" allows one to specify,
>> which  frames are allowed to be received by given macvlan interface.
>> This logic is used only on received frames on underlying interface.
>> The ability to send frames from macvlan interface through underlying
>> interface is not modified. This feature allows one to simulate 802.1x
>> mac based VLAN behavior by using proper netlink message to configure
>> this behavior with utility such as "ip link" from iproute2 suite.
>> This feature allows to create MAC based VLAN associations instead of
>> standard port or tag based, to be able to associate several different
>> clients/users behind one common port based on their MAC addresses.
>>
>
> Still obscure changelog...
>
>> Signed-off-by: Stefan Gula <steweg@...il.com>
>>
>
> Please include next time
>
> V3: list of changes
>
>
>
> Why GFP_ATOMIC here ?
changed to GFP_KERNEL

>
> How many 'sources' are expected per port ?
>
> Above a certain (small) threshold, macvlan_fill_info() will 'overflow'
> skb capacity and return an error.
>
> Take a look at macvlan_get_size() ?
There should be no defined limits on how many MAC addresses you can
put under one macvlan interface - it should be fully dynamic. You are
right about the function, but I have a difficulty with fixing that. It
is no problem to calculate the space needed to dump all mac-address,
but I tried to check how many times is macvlan_get_size called and it
is called only once per macvlan interface initialization, which is
obviously wrong in my case as I need that number to be changed each
time before fill_info is called. I tried to find and example how to
managed that from other drivers, but I was unsuccessful. Do you have
any idea?
--
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