linux-kernel - Re: [patch v2, kernel version 3.2.1] Source mode for macvlan interface

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]

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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/