* Re: linux-next: manual merge of the random tree with the net-next tree
From: Markos Chandras @ 2013-11-14 15:17 UTC (permalink / raw)
To: Stephen Rothwell, Daniel Borkmann
Cc: Theodore Ts'o, linux-next, linux-kernel, Hannes Frederic Sowa,
David Miller, netdev
In-Reply-To: <20131113074657.287f83d9669c8144865a77b6@canb.auug.org.au>
On 11/12/2013 08:46 PM, Stephen Rothwell wrote:
> Hi Daniel,
>
> On Tue, 12 Nov 2013 09:55:29 +0100 Daniel Borkmann <dborkman@redhat.com> wrote:
>>
>> On 11/12/2013 05:55 AM, Stephen Rothwell wrote:
>>>
>>> Today's linux-next merge of the random tree got a conflict in
>>> drivers/char/random.c between commit 0244ad004a54 ("random32: add
>>> prandom_reseed_late() and call when nonblocking pool becomes
>>> initialized") from the net-next tree and commit 301f0595c0e7 ("random:
>>> printk notifications for urandom pool initialization") from the random
>>> tree.
>>>
>>> I fixed it up (probably not properly - see below) and can carry the fix
>>> as necessary (no action is required).
>>
>> As per Hannes' suggestion, the result should look like (see cover
>> letter in [1]):
>>
>> if (r->entropy_total > 128) {
>> r->initialized = 1;
>> r->entropy_total = 0;
>> if (r == &nonblocking_pool) {
>> prandom_reseed_late();
>> pr_notice("random: %s pool is initialized\n",
>> r->name);
>> }
>> }
>
> I will use that from today. Thanks.
>
Hi Stephen,
This broke the build for MIPS for the malta_defconfig when using the
latest Mentor toolchain.
In file included from include/linux/fs.h:16:0,
from fs/fuse/fuse_i.h:13,
from fs/fuse/file.c:9:
fs/fuse/file.c: In function 'fuse_file_poll':
include/linux/rbtree.h:82:28: warning: 'parent' may be used
uninitialized in this function [-Wmaybe-uninitialized]
fs/fuse/file.c:2580:27: note: 'parent' was declared here
drivers/char/random.c: In function 'init_std_data':
drivers/char/random.c:1249:1: internal compiler error: in
add_insn_before, at emit-rtl.c:3857
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://sourcery.mentor.com/GNUToolchain/> for instructions.
make[2]: *** [drivers/char/random.o] Error 1
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs....
If you want to reproduce it you can do the following steps:
- Get a MIPS Mentor toolchain from
https://sourcery.mentor.com/GNUToolchain/release2554
- make ARCH=mips CROSS_COMPILE=$TOOLCHAIN_PATH/bin/mips-linux-gnu-
malta_defconfig
- make ARCH=mips CROSS_COMPILE=$TOOLCHAIN_PATH/bin/mips-linux-gnu-
We are working with the toolchain group to come up with a workaround in
the code to resolve the problem.
--
markos
^ permalink raw reply
* Re: [RFC][PATCH 0/3] net_tstamp: Add SIOCGHWTSTAMP ioctl
From: Ben Hutchings @ 2013-11-14 15:10 UTC (permalink / raw)
To: Richard Cochran; +Cc: David Miller, netdev, linux-net-drivers
In-Reply-To: <20131114074118.GC4908@netboy>
On Thu, 2013-11-14 at 08:41 +0100, Richard Cochran wrote:
> On Thu, Nov 14, 2013 at 02:37:15AM +0000, Ben Hutchings wrote:
> > SIOCSHWTSTAMP returns the real configuration to the application
> > using it, but there is currently no way for any other
> > application to find out the configuration non-destructively.
>
> I guess that the reasoning behind the original interface is that an
> application only wants to know the settings when it needs a particular
> setting in order to operate correctly. This would make the query call
> pointless, since the application might as well just go ahead and set
> the values that it needs.
>
> Do you have a particular use case in mind?
The immediate motivation is wanting to include this information in
diagnostic reports.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: Cannot send unicast Ethernet Frame from tap0 to tap1 via bridge
From: Albert Krenz @ 2013-11-14 15:08 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev
In-Reply-To: <5284E3C1.6030905@gmail.com>
ok, understood. Didn't know that the bridge handels the assigned
network devices as their own ports. Thought it's working like a
regular switch which ports have no mac address.
Thanks for your help.
Greetings
Albert Krenz
2013/11/14 Vlad Yasevich <vyasevich@gmail.com>:
> On 11/14/2013 06:09 AM, Albert Krenz wrote:
>>
>> Hello together,
>> i am experiencing a strange behaviour in a bridge which bridges two
>> tap Interfaces (namely tap0 and tap1) that are generated by two
>> C-Applications.
>>
>> It looks like the following:
>>
>> +------------------------+
>> +-----------------------+
>> | |
>> | |
>> | Application 1 | ------- tap0 ----- br1 ---- tap1 ----- |
>> Application 2 |
>> | |
>> | |
>> +------------------------+
>> +-----------------------+
>>
>> Application 1 creates tap0 and Application 2 creates tap1. The
>> creation of the devices is done like in
>> https://www.kernel.org/doc/Documentation/networking/tuntap.txt
>> Both Applications acces their respective tap-device via File-IO. The
>> bridge should bridge the network devices of both tap's.
>>
>> Here are the MAC-addresses of both tap devices (they only differ in
>> the last byte):
>> tap0: XX:XX:XX:XX:XX:B4
>> tap1: XX:XX:XX:XX:XX:B3
>>
>> What i want to accomplish is sending an Ethernet Frame (Layer 2, so no
>> IP Frames) from Application 1 to Application 2 and vice versa.
>> Therefore i am periodically (1 time per second) writing a Frame with
>> Dst-addr. of tap1 and Src-addr. of tap0 and vice-versa, to the
>> File-descriptor of the respectiv tap-device.
>
>
> This is your problem. You are trying to use the mac addresses assigned
> to the tap devices themselves. Those mac addresses identify the ports of
> the bridge and anything destined to those mac addresses is consumed
> by the bridge itself.
>
> This works just like any other bridge/switch. You typically address
> your packets to some device that sits behind the port, not to the port
> itself.
>
>
>> I can now check the traversing of the Frame via Wireshark from tap0 to
>> br1, but it never gets to tap1 and therefore Application 2 never
>> receives a Frame. Also in the other direction the Frames never pass
>> through br1 but get stuck.
>>
>> If i am not using the MAC-addr. of the TAP Devices but a random
>> unknown Dst-addr like XX:XX:XX:XX:XX:F0 (MAC address not known in the
>> bridge) it works like a charm and the Frame passes through the bridge
>> and is received by Application 1 or Application 2.
>> The same goes for Broadcast/Multicast addresses.
>>
>> I then tried disabling network Filtering via:
>> echo 0 > bridge-nf-call-arptables
>> echo 0 > bridge-nf-call-iptables
>> echo 0 > bridge-nf-call-ip6tables
>> but this didn't do the trick.
>>
>>
>> What also did not work was setting tap0/tap1/br1 into promiscuous
>> mode. Maybe i first have to add a routing rule via ebtables? I have
>> tried:
>> ebtables - A FORWARD -i br1 -o br1 -j ACCEPT
>> which i found on the internet and did also not work.
>>
>> My Questions is now: is it possible to bridge two tap devices to send
>> RAW Ethernet Frames between two Applications? I think this should work
>> cause it is similar to an KVM/QEMU setup where multiple Virtual Guest
>> OS's are also able to communicate between each other (via IP frames).
>> So does anyone have an idea what i am missing?
>
>
> Right. This works in QEMU/KVM because the packets are addressed to the
> guest which has a different HW address the the bridge port.
>
> What you can do is assign your application a mac address that is generated
> from the mac address of the tap device. Then use those
> addresses and it will work.
>
> -vlad
>
>>
>> Greetings
>> Albert Krenz
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply
* Re: [PATCH net v2 1/2] macvlan: introduce macvlan_dev_real_dev() helper function
From: Vlad Yasevich @ 2013-11-14 15:03 UTC (permalink / raw)
To: Michal Kubecek, netdev; +Cc: David S. Miller, Patrick McHardy, John Fastabend
In-Reply-To: <b4ca4f2204f0ffb0bd7f959192462944a8d846a4.1384436410.git.mkubecek@suse.cz>
On 11/14/2013 09:00 AM, Michal Kubecek wrote:
> Introduce helper function macvlan_dev_real_dev which returns the
> underlying device of a macvlan device, similar to vlan_dev_real_dev()
> for 802.1q VLAN devices.
>
> v2: IFF_MACVLAN flag and equivalent of is_macvlan_dev() were
> introduced in the meantime
>
> Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
> ---
> include/linux/if_macvlan.h | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/include/linux/if_macvlan.h b/include/linux/if_macvlan.h
> index c270285..ac9aab2 100644
> --- a/include/linux/if_macvlan.h
> +++ b/include/linux/if_macvlan.h
> @@ -119,4 +119,20 @@ extern int macvlan_link_register(struct rtnl_link_ops *ops);
> extern netdev_tx_t macvlan_start_xmit(struct sk_buff *skb,
> struct net_device *dev);
>
> +#if IS_ENABLED(CONFIG_MACVLAN)
> +static inline struct net_device *
> +macvlan_dev_real_dev(const struct net_device *dev)
> +{
> + struct macvlan_dev *macvlan = netdev_priv(dev);
> +
> + return macvlan->lowerdev;
> +}
> +#else
> +static inline struct net_device *
> +macvlan_dev_real_dev(const struct net_device *dev)
> +{
> + return NULL;
> +}
> +#endif
> +
You may want to do the same here as was done for vlan_dev_real_dev().
This function is not intended to be called blindly and should always
be called after netif_is_macvlan().
-vlad
> #endif /* _LINUX_IF_MACVLAN_H */
>
^ permalink raw reply
* Re: Cannot send unicast Ethernet Frame from tap0 to tap1 via bridge
From: Vlad Yasevich @ 2013-11-14 14:52 UTC (permalink / raw)
To: Albert Krenz, netdev
In-Reply-To: <CAPRaSD6LX4BP51u0kJ6r7OEQHPyykrS+9we9bK6GnB3hbWRAVQ@mail.gmail.com>
On 11/14/2013 06:09 AM, Albert Krenz wrote:
> Hello together,
> i am experiencing a strange behaviour in a bridge which bridges two
> tap Interfaces (namely tap0 and tap1) that are generated by two
> C-Applications.
>
> It looks like the following:
>
> +------------------------+
> +-----------------------+
> | |
> | |
> | Application 1 | ------- tap0 ----- br1 ---- tap1 ----- |
> Application 2 |
> | |
> | |
> +------------------------+
> +-----------------------+
>
> Application 1 creates tap0 and Application 2 creates tap1. The
> creation of the devices is done like in
> https://www.kernel.org/doc/Documentation/networking/tuntap.txt
> Both Applications acces their respective tap-device via File-IO. The
> bridge should bridge the network devices of both tap's.
>
> Here are the MAC-addresses of both tap devices (they only differ in
> the last byte):
> tap0: XX:XX:XX:XX:XX:B4
> tap1: XX:XX:XX:XX:XX:B3
>
> What i want to accomplish is sending an Ethernet Frame (Layer 2, so no
> IP Frames) from Application 1 to Application 2 and vice versa.
> Therefore i am periodically (1 time per second) writing a Frame with
> Dst-addr. of tap1 and Src-addr. of tap0 and vice-versa, to the
> File-descriptor of the respectiv tap-device.
This is your problem. You are trying to use the mac addresses assigned
to the tap devices themselves. Those mac addresses identify the ports
of the bridge and anything destined to those mac addresses is consumed
by the bridge itself.
This works just like any other bridge/switch. You typically address
your packets to some device that sits behind the port, not to the port
itself.
> I can now check the traversing of the Frame via Wireshark from tap0 to
> br1, but it never gets to tap1 and therefore Application 2 never
> receives a Frame. Also in the other direction the Frames never pass
> through br1 but get stuck.
>
> If i am not using the MAC-addr. of the TAP Devices but a random
> unknown Dst-addr like XX:XX:XX:XX:XX:F0 (MAC address not known in the
> bridge) it works like a charm and the Frame passes through the bridge
> and is received by Application 1 or Application 2.
> The same goes for Broadcast/Multicast addresses.
>
> I then tried disabling network Filtering via:
> echo 0 > bridge-nf-call-arptables
> echo 0 > bridge-nf-call-iptables
> echo 0 > bridge-nf-call-ip6tables
> but this didn't do the trick.
>
>
> What also did not work was setting tap0/tap1/br1 into promiscuous
> mode. Maybe i first have to add a routing rule via ebtables? I have
> tried:
> ebtables - A FORWARD -i br1 -o br1 -j ACCEPT
> which i found on the internet and did also not work.
>
> My Questions is now: is it possible to bridge two tap devices to send
> RAW Ethernet Frames between two Applications? I think this should work
> cause it is similar to an KVM/QEMU setup where multiple Virtual Guest
> OS's are also able to communicate between each other (via IP frames).
> So does anyone have an idea what i am missing?
Right. This works in QEMU/KVM because the packets are addressed to the
guest which has a different HW address the the bridge port.
What you can do is assign your application a mac address that is
generated from the mac address of the tap device. Then use those
addresses and it will work.
-vlad
>
> Greetings
> Albert Krenz
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net] sit: fix use after free of fb_tunnel_dev
From: Eric Dumazet @ 2013-11-14 14:47 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: davem, edumazet, nicolas.dichtel, netdev
In-Reply-To: <1384396058-26850-1-git-send-email-willemb@google.com>
On Wed, 2013-11-13 at 21:27 -0500, Willem de Bruijn wrote:
> Bug: The fallback device is created in sit_init_net and assumed to be
> freed in sit_exit_net. First, it is dereferenced in that function, in
> sit_destroy_tunnels:
>
> struct net *net = dev_net(sitn->fb_tunnel_dev);
>
> Prior to this, rtnl_unlink_register has removed all devices that match
> rtnl_link_ops == sit_link_ops.
>
> Commit 205983c43700 added the line
>
> + sitn->fb_tunnel_dev->rtnl_link_ops = &sit_link_ops;
>
> which cases the fallback device to match here and be freed before it
> is last dereferenced.
>
> Fix: This commit adds an explicit .delllink callback to sit_link_ops
> that skips deallocation at rtnl_unlink_register for the fallback
> device. This mechanism is comparable to the one in ip_tunnel.
>
> It also modifies sit_destroy_tunnels and its only caller sit_exit_net
> to avoid the offending dereference in the first place. That double
> lookup is more complicated than required.
>
> Test: The bug is only triggered when CONFIG_NET_NS is enabled. It
> causes a GPF only when CONFIG_DEBUG_SLAB is enabled. Verified that
> this bug exists at the mentioned commit, at davem-net HEAD and at
> 3.11.y HEAD. Verified that it went away after applying this patch.
>
> Fixes: 205983c43700 ("sit: allow to use rtnl ops on fb tunnel")
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
>
> ---
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* [PATCH net] ip6tnl: fix use after free of fb_tnl_dev
From: Nicolas Dichtel @ 2013-11-14 14:47 UTC (permalink / raw)
To: rostedt
Cc: linux-kernel, stable, gregkh, williams, linux-rt-users, lclaudio,
davem, netdev, Nicolas Dichtel, Willem de Bruijn
In-Reply-To: <20131113211430.1ad3bb7d@gandalf.local.home>
Bug has been introduced by commit bb8140947a24 ("ip6tnl: allow to use rtnl ops
on fb tunnel").
When ip6_tunnel.ko is unloaded, FB device is delete by rtnl_link_unregister()
and then we try to use the pointer in ip6_tnl_destroy_tunnels().
Let's add an handler for dellink, which will never remove the FB tunnel. With
this patch it will no more be possible to remove it via 'ip link del ip6tnl0',
but it's safer.
The same fix was already proposed by Willem de Bruijn <willemb@google.com> for
sit interfaces.
CC: Willem de Bruijn <willemb@google.com>
Reported-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv6/ip6_tunnel.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 583b77e2f69b..c1e11b5d6ccc 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1635,6 +1635,15 @@ static int ip6_tnl_changelink(struct net_device *dev, struct nlattr *tb[],
return ip6_tnl_update(t, &p);
}
+static void ip6_tnl_dellink(struct net_device *dev, struct list_head *head)
+{
+ struct net *net = dev_net(dev);
+ struct ip6_tnl_net *ip6n = net_generic(net, ip6_tnl_net_id);
+
+ if (dev != ip6n->fb_tnl_dev)
+ unregister_netdevice_queue(dev, head);
+}
+
static size_t ip6_tnl_get_size(const struct net_device *dev)
{
return
@@ -1699,6 +1708,7 @@ static struct rtnl_link_ops ip6_link_ops __read_mostly = {
.validate = ip6_tnl_validate,
.newlink = ip6_tnl_newlink,
.changelink = ip6_tnl_changelink,
+ .dellink = ip6_tnl_dellink,
.get_size = ip6_tnl_get_size,
.fill_info = ip6_tnl_fill_info,
};
@@ -1715,9 +1725,9 @@ static struct xfrm6_tunnel ip6ip6_handler __read_mostly = {
.priority = 1,
};
-static void __net_exit ip6_tnl_destroy_tunnels(struct ip6_tnl_net *ip6n)
+static void __net_exit ip6_tnl_destroy_tunnels(struct net *net)
{
- struct net *net = dev_net(ip6n->fb_tnl_dev);
+ struct ip6_tnl_net *ip6n = net_generic(net, ip6_tnl_net_id);
struct net_device *dev, *aux;
int h;
struct ip6_tnl *t;
@@ -1785,10 +1795,8 @@ err_alloc_dev:
static void __net_exit ip6_tnl_exit_net(struct net *net)
{
- struct ip6_tnl_net *ip6n = net_generic(net, ip6_tnl_net_id);
-
rtnl_lock();
- ip6_tnl_destroy_tunnels(ip6n);
+ ip6_tnl_destroy_tunnels(net);
rtnl_unlock();
}
--
1.8.4.1
^ permalink raw reply related
* [PATCH 1/2] netfilter: synproxy: send mss option to backend
From: Martin Topholm @ 2013-11-14 14:35 UTC (permalink / raw)
To: pablo; +Cc: brouer, kaber, netfilter-devel, netdev
In-Reply-To: <1384439731-16296-1-git-send-email-mph@one.com>
When the synproxy_parse_options is called on the client ack the mss
option will not be present. Consequently mss wont be included in the
backend syn packet, which falls back to 536 bytes mss.
Therefore XT_SYNPROXY_OPT_MSS is explicitly flagged when recovering mss
value from cookie.
Signed-off-by: Martin Topholm <mph@one.com>
Reviewed-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
net/ipv4/netfilter/ipt_SYNPROXY.c | 1 +
net/ipv6/netfilter/ip6t_SYNPROXY.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/net/ipv4/netfilter/ipt_SYNPROXY.c b/net/ipv4/netfilter/ipt_SYNPROXY.c
index 01cffea..f13bd91 100644
--- a/net/ipv4/netfilter/ipt_SYNPROXY.c
+++ b/net/ipv4/netfilter/ipt_SYNPROXY.c
@@ -244,6 +244,7 @@ synproxy_recv_client_ack(const struct synproxy_net *snet,
this_cpu_inc(snet->stats->cookie_valid);
opts->mss = mss;
+ opts->options |= XT_SYNPROXY_OPT_MSS;
if (opts->options & XT_SYNPROXY_OPT_TIMESTAMP)
synproxy_check_timestamp_cookie(opts);
diff --git a/net/ipv6/netfilter/ip6t_SYNPROXY.c b/net/ipv6/netfilter/ip6t_SYNPROXY.c
index bf9f612..f78f41a 100644
--- a/net/ipv6/netfilter/ip6t_SYNPROXY.c
+++ b/net/ipv6/netfilter/ip6t_SYNPROXY.c
@@ -259,6 +259,7 @@ synproxy_recv_client_ack(const struct synproxy_net *snet,
this_cpu_inc(snet->stats->cookie_valid);
opts->mss = mss;
+ opts->options |= XT_SYNPROXY_OPT_MSS;
if (opts->options & XT_SYNPROXY_OPT_TIMESTAMP)
synproxy_check_timestamp_cookie(opts);
^ permalink raw reply related
* [PATCH 0/2] Netfilter SYNPROXY mss and wscale bugfix
From: Martin Topholm @ 2013-11-14 14:35 UTC (permalink / raw)
To: pablo; +Cc: brouer, kaber, netfilter-devel, netdev
The following series fixes two bugs we have discovered in the netfilter
module SYNPROXY.
The first is related to the mss option not getting transferred to the
backend servers.
And the second it related to passing of the windows scaling option.
Martin Topholm (2):
netfilter: synproxy: send mss option to backend
netfilter: synproxy: correct wscale option passing
net/ipv4/netfilter/ipt_SYNPROXY.c | 1 +
net/ipv6/netfilter/ip6t_SYNPROXY.c | 1 +
net/netfilter/nf_synproxy_core.c | 7 ++++---
3 files changed, 6 insertions(+), 3 deletions(-)
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Vlad Yasevich @ 2013-11-14 14:41 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG, Veaceslav Falico, Vlad Yasevich
Cc: Linux Netdev List
In-Reply-To: <5284DE65.40105@profihost.ag>
On 11/14/2013 09:29 AM, Stefan Priebe - Profihost AG wrote:
> Am 14.11.2013 15:27, schrieb Vlad Yasevich:
>> On 11/14/2013 06:54 AM, Veaceslav Falico wrote:
>>> On Wed, Nov 13, 2013 at 10:09:30PM -0500, Vlad Yasevich wrote:
>>>> Can you try out attached patch please. I ran it in my environment and
>>>> always get promisc link when attaching devices to the bridge.
>>>
>>> It's interesting, actually, why do we need to check for IFF_UP at all
>>> when
>>> changing flags.
>>>
>>> The addition of IFF_UP goes up to:
>>>
>>> commit b6c40d68ff6498b7f63ddf97cf0aa818d748dee7
>>> Author: Patrick McHardy <kaber@trash.net>
>>> Date: Tue Oct 7 15:26:48 2008 -0700
>>>
>>> net: only invoke dev->change_rx_flags when device is UP
>>>
>>> Jesper Dangaard Brouer <hawk@comx.dk> reported a bug when setting a
>>> VLAN
>>> device down that is in promiscous mode:
>>>
>>> When the VLAN device is set down, the promiscous count on the real
>>> device is decremented by one by vlan_dev_stop(). When removing the
>>> promiscous flag from the VLAN device afterwards, the promiscous
>>> count on the real device is decremented a second time by the
>>> vlan_change_rx_flags() callback.
>>>
>>> ... snip ...
>>>
>>
>> This was applied in 2.6.27 timeframe.
>>
>>> However, I'm not sure that this is still needed, cause:
>>>
>>> commit deede2fabe24e00bd7e246eb81cd5767dc6fcfc7
>>> Author: Matthijs Kooijman <matthijs@stdin.nl>
>>> Date: Mon Oct 31 04:53:13 2011 +0000
>>>
>>> vlan: Don't propagate flag changes on down interfaces.
>>>
>>> When (de)configuring a vlan interface, the IFF_ALLMULTI ans
>>> IFF_PROMISC
>>> flags are cleared or set on the underlying interface. So, if these
>>> flags
>>> are changed on a vlan interface that is not up, the flags underlying
>>> interface might be set or cleared twice.
>>>
>>> Only propagating flag changes when a device is up makes sure this
>>> does
>>> not happen. It also makes sure that an underlying device is not
>>> set to
>>> promiscuous or allmulti mode for a vlan device that is down.
>>>
>>> ... snip ...
>>>
>>
>> And this in 3.2. So how did this work for Stefan in 3.9? Unless there
>> is something in Ubuntu that changed how the stacked interfaces are
>> configured and is keeping interfaces down longer then it used to.
>
> Stop here ;-) in 3.9 it was the other way round.
>
> This one worked:
>> eth2
>> \
>> -- bond1 -- vmbr1
>> / \
>> eth3 \ vmbr1.3000
>> \ ---- tap114i1
>
How are you attaching tap to the vlan device? Or is it attached to
vmbr1?
> this one did not:
>> eth2
>> \
>> -- bond1 -- vmbr1
>> / \
>> eth3 ----- bond1.3000 --- vmbr1v3000
>> \ ---- tap114i1
>
> Now with the patch - the 2nd one works the first one does not.
Ok, in this case, you have a VLAN (bond1.3000) configured on top of
bond interface. That vlan is then attached to the bridge (vmbr1v3000).
The tap interface for your VM (tap114i1) is also attached to the same
bridge. In this case, VM will receive only traffic for VLAN 3000 and
it we receive it untagged.
I guess I'd like to understand what you are trying to achieve.
Thanks working with us on this.
-vlad
>
> Stefan
>
>>> which fixed completely the initial issue with vlans.
>>>
>>> Maybe we should just remove the IFF_UP check in dev_change_rx_flags(),
>>> and
>>> let the drivers using it handle its own logic, as vlan does?
>>>
>>
>> This should work, but this might regress a few drivers. Looking through
>> the callers of dev_set_promiscuity at least DSA driver suffers
>> the same fate as VLAN.
>>
>> -vlad
>>
>>> Something like this:
>>>
>>> diff --git a/net/core/dev.c b/net/core/dev.c
>>> index 8ffc52e..9615cd7 100644
>>> --- a/net/core/dev.c
>>> +++ b/net/core/dev.c
>>> @@ -4995,7 +4995,7 @@ static void dev_change_rx_flags(struct net_device
>>> *dev, int flags)
>>> {
>>> const struct net_device_ops *ops = dev->netdev_ops;
>>>
>>> - if ((dev->flags & IFF_UP) && ops->ndo_change_rx_flags)
>>> + if (ops->ndo_change_rx_flags)
>>> ops->ndo_change_rx_flags(dev, flags);
>>> }
>>>
>>>
>>>>
>>>> Thanks
>>>> -vlad
>>
^ permalink raw reply
* Re: [PATCH 0/2] Netfilter SYNPROXY mss and wscale bugfix
From: Jesper Dangaard Brouer @ 2013-11-14 14:41 UTC (permalink / raw)
To: Martin Topholm; +Cc: pablo, brouer, kaber, netfilter-devel, netdev
In-Reply-To: <1384439731-16296-1-git-send-email-mph@one.com>
On Thu, 14 Nov 2013 15:35:29 +0100
Martin Topholm <mph@one.com> wrote:
> The following series fixes two bugs we have discovered in the netfilter
> module SYNPROXY.
>
> The first is related to the mss option not getting transferred to the
> backend servers.
>
> And the second it related to passing of the windows scaling option.
>
> Martin Topholm (2):
> netfilter: synproxy: send mss option to backend
> netfilter: synproxy: correct wscale option passing
>
> net/ipv4/netfilter/ipt_SYNPROXY.c | 1 +
> net/ipv6/netfilter/ip6t_SYNPROXY.c | 1 +
> net/netfilter/nf_synproxy_core.c | 7 ++++---
> 3 files changed, 6 insertions(+), 3 deletions(-)
ACK series
I have already reviewed the patches offlist with Martin and helped him
on howto submit patches etc.. Nice work Martin :-)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH 1/3] net: sched: tbf: fix calculation of max_size
From: Eric Dumazet @ 2013-11-14 14:38 UTC (permalink / raw)
To: Yang Yingliang; +Cc: davem, netdev
In-Reply-To: <1384419714-24364-2-git-send-email-yangyingliang@huawei.com>
On Thu, 2013-11-14 at 17:01 +0800, Yang Yingliang wrote:
> Current max_size is caluated from rate table.
> Now, the rate table has been replaced and it's
> not proper to caculate max_size with rate64.
> Use psched_ns_t2l to calculate the max_size.
>
> psched_ns_t2l():convert time in ns to length in
> bytes which to determinate how many bytes can be
> sent in given time.
I have no evidence you fix a real bug.
Please provide a tc script and show us it breaks.
Also CC Jesper you wrote this code.
^ permalink raw reply
* Re: [PATCH 2/3] net: sched: htb: fix condition of failure when rate is 0
From: Eric Dumazet @ 2013-11-14 14:37 UTC (permalink / raw)
To: Yang Yingliang; +Cc: davem, netdev
In-Reply-To: <1384419714-24364-3-git-send-email-yangyingliang@huawei.com>
On Thu, 2013-11-14 at 17:01 +0800, Yang Yingliang wrote:
> When rate32 is 0, it doesn't means wrong.
> Because htb support 64bit rates now, it
> could use rate64.
> So change the condition, when rate32 and
> rate64 are both 0, it goes to failure.
This is not needed at all and buggy.
User land is supposed to provide a not zero 32bit rate.
If it does, too bad. We have to fail.
^ permalink raw reply
* Re: [RFC 0/7] genetlink: reduce ops size and complexity
From: Johannes Berg @ 2013-11-14 14:36 UTC (permalink / raw)
To: netdev
In-Reply-To: <1384420486-8713-1-git-send-email-johannes@sipsolutions.net>
On Thu, 2013-11-14 at 10:14 +0100, Johannes Berg wrote:
> This series of patches updates a few genetlink users and then
> makes the ops a static const array, reducing kernel size and
> code complexity.
FWIW, for the full series (including patches 8 and 9) we get
drivers/net/team/team.c | 2
drivers/net/wireless/mac80211_hwsim.c | 2
include/net/genetlink.h | 17 +---
kernel/taskstats.c | 39 +++------
net/core/drop_monitor.c | 2
net/hsr/hsr_netlink.c | 46 ++++-------
net/ieee802154/ieee802154.h | 19 ++++
net/ieee802154/netlink.c | 28 +++++--
net/ieee802154/nl-mac.c | 61 ++-------------
net/ieee802154/nl-phy.c | 37 +--------
net/ipv4/tcp_metrics.c | 2
net/irda/irnetlink.c | 2
net/l2tp/l2tp_netlink.c | 2
net/netfilter/ipvs/ip_vs_ctl.c | 2
net/netlabel/netlabel_cipso_v4.c | 2
net/netlabel/netlabel_mgmt.c | 2
net/netlabel/netlabel_unlabeled.c | 2
net/netlink/genetlink.c | 133
+++++++++-------------------------
net/nfc/netlink.c | 2
net/openvswitch/datapath.c | 10 +-
net/wimax/op-msg.c | 25 ------
net/wimax/op-reset.c | 17 ----
net/wimax/op-rfkill.c | 21 -----
net/wimax/op-state-get.c | 17 ----
net/wimax/stack.c | 79 ++++++++++----------
net/wimax/wimax-internal.h | 7 +
net/wireless/nl80211.c | 2
27 files changed, 190 insertions(+), 390 deletions(-)
johannes
^ permalink raw reply
* [PATCH 2/2] netfilter: synproxy: correct wscale option passing
From: Martin Topholm @ 2013-11-14 14:35 UTC (permalink / raw)
To: pablo; +Cc: brouer, kaber, netfilter-devel, netdev
In-Reply-To: <1384439731-16296-1-git-send-email-mph@one.com>
Timestamp are used to store additional syncookie parameters such as sack,
ecn, and wscale. The wscale value we need to encode is the client's
wscale, since we can't recover that later in the session. Next overwrite
the wscale option so the later synproxy_send_client_synack will send
the backend's wscale to the client.
Signed-off-by: Martin Topholm <mph@one.com>
Reviewed-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
net/netfilter/nf_synproxy_core.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/netfilter/nf_synproxy_core.c b/net/netfilter/nf_synproxy_core.c
index cdf4567..9858e3e 100644
--- a/net/netfilter/nf_synproxy_core.c
+++ b/net/netfilter/nf_synproxy_core.c
@@ -151,9 +151,10 @@ void synproxy_init_timestamp_cookie(const struct xt_synproxy_info *info,
opts->tsecr = opts->tsval;
opts->tsval = tcp_time_stamp & ~0x3f;
- if (opts->options & XT_SYNPROXY_OPT_WSCALE)
- opts->tsval |= info->wscale;
- else
+ if (opts->options & XT_SYNPROXY_OPT_WSCALE) {
+ opts->tsval |= opts->wscale;
+ opts->wscale = info->wscale;
+ } else
opts->tsval |= 0xf;
if (opts->options & XT_SYNPROXY_OPT_SACK_PERM)
^ permalink raw reply related
* Re: [PATCH iproute2] htb: support 64bit rates
From: Eric Dumazet @ 2013-11-14 14:32 UTC (permalink / raw)
To: Yang Yingliang; +Cc: Stephen Hemminger, netdev
In-Reply-To: <528483CE.6050100@huawei.com>
On Thu, 2013-11-14 at 16:03 +0800, Yang Yingliang wrote:
> On 2013/11/13 22:21, Eric Dumazet wrote:
> > On Wed, 2013-11-13 at 17:11 +0800, Yang Yingliang wrote:
> >>> - if (!buffer) buffer = opt.rate.rate / get_hz() + mtu;
> >>> - if (!cbuffer) cbuffer = opt.ceil.rate / get_hz() + mtu;
> >>> + if (!buffer)
> >>> + buffer = rate64 / get_hz() + mtu;
> >>> + if (!cbuffer)
> >>> + cbuffer = ceil64 / get_hz() + mtu;
> >>
> >> Hi,
> >> It may overflow here if rate64 and mtu are big enough.
> >
> > Not really.
> >
> > get_hz() on current kernels is really huge : 1000000000
>
> Yeah, in normal condition, it won't happen.
> If user make a wrong input, such as "rate 0x800000000Gbit",
> Overflow happens. Although it has no impact on the value of the "opt.buffer".
> If it's better to have a judgement of the buffer's value. :)
Oh well, I can see you never really used HTB on high rates.
I'll send a v2 so that you can feel better ;)
^ permalink raw reply
* Re: [RFC PATCH net-next 2/2] udp: add sk opt to allow sending pkt with src 0.0.0.0
From: Hannes Frederic Sowa @ 2013-11-14 14:31 UTC (permalink / raw)
To: David Miller
Cc: nicolas.dichtel, netdev, David.Laight, jiri, vyasevich, kuznet,
jmorris, yoshfuji, kaber, thaller, stephen
In-Reply-To: <20131111.001803.110603937316567461.davem@davemloft.net>
On Mon, Nov 11, 2013 at 12:18:03AM -0500, David Miller wrote:
> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> Date: Sat, 9 Nov 2013 01:54:34 +0100
>
> > This feature allows to a send packets with address source set to 0.0.0.0 even if
> > an ip address is available on another interface.
> >
> > It's useful for DHCP client, to allow them to use UDP sockets and be compliant
> > with the RFC2131, Section 4.1:
> >
> > 4.1 Constructing and sending DHCP messages
> > ...
> > DHCP messages broadcast by a client prior to that client obtaining
> > its IP address must have the source address field in the IP header
> > set to 0.
> >
> > Based on a previous work from
> > Guillaume Gaudonville <guillaume.gaudonville@6wind.com>.
> >
> > Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>
> This requirement of the RFC is inconsistent with a host based
> addressing model, that which Linux employs, it assumes an interface
> based one.
>
> The wording here is also very ambiguous.
>
> This RFC fails to even remotely consider what the right behavior
> should be in a host based addressing environment at all, and anyone
> reading this RFC should just accept that.
>
> Furthermore, the fact that you're implementing _addressing_ policy in
> the UDP code makes this change even more unreasonable.
I agree on this and will check how other operating systems which only
use sockets do deal with that.
Do you have an idea how to deal with the rp_filter issue if no ip address is
set? Should we relax it in such cases?
Greetings,
Hannes
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Stefan Priebe - Profihost AG @ 2013-11-14 14:29 UTC (permalink / raw)
To: Vlad Yasevich, Veaceslav Falico, Vlad Yasevich; +Cc: Linux Netdev List
In-Reply-To: <5284DDCE.4090901@gmail.com>
Am 14.11.2013 15:27, schrieb Vlad Yasevich:
> On 11/14/2013 06:54 AM, Veaceslav Falico wrote:
>> On Wed, Nov 13, 2013 at 10:09:30PM -0500, Vlad Yasevich wrote:
>>> Can you try out attached patch please. I ran it in my environment and
>>> always get promisc link when attaching devices to the bridge.
>>
>> It's interesting, actually, why do we need to check for IFF_UP at all
>> when
>> changing flags.
>>
>> The addition of IFF_UP goes up to:
>>
>> commit b6c40d68ff6498b7f63ddf97cf0aa818d748dee7
>> Author: Patrick McHardy <kaber@trash.net>
>> Date: Tue Oct 7 15:26:48 2008 -0700
>>
>> net: only invoke dev->change_rx_flags when device is UP
>>
>> Jesper Dangaard Brouer <hawk@comx.dk> reported a bug when setting a
>> VLAN
>> device down that is in promiscous mode:
>>
>> When the VLAN device is set down, the promiscous count on the real
>> device is decremented by one by vlan_dev_stop(). When removing the
>> promiscous flag from the VLAN device afterwards, the promiscous
>> count on the real device is decremented a second time by the
>> vlan_change_rx_flags() callback.
>>
>> ... snip ...
>>
>
> This was applied in 2.6.27 timeframe.
>
>> However, I'm not sure that this is still needed, cause:
>>
>> commit deede2fabe24e00bd7e246eb81cd5767dc6fcfc7
>> Author: Matthijs Kooijman <matthijs@stdin.nl>
>> Date: Mon Oct 31 04:53:13 2011 +0000
>>
>> vlan: Don't propagate flag changes on down interfaces.
>>
>> When (de)configuring a vlan interface, the IFF_ALLMULTI ans
>> IFF_PROMISC
>> flags are cleared or set on the underlying interface. So, if these
>> flags
>> are changed on a vlan interface that is not up, the flags underlying
>> interface might be set or cleared twice.
>>
>> Only propagating flag changes when a device is up makes sure this
>> does
>> not happen. It also makes sure that an underlying device is not
>> set to
>> promiscuous or allmulti mode for a vlan device that is down.
>>
>> ... snip ...
>>
>
> And this in 3.2. So how did this work for Stefan in 3.9? Unless there
> is something in Ubuntu that changed how the stacked interfaces are
> configured and is keeping interfaces down longer then it used to.
Stop here ;-) in 3.9 it was the other way round.
This one worked:
> eth2
> \
> -- bond1 -- vmbr1
> / \
> eth3 \ vmbr1.3000
> \ ---- tap114i1
this one did not:
> eth2
> \
> -- bond1 -- vmbr1
> / \
> eth3 ----- bond1.3000 --- vmbr1v3000
> \ ---- tap114i1
Now with the patch - the 2nd one works the first one does not.
Stefan
>> which fixed completely the initial issue with vlans.
>>
>> Maybe we should just remove the IFF_UP check in dev_change_rx_flags(),
>> and
>> let the drivers using it handle its own logic, as vlan does?
>>
>
> This should work, but this might regress a few drivers. Looking through
> the callers of dev_set_promiscuity at least DSA driver suffers
> the same fate as VLAN.
>
> -vlad
>
>> Something like this:
>>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 8ffc52e..9615cd7 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -4995,7 +4995,7 @@ static void dev_change_rx_flags(struct net_device
>> *dev, int flags)
>> {
>> const struct net_device_ops *ops = dev->netdev_ops;
>>
>> - if ((dev->flags & IFF_UP) && ops->ndo_change_rx_flags)
>> + if (ops->ndo_change_rx_flags)
>> ops->ndo_change_rx_flags(dev, flags);
>> }
>>
>>
>>>
>>> Thanks
>>> -vlad
>
^ permalink raw reply
* Re: [PATCH iproute2] htb: support 64bit rates
From: Eric Dumazet @ 2013-11-14 14:28 UTC (permalink / raw)
To: Yang Yingliang; +Cc: Stephen Hemminger, netdev
In-Reply-To: <528485D0.5030300@huawei.com>
On Thu, 2013-11-14 at 16:12 +0800, Yang Yingliang wrote:
> On 2013/11/13 6:34, Eric Dumazet wrote:
>
> [...]
> > @@ -256,6 +270,7 @@ static int htb_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
> > struct tc_htb_glob *gopt;
> > double buffer,cbuffer;
> > unsigned int linklayer;
> > + __u64 rate64, ceil64;
> > SPRINT_BUF(b1);
> > SPRINT_BUF(b2);
> > SPRINT_BUF(b3);
> > @@ -275,12 +290,25 @@ static int htb_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
> > if (show_details)
> > fprintf(f, "quantum %d ", (int)hopt->quantum);
> > }
> > - fprintf(f, "rate %s ", sprint_rate(hopt->rate.rate, b1));
> > +
> > + rate64 = hopt->rate.rate;
> > + if (tb[TCA_HTB_RATE64] &&
> > + RTA_PAYLOAD(tb[TCA_HTB_RATE64]) >= sizeof(rate64)) {
> > + rate64 = rta_getattr_u64(tb[TCA_HTB_RATE64]);
> > + }
> > +
>
> If RTA_PAYLOAD(tb[TCA_HTB_RATE64]) < sizeof(rate64),
> it means something wrong, it don't need to continue,
> "return -1" would be better.
Nothing wrong actually.
Checking for these conditions are absolutely normal, to maintain
compatibility between old/new tc and or kernels.
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Vlad Yasevich @ 2013-11-14 14:27 UTC (permalink / raw)
To: Veaceslav Falico, Vlad Yasevich; +Cc: Stefan Priebe, Linux Netdev List
In-Reply-To: <20131114115451.GT19702@redhat.com>
On 11/14/2013 06:54 AM, Veaceslav Falico wrote:
> On Wed, Nov 13, 2013 at 10:09:30PM -0500, Vlad Yasevich wrote:
>> Can you try out attached patch please. I ran it in my environment and
>> always get promisc link when attaching devices to the bridge.
>
> It's interesting, actually, why do we need to check for IFF_UP at all when
> changing flags.
>
> The addition of IFF_UP goes up to:
>
> commit b6c40d68ff6498b7f63ddf97cf0aa818d748dee7
> Author: Patrick McHardy <kaber@trash.net>
> Date: Tue Oct 7 15:26:48 2008 -0700
>
> net: only invoke dev->change_rx_flags when device is UP
>
> Jesper Dangaard Brouer <hawk@comx.dk> reported a bug when setting a
> VLAN
> device down that is in promiscous mode:
>
> When the VLAN device is set down, the promiscous count on the real
> device is decremented by one by vlan_dev_stop(). When removing the
> promiscous flag from the VLAN device afterwards, the promiscous
> count on the real device is decremented a second time by the
> vlan_change_rx_flags() callback.
>
> ... snip ...
>
This was applied in 2.6.27 timeframe.
> However, I'm not sure that this is still needed, cause:
>
> commit deede2fabe24e00bd7e246eb81cd5767dc6fcfc7
> Author: Matthijs Kooijman <matthijs@stdin.nl>
> Date: Mon Oct 31 04:53:13 2011 +0000
>
> vlan: Don't propagate flag changes on down interfaces.
>
> When (de)configuring a vlan interface, the IFF_ALLMULTI ans
> IFF_PROMISC
> flags are cleared or set on the underlying interface. So, if these
> flags
> are changed on a vlan interface that is not up, the flags underlying
> interface might be set or cleared twice.
>
> Only propagating flag changes when a device is up makes sure this does
> not happen. It also makes sure that an underlying device is not set to
> promiscuous or allmulti mode for a vlan device that is down.
>
> ... snip ...
>
And this in 3.2. So how did this work for Stefan in 3.9? Unless there
is something in Ubuntu that changed how the stacked interfaces are
configured and is keeping interfaces down longer then it used to.
> which fixed completely the initial issue with vlans.
>
> Maybe we should just remove the IFF_UP check in dev_change_rx_flags(), and
> let the drivers using it handle its own logic, as vlan does?
>
This should work, but this might regress a few drivers. Looking through
the callers of dev_set_promiscuity at least DSA driver suffers
the same fate as VLAN.
-vlad
> Something like this:
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 8ffc52e..9615cd7 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -4995,7 +4995,7 @@ static void dev_change_rx_flags(struct net_device
> *dev, int flags)
> {
> const struct net_device_ops *ops = dev->netdev_ops;
>
> - if ((dev->flags & IFF_UP) && ops->ndo_change_rx_flags)
> + if (ops->ndo_change_rx_flags)
> ops->ndo_change_rx_flags(dev, flags);
> }
>
>
>>
>> Thanks
>> -vlad
^ permalink raw reply
* Re: IPv6: Blackhole route support partial ?
From: Hannes Frederic Sowa @ 2013-11-14 14:11 UTC (permalink / raw)
To: Kamala R; +Cc: davem, linux-kernel, netdev
In-Reply-To: <CAP8BHkEyASA52Q4Zg4w5OqR7Hv7Y_it8SnG_tMPViza_T9TV+Q@mail.gmail.com>
Hi!
On Thu, Nov 14, 2013 at 01:50:20PM +0530, Kamala R wrote:
> I have one quick question before I send the patch across. I noticed
> that "ip -6 route show" shows an error -22 in the output which
> signifies -EINVAL associated with blackhole routes. This behaviour is
> not consistent with that of "ip route show" that shows no such error
> for a blackhole route. Does this qualify a bug that needs fixing ?
You mean that we don't show the error for IPv4 routes? Is this a kernel or
iproute problem?
Greetings,
Hannes
^ permalink raw reply
* [RFC 9/7] genetlink: make genl_ops flags a u8 and move to end
From: Johannes Berg @ 2013-11-14 14:01 UTC (permalink / raw)
To: netdev
In-Reply-To: <1384420486-8713-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
To save some space in the struct on 32-bit systems,
make the flags a u8 (only 4 bits are used) and also
move them to the end of the struct.
This has no impact on 64-bit systems as alignment of
the struct in an array uses up the space anyway.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/genetlink.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/net/genetlink.h b/include/net/genetlink.h
index 0b6b10b..eddcdf2 100644
--- a/include/net/genetlink.h
+++ b/include/net/genetlink.h
@@ -110,15 +110,15 @@ static inline void genl_info_net_set(struct genl_info *info, struct net *net)
* @ops_list: operations list
*/
struct genl_ops {
- u8 cmd;
- u8 internal_flags;
- unsigned int flags;
const struct nla_policy *policy;
int (*doit)(struct sk_buff *skb,
struct genl_info *info);
int (*dumpit)(struct sk_buff *skb,
struct netlink_callback *cb);
int (*done)(struct netlink_callback *cb);
+ u8 cmd;
+ u8 internal_flags;
+ u8 flags;
};
int __genl_register_family(struct genl_family *family);
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH net v2 2/2] macvlan: disable LRO on lower device instead of macvlan
From: Michal Kubecek @ 2013-11-14 14:00 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Patrick McHardy, John Fastabend
In-Reply-To: <cover.1384436410.git.mkubecek@suse.cz>
A macvlan device has always LRO disabled so that calling
dev_disable_lro() on it does nothing. If we need to disable LRO
e.g. because
- the macvlan device is inserted into a bridge
- IPv6 forwarding is enabled for it
- it is in a different namespace than lowerdev and IPv4
forwarding is enabled in it
we need to disable LRO on its underlying device instead (as we
do for 802.1q VLAN devices).
v2: use newly introduced netif_is_macvlan()
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
---
net/core/dev.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index 974143d..7e00a73 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -131,6 +131,7 @@
#include <linux/static_key.h>
#include <linux/hashtable.h>
#include <linux/vmalloc.h>
+#include <linux/if_macvlan.h>
#include "net-sysfs.h"
@@ -1424,6 +1425,10 @@ void dev_disable_lro(struct net_device *dev)
if (is_vlan_dev(dev))
dev = vlan_dev_real_dev(dev);
+ /* the same for macvlan devices */
+ if (netif_is_macvlan(dev))
+ dev = macvlan_dev_real_dev(dev);
+
dev->wanted_features &= ~NETIF_F_LRO;
netdev_update_features(dev);
--
1.8.1.4
^ permalink raw reply related
* [PATCH net v2 1/2] macvlan: introduce macvlan_dev_real_dev() helper function
From: Michal Kubecek @ 2013-11-14 14:00 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Patrick McHardy, John Fastabend
In-Reply-To: <cover.1384436410.git.mkubecek@suse.cz>
Introduce helper function macvlan_dev_real_dev which returns the
underlying device of a macvlan device, similar to vlan_dev_real_dev()
for 802.1q VLAN devices.
v2: IFF_MACVLAN flag and equivalent of is_macvlan_dev() were
introduced in the meantime
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
---
include/linux/if_macvlan.h | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/include/linux/if_macvlan.h b/include/linux/if_macvlan.h
index c270285..ac9aab2 100644
--- a/include/linux/if_macvlan.h
+++ b/include/linux/if_macvlan.h
@@ -119,4 +119,20 @@ extern int macvlan_link_register(struct rtnl_link_ops *ops);
extern netdev_tx_t macvlan_start_xmit(struct sk_buff *skb,
struct net_device *dev);
+#if IS_ENABLED(CONFIG_MACVLAN)
+static inline struct net_device *
+macvlan_dev_real_dev(const struct net_device *dev)
+{
+ struct macvlan_dev *macvlan = netdev_priv(dev);
+
+ return macvlan->lowerdev;
+}
+#else
+static inline struct net_device *
+macvlan_dev_real_dev(const struct net_device *dev)
+{
+ return NULL;
+}
+#endif
+
#endif /* _LINUX_IF_MACVLAN_H */
--
1.8.1.4
^ permalink raw reply related
* [PATCH net v2 0/2] macvlan: disable LRO on lowerdev instead of a macvlan
From: Michal Kubecek @ 2013-11-14 14:00 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Patrick McHardy, John Fastabend
A customer of ours encountered a problem with LRO on an ixgbe network
card. Analysis showed that it was a known conflict of forwarding and LRO
but the forwarding was enabled in an LXC container where only a macvlan
was, not the ethernet device itself.
I believe the solution is exactly the same as what we do for "normal"
(802.1q) VLAN devices: if dev_disable_lro() is called for such device,
LRO is disabled on the underlying "real" device instead.
v2: adapt to changes merged from net-next
Michal Kubecek (2):
macvlan: introduce macvlan_dev_real_dev() helper function
macvlan: disable LRO on lower device instead of macvlan
include/linux/if_macvlan.h | 16 ++++++++++++++++
net/core/dev.c | 5 +++++
2 files changed, 21 insertions(+)
--
1.8.1.4
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox