* Re: BW regression after "tcp: refine TSO autosizing"
From: Eyal Perry @ 2015-01-18 21:40 UTC (permalink / raw)
To: Eric Dumazet, Eyal Perry
Cc: Or Gerlitz, Linux Netdev List, Amir Vadai, Yevgeny Petrilin,
Saeed Mahameed, Ido Shamay, Amir Ancel
In-Reply-To: <1421603317.11734.154.camel@edumazet-glaptop2.roam.corp.google.com>
On 1/18/2015 19:48 PM, Eric Dumazet wrote:
> On Sun, 2015-01-18 at 18:22 +0200, Eyal Perry wrote:
>
>> Please let me know if you see something in the results.
> Getting high throughput on a single flow means lot of tweaking.
>
> For a start, mlx4 is known to have interrupt mitigation that can hurt,
> as the TX interrupt timer is restarted for every packet that is
> delivered to the NIC.
>
> ethtool -c ethX
> ..
> tx-usecs: 16
> tx-frames: 16
> tx-usecs-irq: 0
> tx-frames-irq: 256
> ...
>
> -> TX IRQ can be delayed by 16*16 = 256 usec.
>
> Can you try :
>
> ethtool -C ethX tx-usecs 2 tx-frames 2
>
> Or even
>
> ethtool -C ethX tx-usecs 1 tx-frames 1
So indeed, interrupt mitigation (tx-usecs 1 tx-frames 1) improves things up
for the "refined TSO autosizing" kernel (from 18.4Gbps to 19.7Gbps). but
in the
other kernel, the BW is remains the same with and without the coalescing.
> Interrupt mitigation is a trade-off.
>
> If one customer wants high throughput on a single flow, then you might
> remove interrupt mitigation.
>
> If another customer wants cpu efficiency with thousand of flows, I guess
> current mlx4 defaults are pretty good.
>
^ permalink raw reply
* Re: [PATCH net-next 1/2] udp: Do not require sock in udp_tunnel_xmit_skb
From: Or Gerlitz @ 2015-01-18 22:43 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Thomas Graf, Linux Netdev List
In-Reply-To: <1421518700-22460-2-git-send-email-therbert@google.com>
On Sat, Jan 17, 2015 at 8:18 PM, Tom Herbert <therbert@google.com> wrote:
> The UDP tunnel transmit functions udp_tunnel_xmit_skb and
> udp_tunnel6_xmit_skb include a socket argument. The socket being
> passed to the functions (from VXLAN) is a UDP created for receive
> side. The only thing that the socket is used for in the transmit
> functions is to get the setting for checksum (enabled or zero).
Tom, just to clarify - re the sockets usage in the transmit side,
somewhere bind or alike is done on them such that we have multiple
source UDP ports for given host VXLAN traffic. Here for example the
sender host is 192.168.31.17 and two ports are seen here 54206 and
50795.
Just wanted to make sure this series doesn't change that, since if
this is the case, we introduce here a regression w.r.t RSS hash
spreading from the outer UDP header data at the receiver side (which
is the right thing to do, per your LKS session...)
IP 192.168.31.18.45367 > 192.168.31.17.4789: UDP, length 62
IP 192.168.31.18.45515 > 192.168.31.17.4789: UDP, length 62
IP 192.168.31.17.54206 > 192.168.31.18.4789: UDP, length 26814
IP 192.168.31.18.45367 > 192.168.31.17.4789: UDP, length 62
IP 192.168.31.18.45515 > 192.168.31.17.4789: UDP, length 62
IP 192.168.31.17.50795 > 192.168.31.18.4789: UDP, length 25498
IP 192.168.31.17.50795 > 192.168.31.18.4789: UDP, length 64922
IP 192.168.31.17.50795 > 192.168.31.18.4789: UDP, length 64922
IP 192.168.31.18.45367 > 192.168.31.17.4789: UDP, length 62
IP 192.168.31.17.54206 > 192.168.31.18.4789: UDP, length 38170
> This patch removes the argument and and adds a nocheck argument
> for checksum setting. This eliminates the unnecessary dependency
> on a UDP socket for UDP tunnel transmit.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> drivers/net/vxlan.c | 10 ++++++----
> include/net/udp_tunnel.h | 16 ++++++++--------
> net/ipv4/udp_tunnel.c | 12 ++++++------
> net/ipv6/ip6_udp_tunnel.c | 12 ++++++------
> 4 files changed, 26 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> index 6b6b456..4fb4205 100644
> --- a/drivers/net/vxlan.c
> +++ b/drivers/net/vxlan.c
> @@ -1763,8 +1763,9 @@ static int vxlan6_xmit_skb(struct vxlan_sock *vs,
>
> skb_set_inner_protocol(skb, htons(ETH_P_TEB));
>
> - udp_tunnel6_xmit_skb(vs->sock, dst, skb, dev, saddr, daddr, prio,
> - ttl, src_port, dst_port);
> + udp_tunnel6_xmit_skb(dst, skb, dev, saddr, daddr, prio,
> + ttl, src_port, dst_port,
> + udp_get_no_check6_tx(vs->sock->sk));
> return 0;
> err:
> dst_release(dst);
> @@ -1842,8 +1843,9 @@ int vxlan_xmit_skb(struct vxlan_sock *vs,
>
> skb_set_inner_protocol(skb, htons(ETH_P_TEB));
>
> - return udp_tunnel_xmit_skb(vs->sock, rt, skb, src, dst, tos,
> - ttl, df, src_port, dst_port, xnet);
> + return udp_tunnel_xmit_skb(rt, skb, src, dst, tos,
> + ttl, df, src_port, dst_port, xnet,
> + vs->sock->sk->sk_no_check_tx);
> }
> EXPORT_SYMBOL_GPL(vxlan_xmit_skb);
>
> diff --git a/include/net/udp_tunnel.h b/include/net/udp_tunnel.h
> index 2a50a70..1a20d33 100644
> --- a/include/net/udp_tunnel.h
> +++ b/include/net/udp_tunnel.h
> @@ -77,17 +77,17 @@ void setup_udp_tunnel_sock(struct net *net, struct socket *sock,
> struct udp_tunnel_sock_cfg *sock_cfg);
>
> /* Transmit the skb using UDP encapsulation. */
> -int udp_tunnel_xmit_skb(struct socket *sock, struct rtable *rt,
> - struct sk_buff *skb, __be32 src, __be32 dst,
> - __u8 tos, __u8 ttl, __be16 df, __be16 src_port,
> - __be16 dst_port, bool xnet);
> +int udp_tunnel_xmit_skb(struct rtable *rt, struct sk_buff *skb,
> + __be32 src, __be32 dst, __u8 tos, __u8 ttl,
> + __be16 df, __be16 src_port, __be16 dst_port,
> + bool xnet, bool nocheck);
>
> #if IS_ENABLED(CONFIG_IPV6)
> -int udp_tunnel6_xmit_skb(struct socket *sock, struct dst_entry *dst,
> - struct sk_buff *skb, struct net_device *dev,
> - struct in6_addr *saddr, struct in6_addr *daddr,
> +int udp_tunnel6_xmit_skb(struct dst_entry *dst, struct sk_buff *skb,
> + struct net_device *dev, struct in6_addr *saddr,
> + struct in6_addr *daddr,
> __u8 prio, __u8 ttl, __be16 src_port,
> - __be16 dst_port);
> + __be16 dst_port, bool nocheck);
> #endif
>
> void udp_tunnel_sock_release(struct socket *sock);
> diff --git a/net/ipv4/udp_tunnel.c b/net/ipv4/udp_tunnel.c
> index 9996e63..c83b354 100644
> --- a/net/ipv4/udp_tunnel.c
> +++ b/net/ipv4/udp_tunnel.c
> @@ -75,10 +75,10 @@ void setup_udp_tunnel_sock(struct net *net, struct socket *sock,
> }
> EXPORT_SYMBOL_GPL(setup_udp_tunnel_sock);
>
> -int udp_tunnel_xmit_skb(struct socket *sock, struct rtable *rt,
> - struct sk_buff *skb, __be32 src, __be32 dst,
> - __u8 tos, __u8 ttl, __be16 df, __be16 src_port,
> - __be16 dst_port, bool xnet)
> +int udp_tunnel_xmit_skb(struct rtable *rt, struct sk_buff *skb,
> + __be32 src, __be32 dst, __u8 tos, __u8 ttl,
> + __be16 df, __be16 src_port, __be16 dst_port,
> + bool xnet, bool nocheck)
> {
> struct udphdr *uh;
>
> @@ -90,9 +90,9 @@ int udp_tunnel_xmit_skb(struct socket *sock, struct rtable *rt,
> uh->source = src_port;
> uh->len = htons(skb->len);
>
> - udp_set_csum(sock->sk->sk_no_check_tx, skb, src, dst, skb->len);
> + udp_set_csum(nocheck, skb, src, dst, skb->len);
>
> - return iptunnel_xmit(sock->sk, rt, skb, src, dst, IPPROTO_UDP,
> + return iptunnel_xmit(skb->sk, rt, skb, src, dst, IPPROTO_UDP,
> tos, ttl, df, xnet);
> }
> EXPORT_SYMBOL_GPL(udp_tunnel_xmit_skb);
> diff --git a/net/ipv6/ip6_udp_tunnel.c b/net/ipv6/ip6_udp_tunnel.c
> index 8db6c98..32d9b26 100644
> --- a/net/ipv6/ip6_udp_tunnel.c
> +++ b/net/ipv6/ip6_udp_tunnel.c
> @@ -62,14 +62,14 @@ error:
> }
> EXPORT_SYMBOL_GPL(udp_sock_create6);
>
> -int udp_tunnel6_xmit_skb(struct socket *sock, struct dst_entry *dst,
> - struct sk_buff *skb, struct net_device *dev,
> - struct in6_addr *saddr, struct in6_addr *daddr,
> - __u8 prio, __u8 ttl, __be16 src_port, __be16 dst_port)
> +int udp_tunnel6_xmit_skb(struct dst_entry *dst, struct sk_buff *skb,
> + struct net_device *dev, struct in6_addr *saddr,
> + struct in6_addr *daddr,
> + __u8 prio, __u8 ttl, __be16 src_port,
> + __be16 dst_port, bool nocheck)
> {
> struct udphdr *uh;
> struct ipv6hdr *ip6h;
> - struct sock *sk = sock->sk;
>
> __skb_push(skb, sizeof(*uh));
> skb_reset_transport_header(skb);
> @@ -85,7 +85,7 @@ int udp_tunnel6_xmit_skb(struct socket *sock, struct dst_entry *dst,
> | IPSKB_REROUTED);
> skb_dst_set(skb, dst);
>
> - udp6_set_csum(udp_get_no_check6_tx(sk), skb, saddr, daddr, skb->len);
> + udp6_set_csum(nocheck, skb, saddr, daddr, skb->len);
>
> __skb_push(skb, sizeof(*ip6h));
> skb_reset_network_header(skb);
> --
> 2.2.0.rc0.207.ga3a616c
>
> --
> 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: net: prevent of emerging cross-namespace symlinks patches for 3.14?
From: Miquel van Smoorenburg @ 2015-01-18 23:17 UTC (permalink / raw)
To: Alexander Y. Fomichev; +Cc: netdev, stable, David Miller
In-Reply-To: <CAChDUfTktt7DAg+Mi0+PWcykhHWvE9wg5FNieWUuoBjZGsU8jQ@mail.gmail.com>
On 15/01/15 19:39, Alexander Y. Fomichev wrote:
> On Thu, Jan 15, 2015 at 12:45 AM, Miquel van Smoorenburg mikevs@xs4all.net> wrote:
>> [first sent to lkml, now to netdev and the original patch author]
>>
>> When running 'lxc' on the latest -stable kernel, 3.14.28, I'm seeing these
>> errors:
>>
>> Jan 14 17:47:16 lxc2 kernel: [ 10.704892] sysfs: cannot create duplicate
>> filename '/devices/virtual/net/eth0.104/upper_eth0'
>> I did not see these errors in 3.12. This was fixed in 3.17
>
> Hi,
>
> no objections of course,
> actually it was written and tested with 3.14 in mind.
David, could you have a quick look and ack this if you agree this should
go in 3.14-stable ?
Thanks
Mike.
^ permalink raw reply
* RE: [net-next v2 13/15] i40e: limit WoL and link settings to partition 1
From: Nelson, Shannon @ 2015-01-18 23:26 UTC (permalink / raw)
To: Yuval Mintz, Kirsher, Jeffrey T, David Miller
Cc: netdev, nhorman@redhat.com, sassmann@redhat.com,
jogreene@redhat.com
In-Reply-To: <B5657A6538887040AD3A81F1008BEC63BC8933@avmb3.qlogic.org>
> From: Yuval Mintz [mailto:Yuval.Mintz@qlogic.com]
> Sent: Saturday, January 17, 2015 10:10 PM
>
> >From: Shannon Nelson <shannon.nelson@intel.com>
>
> >When in multi-function mode, e.g. Dell's NPAR, only partition 1
> >of each MAC is allowed to set WoL, speed, and flow control.
>
> Isn't it problematic? I mean, in bnx2x we address ~same issue -
> but due to symmetry we prevent ALL interfaces from changing
> the link configuration.
Yes, this multi-function hardware port makes for "interesting opportunities" in hardware configuration. In our case, our requirements are to still allow for configuration of the hardware port. This is not unlike how a PF controls the physical port for its VF devices.
>
> How can user be aware of this 'private' behavior? via system logs?
> documentation?
In this case, note that we have added a log message that says these are dependent on the initial partition of the port for setting control. Also, the particular vendor using the device in this configuration will supply and support the user documentation.
>
> How does it interact with Physical Device Assignment of the first
> partition?
I'm not sure I understand this question, but I'll answer a different question: these multifunction ports show up as additional PCI functions, again, not unlike VF devices.
>
> Cheers,
> Yuval
sln
^ permalink raw reply
* Re: Problem with patch "make nlmsg_end() and genlmsg_end() void"
From: Marcel Holtmann @ 2015-01-18 23:44 UTC (permalink / raw)
To: Network Development, Johannes Berg; +Cc: David S. Miller, Tom Gundersen
In-Reply-To: <0397034D-1DF4-409F-B335-FCD0D7EAB940@holtmann.org>
Hi Johannes,
> your commit 053c095a82cf773075e83d7233b5cc19a1f73ece is causing problems with systemd-networkd.
>
> I have an up-to-date Arch Linux installation in a KVM and your change causes massive problems. It makes systemd-networkd to run out of memory.
>
> systemd-fsck[84]: /dev/vda1: clean, 53283/131072 files, 409813/524032 blocks
> Out of memory: Kill process 142 (systemd-network) score 923 or sacrifice child
> Killed process 142 (systemd-network) total-vm:478416kB, anon-rss:463472kB, file-rss:460kB
> [FAILED] Failed to start Network Service.
> See "systemctl status systemd-networkd.service" for details.
> Stopping Network Service...
> [ OK ] Stopped Network Service.
> Starting Network Service...
>
> Arch Linux 3.19.0-rc4-devel+ (ttyS0)
>
> marcel login: Out of memory: Kill process 154 (systemd-network) score 932 or sacrifice child
> Killed process 154 (systemd-network) total-vm:540784kB, anon-rss:468380kB, file-rss:132kB
> Out of memory: Kill process 158 (systemd-network) score 932 or sacrifice child
> Killed process 158 (systemd-network) total-vm:540388kB, anon-rss:468528kB, file-rss:48kB
> Out of memory: Kill process 160 (systemd-network) score 932 or sacrifice child
> Killed process 160 (systemd-network) total-vm:540916kB, anon-rss:468528kB, file-rss:4kB
> Out of memory: Kill process 162 (systemd-network) score 931 or sacrifice child
> Killed process 162 (systemd-network) total-vm:540916kB, anon-rss:468104kB, file-rss:76kB
so this was freaking nasty to find since I had to dig into every single RTNL location that might have an affect on this. I think that I tracked this down to these two locations:
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index e13b9dbdf154..0e26b9f66cad 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1327,7 +1327,7 @@ static int rtnl_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb)
*/
WARN_ON((err == -EMSGSIZE) && (skb->len == 0));
- if (err <= 0)
+ if (err < 0)
goto out;
nl_dump_check_consistent(cb, nlmsg_hdr(skb));
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 8975d9501d50..d6b4f5d08014 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -4213,7 +4213,7 @@ static int inet6_dump_addr(struct sk_buff *skb, struct netlink_callback *cb,
goto cont;
if (in6_dump_addrs(idev, skb, cb, type,
- s_ip_idx, &ip_idx) <= 0)
+ s_ip_idx, &ip_idx) < 0)
goto done;
cont:
idx++;
However I am not sure that these are the only ones. We might have additional issues in functionality that systemd-networkd actually does not use at the moment. These two changes make my KVM image boot properly again.
And actually I am not even sure that these two changes are correct. My KVM image is a dead simple image with no IPv6 support. This change might actually just broke IPv6 and I would not notice.
Tom, do you know if we can do anything in systemd-networkd in regards to RTNL and netlink handling to throw a big warning when something comes back from the kernel that would cause massive memory allocation.
Regards
Marcel
^ permalink raw reply related
* Re: [PATCH 1/7] net: wireless: wcn36xx: add wcn3620 chip type definition
From: Andy Green @ 2015-01-19 0:24 UTC (permalink / raw)
To: Kalle Valo; +Cc: Eugene Krasnikov, wcn36xx, linux-wireless, netdev
In-Reply-To: <878uh06ulp.fsf@kamboji.qca.qualcomm.com>
On 18 January 2015 at 22:17, Kalle Valo <kvalo@codeaurora.org> wrote:
> Andy Green <andy.green@linaro.org> writes:
>
>> Convert the list of chip types to an enum, add the default
>> UNKNOWN type and a type for WCN3620 chip
>>
>> Signed-off-by: Andy Green <andy.green@linaro.org>
>
> Please just use "wcn36xx: ", you should drop "net: wireless: " entirely.
OK.
Can you help me understand what you'd like to see happen with the chip
variant detection stuff?
There's a comment sent to one list only saying it might be preferable
to keep the old detection code as the default. But there are no
in-tree users of wcn36xx (mainly due to PIL not being in mainline, I
guess).
The old test's equivalence that AC == 3680 seems kind of weak to me
and establishing the type must be passed in from platform code
reflects the situation that there's no public way to detect the chip
type from Qualcomm. In the second not-for-upstream series I use that
to pass it in from DT, which is how it'd be normally used.
-Andy
> --
> Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/6] selftests: Introduce minimal shared logic for running tests
From: Michael Ellerman @ 2015-01-19 0:35 UTC (permalink / raw)
To: Shuah Khan
Cc: linux-kernel, mmarek, gregkh, akpm, rostedt, mingo, davem,
keescook, tranmanphong, cov, dh.herrmann, hughd, bobby.prani,
serge.hallyn, ebiederm, tim.bird, josh, koct9i, linux-kbuild,
linux-api, netdev
In-Reply-To: <54B95006.3080502@osg.samsung.com>
On Fri, 2015-01-16 at 10:53 -0700, Shuah Khan wrote:
> On 01/09/2015 02:06 AM, Michael Ellerman wrote:
> > This adds a Make include file which most selftests can then include to
> > get the run_tests logic.
> >
> > On its own this has the advantage of some reduction in repetition, and
> > also means the pass/fail message is defined in fewer places.
> >
> > However the key advantage is it will allow us to implement install very
> > simply in a subsequent patch.
> >
> > The default implementation just executes each program in $(TEST_PROGS).
> >
> > We use a variable to hold the default implementation of $(RUN_TESTS)
> > because that gives us a clean way to override it if necessary, ie. using
> > override. The mount, memory-hotplug and mqueue tests use that to provide
> > a different implementation.
> >
> > Tests are not run via /bin/bash, so if they are scripts they must be
> > executable, we add u+x to several.
> >
> > Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>
> I like the shared logic approach in general provided it leaves the
> flexibility to not use the shared logic if a test have the need to
> do so.
Yes of course it does, it's entirely optional to include lib.mk.
> This series requires some patch planning. shared logic patch
> followed by individual test patches as opposed a single patch.
It could be a single patch too, but there's no reason to do it that way. The
series works fine as I sent it.
> I would like to see the shared logic work done on top of my patch v4
> series.
That's a waste of time. This series replaces your v4. Doing this "on top" of
your v4 would just mean reverting your v4 series and then applying this.
cheers
^ permalink raw reply
* Re: [PATCH 4/6] kbuild: add a new kselftest_install make target to install selftests
From: Michael Ellerman @ 2015-01-19 0:35 UTC (permalink / raw)
To: Shuah Khan
Cc: linux-kernel, mmarek, gregkh, akpm, rostedt, mingo, davem,
keescook, tranmanphong, cov, dh.herrmann, hughd, bobby.prani,
serge.hallyn, ebiederm, tim.bird, josh, koct9i, linux-kbuild,
linux-api, netdev
In-Reply-To: <54B93DA1.2010601@osg.samsung.com>
On Fri, 2015-01-16 at 09:34 -0700, Shuah Khan wrote:
> On 01/09/2015 02:06 AM, Michael Ellerman wrote:
> > Add a new make target to install kernel selftests. This new target will
> > build and install selftests.
> >
> > The default is just $(objtree)/selftests. This is preferable to
> > something based on $(INSTALL_MOD_PATH) (which defaults to /), as it
> > allows a normal user to install the tests. This is similar to the
> > default behaviour of make headers_install.
>
> A normal user can install tests at any location they choose by
> overriding the default path. For example:
>
> INSTALL_MOD_PATH=/tmp make kselftest_install
>
> will install under tmp.
Why default to a directory that most users can't write to? That's not helpful.
Users who are root can override the path, for example:
INSTALL_MOD_PATH=/ make kselftest_install
> The approach I used also ties test installs to kernel release.
> This addresses an important use-case for kernel developers
> that want to compare results from release to release.
Sure, I'm happy to add the kernel release, so the default would be
$(objtree)/selftests/$(kernel-release)/.
> The use-case for any user to be able to install tests at
> any location is addressed by the above example.
The default should work for most users most of the time, / does not achieve
that.
> I would like these two above use-cases continued to be supported,
> especially the one that tries the test installs to kernel release.
That's fine, I'm happy to update this to use kernel release. But defaulting to
/ doesn't make sense.
> Another goal is to keep changes to the main Makefile minimal and
> the rest of the install support belongs under selftests/Makefile
> and any other include file (like the one you proposed).
Yes, this patch does just that.
cheers
^ permalink raw reply
* Re: [PATCH 2/6] selftests: Add install target
From: Michael Ellerman @ 2015-01-19 0:35 UTC (permalink / raw)
To: Shuah Khan
Cc: linux-kernel, mmarek, gregkh, akpm, rostedt, mingo, davem,
keescook, tranmanphong, cov, dh.herrmann, hughd, bobby.prani,
serge.hallyn, ebiederm, tim.bird, josh, koct9i, linux-kbuild,
linux-api, netdev
In-Reply-To: <54B94E75.8030504@osg.samsung.com>
On Fri, 2015-01-16 at 10:46 -0700, Shuah Khan wrote:
> On 01/09/2015 02:06 AM, Michael Ellerman wrote:
> > This adds make install support to selftests. The basic usage is:
> >
> > $ cd tools/testing/selftests
> > $ make install
> >
> > That installs into tools/testing/selftests/install, which can then be
> > copied where ever necessary.
> >
> > The install destination is also configurable using eg:
> >
> > $ INSTALL_PATH=/mnt/selftests make install
>
> Please see my response to [PATCH 4/6] kbuild: add a new
> kselftest_install make target to install selftests
>
> These are addressed by the current approach to use existing
> INSTALL_MOD_PATH.
No that's a separate issue.
This patch adds install support for tools/testing/selftests, *completely
separate* from the kbuild infrastructure.
That is an existing use case, ie. using selftests on its own, which this patch
easily continues to support.
cheers
^ permalink raw reply
* Re: Problem with patch "make nlmsg_end() and genlmsg_end() void"
From: Scott Feldman @ 2015-01-19 1:53 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Network Development, Johannes Berg, David S. Miller,
Tom Gundersen
In-Reply-To: <E586D25A-9DAF-4535-A282-120F0C6EAE19@holtmann.org>
This patch needs to be reverted ASAP. git bisect landed me here also;
my processes are getting the OOM msgs. What testing was done?
Seems someone does care that nlmsg_end() returns skb->len.
-scott
On Sun, Jan 18, 2015 at 3:44 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Johannes,
>
>> your commit 053c095a82cf773075e83d7233b5cc19a1f73ece is causing problems with systemd-networkd.
>>
>> I have an up-to-date Arch Linux installation in a KVM and your change causes massive problems. It makes systemd-networkd to run out of memory.
>>
>> systemd-fsck[84]: /dev/vda1: clean, 53283/131072 files, 409813/524032 blocks
>> Out of memory: Kill process 142 (systemd-network) score 923 or sacrifice child
>> Killed process 142 (systemd-network) total-vm:478416kB, anon-rss:463472kB, file-rss:460kB
>> [FAILED] Failed to start Network Service.
>> See "systemctl status systemd-networkd.service" for details.
>> Stopping Network Service...
>> [ OK ] Stopped Network Service.
>> Starting Network Service...
>>
>> Arch Linux 3.19.0-rc4-devel+ (ttyS0)
>>
>> marcel login: Out of memory: Kill process 154 (systemd-network) score 932 or sacrifice child
>> Killed process 154 (systemd-network) total-vm:540784kB, anon-rss:468380kB, file-rss:132kB
>> Out of memory: Kill process 158 (systemd-network) score 932 or sacrifice child
>> Killed process 158 (systemd-network) total-vm:540388kB, anon-rss:468528kB, file-rss:48kB
>> Out of memory: Kill process 160 (systemd-network) score 932 or sacrifice child
>> Killed process 160 (systemd-network) total-vm:540916kB, anon-rss:468528kB, file-rss:4kB
>> Out of memory: Kill process 162 (systemd-network) score 931 or sacrifice child
>> Killed process 162 (systemd-network) total-vm:540916kB, anon-rss:468104kB, file-rss:76kB
>
> so this was freaking nasty to find since I had to dig into every single RTNL location that might have an affect on this. I think that I tracked this down to these two locations:
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index e13b9dbdf154..0e26b9f66cad 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -1327,7 +1327,7 @@ static int rtnl_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb)
> */
> WARN_ON((err == -EMSGSIZE) && (skb->len == 0));
>
> - if (err <= 0)
> + if (err < 0)
> goto out;
>
> nl_dump_check_consistent(cb, nlmsg_hdr(skb));
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 8975d9501d50..d6b4f5d08014 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -4213,7 +4213,7 @@ static int inet6_dump_addr(struct sk_buff *skb, struct netlink_callback *cb,
> goto cont;
>
> if (in6_dump_addrs(idev, skb, cb, type,
> - s_ip_idx, &ip_idx) <= 0)
> + s_ip_idx, &ip_idx) < 0)
> goto done;
> cont:
> idx++;
>
> However I am not sure that these are the only ones. We might have additional issues in functionality that systemd-networkd actually does not use at the moment. These two changes make my KVM image boot properly again.
>
> And actually I am not even sure that these two changes are correct. My KVM image is a dead simple image with no IPv6 support. This change might actually just broke IPv6 and I would not notice.
>
> Tom, do you know if we can do anything in systemd-networkd in regards to RTNL and netlink handling to throw a big warning when something comes back from the kernel that would cause massive memory allocation.
>
> Regards
>
> Marcel
>
> --
> 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: Problem with patch "make nlmsg_end() and genlmsg_end() void"
From: Marcel Holtmann @ 2015-01-19 2:10 UTC (permalink / raw)
To: Scott Feldman
Cc: Network Development, Johannes Berg, David S. Miller,
Tom Gundersen
In-Reply-To: <CAE4R7bCWSM+SyDR830N1GmukyaMYE_DT0fd4L_x6Py5PEqMe_A@mail.gmail.com>
Hi Scott,
> This patch needs to be reverted ASAP. git bisect landed me here also;
> my processes are getting the OOM msgs. What testing was done?
>
> Seems someone does care that nlmsg_end() returns skb->len.
I still wonder how this affects userspace. I have not figured that out. Something goes wrong pretty badly somewhere.
Have you tried the small diff with the two locations that were problematic for me?
Regards
Marcel
^ permalink raw reply
* linux-next: build failure after merge of the net-next tree
From: Stephen Rothwell @ 2015-01-19 3:06 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Jiri Pirko, Scott Feldman,
Gustavo Padovan
[-- Attachment #1: Type: text/plain, Size: 836 bytes --]
Hi all,
After merging the net-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
In file included from net/bridge/br.c:22:0:
include/net/switchdev.h:73:1: error: expected identifier or '(' before '{' token
{
^
include/net/switchdev.h:71:19: warning: 'call_netdev_switch_notifiers' declared 'static' but never defined [-Wunused-function]
static inline int call_netdev_switch_notifiers(unsigned long val, struct net_device *dev,
^
Caused by commit 03bf0c281234 ("switchdev: introduce switchdev notifier").
I have used the net-next tree from next-20150116 for today. I also had
to use the bluetooth tree from next-20150116 as it was fast forwarded
to be the same as the net-next tree today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] iproute2: bridge: support vlan range
From: roopa @ 2015-01-19 3:06 UTC (permalink / raw)
To: Scott Feldman; +Cc: Netdev, shemminger, vyasevic@redhat.com, Wilson Kok
In-Reply-To: <CAE4R7bA6f-f9zTL4iKn11xAWD7evbEGMb+b8zgrm780Hx0yg4w@mail.gmail.com>
On 1/18/15, 9:44 AM, Scott Feldman wrote:
> On Sun, Jan 18, 2015 at 1:11 AM, roopa <roopa@cumulusnetworks.com> wrote:
>> On 1/17/15, 5:35 PM, Scott Feldman wrote:
>>> On Thu, Jan 15, 2015 at 10:52 PM, <roopa@cumulusnetworks.com> wrote:
>>>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>>>
>>>> This patch adds vlan range support to bridge command
>>>> using the newly added vinfo flags BRIDGE_VLAN_INFO_RANGE_BEGIN and
>>>> BRIDGE_VLAN_INFO_RANGE_END.
>>>>
>>>> + vinfo.flags |=
>>>> BRIDGE_VLAN_INFO_RANGE_BEGIN;
>>>> + } else {
>>>> + vinfo.vid = atoi(*argv);
>>>> + }
>>>> } else if (strcmp(*argv, "self") == 0) {
>>>> flags |= BRIDGE_FLAGS_SELF;
>>>> } else if (strcmp(*argv, "master") == 0) {
>>>> @@ -67,7 +78,7 @@ static int vlan_modify(int cmd, int argc, char **argv)
>>>> argc--; argv++;
>>>> }
>>>>
>>>> - if (d == NULL || vid == -1) {
>>>> + if (d == NULL || vinfo.vid == -1) {
>>> Where was vinfo.vid initialized to -1? Maybe use vid rather than
>>> vinfo.vid in the code above where parsing the arg, and continue using
>>> vid and vid_end until final put of vinfo.
>>>
>> There is already a "memset(&vinfo, 0, sizeof(vinfo));" in the code in the
>> beginning of the function.
> That's the problem...vinfo.vid is initialized to 0, not -1, so
> checking if vinfo.vid == -1 is always false.
ack, v2 coming ... thanks
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: Marcel Holtmann @ 2015-01-19 3:13 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David S. Miller, netdev, linux-next, linux-kernel, Jiri Pirko,
Scott Feldman, Gustavo F. Padovan
In-Reply-To: <20150119140610.6b41b5ef@canb.auug.org.au>
Hi Stephen,
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from net/bridge/br.c:22:0:
> include/net/switchdev.h:73:1: error: expected identifier or '(' before '{' token
> {
> ^
> include/net/switchdev.h:71:19: warning: 'call_netdev_switch_notifiers' declared 'static' but never defined [-Wunused-function]
> static inline int call_netdev_switch_notifiers(unsigned long val, struct net_device *dev,
> ^
>
> Caused by commit 03bf0c281234 ("switchdev: introduce switchdev notifier").
>
> I have used the net-next tree from next-20150116 for today. I also had
> to use the bluetooth tree from next-20150116 as it was fast forwarded
> to be the same as the net-next tree today.
it seems Dave forgot to push out his net-next tree, but in theory it should contain a fix for it.
Regards
Marcel
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: Stephen Rothwell @ 2015-01-19 3:30 UTC (permalink / raw)
To: Marcel Holtmann
Cc: David S. Miller, netdev, linux-next, linux-kernel, Jiri Pirko,
Scott Feldman, Gustavo F. Padovan
In-Reply-To: <289C7DCC-D2B3-43B6-B661-EE19371D8B17@holtmann.org>
[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]
Hi Marcel,
On Sun, 18 Jan 2015 19:13:17 -0800 Marcel Holtmann <marcel@holtmann.org> wrote:
>
> > After merging the net-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > In file included from net/bridge/br.c:22:0:
> > include/net/switchdev.h:73:1: error: expected identifier or '(' before '{' token
> > {
> > ^
> > include/net/switchdev.h:71:19: warning: 'call_netdev_switch_notifiers' declared 'static' but never defined [-Wunused-function]
> > static inline int call_netdev_switch_notifiers(unsigned long val, struct net_device *dev,
> > ^
> >
> > Caused by commit 03bf0c281234 ("switchdev: introduce switchdev notifier").
> >
> > I have used the net-next tree from next-20150116 for today. I also had
> > to use the bluetooth tree from next-20150116 as it was fast forwarded
> > to be the same as the net-next tree today.
>
> it seems Dave forgot to push out his net-next tree, but in theory it should contain a fix for it.
Or he did so after I fetched his tree this morning. Either way, I
assume it will be fixed tomorrow.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: Problem with patch "make nlmsg_end() and genlmsg_end() void"
From: David Miller @ 2015-01-19 4:37 UTC (permalink / raw)
To: marcel; +Cc: sfeldma, netdev, johannes, teg
In-Reply-To: <01A82AB9-6ABD-4AD0-9CBC-628091569DB0@holtmann.org>
From: Marcel Holtmann <marcel@holtmann.org>
Date: Sun, 18 Jan 2015 18:10:46 -0800
> Hi Scott,
>
>> This patch needs to be reverted ASAP. git bisect landed me here also;
>> my processes are getting the OOM msgs. What testing was done?
>>
>> Seems someone does care that nlmsg_end() returns skb->len.
>
> I still wonder how this affects userspace. I have not figured that
> out. Something goes wrong pretty badly somewhere.
>
> Have you tried the small diff with the two locations that were
> problematic for me?
There were a lot more cases not converted properly, I hope the
patch below gets them all.
Johannes, this was either not tested or tested very poorly, please
don't submit changes like this. Even neighbour entry and route
dumping were hosed.
====================
[PATCH] netlink: Fix bugs in nlmsg_end() conversions.
Commit 053c095a82cf ("netlink: make nlmsg_end() and genlmsg_end()
void") didn't catch all of the cases where callers were breaking out
on the return value being equal to zero, which they no longer should
when zero means success.
Fix all such cases.
Reported-by: Marcel Holtmann <marcel@holtmann.org>
Reported-by: Scott Feldman <sfeldma@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/core/neighbour.c | 8 ++++----
net/core/rtnetlink.c | 2 +-
net/decnet/dn_route.c | 5 +----
net/ipv4/devinet.c | 6 +++---
net/ipv4/route.c | 2 +-
net/ipv6/addrconf.c | 2 +-
6 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index d36d564..70fe9e1 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -2128,7 +2128,7 @@ static int neightbl_dump_info(struct sk_buff *skb, struct netlink_callback *cb)
if (neightbl_fill_info(skb, tbl, NETLINK_CB(cb->skb).portid,
cb->nlh->nlmsg_seq, RTM_NEWNEIGHTBL,
- NLM_F_MULTI) <= 0)
+ NLM_F_MULTI) < 0)
break;
nidx = 0;
@@ -2144,7 +2144,7 @@ static int neightbl_dump_info(struct sk_buff *skb, struct netlink_callback *cb)
NETLINK_CB(cb->skb).portid,
cb->nlh->nlmsg_seq,
RTM_NEWNEIGHTBL,
- NLM_F_MULTI) <= 0)
+ NLM_F_MULTI) < 0)
goto out;
next:
nidx++;
@@ -2274,7 +2274,7 @@ static int neigh_dump_table(struct neigh_table *tbl, struct sk_buff *skb,
if (neigh_fill_info(skb, n, NETLINK_CB(cb->skb).portid,
cb->nlh->nlmsg_seq,
RTM_NEWNEIGH,
- NLM_F_MULTI) <= 0) {
+ NLM_F_MULTI) < 0) {
rc = -1;
goto out;
}
@@ -2311,7 +2311,7 @@ static int pneigh_dump_table(struct neigh_table *tbl, struct sk_buff *skb,
if (pneigh_fill_info(skb, n, NETLINK_CB(cb->skb).portid,
cb->nlh->nlmsg_seq,
RTM_NEWNEIGH,
- NLM_F_MULTI, tbl) <= 0) {
+ NLM_F_MULTI, tbl) < 0) {
read_unlock_bh(&tbl->lock);
rc = -1;
goto out;
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index e13b9db..0e26b9f 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1327,7 +1327,7 @@ static int rtnl_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb)
*/
WARN_ON((err == -EMSGSIZE) && (skb->len == 0));
- if (err <= 0)
+ if (err < 0)
goto out;
nl_dump_check_consistent(cb, nlmsg_hdr(skb));
diff --git a/net/decnet/dn_route.c b/net/decnet/dn_route.c
index 812e5e6..1d7c125 100644
--- a/net/decnet/dn_route.c
+++ b/net/decnet/dn_route.c
@@ -1710,9 +1710,6 @@ static int dn_cache_getroute(struct sk_buff *in_skb, struct nlmsghdr *nlh)
rt->rt_flags |= RTCF_NOTIFY;
err = dn_rt_fill_info(skb, NETLINK_CB(in_skb).portid, nlh->nlmsg_seq, RTM_NEWROUTE, 0, 0);
-
- if (err == 0)
- goto out_free;
if (err < 0) {
err = -EMSGSIZE;
goto out_free;
@@ -1763,7 +1760,7 @@ int dn_cache_dump(struct sk_buff *skb, struct netlink_callback *cb)
skb_dst_set(skb, dst_clone(&rt->dst));
if (dn_rt_fill_info(skb, NETLINK_CB(cb->skb).portid,
cb->nlh->nlmsg_seq, RTM_NEWROUTE,
- 1, NLM_F_MULTI) <= 0) {
+ 1, NLM_F_MULTI) < 0) {
skb_dst_drop(skb);
rcu_read_unlock_bh();
goto done;
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 5f344eb..59ebe16 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1883,7 +1883,7 @@ static int inet_netconf_dump_devconf(struct sk_buff *skb,
cb->nlh->nlmsg_seq,
RTM_NEWNETCONF,
NLM_F_MULTI,
- -1) <= 0) {
+ -1) < 0) {
rcu_read_unlock();
goto done;
}
@@ -1899,7 +1899,7 @@ cont:
NETLINK_CB(cb->skb).portid,
cb->nlh->nlmsg_seq,
RTM_NEWNETCONF, NLM_F_MULTI,
- -1) <= 0)
+ -1) < 0)
goto done;
else
h++;
@@ -1910,7 +1910,7 @@ cont:
NETLINK_CB(cb->skb).portid,
cb->nlh->nlmsg_seq,
RTM_NEWNETCONF, NLM_F_MULTI,
- -1) <= 0)
+ -1) < 0)
goto done;
else
h++;
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index f6e43ca..2000110 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2483,7 +2483,7 @@ static int inet_rtm_getroute(struct sk_buff *in_skb, struct nlmsghdr *nlh)
err = rt_fill_info(net, dst, src, &fl4, skb,
NETLINK_CB(in_skb).portid, nlh->nlmsg_seq,
RTM_NEWROUTE, 0, 0);
- if (err <= 0)
+ if (err < 0)
goto errout_free;
err = rtnl_unicast(skb, net, NETLINK_CB(in_skb).portid);
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 8975d95..d6b4f5d 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -4213,7 +4213,7 @@ static int inet6_dump_addr(struct sk_buff *skb, struct netlink_callback *cb,
goto cont;
if (in6_dump_addrs(idev, skb, cb, type,
- s_ip_idx, &ip_idx) <= 0)
+ s_ip_idx, &ip_idx) < 0)
goto done;
cont:
idx++;
--
2.1.0
^ permalink raw reply related
* Re: [net-next PATCH v2 02/12] net: flow_table: add flow, delete flow
From: Simon Horman @ 2015-01-19 5:06 UTC (permalink / raw)
To: John Fastabend; +Cc: tgraf, sfeldma, netdev, gerlitz.or, jhs, andy, davem
In-Reply-To: <20150113213556.13874.41211.stgit@nitbit.x32>
[snip]
> diff --git a/include/linux/if_flow.h b/include/linux/if_flow.h
> index 3e1829e..23dec9b 100644
> --- a/include/linux/if_flow.h
> +++ b/include/linux/if_flow.h
> @@ -185,4 +185,23 @@ struct net_flow_tbl_node {
> __u32 flags;
> struct net_flow_jump_table *jump;
> };
> -#endif
> +
> +/**
> + * @struct net_flow_rule
> + * @brief describes the match/action entry
> + *
> + * @uid unique identifier for flow
> + * @priority priority to execute flow match/action in table
> + * @match null terminated set of match uids match criteria
> + * @actoin null terminated set of action uids to apply to match
Hi John,
@action is miss-spelt above.
[snip]
^ permalink raw reply
* Re: [net-next PATCH v2 03/12] net: flow: implement flow cache for get routines
From: Simon Horman @ 2015-01-19 5:08 UTC (permalink / raw)
To: John Fastabend; +Cc: tgraf, sfeldma, netdev, gerlitz.or, jhs, andy, davem
In-Reply-To: <20150113213621.13874.40461.stgit@nitbit.x32>
On Tue, Jan 13, 2015 at 01:36:22PM -0800, John Fastabend wrote:
[snip]
> diff --git a/include/linux/if_flow.h b/include/linux/if_flow.h
> index 23dec9b..dc70e3e 100644
> --- a/include/linux/if_flow.h
> +++ b/include/linux/if_flow.h
[snip]
> @@ -198,10 +201,28 @@ struct net_flow_tbl_node {
> * Flows must match all entries in match set.
> */
> struct net_flow_rule {
> + struct rhash_head node;
Hi John,
its seems that the 'node' field is new to this structure,
as compared with earlier versions with of this code, and
that some documentation for it should be added to
the comment immediately above the struct definition?
[snip]
^ permalink raw reply
* Re: [net-next PATCH v2 01/12] net: flow_table: create interface for hw match/action tables
From: Simon Horman @ 2015-01-19 5:09 UTC (permalink / raw)
To: John Fastabend; +Cc: tgraf, sfeldma, netdev, gerlitz.or, jhs, andy, davem
In-Reply-To: <20150113213529.13874.16858.stgit@nitbit.x32>
[snip]
> --- /dev/null
> +++ b/net/core/flow_table.c
> @@ -0,0 +1,942 @@
> +/*
> + * include/uapi/linux/if_flow.h - Flow table interface for Switch devices
Hi John,
its seems that the path in the above comment should be
net/core/flow_table.c.
[snip]
^ permalink raw reply
* [PATCH net-next] bridge: remove oflags from setlink/dellink.
From: Rami Rosen @ 2015-01-19 9:45 UTC (permalink / raw)
To: davem; +Cc: netdev, roopa, hemminger, Rami Rosen
Commit 02dba4388d16 ("bridge: fix setlink/dellink notifications") removed usage of oflags in
both rtnl_bridge_setlink() and rtnl_bridge_dellink() methods. This patch removes this variable as it is no
longer needed.
Signed-off-by: Rami Rosen <rami.rosen@intel.com>
---
net/core/rtnetlink.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 0e26b9f..47b39f3 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2918,7 +2918,7 @@ static int rtnl_bridge_setlink(struct sk_buff *skb, struct nlmsghdr *nlh)
struct net_device *dev;
struct nlattr *br_spec, *attr = NULL;
int rem, err = -EOPNOTSUPP;
- u16 oflags, flags = 0;
+ u16 flags = 0;
bool have_flags = false;
if (nlmsg_len(nlh) < sizeof(*ifm))
@@ -2948,8 +2948,6 @@ static int rtnl_bridge_setlink(struct sk_buff *skb, struct nlmsghdr *nlh)
}
}
- oflags = flags;
-
if (!flags || (flags & BRIDGE_FLAGS_MASTER)) {
struct net_device *br_dev = netdev_master_upper_dev_get(dev);
@@ -2993,7 +2991,7 @@ static int rtnl_bridge_dellink(struct sk_buff *skb, struct nlmsghdr *nlh)
struct net_device *dev;
struct nlattr *br_spec, *attr = NULL;
int rem, err = -EOPNOTSUPP;
- u16 oflags, flags = 0;
+ u16 flags = 0;
bool have_flags = false;
if (nlmsg_len(nlh) < sizeof(*ifm))
@@ -3023,8 +3021,6 @@ static int rtnl_bridge_dellink(struct sk_buff *skb, struct nlmsghdr *nlh)
}
}
- oflags = flags;
-
if (!flags || (flags & BRIDGE_FLAGS_MASTER)) {
struct net_device *br_dev = netdev_master_upper_dev_get(dev);
--
1.9.3
^ permalink raw reply related
* Re: Regression from "ipv4: Cache ip_error() routes even when not forwarding."
From: Francesco Ruggeri @ 2015-01-19 6:08 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Francesco Ruggeri, David Miller, netdev, duanj.fnst
In-Reply-To: <CA+HUmGjWOhgEvvtmC=F9TiDbOBXKwcVC+oOtg_vQ2i3G7M5Jng@mail.gmail.com>
On Sat, Jan 17, 2015 at 8:30 AM, Francesco Ruggeri <fruggeri@arista.com> wrote:
> On Sat, Jan 17, 2015 at 12:25 AM, Julian Anastasov <ja@ssi.bg> wrote:
>>
>> Hello,
>>
>> On Fri, 16 Jan 2015, Francesco Ruggeri wrote:
>>
>>> Commit 251da413("ipv4: Cache ip_error() routes even when not forwarding."),
>>> later slightly modified by cd0f0b95("ipv4: distinguish EHOSTUNREACH from
>>> the ENETUNREACH"), introduced a regression where an ip_error route is cached
>>> when an ARP request is received on a non-forwarding non matching interface,
>>> and it affects later legitimate packets for the same destination even if
>>> coming over different interfaces.
>>> Attached are two scripts that show the problem. The first one does basic
>>> forwarding, and the second one does proxy arp.
>>> In both cases a dummy interface is created for the sole purpose of receiving
>>> an ARP request that results in the ip_error route to be cached. The offending
>>> ARP request is generated by using a 'ping -c 1' (commented out in the scripts).
>>> Verified in 3.16 build.
>>
>> 3.16? Just in case, can you check if this
>> fix from 3.18 helps:
>
> Thanks, I will.
>
Thanks Julian, the commit you pointed me to did fix my problem.
Francesco
> Francesco
>
>>
>> commit fa19c2b050ab5254326f5fc07096dd3c6a8d5d58
>> Author: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
>> Date: Thu Oct 30 10:09:53 2014 +0100
>>
>> ipv4: Do not cache routing failures due to disabled forwarding.
>>
>> Regards
>>
>> --
>> Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* RE: [net-next v2 13/15] i40e: limit WoL and link settings to partition 1
From: Yuval Mintz @ 2015-01-19 6:09 UTC (permalink / raw)
To: Nelson, Shannon, Kirsher, Jeffrey T, David Miller
Cc: netdev, nhorman@redhat.com, sassmann@redhat.com,
jogreene@redhat.com
In-Reply-To: <FC41C24E35F18A40888AACA1A36F3E418ADD6433@fmsmsx115.amr.corp.intel.com>
> > How can user be aware of this 'private' behavior?
> > via system logs? documentation?
> In this case, note that we have added a log message that
> says these are dependent on the initial partition of the port
> for setting control. Also, the particular vendor using the
> device in this configuration will supply and support the user documentation.
What I'm 'aiming' for is that this is a common problem;
I.e., having multiple PCI functions per a physical port is a constellation
which exists in several devices.
I think the community strives in such scenarios to uphold a unite front
for user experience - if the 'right' answer is that the network device
associated with the first PCI function is the configuration node in such
cases, then we should strive making it so for all drivers.
> > How does it interact with Physical Device Assignment of the first
> > partition?
> I'm not sure I understand this question, but I'll answer a different
> question: these multifunction ports show up as additional PCI
> functions, again, not unlike VF devices.
You can't refrain from user assigning the first partition to a VM.
In such a case, you receive quite a bizarre configuration when you
all a ~random device on some VM to control the physical port.
^ permalink raw reply
* Re: [PATCH net-next] bridge: remove oflags from setlink/dellink.
From: David Miller @ 2015-01-19 6:23 UTC (permalink / raw)
To: rami.rosen; +Cc: netdev, roopa, hemminger
In-Reply-To: <1421660704-5122-1-git-send-email-rami.rosen@intel.com>
From: Rami Rosen <rami.rosen@intel.com>
Date: Mon, 19 Jan 2015 11:45:04 +0200
> Commit 02dba4388d16 ("bridge: fix setlink/dellink notifications") removed usage of oflags in
> both rtnl_bridge_setlink() and rtnl_bridge_dellink() methods. This patch removes this variable as it is no
> longer needed.
>
> Signed-off-by: Rami Rosen <rami.rosen@intel.com>
Applied, thanks.
^ permalink raw reply
* [PATCH net-next 0/7] r8152: adjust the code
From: Hayes Wang @ 2015-01-19 7:13 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
Code adjustment.
Hayes Wang (7):
r8152: adjust rx_bottom
r8152: adjust lpm timer
r8152: check linking status with netif_carrier_ok
r8152: check RTL8152_UNPLUG for rtl8152_close
r8152: adjust the link feed for hw_features
r8152: replace get_protocol with vlan_get_protocol
r8152: use BIT macro
drivers/net/usb/r8152.c | 99 +++++++++++++++++++++++--------------------------
1 file changed, 46 insertions(+), 53 deletions(-)
--
2.1.0
^ permalink raw reply
* [PATCH net-next 1/7] r8152: adjust rx_bottom
From: Hayes Wang @ 2015-01-19 7:13 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1394712342-15778-118-Taiwan-albertk@realtek.com>
If a error occurs when submitting rx, skip the remaining submissions
and try to submit them again next time.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 2e22442..78a8917 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1655,7 +1655,7 @@ static int rx_bottom(struct r8152 *tp, int budget)
{
unsigned long flags;
struct list_head *cursor, *next, rx_queue;
- int work_done = 0;
+ int ret = 0, work_done = 0;
if (!skb_queue_empty(&tp->rx_queue)) {
while (work_done < budget) {
@@ -1746,7 +1746,18 @@ find_next_rx:
}
submit:
- r8152_submit_rx(tp, agg, GFP_ATOMIC);
+ if (!ret) {
+ ret = r8152_submit_rx(tp, agg, GFP_ATOMIC);
+ } else {
+ urb->actual_length = 0;
+ list_add_tail(&agg->list, next);
+ }
+ }
+
+ if (!list_empty(&rx_queue)) {
+ spin_lock_irqsave(&tp->rx_lock, flags);
+ list_splice_tail(&rx_queue, &tp->rx_done);
+ spin_unlock_irqrestore(&tp->rx_lock, flags);
}
out1:
--
2.1.0
^ permalink raw reply related
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