* Re: [PATCH] net-tcp: fix panic in tcp_fastopen_cache_set()
From: Eric Dumazet @ 2013-11-14 19:38 UTC (permalink / raw)
To: Johannes Berg; +Cc: Dave Jones, David Miller, netdev, Yuchung Cheng
In-Reply-To: <1384457800.28716.30.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, 2013-11-14 at 11:36 -0800, Eric Dumazet wrote:
> On Thu, 2013-11-14 at 20:13 +0100, Johannes Berg wrote:
> > On Wed, 2013-11-13 at 15:00 -0800, Eric Dumazet wrote:
> >
> > > --- a/net/ipv4/tcp_metrics.c
> > > +++ b/net/ipv4/tcp_metrics.c
> > > @@ -663,10 +663,13 @@ void tcp_fastopen_cache_get(struct sock *sk, u16 *mss,
> > > void tcp_fastopen_cache_set(struct sock *sk, u16 mss,
> > > struct tcp_fastopen_cookie *cookie, bool syn_lost)
> > > {
> > > + struct dst_entry *dst = __sk_dst_get(sk);
> > > struct tcp_metrics_block *tm;
> > >
> > > + if (!dst)
> > > + return;
> > > rcu_read_lock();
> > > - tm = tcp_get_metrics(sk, __sk_dst_get(sk), true);
> >
> > Doesn't that __sk_dst_get() have to go inside the rcu_read_lock()?
> >
> > Then again, I guess we hold the socket. Still looks a bit weird to be
> > moving it out.
>
> Yep, in fact this rcu_read_lock() is not needed. I'll send a v2.
I take it back.
the rcu_read_lock() protects the tcp_get_metrics(), not the
__sk_dst_get(sk)
So the patch is correct, unless you disagree of course ;)
^ permalink raw reply
* Re: [PATCH] connector: improved unaligned access error fix
From: Pete Zaitcev @ 2013-11-14 19:45 UTC (permalink / raw)
To: Chris Metcalf
Cc: Evgeniy Polyakov, Erik Jacobson, Andrew Morton, Matt Helsley,
netdev, linux-kernel, zaitcev
In-Reply-To: <201311141743.rAEHhuEV004998@farm-0012.internal.tilera.com>
On Thu, 14 Nov 2013 12:09:21 -0500
Chris Metcalf <cmetcalf@tilera.com> wrote:
> - __u8 buffer[CN_PROC_MSG_SIZE];
> + __u8 buffer[CN_PROC_MSG_SIZE] __aligned(8);
> - msg = (struct cn_msg *)buffer;
> + msg = buffer_to_cn_msg(buffer);
> ev = (struct proc_event *)msg->data;
> memset(&ev->event_data, 0, sizeof(ev->event_data));
Why is memset(buffer,0,CN_PROC_MSG_SIZE) not acceptable?
-- Pete
^ permalink raw reply
* Re: softirq lockdep trace when ethernet (tg3) brought up.
From: Eric Dumazet @ 2013-11-14 19:41 UTC (permalink / raw)
To: Dave Jones; +Cc: netdev
In-Reply-To: <20131114191621.GB9630@redhat.com>
On Thu, 2013-11-14 at 14:16 -0500, Dave Jones wrote:
> See this during boot on one of my test boxes:
> Not sure why it only shows up on that machine. TG3 specific ?
Not tg3 specific, 32bit arches specific ;)
Thanks for the report, I'll take a look.
^ 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: David Miller @ 2013-11-14 19:57 UTC (permalink / raw)
To: nicolas.dichtel
Cc: hannes, netdev, David.Laight, jiri, vyasevich, kuznet, jmorris,
yoshfuji, kaber, thaller, stephen
In-Reply-To: <5284CA7C.7030402@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 14 Nov 2013 14:05:00 +0100
> Le 11/11/2013 06:18, David Miller a écrit :
>> Furthermore, the fact that you're implementing _addressing_ policy in
>> the UDP code makes this change even more unreasonable.
>>
> I made this choice because using 0.0.0.0, for TCP for example, seems a
> non-sense.
It's at the very least something applicable to all datagram sockets.
^ 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: David Miller @ 2013-11-14 20:00 UTC (permalink / raw)
To: hannes
Cc: nicolas.dichtel, netdev, David.Laight, jiri, vyasevich, kuznet,
jmorris, yoshfuji, kaber, thaller, stephen
In-Reply-To: <20131114143154.GD26901@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Thu, 14 Nov 2013 15:31:54 +0100
> 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?
I think it is kind of pointless to protect ourselves from locally
generated packets, for which the flow ID was explicitly asked for
by the application.
So yes I think relaxing rp_filter in such cases makes sense.
^ permalink raw reply
* Re: [PATCH] net/hsr: Fix possible leak in 'hsr_get_node_status()'
From: Geyslan Gregório Bem @ 2013-11-14 20:29 UTC (permalink / raw)
To: Geyslan Gregório Bem
Cc: David S. Miller, Arvid Brodin, open list:NETWORKING [GENERAL],
open list
In-Reply-To: <1384456378-29970-1-git-send-email-geyslan@gmail.com>
2013/11/14 Geyslan G. Bem <geyslan@gmail.com>:
> 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>
> ---
> net/hsr/hsr_netlink.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/hsr/hsr_netlink.c b/net/hsr/hsr_netlink.c
> index 4e66bf6..aef8429 100644
> --- a/net/hsr/hsr_netlink.c
> +++ b/net/hsr/hsr_netlink.c
> @@ -249,7 +249,7 @@ static int hsr_get_node_status(struct sk_buff *skb_in, struct genl_info *info)
> &hsr_node_if2_age,
> &hsr_node_if2_seq);
> if (res < 0)
> - goto fail;
> + goto nla_put_failure;
>
> res = nla_put(skb_out, HSR_A_NODE_ADDR, ETH_ALEN,
> nla_data(info->attrs[HSR_A_NODE_ADDR]));
> --
> 1.8.4.2
>
It's a Coverity catch: CID 1128855.
--
Regards,
Geyslan G. Bem
hackingbits.com
^ permalink raw reply
* [PATCH] net: sctp: recover a tranport when an ack comes
From: Chang Xiangzhong @ 2013-11-14 20:40 UTC (permalink / raw)
To: vyasevich, nhorman
Cc: davem, linux-sctp, netdev, linux-kernel, dreibh, ernstgr,
Chang Xiangzhong
Expected Behavior:
When hearing an ack from a tranport/path, set its state to normal/on if it's
in abnormal(__partial_failure__ or inactive) state.
state machine of tranport->state
Whenever a T3_RTX timer expires, then transport->error_count++.
When (association->pf_retrans < transport->error_count < tranport->pathmaxrtx)
transport->state = SCTP_PF //partial failure
When a heartbeat-ack comes or conventional ack acknowledged its availability,
transport->state = SCTP_ON
Signed-off-by: Chang Xiangzhong <changxiangzhong@gmail.com>
Fixes: 5aa93bcf66f ("sctp: Implement quick failover draft from tsvwg")
---
net/sctp/outqueue.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
index 94df758..2557fa5 100644
--- a/net/sctp/outqueue.c
+++ b/net/sctp/outqueue.c
@@ -1517,6 +1517,7 @@ static void sctp_check_transmitted(struct sctp_outq *q,
* active if it is not so marked.
*/
if ((transport->state == SCTP_INACTIVE ||
+ transport->state == SCTP_PF ||
transport->state == SCTP_UNCONFIRMED) &&
sctp_cmp_addr_exact(&transport->ipaddr, saddr)) {
sctp_assoc_control_transport(
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] rds: fix local ping DoS
From: Jay Fenlason @ 2013-11-14 20:47 UTC (permalink / raw)
To: David Miller
Cc: johunt, netdev, venkat.x.venkatsubra, linux-kernel, jjolly, honli
In-Reply-To: <20131114.020355.1973894145326845195.davem@davemloft.net>
On Thu, Nov 14, 2013 at 02:03:55AM -0500, David Miller wrote:
> From: Josh Hunt <johunt@akamai.com>
> Date: Wed, 13 Nov 2013 17:15:43 -0800
>
> > The rds_ib_xmit function in net/rds/ib_send.c in the Reliable Datagram Sockets
> > (RDS) protocol implementation allows local users to cause a denial of service
> > (BUG_ON and kernel panic) by establishing an RDS connection with the source
> > IP address equal to the IPoIB interface's own IP address, as demonstrated by
> > rds-ping.
> >
> > A local unprivileged user could use this flaw to crash the system.
> >
> > CVE-2012-2372
> >
> > Reported-by: Honggang Li <honli@redhat.com>
> > Signed-off-by: Josh Hunt <johunt@akamai.com>
>
> I'm sorry I can't apply this. This commit message needs to be much
> less terse and explain things more.
>
> First of all, why is the "off % RDS_FRAG_SIZE" important?
>
> And, even more importantly, why is is OK to avoid this assertion just
> because we're going over loopback?
>
> Furthermore, why doesn't net/rds/iw_send.c:rds_iw_xmit() have the same
> exact problem? It makes the same exact assertion check.
>
> I know this RDS code is a steaming pile of poo, but that doesn't mean
> we just randomly adjust assertions to make crashes go away without
> sufficient understanding of exactly what's going on.
And that is why rds should be moved to staging, where nobody will
accidentally think that it is actually being maintained.
-- JF
^ permalink raw reply
* Re: [PATCH] net-tcp: fix panic in tcp_fastopen_cache_set()
From: Johannes Berg @ 2013-11-14 20:53 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Dave Jones, David Miller, netdev, Yuchung Cheng
In-Reply-To: <1384457922.28716.32.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, 2013-11-14 at 11:38 -0800, Eric Dumazet wrote:
> > > Doesn't that __sk_dst_get() have to go inside the rcu_read_lock()?
> > >
> > > Then again, I guess we hold the socket. Still looks a bit weird to be
> > > moving it out.
> >
> > Yep, in fact this rcu_read_lock() is not needed. I'll send a v2.
>
> I take it back.
>
> the rcu_read_lock() protects the tcp_get_metrics(), not the
> __sk_dst_get(sk)
>
> So the patch is correct, unless you disagree of course ;)
Heh. I have no idea, it just seemed a little odd on first look given
that __sk_dst_get() *can* actually use RCU protection. :)
johannes
^ permalink raw reply
* Fw: [Bug 64981] New: pulseaudio over network desyncs
From: Stephen Hemminger @ 2013-11-14 20:58 UTC (permalink / raw)
To: netdev
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
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH net V2 1/2] tuntap: limit head length of skb allocated
From: David Miller @ 2013-11-14 21:06 UTC (permalink / raw)
To: jasowang; +Cc: netdev, linux-kernel, mst, stefanha, gregory.v.rose
In-Reply-To: <1384322440-29038-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Wed, 13 Nov 2013 14:00:39 +0800
> We currently use hdr_len as a hint of head length which is advertised by
> guest. But when guest advertise a very big value, it can lead to an 64K+
> allocating of kmalloc() which has a very high possibility of failure when host
> memory is fragmented or under heavy stress. The huge hdr_len also reduce the
> effect of zerocopy or even disable if a gso skb is linearized in guest.
>
> To solves those issues, this patch introduces an upper limit (PAGE_SIZE) of the
> head, which guarantees an order 0 allocation each time.
>
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net V2 2/2] macvtap: limit head length of skb allocated
From: David Miller @ 2013-11-14 21:06 UTC (permalink / raw)
To: jasowang; +Cc: netdev, linux-kernel, mst, stefanha, gregory.v.rose
In-Reply-To: <1384322440-29038-2-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Wed, 13 Nov 2013 14:00:40 +0800
> We currently use hdr_len as a hint of head length which is advertised by
> guest. But when guest advertise a very big value, it can lead to an 64K+
> allocating of kmalloc() which has a very high possibility of failure when host
> memory is fragmented or under heavy stress. The huge hdr_len also reduce the
> effect of zerocopy or even disable if a gso skb is linearized in guest.
>
> To solves those issues, this patch introduces an upper limit (PAGE_SIZE) of the
> head, which guarantees an order 0 allocation each time.
>
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH 1/2] random32: add __init prefix to prandom_start_seed_timer
From: David Miller @ 2013-11-14 21:06 UTC (permalink / raw)
To: dborkman; +Cc: netdev, hannes
In-Reply-To: <1384296342-3348-1-git-send-email-dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Tue, 12 Nov 2013 23:45:41 +0100
> We only call that in functions annotated with __init, so add __init
> prefix in prandom_start_seed_timer() as well, so that the kernel can
> make use of this hint and we can possibly free up resources after it's
> usage. And since it's an internal function rename it to
> __prandom_start_seed_timer().
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] random32: use msecs_to_jiffies for reseed timer
From: David Miller @ 2013-11-14 21:07 UTC (permalink / raw)
To: dborkman; +Cc: netdev, hannes
In-Reply-To: <1384296342-3348-2-git-send-email-dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Tue, 12 Nov 2013 23:45:42 +0100
> Use msecs_to_jiffies, for these calculations as different HZ
> considerations are taken into account for conversion of the timer
> shot, and also it makes the code more readable.
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied.
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Vlad Yasevich @ 2013-11-14 21:13 UTC (permalink / raw)
To: Veaceslav Falico, Stefan Priebe - Profihost AG
Cc: vyasevic, Linux Netdev List
In-Reply-To: <20131114122928.GV19702@redhat.com>
On 11/14/2013 07:29 AM, Veaceslav Falico wrote:
> On Thu, Nov 14, 2013 at 08:47:28AM +0100, Stefan Priebe - Profihost AG
> wrote:
>> Hi,
>>
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> / \
>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>> \ ---- tap114i1
>>
>> thos one works fine now.
>>
>>
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> / \
>>> eth3 \ vmbr1.3000
>>> \ ---- tap114i1
>>
>> this one does not. Another note to this one. It also never worked on
>> RHEL6 - it started working with about 2.6.39 and stopped with 3.9 or
>> 3.10. But it was the only one where gvrp on vlans had worked.
>
> bridge device in this config is neither master nor slave, if I read it
> correctly.
Bridge doesn't propagate rx_flags to lower-level devices. It
automatically set all lower devices to promisc mode.
So, in the second case above, eth2 and eth3 have to be in promisc, but
nothing else does. I am not sure I understand Stefans notation though
wrt to how vmbr1.3000 and tap114i1 are configured. Stefan, can you
elaborate?
Thanks
-vlad
>
> You might want to try my patch to see if it works (my previous email).
>
>>
>> Greets,
>> Stefan
>> --
>> 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 0/3] bridge: Fix undesirable behavior related to vlan
From: David Miller @ 2013-11-14 21:17 UTC (permalink / raw)
To: makita.toshiaki; +Cc: stephen, vyasevic, netdev
In-Reply-To: <1384331175-4136-1-git-send-email-makita.toshiaki@lab.ntt.co.jp>
From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Date: Wed, 13 Nov 2013 17:26:11 +0900
> There seem to be some problems around vlan code.
>
> - Unexpectedly filter vlan by NIC.
> - Not correctly decrement refcount of vlan_vid_info.
> - Memory leak when deleting a bridge with vlan_info allocated.
>
> This is a patch series to fix these issues.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: ethernet: ti/cpsw: do not crash on single-MAC machines during resume
From: David Miller @ 2013-11-14 21:21 UTC (permalink / raw)
To: zonque; +Cc: netdev, mugunthanvnm
In-Reply-To: <1384347180-3490-1-git-send-email-zonque@gmail.com>
From: Daniel Mack <zonque@gmail.com>
Date: Wed, 13 Nov 2013 13:53:00 +0100
> To prevent Oopses, cpsw_suspend() should only soft-reset sliver 1
> on dual MAC enabled machines.
>
> Signed-off-by: Daniel Mack <zonque@gmail.com>
Please reimplement this using for_each_slave() as Mungunthan suggested.
Thanks.
^ permalink raw reply
* Re: [PATCH] connector: improved unaligned access error fix
From: Chris Metcalf @ 2013-11-14 21:22 UTC (permalink / raw)
To: Pete Zaitcev
Cc: Evgeniy Polyakov, Erik Jacobson, Andrew Morton, Matt Helsley,
netdev, linux-kernel
In-Reply-To: <20131114124549.7b5f3a7b@lembas.zaitcev.lan>
On 11/14/2013 2:45 PM, Pete Zaitcev wrote:
> On Thu, 14 Nov 2013 12:09:21 -0500
> Chris Metcalf <cmetcalf@tilera.com> wrote:
>
>> - __u8 buffer[CN_PROC_MSG_SIZE];
>> + __u8 buffer[CN_PROC_MSG_SIZE] __aligned(8);
>> - msg = (struct cn_msg *)buffer;
>> + msg = buffer_to_cn_msg(buffer);
>> ev = (struct proc_event *)msg->data;
>> memset(&ev->event_data, 0, sizeof(ev->event_data));
> Why is memset(buffer,0,CN_PROC_MSG_SIZE) not acceptable?
That would be fine from a correctness point of view; I'm happy
either way. My patch nominally has better performance, for
what that's worth, since the memset() call is for a smaller
range (24 bytes instead of 60). It also avoids the need for
put_unaligned(), which even on platforms that allow unaligned
stores can still be slower.
I can certainly do a v2 with the larger memset() instead if
that's the consensus.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply
* Re: [PATCH] net-tcp: fix panic in tcp_fastopen_cache_set()
From: Eric Dumazet @ 2013-11-14 21:22 UTC (permalink / raw)
To: Johannes Berg; +Cc: Dave Jones, David Miller, netdev, Yuchung Cheng
In-Reply-To: <1384462403.13941.41.camel@jlt4.sipsolutions.net>
On Thu, 2013-11-14 at 21:53 +0100, Johannes Berg wrote:
> Heh. I have no idea, it just seemed a little odd on first look given
> that __sk_dst_get() *can* actually use RCU protection. :)
Yep, the deal is that if you own socket lock, you do not need
rcu_read_lock()
Look for dst_negative_advice() as another example :
We call __sk_dst_get(sk) without rcu_read_lock() protection.
^ permalink raw reply
* Re: [PATCH net 0/6] net_tstamp: Validate hwtstamp_config completely before applying it
From: David Miller @ 2013-11-14 21:23 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, richardcochran
In-Reply-To: <1384389542.29151.5.camel@bwh-desktop.uk.level5networks.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 14 Nov 2013 00:39:02 +0000
> This series fixes very similar bugs in 6 implementations of
> SIOCSHWTSTAMP.
Series applied, thanks Ben.
^ permalink raw reply
* Re: [PATCH v2] tcp: tsq: restore minimal amount of queueing
From: David Miller @ 2013-11-14 21:26 UTC (permalink / raw)
To: eric.dumazet; +Cc: arno, sujith, xiyou.wangcong, netdev, nbd
In-Reply-To: <1384353174.28458.110.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 13 Nov 2013 06:32:54 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> After commit c9eeec26e32e ("tcp: TSQ can use a dynamic limit"), several
> users reported throughput regressions, notably on mvneta and wifi
> adapters.
>
> 802.11 AMPDU requires a fair amount of queueing to be effective.
>
> This patch partially reverts the change done in tcp_write_xmit()
> so that the minimal amount is sysctl_tcp_limit_output_bytes.
>
> It also remove the use of this sysctl while building skb stored
> in write queue, as TSO autosizing does the right thing anyway.
>
> Users with well behaving NICS and correct qdisc (like sch_fq),
> can then lower the default sysctl_tcp_limit_output_bytes value from
> 128KB to 8KB.
>
> This new usage of sysctl_tcp_limit_output_bytes permits each driver
> authors to check how their driver performs when/if the value is set
> to a minimum of 4KB.
>
> Normally, line rate for a single TCP flow should be possible,
> but some drivers rely on timers to perform TX completion and
> too long TX completion delays prevent reaching full throughput.
>
> Fixes: c9eeec26e32e ("tcp: TSQ can use a dynamic limit")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Sujith Manoharan <sujith@msujith.org>
> Reported-by: Arnaud Ebalard <arno@natisbad.org>
> Tested-by: Sujith Manoharan <sujith@msujith.org>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH net] bonding: fix two race conditions in bond_store_updelay/downdelay
From: David Miller @ 2013-11-14 21:29 UTC (permalink / raw)
To: nikolay; +Cc: netdev, fubar, andy, vfalico
In-Reply-To: <1384358866-15157-1-git-send-email-nikolay@redhat.com>
From: Nikolay Aleksandrov <nikolay@redhat.com>
Date: Wed, 13 Nov 2013 17:07:46 +0100
> This patch fixes two race conditions between bond_store_updelay/downdelay
> and bond_store_miimon which could lead to division by zero as miimon can
> be set to 0 while either updelay/downdelay are being set and thus miss the
> zero check in the beginning, the zero div happens because updelay/downdelay
> are stored as new_value / bond->params.miimon. Use rtnl to synchronize with
> miimon setting.
>
> CC: Jay Vosburgh <fubar@us.ibm.com>
> CC: Andy Gospodarek <andy@greyhouse.net>
> CC: Veaceslav Falico <vfalico@redhat.com>
> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] net: phylib: add adjust_state callback to phy device
From: David Miller @ 2013-11-14 21:32 UTC (permalink / raw)
To: zonque; +Cc: netdev, marek.belisko, ujhelyi.m
In-Reply-To: <1384376870-7810-1-git-send-email-zonque@gmail.com>
From: Daniel Mack <zonque@gmail.com>
Date: Wed, 13 Nov 2013 22:07:49 +0100
> Allow phy drivers to take action when the core does its link adjustment.
> No change for drivers that do not implement this callback.
>
> Signed-off-by: Daniel Mack <zonque@gmail.com>
So you're using this to reset the entire PHY via the reset bit in the
BMCR register when the link goes down.
But this is going to break things.
If the phy library previously programmed a non-autonegotiated static
link configuration into the BMCR register, your reset is going to
undo that.
Now the configuration phylib thinks the chip has and the one it
acutally does is out of sync.
I'm not applying these patches, sorry.
^ permalink raw reply
* Re: [PATCH] net-tcp: fix panic in tcp_fastopen_cache_set()
From: David Miller @ 2013-11-14 21:33 UTC (permalink / raw)
To: eric.dumazet; +Cc: davej, netdev, ycheng
In-Reply-To: <1384383646.28458.138.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 13 Nov 2013 15:00:46 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> We had some reports of crashes using TCP fastopen, and Dave Jones
> gave a nice stack trace pointing to the error.
>
> Issue is that tcp_get_metrics() should not be called with a NULL dst
>
> Fixes: 1fe4c481ba637 ("net-tcp: Fast Open client - cookie cache")
> 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] 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
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