* Re: [PATCH v2] geneve: Fix setting ttl value in collect metadata mode
From: Pravin Shelar @ 2017-09-12 23:43 UTC (permalink / raw)
To: Haishuang Yan
Cc: David S. Miller, Girish Moodalbail,
Linux Kernel Network Developers, linux-kernel
In-Reply-To: <1505199911-21153-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
On Tue, Sep 12, 2017 at 12:05 AM, Haishuang Yan
<yanhaishuang@cmss.chinamobile.com> wrote:
> Similar to vxlan/ipip tunnel, if key->tos is zero in collect metadata
> mode, tos should also fallback to ip{4,6}_dst_hoplimit.
>
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
>
> ---
> Changes since v2:
> * Make the commit message more clearer.
> ---
> drivers/net/geneve.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
> index f640407..d52a65f 100644
> --- a/drivers/net/geneve.c
> +++ b/drivers/net/geneve.c
> @@ -834,11 +834,10 @@ static int geneve_xmit_skb(struct sk_buff *skb, struct net_device *dev,
> sport = udp_flow_src_port(geneve->net, skb, 1, USHRT_MAX, true);
> if (geneve->collect_md) {
> tos = ip_tunnel_ecn_encap(key->tos, ip_hdr(skb), skb);
> - ttl = key->ttl;
> } else {
> tos = ip_tunnel_ecn_encap(fl4.flowi4_tos, ip_hdr(skb), skb);
> - ttl = key->ttl ? : ip4_dst_hoplimit(&rt->dst);
> }
> + ttl = key->ttl ? : ip4_dst_hoplimit(&rt->dst);
> df = key->tun_flags & TUNNEL_DONT_FRAGMENT ? htons(IP_DF) : 0;
>
This changes user API of Geneve collect-metadata mode. I do not see
good reason for this. Why user can not set right TTL for the flow?
^ permalink raw reply
* Re: [PATCH] datapath: Fix an error handling path in 'ovs_nla_init_match_and_action()'
From: Tonghao Zhang @ 2017-09-13 0:51 UTC (permalink / raw)
To: Christophe JAILLET
Cc: pravin shelar, David Miller, Linux Kernel Network Developers,
ovs dev, linux-kernel, kernel-janitors
In-Reply-To: <20170911192015.17553-1-christophe.jaillet@wanadoo.fr>
On Tue, Sep 12, 2017 at 3:20 AM, Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
> All other error handling paths in this function go through the 'error'
> label. This one should do the same.
>
> Fixes: 9cc9a5cb176c ("datapath: Avoid using stack larger than 1024.")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> I think that the comment above the function could be improved. It looks
> like the commit log which has introduced this function.
>
> I'm also not sure that commit 9cc9a5cb176c is of any help. It is
> supposed to remove a warning, and I guess it does. But 'ovs_nla_init_match_and_action()'
> is called unconditionnaly from 'ovs_flow_cmd_set()'. So even if the stack
> used by each function is reduced, the overall stack should be the same, if
> not larger.
>
> So this commit sounds like adding a bug where the code was fine and states
> to fix an issue but, at the best, only hides it.
>
> Instead of fixing the code with the proposed patch, reverting the initial
> commit could also be considered.
> ---
> net/openvswitch/datapath.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
> index 76cf273a56c7..c3aec6227c91 100644
> --- a/net/openvswitch/datapath.c
> +++ b/net/openvswitch/datapath.c
> @@ -1112,7 +1112,8 @@ static int ovs_nla_init_match_and_action(struct net *net,
> if (!a[OVS_FLOW_ATTR_KEY]) {
> OVS_NLERR(log,
> "Flow key attribute not present in set flow.");
> - return -EINVAL;
> + error = -EINVAL;
> + goto error;
Thank for your report. But I really don't understand.
In the 'ovs_nla_init_match_and_action', we only init 'match' when the
OVS_FLOW_ATTR_KEY is set.
If the 'OVS_FLOW_ATTR_ACTIONS' is set, but not 'OVS_FLOW_ATTR_KEY', we
can return directly because the match is not inited yet, and it is
unnecessary to set it's mask NULL. Then ovs_flow_cmd_set can run via
value returned.
> }
>
> *acts = get_flow_actions(net, a[OVS_FLOW_ATTR_ACTIONS], key,
> --
> 2.11.0
>
^ permalink raw reply
* Re: Regression in throughput between kvm guests over virtual bridge
From: Jason Wang @ 2017-09-13 1:16 UTC (permalink / raw)
To: Matthew Rosato, netdev; +Cc: davem, mst
In-Reply-To: <4c7e2924-b10f-0e97-c388-c8809ecfdeeb@linux.vnet.ibm.com>
On 2017年09月13日 01:56, Matthew Rosato wrote:
> We are seeing a regression for a subset of workloads across KVM guests
> over a virtual bridge between host kernel 4.12 and 4.13. Bisecting
> points to c67df11f "vhost_net: try batch dequing from skb array"
>
> In the regressed environment, we are running 4 kvm guests, 2 running as
> uperf servers and 2 running as uperf clients, all on a single host.
> They are connected via a virtual bridge. The uperf client profile looks
> like:
>
> <?xml version="1.0"?>
> <profile name="TCP_STREAM">
> <group nprocs="1">
> <transaction iterations="1">
> <flowop type="connect" options="remotehost=192.168.122.103
> protocol=tcp"/>
> </transaction>
> <transaction duration="300">
> <flowop type="write" options="count=16 size=30000"/>
> </transaction>
> <transaction iterations="1">
> <flowop type="disconnect"/>
> </transaction>
> </group>
> </profile>
>
> So, 1 tcp streaming instance per client. When upgrading the host kernel
> from 4.12->4.13, we see about a 30% drop in throughput for this
> scenario. After the bisect, I further verified that reverting c67df11f
> on 4.13 "fixes" the throughput for this scenario.
>
> On the other hand, if we increase the load by upping the number of
> streaming instances to 50 (nprocs="50") or even 10, we see instead a
> ~10% increase in throughput when upgrading host from 4.12->4.13.
>
> So it may be the issue is specific to "light load" scenarios. I would
> expect some overhead for the batching, but 30% seems significant... Any
> thoughts on what might be happening here?
>
Hi, thanks for the bisecting. Will try to see if I can reproduce.
Various factors could have impact on stream performance. If possible,
could you collect the #pkts and average packet size during the test? And
if you guest version is above 4.12, could you please retry with
napi_tx=true?
Thanks
^ permalink raw reply
* Re: [PATCH v2 net] smsc95xx: Configure pause time to 0xffff when tx flow control enabled
From: David Miller @ 2017-09-13 3:36 UTC (permalink / raw)
To: Nisar.Sayed; +Cc: UNGLinuxDriver, netdev, steve.glendinning
In-Reply-To: <CE371C1263339941885964188A0225FA335B8D@CHN-SV-EXMX03.mchp-main.com>
From: <Nisar.Sayed@microchip.com>
Date: Mon, 11 Sep 2017 17:43:11 +0000
> From: Nisar Sayed <Nisar.Sayed@microchip.com>
>
> Configure pause time to 0xffff when tx flow control enabled
>
> Set pause time to 0xffff in the pause frame to indicate the
> partner to stop sending the packets. When RX buffer frees up,
> the device sends pause frame with pause time zero for partner to
> resume transmission.
>
> Fixes: 2f7ca802bdae ("Add SMSC LAN9500 USB2.0 10/100 ethernet adapter driver")
> Signed-off-by: Nisar Sayed <Nisar.Sayed@microchip.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] openvswitch: Fix an error handling path in 'ovs_nla_init_match_and_action()'
From: David Miller @ 2017-09-13 3:38 UTC (permalink / raw)
To: christophe.jaillet-39ZsbGIQGT5GWvitb5QawA
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170911195620.17931-1-christophe.jaillet-39ZsbGIQGT5GWvitb5QawA@public.gmane.org>
From: Christophe JAILLET <christophe.jaillet-39ZsbGIQGT5GWvitb5QawA@public.gmane.org>
Date: Mon, 11 Sep 2017 21:56:20 +0200
> All other error handling paths in this function go through the 'error'
> label. This one should do the same.
>
> Fixes: 9cc9a5cb176c ("datapath: Avoid using stack larger than 1024.")
> Signed-off-by: Christophe JAILLET <christophe.jaillet-39ZsbGIQGT5GWvitb5QawA@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH net] tcp/dccp: remove reqsk_put() from inet_child_forget()
From: David Miller @ 2017-09-13 3:39 UTC (permalink / raw)
To: eric.dumazet; +Cc: sp3485, netdev, xiyou.wangcong, andrew.aday
In-Reply-To: <1505170718.15310.134.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 11 Sep 2017 15:58:38 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Back in linux-4.4, I inadvertently put a call to reqsk_put() in
> inet_child_forget(), forgetting it could be called from two different
> points.
>
> In the case it is called from inet_csk_reqsk_queue_add(), we want to
> keep the reference on the request socket, since it is released later by
> the caller (tcp_v{4|6}_rcv())
>
> This bug never showed up because atomic_dec_and_test() was not signaling
> the underflow, and SLAB_DESTROY_BY RCU semantic for request sockets
> prevented the request to be put in quarantine.
>
> Recent conversion of socket refcount from atomic_t to refcount_t finally
> exposed the bug.
>
> So move the reqsk_put() to inet_csk_listen_stop() to fix this.
>
> Thanks to Shankara Pailoor for using syzkaller and providing
> a nice set of .config and C repro.
...
> Fixes: ebb516af60e1 ("tcp/dccp: fix race at listener dismantle phase")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Shankara Pailoor <sp3485@columbia.edu>
> Tested-by: Shankara Pailoor <sp3485@columbia.edu>
Applied and queued up for -stable.
Thanks.
^ permalink raw reply
* Re: [Patch net v3 0/3] net_sched: fix filter chain reference counting
From: David Miller @ 2017-09-13 3:41 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, jiri, jakub.kicinski, jhs
In-Reply-To: <20170911233332.7594-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Mon, 11 Sep 2017 16:33:29 -0700
> This patchset fixes tc filter chain reference counting and nasty race
> conditions with RCU callbacks. Please see each patch for details.
Series applied, thanks Cong.
^ permalink raw reply
* Re: [patch net] mlxsw: spectrum: Prevent mirred-related crash on removal
From: David Miller @ 2017-09-13 3:43 UTC (permalink / raw)
To: jiri; +Cc: netdev, yuvalm, idosch, flokli, mlxsw
In-Reply-To: <20170912065053.1392-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 12 Sep 2017 08:50:53 +0200
> From: Yuval Mintz <yuvalm@mellanox.com>
>
> When removing the offloading of mirred actions under
> matchall classifiers, mlxsw would find the destination port
> associated with the offloaded action and utilize it for undoing
> the configuration.
>
> Depending on the order by which ports are removed, it's possible that
> the destination port would get removed before the source port.
> In such a scenario, when actions would be flushed for the source port
> mlxsw would perform an illegal dereference as the destination port is
> no longer listed.
>
> Since the only item necessary for undoing the configuration on the
> destination side is the port-id and that in turn is already maintained
> by mlxsw on the source-port, simply stop trying to access the
> destination port and use the port-id directly instead.
>
> Fixes: 763b4b70af ("mlxsw: spectrum: Add support in matchall mirror TC offloading")
> Signed-off-by: Yuval Mintz <yuvalm@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v4 1/2] ip_tunnel: fix ip tunnel lookup in collect_md mode
From: David Miller @ 2017-09-13 3:45 UTC (permalink / raw)
To: yanhaishuang; +Cc: kuznet, yoshfuji, netdev, linux-kernel, pshelar
In-Reply-To: <1505209677-12728-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Tue, 12 Sep 2017 17:47:56 +0800
> In collect_md mode, if the tun dev is down, it still can call
> ip_tunnel_rcv to receive on packets, and the rx statistics increase
> improperly.
>
> When the md tunnel is down, it's not neccessary to increase RX drops
> for the tunnel device, packets would be recieved on fallback tunnel,
> and the RX drops on fallback device will be increased as expected.
>
> Fixes: 2e15ea390e6f ("ip_gre: Add support to collect tunnel metadata.")
> Cc: Pravin B Shelar <pshelar@nicira.com>
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Applied.
^ permalink raw reply
* Re: [PATCH v4 2/2] ip6_tunnel: fix ip6 tunnel lookup in collect_md mode
From: David Miller @ 2017-09-13 3:45 UTC (permalink / raw)
To: yanhaishuang; +Cc: kuznet, yoshfuji, netdev, linux-kernel, ast
In-Reply-To: <1505209677-12728-2-git-send-email-yanhaishuang@cmss.chinamobile.com>
From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Tue, 12 Sep 2017 17:47:57 +0800
> In collect_md mode, if the tun dev is down, it still can call
> __ip6_tnl_rcv to receive on packets, and the rx statistics increase
> improperly.
>
> When the md tunnel is down, it's not neccessary to increase RX drops
> for the tunnel device, packets would be recieved on fallback tunnel,
> and the RX drops on fallback device will be increased as expected.
>
> Fixes: 8d79266bc48c ("ip6_tunnel: add collect_md mode to IPv6 tunnels")
> Cc: Alexei Starovoitov <ast@fb.com>
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Applied.
^ permalink raw reply
* RE: [PATCH v3] iproute2: add support for GRE ignore-df knob
From: Michele Lucini @ 2017-09-13 3:56 UTC (permalink / raw)
To: Philip Prindeville, Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <C28C1CD8-95FD-43C6-86DA-0C89D3776668@redfish-solutions.com>
Guys, thanks heaps for this, much appreciated!
Cheers.
Mike
-----Original Message-----
From: Philip Prindeville [mailto:philipp@redfish-solutions.com]
Sent: Friday, 21 July 2017 10:35 AM
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: netdev@vger.kernel.org; Michele Lucini <mlucini@safearea.com.au>
Subject: Re: [PATCH v3] iproute2: add support for GRE ignore-df knob
> On Jul 20, 2017, at 6:26 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
>
> On Thu, 20 Jul 2017 13:06:10 -0600
> "Philip Prindeville" <philipp@redfish-solutions.com> wrote:
>
>> From: Philip Prindeville <philipp@redfish-solutions.com>
>>
>> In the presence of firewalls which improperly block ICMP Unreachable
>> (including Fragmentation Required) messages, Path MTU Discovery is
>> prevented from working.
>>
>> The workaround is to handle IPv4 payloads opaquely, ignoring the DF
>> bit.
>>
>> Kernel commit 22a59be8b7693eb2d0897a9638f5991f2f8e4ddd ("net: ipv4:
>> Add ability to have GRE ignore DF bit in IPv4 payloads") is
>> complemented by this user-space changeset which exposes control of
>> this setting.
>>
>> Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
>> Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
>
> Applied, thanks Philip
Thanks! Sorry I didn’t realize that the first submission a year ago hadn’t been applied and it took me this long to redux and resubmit it.
Michele: hopefully this comes out in your distro-of-choice fairly soon. Like I said, I thought this had already been rolled in.
-Philip
^ permalink raw reply
* Re: [PATCH] ipv4: Namespaceify tcp_fastopen knob
From: David Miller @ 2017-09-13 3:57 UTC (permalink / raw)
To: yanhaishuang; +Cc: kuznet, edumazet, netdev, linux-kernel
In-Reply-To: <1505212257-13386-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Tue, 12 Sep 2017 18:30:57 +0800
> Different namespace application might require enable TCP Fast Open
> feature independently of the host.
>
> Reported-by: Luca BRUNO <lucab@debian.org>
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
...
> diff --git a/samples/bpf/test_ipip.sh b/samples/bpf/test_ipip.sh
> index 1969254..7bbc521 100755
> --- a/samples/bpf/test_ipip.sh
> +++ b/samples/bpf/test_ipip.sh
> @@ -173,6 +173,8 @@ function cleanup {
> cleanup
> echo "Testing IP tunnels..."
> test_ipip
> +sleep 1
> test_ipip6
> +sleep 1
> test_ip6ip6
> echo "*** PASS ***"
This seems like a completely unrelated change.
^ permalink raw reply
* Re: [PATCH net] net: bonding: fix tlb_dynamic_lb default value
From: David Miller @ 2017-09-13 3:59 UTC (permalink / raw)
To: nikolay; +Cc: netdev, j.vosburgh, vfalico, andy, maheshb
In-Reply-To: <1505218205-2637-1-git-send-email-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Tue, 12 Sep 2017 15:10:05 +0300
> Commit 8b426dc54cf4 ("bonding: remove hardcoded value") changed the
> default value for tlb_dynamic_lb which lead to either broken ALB mode
> (since tlb_dynamic_lb can be changed only in TLB) or setting TLB mode
> with tlb_dynamic_lb equal to 0.
> The first issue was recently fixed by setting tlb_dynamic_lb to 1 always
> when switching to ALB mode, but the default value is still wrong and
> we'll enter TLB mode with tlb_dynamic_lb equal to 0 if the mode is
> changed via netlink or sysfs. In order to restore the previous behaviour
> and default value simply remove the mode check around the default param
> initialization for tlb_dynamic_lb which will always set it to 1 as
> before.
>
> Fixes: 8b426dc54cf4 ("bonding: remove hardcoded value")
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] w90p910_ether: include linux/interrupt.h
From: David Miller @ 2017-09-13 3:59 UTC (permalink / raw)
To: arnd; +Cc: mcuos.com, linux-arm-kernel, netdev, linux-kernel
In-Reply-To: <20170912123227.3418786-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 12 Sep 2017 14:31:48 +0200
> A randconfig build caused a compile failure:
>
> drivers/net/ethernet/nuvoton/w90p910_ether.c: In function 'w90p910_ether_close':
> drivers/net/ethernet/nuvoton/w90p910_ether.c:580:2: error: implicit declaration of function 'free_irq'; did you mean 'free_uid'? [-Werror=implicit-function-declaration]
>
> Adding the correct include fixes the problem.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
^ permalink raw reply
* Dear Talented
From: Kim Sharma @ 2017-09-13 2:33 UTC (permalink / raw)
To: Recipients
Dear Talented,
I am Talent Scout For BLUE SKY FILM STUDIO, Present Blue sky Studio a
Film Corporation Located in the United State, is Soliciting for the
Right to use Your Photo/Face and Personality as One of the Semi -Major
Role/ Character in our Upcoming ANIMATED Stereoscope 3D Movie-The Story
of Anubis (Anubis 2018) The Movie is Currently Filming (In
Production) Please Note That There Will Be No Auditions, Traveling or
Any Special / Professional Acting Skills, Since the Production of This
Movie Will Be Done with our State of Art Computer -Generating Imagery
Equipment. We Are Prepared to Pay the Total Sum of $620,000.00 USD. For
More Information/Understanding, Please Write us on the E-Mail Below.
CONTACT EMAIL: Blueskyanimatedstudio@usa.com
All Reply to: Blueskyanimatedstudio@usa.com
Note: Only the Response send to this mail will be Given a Prior
Consideration.
Talent Scout
Kim Sharma
^ permalink raw reply
* Re: [Patch net v3 1/3] net_sched: get rid of tcfa_rcu
From: Jiri Pirko @ 2017-09-13 6:13 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, Jiri Pirko, Jakub Kicinski,
Jamal Hadi Salim, Eric Dumazet
In-Reply-To: <CAM_iQpUwC6cMBOVuwgCsE+wL88OeL04qw2vSN7_Ng6_GCA5A=g@mail.gmail.com>
Tue, Sep 12, 2017 at 11:53:09PM CEST, xiyou.wangcong@gmail.com wrote:
>On Tue, Sep 12, 2017 at 2:36 PM, Jiri Pirko <jiri@resnulli.us> wrote:
>> Tue, Sep 12, 2017 at 11:10:22PM CEST, xiyou.wangcong@gmail.com wrote:
>>>On Tue, Sep 12, 2017 at 3:40 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>>> This patch helps:
>>>
>>>Looks good to me. Please feel free to submit a formal patch.
>>
>> Okay, I will send the patch to you formally so you can add it as a first
>> patch of your patchset.
>
>I can carry it by myself if it fits to this patchset. However, I believe it
>should be independent since it has to be backported much further
>than this patchset. I don't know why no one triggered the crash
>before call_rcu() was introduced there.
>
>Anyway, I believe you should submit your patch alone, either before
>or after this patchset, there should be no conflict.
Okay. Will to it before the patchset. Thanks!
^ permalink raw reply
* Re: [Patch net v3 0/3] net_sched: fix filter chain reference counting
From: Jiri Pirko @ 2017-09-13 6:13 UTC (permalink / raw)
To: David Miller; +Cc: xiyou.wangcong, netdev, jiri, jakub.kicinski, jhs
In-Reply-To: <20170912.204118.1990439437521288402.davem@davemloft.net>
Wed, Sep 13, 2017 at 05:41:18AM CEST, davem@davemloft.net wrote:
>From: Cong Wang <xiyou.wangcong@gmail.com>
>Date: Mon, 11 Sep 2017 16:33:29 -0700
>
>> This patchset fixes tc filter chain reference counting and nasty race
>> conditions with RCU callbacks. Please see each patch for details.
>
>Series applied, thanks Cong.
Ha, so after :)
^ permalink raw reply
* Re: [PATCH] tcp: TCP_USER_TIMEOUT can not work in tcp_probe_timer()
From: liujian @ 2017-09-13 6:56 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuznet, yoshfuji, edumazet, ycheng, hkchu, netdev,
weiyongjun1, wangkefeng 00227729
In-Reply-To: <1505230686.15310.141.camel@edumazet-glaptop3.roam.corp.google.com>
在 2017/9/12 23:38, Eric Dumazet 写道:
> On Tue, 2017-09-12 at 08:05 -0700, Eric Dumazet wrote:
>> On Tue, 2017-09-12 at 14:08 +0800, liujian wrote:
>>> Hi,
>>>
>>> In the scenario, tcp server side IP changed, and at that memont,
>>> userspace application still send data continuously;
>>> tcp_send_head(sk)'s timestamp always be refreshed.
>>>
>>> Here is the packetdrill script:
>>>
>>> 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
>>> +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
>>> +0 bind(3, ..., ...) = 0
>>> +0 listen(3, 1) = 0
>>>
>>> +0 < S 0:0(0) win 0 <mss 1460,sackOK,nop,nop,nop,wscale 7>
>>> +0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 7>
>>>
>>> +.1 < . 1:1(0) ack 1 win 65530
>>> +0 accept(3, ..., ...) = 4
>>>
>>> +0 setsockopt(4, SOL_TCP, TCP_USER_TIMEOUT, [3000], 4) = 0
>>> +0 write(4, ..., 24) = 24
>>> +0 > P. 1:25(24) ack 1 win 229
>>> +.1 < . 1:1(0) ack 25 win 65530
>>>
>>> //change the ipaddress
>>> +1 `ifconfig tun0 192.168.0.10/16`
>>>
>>> +1 write(4, ..., 24) = 24
>>> +1 write(4, ..., 24) = 24
>>> +1 write(4, ..., 24) = 24
>>> +1 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>> +3 write(4, ..., 24) = 24
>>>
>>> +0 `ifconfig tun0 192.168.0.1/16`
>>> +0 < . 1:1(0) ack 1 win 1000
>>> +0 write(4, ..., 24) = -1
>>>
>>>
>>
>> This has nothing to do with the code patch you have changed.
>>
>> How have you tested your patch exactly ?
>>
I tested the patch, it can work.
[root@localhost ~]# time ./gtests/net/packetdrill/packetdrill test.pkt
test.pkt:24: runtime error in write call: Expected result 24 but got -1 with errno 110 (Connection timed out)
real 0m5.356s
user 0m0.026s
sys 0m0.104s
[root@localhost ~]# ss -toenmi src :8080
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 48 192.168.0.1:8080 192.0.2.1:39559 timer:(persist,186ms,2) ino:37178 sk:6 <->
skmem:(r0,rb369280,t0,tb87040,f1792,w2304,o0,bl0) sack cubic wscale:7,7 rto:301 backoff:2 rtt:100.253/37.643 mss:1460 cwnd:10 bytes_acked:24 segs_out:5 segs_in:3 send 1.2Mbps lastsnd:976 lastrcv:4082 lastack:3982 pacing_rate 2.3Mbps rcv_space:29200
if change the TCP_USER_TIMEOUT to 30s, test result as below:
[root@localhost ~]# time ./gtests/net/packetdrill/packetdrill test.pkt
test.pkt:37: runtime error in write call: Expected result 24 but got -1 with errno 110 (Connection timed out)
real 0m44.362s
user 0m0.018s
sys 0m0.110s
ESTAB 0 360 192.168.0.1:8080 192.0.2.1:47577 timer:(persist,516ms,6) ino:18806 sk:5 <->
skmem:(r0,rb369280,t0,tb87040,f1792,w2304,o0,bl0) sack cubic wscale:7,7 rto:301 backoff:6 rtt:100.228/37.623 mss:10 bytes_acked:24 segs_out:22 segs_in:3 send 1.2Mbps lastsnd:2343 lastrcv:40450 lastack:40350 pacing_rate 2.3Mbps rcv_sp
>
> lpaa23:~# ss -toenmi src :8080
> State Recv-Q Send-Q Local Address:Port Peer
> Address:Port
> ESTAB 0 144 192.168.134.161:8080
> 192.0.2.1:51165 timer:(persist,8.262ms,5) ino:1
> 82083 sk:3 <->
> skmem:(r0,rb359040,t0,tb46080,f1792,w2304,o0,bl0,d0) sack cubic
> wscale:7,8 rto:301 backoff:5 rtt:100.127/37.576
> mss:1460 rcvmss:536 advmss:1460 cwnd:10 bytes_acked:24 segs_out:12
> segs_in:3 data_segs_out:12 send 1.2Mbps lastsnd:1370 l
> astrcv:13348 lastack:13248 pacing_rate 2.3Mbps delivery_rate 116.7Kbps
> app_limited busy:11346ms rcv_space:29200 notsent:1
> 44 minrtt:100.043userspace application still send data continuously
>
> This is the typical RTO timer, not zero window probe.
>
with the script, it is not zero window; but the code enter tcp_probe_timer.
->tcp_sendmsg
-->tcp_push
---->__tcp_push_pending_frames
------>tcp_write_xmit
-------->tcp_transmit_skb (at this function, tcp_send_head(sk)'s timestamp was be refreshed)
---------->ip_queue_xmit (can not find route, return -EHOSTUNREACH)
-------->tcp_transmit_skb (send fail, do not advance send head)
------->tcp_check_probe_timer (reset ICSK_TIME_PROBE0 timer)
Here userspace application still send data continuously,
it triggered ICSK_TIME_PROBE0 timer and tcp_send_head(sk)'s timestamp refresh.
^ permalink raw reply
* Re: [PATCH] tcp: TCP_USER_TIMEOUT can not work in tcp_probe_timer()
From: liujian @ 2017-09-13 7:15 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuznet, yoshfuji, edumazet, ycheng, hkchu, netdev,
weiyongjun1, wangkefeng 00227729
In-Reply-To: <b72fefba-e701-2ec8-0e7b-3bba6ed25205@huawei.com>
在 2017/9/13 14:56, liujian 写道:
>
>
> 在 2017/9/12 23:38, Eric Dumazet 写道:
>> On Tue, 2017-09-12 at 08:05 -0700, Eric Dumazet wrote:
>>> On Tue, 2017-09-12 at 14:08 +0800, liujian wrote:
>>>> Hi,
>>>>
>>>> In the scenario, tcp server side IP changed, and at that memont,
>>>> userspace application still send data continuously;
>>>> tcp_send_head(sk)'s timestamp always be refreshed.
>>>>
>>>> Here is the packetdrill script:
>>>>
>>>> 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
>>>> +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
>>>> +0 bind(3, ..., ...) = 0
>>>> +0 listen(3, 1) = 0
>>>>
>>>> +0 < S 0:0(0) win 0 <mss 1460,sackOK,nop,nop,nop,wscale 7>
>>>> +0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 7>
>>>>
>>>> +.1 < . 1:1(0) ack 1 win 65530
>>>> +0 accept(3, ..., ...) = 4
>>>>
>>>> +0 setsockopt(4, SOL_TCP, TCP_USER_TIMEOUT, [3000], 4) = 0
>>>> +0 write(4, ..., 24) = 24
>>>> +0 > P. 1:25(24) ack 1 win 229
>>>> +.1 < . 1:1(0) ack 25 win 65530
>>>>
>>>> //change the ipaddress
>>>> +1 `ifconfig tun0 192.168.0.10/16`
>>>>
>>>> +1 write(4, ..., 24) = 24
>>>> +1 write(4, ..., 24) = 24
>>>> +1 write(4, ..., 24) = 24
>>>> +1 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>> +3 write(4, ..., 24) = 24
>>>>
>>>> +0 `ifconfig tun0 192.168.0.1/16`
>>>> +0 < . 1:1(0) ack 1 win 1000
>>>> +0 write(4, ..., 24) = -1
>>>>
>>>>
>>>
>>> This has nothing to do with the code patch you have changed.
>>>
>>> How have you tested your patch exactly ?
>>>
> I tested the patch, it can work.
>
> [root@localhost ~]# time ./gtests/net/packetdrill/packetdrill test.pkt
> test.pkt:24: runtime error in write call: Expected result 24 but got -1 with errno 110 (Connection timed out)
>
> real 0m5.356s
> user 0m0.026s
> sys 0m0.104s
>
> [root@localhost ~]# ss -toenmi src :8080
> State Recv-Q Send-Q Local Address:Port Peer Address:Port
> ESTAB 0 48 192.168.0.1:8080 192.0.2.1:39559 timer:(persist,186ms,2) ino:37178 sk:6 <->
> skmem:(r0,rb369280,t0,tb87040,f1792,w2304,o0,bl0) sack cubic wscale:7,7 rto:301 backoff:2 rtt:100.253/37.643 mss:1460 cwnd:10 bytes_acked:24 segs_out:5 segs_in:3 send 1.2Mbps lastsnd:976 lastrcv:4082 lastack:3982 pacing_rate 2.3Mbps rcv_space:29200
>
>
> if change the TCP_USER_TIMEOUT to 30s, test result as below:
>
> [root@localhost ~]# time ./gtests/net/packetdrill/packetdrill test.pkt
> test.pkt:37: runtime error in write call: Expected result 24 but got -1 with errno 110 (Connection timed out)
>
> real 0m44.362s
> user 0m0.018s
> sys 0m0.110s
>
> ESTAB 0 360 192.168.0.1:8080 192.0.2.1:47577 timer:(persist,516ms,6) ino:18806 sk:5 <->
> skmem:(r0,rb369280,t0,tb87040,f1792,w2304,o0,bl0) sack cubic wscale:7,7 rto:301 backoff:6 rtt:100.228/37.623 mss:10 bytes_acked:24 segs_out:22 segs_in:3 send 1.2Mbps lastsnd:2343 lastrcv:40450 lastack:40350 pacing_rate 2.3Mbps rcv_sp
>
>>
>> lpaa23:~# ss -toenmi src :8080
>> State Recv-Q Send-Q Local Address:Port Peer
>> Address:Port
>> ESTAB 0 144 192.168.134.161:8080
>> 192.0.2.1:51165 timer:(persist,8.262ms,5) ino:1
>> 82083 sk:3 <->
>> skmem:(r0,rb359040,t0,tb46080,f1792,w2304,o0,bl0,d0) sack cubic
>> wscale:7,8 rto:301 backoff:5 rtt:100.127/37.576
>> mss:1460 rcvmss:536 advmss:1460 cwnd:10 bytes_acked:24 segs_out:12
>> segs_in:3 data_segs_out:12 send 1.2Mbps lastsnd:1370 l
>> astrcv:13348 lastack:13248 pacing_rate 2.3Mbps delivery_rate 116.7Kbps
>> app_limited busy:11346ms rcv_space:29200 notsent:1
>> 44 minrtt:100.043userspace application still send data continuously
>>
>> This is the typical RTO timer, not zero window probe.
>>
> with the script, it is not zero window; but the code enter tcp_probe_timer.
> ->tcp_sendmsg
> -->tcp_push
> ---->__tcp_push_pending_frames
> ------>tcp_write_xmit
> -------->tcp_transmit_skb (at this function, tcp_send_head(sk)'s timestamp was be refreshed)
> ---------->ip_queue_xmit (can not find route, return -EHOSTUNREACH)
> -------->tcp_transmit_skb (send fail, do not advance send head)
> ------->tcp_check_probe_timer (reset ICSK_TIME_PROBE0 timer)
sorry, change to
->tcp_sendmsg
-->tcp_push
---->__tcp_push_pending_frames
------>tcp_write_xmit
-------->tcp_transmit_skb (at this function, tcp_send_head(sk)'s timestamp was be refreshed)
---------->ip_queue_xmit (can not find route, return -EHOSTUNREACH)
------>tcp_write_xmit (send fail, do not advance send head)
------>tcp_check_probe_timer (reset ICSK_TIME_PROBE0 timer)
> Here userspace application still send data continuously,
> it triggered ICSK_TIME_PROBE0 timer and tcp_send_head(sk)'s timestamp refresh.
>
>
^ permalink raw reply
* [PATCH 01/10] arch:powerpc: return -ENOMEM on failed allocation
From: Allen Pais @ 2017-09-13 7:32 UTC (permalink / raw)
To: linux-kernel
Cc: nouveau, linux-crypto, dri-devel, MPT-FusionLinux.pdl, linux-scsi,
netdev, megaraidlinux.pdl, target-devel, linux-fbdev, linux-btrfs,
Allen Pais
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
---
arch/powerpc/platforms/cell/spider-pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/cell/spider-pci.c b/arch/powerpc/platforms/cell/spider-pci.c
index d1e61e2..82aa3f7 100644
--- a/arch/powerpc/platforms/cell/spider-pci.c
+++ b/arch/powerpc/platforms/cell/spider-pci.c
@@ -106,7 +106,7 @@ static int __init spiderpci_pci_setup_chip(struct pci_controller *phb,
dummy_page_va = kmalloc(PAGE_SIZE, GFP_KERNEL);
if (!dummy_page_va) {
pr_err("SPIDERPCI-IOWA:Alloc dummy_page_va failed.\n");
- return -1;
+ return -ENOMEM;
}
dummy_page_da = dma_map_single(phb->parent, dummy_page_va,
@@ -137,7 +137,7 @@ int __init spiderpci_iowa_init(struct iowa_bus *bus, void *data)
if (!priv) {
pr_err("SPIDERPCI-IOWA:"
"Can't allocate struct spiderpci_iowa_private");
- return -1;
+ return -ENOMEM;
}
if (of_address_to_resource(np, 0, &r)) {
--
2.7.4
^ permalink raw reply related
* [PATCH 02/10] drivers:crypto: return -ENOMEM on allocation failure.
From: Allen Pais @ 2017-09-13 7:32 UTC (permalink / raw)
To: linux-kernel
Cc: nouveau, linux-crypto, dri-devel, MPT-FusionLinux.pdl, linux-scsi,
netdev, megaraidlinux.pdl, target-devel, linux-fbdev, linux-btrfs,
Allen Pais
In-Reply-To: <1505287939-14106-1-git-send-email-allen.lkml@gmail.com>
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
---
drivers/crypto/omap-aes-gcm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-aes-gcm.c b/drivers/crypto/omap-aes-gcm.c
index 7d4f8a4..2542224 100644
--- a/drivers/crypto/omap-aes-gcm.c
+++ b/drivers/crypto/omap-aes-gcm.c
@@ -186,7 +186,7 @@ static int do_encrypt_iv(struct aead_request *req, u32 *tag, u32 *iv)
sk_req = skcipher_request_alloc(ctx->ctr, GFP_KERNEL);
if (!sk_req) {
pr_err("skcipher: Failed to allocate request\n");
- return -1;
+ return -ENOMEM;
}
init_completion(&result.completion);
--
2.7.4
^ permalink raw reply related
* [PATCH 03/10] driver:gpu: return -ENOMEM on allocation failure.
From: Allen Pais @ 2017-09-13 7:32 UTC (permalink / raw)
To: linux-kernel
Cc: nouveau, linux-crypto, dri-devel, MPT-FusionLinux.pdl, linux-scsi,
netdev, megaraidlinux.pdl, target-devel, linux-fbdev, linux-btrfs,
Allen Pais
In-Reply-To: <1505287939-14106-1-git-send-email-allen.lkml@gmail.com>
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
---
drivers/gpu/drm/gma500/mid_bios.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/gma500/mid_bios.c b/drivers/gpu/drm/gma500/mid_bios.c
index d75ecb3..1fa1633 100644
--- a/drivers/gpu/drm/gma500/mid_bios.c
+++ b/drivers/gpu/drm/gma500/mid_bios.c
@@ -237,7 +237,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private *dev_priv, u32 addr)
gct = kmalloc(sizeof(*gct) * vbt.panel_count, GFP_KERNEL);
if (!gct)
- return -1;
+ return -ENOMEM;
gct_virtual = ioremap(addr + sizeof(vbt),
sizeof(*gct) * vbt.panel_count);
--
2.7.4
^ permalink raw reply related
* [PATCH 04/10] drivers:mpt: return -ENOMEM on allocation failure.
From: Allen Pais @ 2017-09-13 7:32 UTC (permalink / raw)
To: linux-kernel
Cc: nouveau, linux-crypto, dri-devel, MPT-FusionLinux.pdl, linux-scsi,
netdev, megaraidlinux.pdl, target-devel, linux-fbdev, linux-btrfs,
Allen Pais
In-Reply-To: <1505287939-14106-1-git-send-email-allen.lkml@gmail.com>
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
---
drivers/message/fusion/mptbase.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 84eab28..7920b2b 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -4328,15 +4328,15 @@ initChainBuffers(MPT_ADAPTER *ioc)
if (ioc->ReqToChain == NULL) {
sz = ioc->req_depth * sizeof(int);
mem = kmalloc(sz, GFP_ATOMIC);
- if (mem == NULL)
- return -1;
+ if (!mem)
+ return -ENOMEM;
ioc->ReqToChain = (int *) mem;
dinitprintk(ioc, printk(MYIOC_s_DEBUG_FMT "ReqToChain alloc @ %p, sz=%d bytes\n",
ioc->name, mem, sz));
mem = kmalloc(sz, GFP_ATOMIC);
- if (mem == NULL)
- return -1;
+ if (!mem)
+ return -ENOMEM;
ioc->RequestNB = (int *) mem;
dinitprintk(ioc, printk(MYIOC_s_DEBUG_FMT "RequestNB alloc @ %p, sz=%d bytes\n",
@@ -4402,8 +4402,8 @@ initChainBuffers(MPT_ADAPTER *ioc)
sz = num_chain * sizeof(int);
if (ioc->ChainToChain == NULL) {
mem = kmalloc(sz, GFP_ATOMIC);
- if (mem == NULL)
- return -1;
+ if (!mem)
+ return -ENOMEM;
ioc->ChainToChain = (int *) mem;
dinitprintk(ioc, printk(MYIOC_s_DEBUG_FMT "ChainToChain alloc @ %p, sz=%d bytes\n",
--
2.7.4
^ permalink raw reply related
* [PATCH 05/10] drivers:net: return -ENOMEM on allocation failure.
From: Allen Pais @ 2017-09-13 7:32 UTC (permalink / raw)
To: linux-kernel
Cc: nouveau, linux-crypto, dri-devel, MPT-FusionLinux.pdl, linux-scsi,
netdev, megaraidlinux.pdl, target-devel, linux-fbdev, linux-btrfs,
Allen Pais
In-Reply-To: <1505287939-14106-1-git-send-email-allen.lkml@gmail.com>
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
---
drivers/net/bonding/bond_alb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
index c02cc81..89df377 100644
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/net/bonding/bond_alb.c
@@ -864,7 +864,7 @@ static int rlb_initialize(struct bonding *bond)
new_hashtbl = kmalloc(size, GFP_KERNEL);
if (!new_hashtbl)
- return -1;
+ return -ENOMEM;
spin_lock_bh(&bond->mode_lock);
--
2.7.4
^ permalink raw reply related
* [PATCH 06/10] drivers:ethernet: return -ENOMEM on allocation failure.
From: Allen Pais @ 2017-09-13 7:32 UTC (permalink / raw)
To: linux-kernel
Cc: nouveau, linux-crypto, dri-devel, MPT-FusionLinux.pdl, linux-scsi,
netdev, megaraidlinux.pdl, target-devel, linux-fbdev, linux-btrfs,
Allen Pais
In-Reply-To: <1505287939-14106-1-git-send-email-allen.lkml@gmail.com>
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
---
drivers/net/ethernet/sun/cassini.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sun/cassini.c b/drivers/net/ethernet/sun/cassini.c
index 382993c..fc0ea3a 100644
--- a/drivers/net/ethernet/sun/cassini.c
+++ b/drivers/net/ethernet/sun/cassini.c
@@ -3984,7 +3984,7 @@ static inline int cas_alloc_rx_desc(struct cas *cp, int ring)
size = RX_DESC_RINGN_SIZE(ring);
for (i = 0; i < size; i++) {
if ((page[i] = cas_page_alloc(cp, GFP_KERNEL)) == NULL)
- return -1;
+ return -ENOMEM;
}
return 0;
}
--
2.7.4
^ 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