* Re: [PATCH] net: sctp: bug-fixing: retran_path not set properly after transports recovering (v3)
From: David Miller @ 2013-11-14 21:36 UTC (permalink / raw)
To: changxiangzhong; +Cc: vyasevich, nhorman, linux-sctp, netdev
In-Reply-To: <1384387106-8105-1-git-send-email-changxiangzhong@gmail.com>
From: Chang Xiangzhong <changxiangzhong@gmail.com>
Date: Thu, 14 Nov 2013 00:58:26 +0100
> When a transport recovers due to the new coming sack, SCTP should
> iterate all of its transport_list to locate the __two__ most recently used
> transport and set to active_path and retran_path respectively. The exising
> code does not find the two properly - In case of the following list:
>
> [most-recent] -> [2nd-most-recent] -> ...
>
> Both active_path and retran_path would be set to the 1st element.
>
> The bug happens when:
> 1) multi-homing
> 2) failure/partial_failure transport recovers
> Both active_path and retran_path would be set to the same most-recent one, in
> other words, retran_path would not take its role - an end user might not even
> notice this issue.
>
> Signed-off-by: Chang Xiangzhong <changxiangzhong@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 1/1] net:fec: fix WARNING caused by lack of calls to dma_mapping_error()
From: David Miller @ 2013-11-14 21:37 UTC (permalink / raw)
To: B38611; +Cc: bhutchings, netdev, stephen
In-Reply-To: <1384394230-23380-1-git-send-email-B38611@freescale.com>
From: Fugang Duan <B38611@freescale.com>
Date: Thu, 14 Nov 2013 09:57:10 +0800
> The driver fails to check the results of DMA mapping and results in
> the following warning: (with kernel config "CONFIG_DMA_API_DEBUG" enable)
...
> Because dma-debug add new interfaces to debug dma mapping errors, pls refer
> to: http://lwn.net/Articles/516640/
>
> After dma mapping, it must call dma_mapping_error() to check mapping error,
> otherwise the map_err_type alway is MAP_ERR_NOT_CHECKED, check_unmap() define
> the mapping is not checked and dump the error msg. So,add dma_mapping_error()
> checking to fix the WARNING
>
> And RX DMA buffers are used repeatedly and the driver copies it into an skb,
> fec_enet_rx() should not map or unmap, use dma_sync_single_for_cpu()/dma_sync_single_for_device()
> instead of dma_map_single()/dma_unmap_single().
>
> There have another potential issue: fec_enet_rx() passes the DMA address to __va().
> Physical and DMA addresses are *not* the same thing. They may differ if the device
> is behind an IOMMU or bounce buffering was required, or just because there is a fixed
> offset between the device and host physical addresses. Also fix it in this patch.
>
> =============================================
> V2: add net_ratelimit() to limit map err message.
> use dma_sync_single_for_cpu() instead of dma_map_single().
> fix the issue that pass DMA addresses to __va() to get virture address.
> V1: initial send
> =============================================
>
> Signed-off-by: Fugang Duan <B38611@freescale.com>
Applied, thanks a lot.
^ permalink raw reply
* [PATCH] ipv4: fix possible seqlock deadlock
From: Eric Dumazet @ 2013-11-14 21:37 UTC (permalink / raw)
To: Dave Jones, David Miller; +Cc: netdev
In-Reply-To: <1384458103.28716.33.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
ip4_datagram_connect() being called from process context,
it should use IP_INC_STATS() instead of IP_INC_STATS_BH()
otherwise we can deadlock on 32bit arches, or get corruptions of
SNMP counters.
Fixes: 584bdf8cbdf6 ("[IPV4]: Fix "ipOutNoRoutes" counter error for TCP and UDP")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Dave Jones <davej@redhat.com>
---
net/ipv4/datagram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/datagram.c b/net/ipv4/datagram.c
index b28e863fe0a7..19e36376d2a0 100644
--- a/net/ipv4/datagram.c
+++ b/net/ipv4/datagram.c
@@ -57,7 +57,7 @@ int ip4_datagram_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
if (IS_ERR(rt)) {
err = PTR_ERR(rt);
if (err == -ENETUNREACH)
- IP_INC_STATS_BH(sock_net(sk), IPSTATS_MIB_OUTNOROUTES);
+ IP_INC_STATS(sock_net(sk), IPSTATS_MIB_OUTNOROUTES);
goto out;
}
^ permalink raw reply related
* Re: Fw: [Bug 64981] New: pulseaudio over network desyncs
From: Eric Dumazet @ 2013-11-14 21:40 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, tjakobi
In-Reply-To: <20131114125854.337ca105@samsung-9>
On Thu, 2013-11-14 at 12:58 -0800, Stephen Hemminger wrote:
>
> Begin forwarded message:
>
> Date: Thu, 14 Nov 2013 12:13:46 -0800
> From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
> To: "stephen@networkplumber.org" <stephen@networkplumber.org>
> Subject: [Bug 64981] New: pulseaudio over network desyncs
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=64981
>
> Bug ID: 64981
> Summary: pulseaudio over network desyncs
> Product: Networking
> Version: 2.5
> Kernel Version: 3.10.18
> Hardware: x86-64
> OS: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> Assignee: shemminger@linux-foundation.org
> Reporter: liquid.acid@gmx.net
> Regression: Yes
>
> Hello,
>
> I updated my dedicated audio server to 3.10.18 at the beginning of the week.
> Yesterday I noticed this issue:
>
> When playing back a video/audio file with mpv (mplayer2 also works), where the
> audio is streamed from my local machine to the audio server via pulseaudio, the
> playback desyncs after 5~10 seconds.
>
> The video playback goes into slow-mo, while the audio plays back fine from the
> DAC connected to the audio server. The maintainer of mpv explained that the
> application relies on the pulseaudio output module returning appropriate
> feedback about the samples played back.
>
> Which in turns requires the audio server to reply properly. Going back to
> 3.10.17 solves the issue, so I bisected and got this commit:
>
> tcp: TSQ can use a dynamic limit
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=0ae5f47eff2e543c3b94eec51c740f38a5071432
>
> What is interesting, that I only get these 5~10 seconds of proper playback
> after boot of the system. If I don't reboot, all subsequent playback attempts
> result in an immediate desync.
>
> I also double-checked that this is related to network. I setup an identical PA
> server here on my laptop (just with a different audio output device), updated
> the kernel to this specific commit and used another machine to play back some
> content. Results in the same issue, so I highly doubt this is related to audio
> components.
>
> Greets,
> Tobias
>
Should be fixed by :
http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=98e09386c0ef4dfd48af7ba60ff908f0d525cdee
Thanks !
^ permalink raw reply
* Re: [PATCH] ipv4: fix possible seqlock deadlock
From: Dave Jones @ 2013-11-14 21:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1384465074.28716.41.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, Nov 14, 2013 at 01:37:54PM -0800, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> ip4_datagram_connect() being called from process context,
> it should use IP_INC_STATS() instead of IP_INC_STATS_BH()
> otherwise we can deadlock on 32bit arches, or get corruptions of
> SNMP counters.
>
> Fixes: 584bdf8cbdf6 ("[IPV4]: Fix "ipOutNoRoutes" counter error for TCP and UDP")
whoa, 2007. Any idea why I only just started hitting this ?
Dave
^ permalink raw reply
* Re: [patch] isdnloop: use strlcpy() instead of strcpy()
From: David Miller @ 2013-11-14 21:50 UTC (permalink / raw)
To: dan.carpenter; +Cc: netdev, isdn, kernel-janitors, isdn4linux
In-Reply-To: <20131114082110.GD8150@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 14 Nov 2013 11:21:10 +0300
> These strings come from a copy_from_user() and there is no way to be
> sure they are NUL terminated.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied and queued up for -stable, thanks Dan.
^ permalink raw reply
* Re: [PATCH] ipv4: fix possible seqlock deadlock
From: Eric Dumazet @ 2013-11-14 21:52 UTC (permalink / raw)
To: Dave Jones; +Cc: David Miller, netdev
In-Reply-To: <20131114214402.GA23872@redhat.com>
On Thu, 2013-11-14 at 16:44 -0500, Dave Jones wrote:
> On Thu, Nov 14, 2013 at 01:37:54PM -0800, Eric Dumazet wrote:
> > From: Eric Dumazet <edumazet@google.com>
> >
> > ip4_datagram_connect() being called from process context,
> > it should use IP_INC_STATS() instead of IP_INC_STATS_BH()
> > otherwise we can deadlock on 32bit arches, or get corruptions of
> > SNMP counters.
> >
> > Fixes: 584bdf8cbdf6 ("[IPV4]: Fix "ipOutNoRoutes" counter error for TCP and UDP")
>
> whoa, 2007. Any idea why I only just started hitting this ?
>
lockdep support was added very recently.
^ permalink raw reply
* Re: [PATCH net v3] bonding: add ip checks when store ip target
From: David Miller @ 2013-11-14 21:55 UTC (permalink / raw)
To: dingtianhong; +Cc: fubar, andy, nikolay, vfalico, netdev
In-Reply-To: <5284ADD2.2060004@huawei.com>
From: Ding Tianhong <dingtianhong@huawei.com>
Date: Thu, 14 Nov 2013 19:02:42 +0800
> targets = bond->params.arp_targets;
> - newtarget = in_aton(buf + 1);
> + if (!in4_pton(buf + 1, -1, (u8 *)&newtarget, -1, NULL) ||
> + IS_IP_TARGET_UNUSABLE_ADDRESS(newtarget)) {
This is not indented correctly.
On the second line, the IS_IP_TARGET... should start at the very
first column after the openning parenthesis on the previous line.
If you are using only TAB characters to indent, rather than an
appropriate mix of TAB and SPACE characters, you are doing it
wrong.
Thanks.
^ permalink raw reply
* Re: [PATCH net 1/3] sit: fix prefix length of ll and v4mapped addresses
From: David Miller @ 2013-11-14 21:59 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <1384433467-4780-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 14 Nov 2013 13:51:05 +0100
> When the local IPv4 endpoint is wilcard (0.0.0.0), the prefix length is
> correctly set, ie 64 if the address is a link local one or 96 if the address is
> a v4 mapped one.
> But when the local endpoint is specified, the prefix length is set to 128 for
> both kind of address. This patch fix this wrong prefix length.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 2/3] sit: link local routes are missing
From: David Miller @ 2013-11-14 21:59 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <1384433467-4780-2-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 14 Nov 2013 13:51:06 +0100
> When a link local address was added to a sit interface, the corresponding route
> was not configured. This breaks routing protocols that use the link local
> address, like OSPFv3.
>
> To ease the code reading, I remove sit_route_add(), which only adds v4 mapped
> routes, and add this kind of route directly in sit_add_v4_addrs(). Thus link
> local and v4 mapped routes are configured in the same place.
>
> Reported-by: Li Hongjun <hongjun.li@6wind.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 3/3] sit/gre6: don't try to add the same route two times
From: David Miller @ 2013-11-14 21:59 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <1384433467-4780-3-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 14 Nov 2013 13:51:07 +0100
> addrconf_add_linklocal() already adds the link local route, so there is no
> reason to add it before calling this function.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied.
^ permalink raw reply
* Re: [PATCH net v2 1/2] macvlan: introduce macvlan_dev_real_dev() helper function
From: David Miller @ 2013-11-14 22:03 UTC (permalink / raw)
To: mkubecek; +Cc: vyasevich, netdev, kaber, john.r.fastabend
In-Reply-To: <20131114155756.GA4161@lion.mk-sys.cz>
From: Michal Kubecek <mkubecek@suse.cz>
Date: Thu, 14 Nov 2013 16:57:57 +0100
> On Thu, Nov 14, 2013 at 10:03:19AM -0500, Vlad Yasevich wrote:
>> On 11/14/2013 09:00 AM, Michal Kubecek wrote:
>> >+#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().
>
> I'm not sure. It makes sense from the developer point of view: if we
> find an inconsistency which must be caused by a bug in kernel code, do
> panic so that the bug is found and fixed as soon as possible. However,
> I remember a discussion where the point was that BUG() and BUG_ON()
> should only be used if there is no way to recover. From this point of
> view, WARN or WARN_ONCE might be better choice - but I'm not strictly
> opposed to BUG().
At least for the time being use BUG(), to be consistent with the same
way how VLAN handles this situation.
Thanks.
^ permalink raw reply
* Re: [PATCH net] ip6tnl: fix use after free of fb_tnl_dev
From: David Miller @ 2013-11-14 22:05 UTC (permalink / raw)
To: nicolas.dichtel
Cc: rostedt, linux-kernel, stable, gregkh, williams, linux-rt-users,
lclaudio, netdev, willemb
In-Reply-To: <1384440423-4275-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 14 Nov 2013 15:47:03 +0100
> 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>
Applied and queued up for -stable, thanks for being so proactive about this
Nicolas.
^ permalink raw reply
* Re: [PATCH net-next 0/6] 6lowpan: udp compression/uncompression fix
From: David Miller @ 2013-11-14 22:06 UTC (permalink / raw)
To: eric.dumazet
Cc: alex.aring, alex.bluesman.smirnov, linux-zigbee-devel, werner,
jukka.rissanen, dbaryshkov, netdev
In-Reply-To: <1384445983.28716.1.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 14 Nov 2013 08:19:43 -0800
> On Thu, 2013-11-14 at 16:48 +0100, Alexander Aring wrote:
>> The current 6LoWPAN udp compression/uncompression is completely broken.
>> This patch series fix a lot of udp compression/uncompression issues and
>> add support parsing with lowpan_fetch_skb function.
>
> If its broken, why targeting net-next tree (which is closed BTW ATM) ?
In any event, if you do want it to go into net-next, please resubmit
this series when the net-next tree opens back up after the merge
window.
Thanks!
^ permalink raw reply
* Re: [PATCH 0/9] genetlink: reduce ops size and complexity (v2)
From: David Miller @ 2013-11-14 22:12 UTC (permalink / raw)
To: johannes
Cc: netdev, linux-wimax, bsingharora, netfilter-devel,
alex.bluesman.smirnov, dbaryshkov
In-Reply-To: <1384445687-30948-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 14 Nov 2013 17:14:38 +0100
> As before - reduce the complexity and data/code size of genetlink ops
> by making them an array rather than a linked list. Most users already
> use an array thanks to genl_register_family_with_ops(), so convert the
> remaining ones allowing us to get rid of the list head in each op.
>
> Also make them const, this just makes sense at that point and the security
> people like making function pointers const as well :-)
I have to say, this is an absolutely fantastic space usage and
complexity improvement.
Applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH] alx: Reset phy speed after resume
From: David Miller @ 2013-11-14 22:15 UTC (permalink / raw)
To: linux
Cc: jcliburn, chris.snook, johannes, wangyijing, maarten.lankhorst,
netdev, linux-kernel
In-Reply-To: <1384445773.29057.5.camel@localhost.tld>
From: hahnjo <linux@hahnjo.de>
Date: Thu, 14 Nov 2013 17:16:13 +0100
> From 27744b24f9291782c1342dbd6cac511e68da907c Mon Sep 17 00:00:00 2001
> From: hahnjo <hahnjo@hahnjo.de>
> Date: Tue, 12 Nov 2013 18:19:24 +0100
> Subject: [PATCH] alx: Reset phy speed after resume
>
> This fixes bug 62491 (https://bugzilla.kernel.org/show_bug.cgi?id=62491).
> After resuming some users got the following error flooding the kernel log:
> alx 0000:02:00.0: invalid PHY speed/duplex: 0xffff
>
> Signed-off-by: Jonas Hahnfeld <linux@hahnjo.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] pkt_sched: fq: change classification of control packets
From: David Miller @ 2013-11-14 22:16 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, maze, willemb, ycheng, stephen
In-Reply-To: <1384447843.28716.15.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 14 Nov 2013 08:50:43 -0800
> From: Maciej Żenczykowski <maze@google.com>
>
> Initial sch_fq implementation copied code from pfifo_fast to classify
> a packet as a high prio packet.
>
> This clashes with setups using PRIO with say 7 bands, as one of the
> band could be incorrectly (mis)classified by FQ.
>
> Packets would be queued in the 'internal' queue, and no pacing ever
> happen for this special queue.
>
> Fixes: afe4fd062416 ("pkt_sched: fq: Fair Queue packet scheduler")
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH net] ip6tnl: fix use after free of fb_tnl_dev
From: Steven Rostedt @ 2013-11-14 22:18 UTC (permalink / raw)
To: David Miller
Cc: nicolas.dichtel, linux-kernel, stable, gregkh, williams,
linux-rt-users, lclaudio, netdev, willemb
In-Reply-To: <20131114.170529.1627250972818871118.davem@davemloft.net>
On Thu, 14 Nov 2013 17:05:29 -0500 (EST)
David Miller <davem@davemloft.net> wrote:
> Applied and queued up for -stable, thanks for being so proactive about this
> Nicolas.
I should also note that I added this back to 3.10.18 and the bug goes
away.
If it's not too late:
Tested-by: Steven Rostedt <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH] connector: improved unaligned access error fix
From: David Miller @ 2013-11-14 22:20 UTC (permalink / raw)
To: cmetcalf; +Cc: zbr, erikj, akpm, matthltc, zaitcev, netdev, linux-kernel
In-Reply-To: <201311141743.rAEHhuEV004998@farm-0012.internal.tilera.com>
From: Chris Metcalf <cmetcalf@tilera.com>
Date: Thu, 14 Nov 2013 12:09:21 -0500
> In af3e095a1fb4, Erik Jacobsen fixed one type of unaligned access
> bug for ia64 by converting a 64-bit write to use put_unaligned().
> Unfortunately, since gcc will convert a short memset() to a series
> of appropriately-aligned stores, the problem is now visible again
> on tilegx, where the memset that zeros out proc_event is converted
> to three 64-bit stores, causing an unaligned access panic.
>
> A better fix for the original problem is to ensure that proc_event
> is aligned to 8 bytes here. We can do that relatively easily by
> arranging to start the struct cn_msg aligned to 8 bytes and then
> offset by 4 bytes. Doing so means that the immediately following
> proc_event structure is then correctly aligned to 8 bytes.
>
> The result is that the memset() stores are now aligned, and as an
> added benefit, we can remove the put_unaligned() calls in the code.
>
> Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
This looks fine to me, applied and queued up for -stable, thanks
Chris.
^ permalink raw reply
* Re: [PATCH] pkt_sched: fq: fix pacing for small frames
From: David Miller @ 2013-11-14 22:22 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, maze, willemb, ycheng, ncardwell
In-Reply-To: <1384455496.28716.27.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 14 Nov 2013 10:58:16 -0800
> @@ -655,9 +664,6 @@ static int fq_change(struct Qdisc *sch, struct nlattr *opt)
> if (tb[TCA_FQ_INITIAL_QUANTUM])
> q->initial_quantum = nla_get_u32(tb[TCA_FQ_INITIAL_QUANTUM]);
>
> - if (tb[TCA_FQ_FLOW_DEFAULT_RATE])
> - q->flow_default_rate = nla_get_u32(tb[TCA_FQ_FLOW_DEFAULT_RATE]);
> -
> if (tb[TCA_FQ_FLOW_MAX_RATE])
> q->flow_max_rate = nla_get_u32(tb[TCA_FQ_FLOW_MAX_RATE]);
>
I think it's at best confusing to suddenly stop ignoring a configuration
parameter the user is giving us.
Can you at least ratelimit warn if the parameter is specified so the user
has some chance to figure out what is happening?
Thanks.
^ permalink raw reply
* Re: [PATCH] virtio-net: mergeable buffer size should include virtio-net header
From: David Miller @ 2013-11-14 22:23 UTC (permalink / raw)
To: eric.dumazet; +Cc: mwdalton, mst, netdev, dborkman, virtualization, edumazet
In-Reply-To: <1384455552.28716.28.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 14 Nov 2013 10:59:12 -0800
> On Thu, 2013-11-14 at 10:41 -0800, Michael Dalton wrote:
>> Commit 2613af0ed18a ("virtio_net: migrate mergeable rx buffers to page
>> frag allocators") changed the mergeable receive buffer size from PAGE_SIZE
>> to MTU-size. However, the merge buffer size does not take into account the
>> size of the virtio-net header. Consequently, packets that are MTU-size
>> will take two buffers intead of one (to store the virtio-net header),
>> substantially decreasing the throughput of MTU-size traffic due to TCP
>> window / SKB truesize effects.
>>
>> This commit changes the mergeable buffer size to include the virtio-net
>> header. The buffer size is cacheline-aligned because skb_page_frag_refill
>> will not automatically align the requested size.
>>
>> Benchmarks taken from an average of 5 netperf 30-second TCP_STREAM runs
>> between two QEMU VMs on a single physical machine. Each VM has two VCPUs and
>> vhost enabled. All VMs and vhost threads run in a single 4 CPU cgroup
>> cpuset, using cgroups to ensure that other processes in the system will not
>> be scheduled on the benchmark CPUs. Transmit offloads and mergeable receive
>> buffers are enabled, but guest_tso4 / guest_csum are explicitly disabled to
>> force MTU-sized packets on the receiver.
>>
>> next-net trunk before 2613af0ed18a (PAGE_SIZE buf): 3861.08Gb/s
>> net-next trunk (MTU 1500- packet uses two buf due to size bug): 4076.62Gb/s
>> net-next trunk (MTU 1480- packet fits in one buf): 6301.34Gb/s
>> net-next trunk w/ size fix (MTU 1500 - packet fits in one buf): 6445.44Gb/s
>>
>> Suggested-by: Eric Northup <digitaleric@google.com>
>> Signed-off-by: Michael Dalton <mwdalton@google.com>
>> ---
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied, thanks.
^ permalink raw reply
* Re: pull request: wireless 2013-11-14
From: David Miller @ 2013-11-14 22:24 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20131114191119.GB17693-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Thu, 14 Nov 2013 14:11:20 -0500
> Please pull this batch of fixes intended for the 3.13 stream!
Pulled, thanks John.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net/hsr: Fix possible leak in 'hsr_get_node_status()'
From: David Miller @ 2013-11-14 22:26 UTC (permalink / raw)
To: geyslan; +Cc: arvid.brodin, netdev, linux-kernel
In-Reply-To: <1384456378-29970-1-git-send-email-geyslan@gmail.com>
From: "Geyslan G. Bem" <geyslan@gmail.com>
Date: Thu, 14 Nov 2013 16:12:54 -0300
> If 'hsr_get_node_data()' returns error, going directly to 'fail' label
> doesn't free the memory pointed by 'skb_out'.
>
> Signed-off-by: Geyslan G. Bem <geyslan@gmail.com>
Looks good, applied, thanks!
^ permalink raw reply
* Re: [PATCH] ipv4: fix possible seqlock deadlock
From: David Miller @ 2013-11-14 22:32 UTC (permalink / raw)
To: eric.dumazet; +Cc: davej, netdev
In-Reply-To: <1384465074.28716.41.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 14 Nov 2013 13:37:54 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> ip4_datagram_connect() being called from process context,
> it should use IP_INC_STATS() instead of IP_INC_STATS_BH()
> otherwise we can deadlock on 32bit arches, or get corruptions of
> SNMP counters.
>
> Fixes: 584bdf8cbdf6 ("[IPV4]: Fix "ipOutNoRoutes" counter error for TCP and UDP")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Dave Jones <davej@redhat.com>
Applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH] pkt_sched: fq: fix pacing for small frames
From: Eric Dumazet @ 2013-11-14 22:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev, maze, willemb, ycheng, ncardwell
In-Reply-To: <20131114.172220.940454781221829007.davem@davemloft.net>
On Thu, 2013-11-14 at 17:22 -0500, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 14 Nov 2013 10:58:16 -0800
>
> > @@ -655,9 +664,6 @@ static int fq_change(struct Qdisc *sch, struct nlattr *opt)
> > if (tb[TCA_FQ_INITIAL_QUANTUM])
> > q->initial_quantum = nla_get_u32(tb[TCA_FQ_INITIAL_QUANTUM]);
> >
> > - if (tb[TCA_FQ_FLOW_DEFAULT_RATE])
> > - q->flow_default_rate = nla_get_u32(tb[TCA_FQ_FLOW_DEFAULT_RATE]);
> > -
> > if (tb[TCA_FQ_FLOW_MAX_RATE])
> > q->flow_max_rate = nla_get_u32(tb[TCA_FQ_FLOW_MAX_RATE]);
> >
>
> I think it's at best confusing to suddenly stop ignoring a configuration
> parameter the user is giving us.
>
> Can you at least ratelimit warn if the parameter is specified so the user
> has some chance to figure out what is happening?
Oh this parameter was removed in 7eec4174ff29cd
("pkt_sched: fq: fix non TCP flows pacing"), I probably should
have added this warning at that time...
OK, we can warn the user, will send a v2.
^ 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