* [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
* 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
* 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 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 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
* 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] 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
* 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] 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 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 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 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 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 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] 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 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 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: 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] 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: [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 v4 1/2] ip_tunnel: fix ip tunnel lookup in collect_md mode
From: Pravin Shelar @ 2017-09-12 23:41 UTC (permalink / raw)
To: Haishuang Yan
Cc: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Linux Kernel Network Developers, linux-kernel, Pravin B Shelar
In-Reply-To: <1505209677-12728-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
On Tue, Sep 12, 2017 at 2:47 AM, Haishuang Yan
<yanhaishuang@cmss.chinamobile.com> wrote:
> 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>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
^ permalink raw reply
* Memory leaks in conntrack
From: Cong Wang @ 2017-09-12 23:20 UTC (permalink / raw)
To: netfilter-devel; +Cc: Linux Kernel Network Developers
Hello,
While testing my TC filter patches (so not related to conntrack), the
following memory leaks are shown up:
unreferenced object 0xffff9b19ba551228 (size 128):
comm "chronyd", pid 338, jiffies 4294910829 (age 53.188s)
hex dump (first 32 bytes):
6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
00 00 00 00 18 00 00 30 00 00 00 00 00 00 00 00 .......0........
backtrace:
[<ffffffff9f1e1175>] create_object+0x169/0x2aa
[<ffffffff9fb77fb2>] kmemleak_alloc+0x25/0x41
[<ffffffff9f1c47ed>] slab_post_alloc_hook+0x44/0x65
[<ffffffff9f1ca2db>] __kmalloc_track_caller+0x113/0x146
[<ffffffff9f193c3b>] __krealloc+0x4a/0x69
[<ffffffff9f948dbd>] nf_ct_ext_add+0xe1/0x145
[<ffffffff9f942395>] init_conntrack+0x1f7/0x36e
[<ffffffff9f942762>] nf_conntrack_in+0x1d3/0x326
[<ffffffff9fa1ea69>] ipv4_conntrack_local+0x4d/0x50
[<ffffffff9f93ad70>] nf_hook_slow+0x3c/0x9b
[<ffffffff9f9c7999>] nf_hook.constprop.40+0xbe/0xd8
[<ffffffff9f9c7ba2>] __ip_local_out+0xb3/0xbf
[<ffffffff9f9c7bca>] ip_local_out+0x1c/0x36
[<ffffffff9f9c9216>] ip_send_skb+0x19/0x3d
[<ffffffff9f9ee3de>] udp_send_skb+0x17e/0x1df
[<ffffffff9f9eea37>] udp_sendmsg+0x5a2/0x77c
unreferenced object 0xffff9b19a69b3340 (size 336):
comm "chronyd", pid 338, jiffies 4294910868 (age 53.032s)
hex dump (first 32 bytes):
01 00 00 00 5a 5a 5a 5a 00 00 00 00 ad 4e ad de ....ZZZZ.....N..
ff ff ff ff 5a 5a 5a 5a ff ff ff ff ff ff ff ff ....ZZZZ........
backtrace:
[<ffffffff9f1e1175>] create_object+0x169/0x2aa
[<ffffffff9fb77fb2>] kmemleak_alloc+0x25/0x41
[<ffffffff9f1c47ed>] slab_post_alloc_hook+0x44/0x65
[<ffffffff9f1c7a7d>] kmem_cache_alloc+0xd7/0x1f1
[<ffffffff9f941b78>] __nf_conntrack_alloc+0xa2/0x146
[<ffffffff9f942250>] init_conntrack+0xb2/0x36e
[<ffffffff9f942762>] nf_conntrack_in+0x1d3/0x326
[<ffffffff9fa1ea69>] ipv4_conntrack_local+0x4d/0x50
[<ffffffff9f93ad70>] nf_hook_slow+0x3c/0x9b
[<ffffffff9f9c7999>] nf_hook.constprop.40+0xbe/0xd8
[<ffffffff9f9c7ba2>] __ip_local_out+0xb3/0xbf
[<ffffffff9f9c7bca>] ip_local_out+0x1c/0x36
[<ffffffff9f9c9216>] ip_send_skb+0x19/0x3d
[<ffffffff9f9ee3de>] udp_send_skb+0x17e/0x1df
[<ffffffff9f9eea37>] udp_sendmsg+0x5a2/0x77c
[<ffffffff9f9f8cb8>] inet_sendmsg+0x37/0x5e
This seems new because I never see this before.
I don't touch chronyd in my VM, so I have no idea why it sends out UDP
packets, my guess is it is some periodical packet.
I don't think I use conntrack either, since /proc/net/ip_conntrack
does not exist.
Here are some related config of my kernel:
$ grep CONNTRACK .config
CONFIG_NF_CONNTRACK=y
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_ZONES=y
CONFIG_NF_CONNTRACK_PROCFS=y
CONFIG_NF_CONNTRACK_EVENTS=y
# CONFIG_NF_CONNTRACK_TIMEOUT is not set
CONFIG_NF_CONNTRACK_TIMESTAMP=y
CONFIG_NF_CONNTRACK_AMANDA=y
CONFIG_NF_CONNTRACK_FTP=y
CONFIG_NF_CONNTRACK_H323=y
CONFIG_NF_CONNTRACK_IRC=y
CONFIG_NF_CONNTRACK_BROADCAST=y
CONFIG_NF_CONNTRACK_NETBIOS_NS=y
CONFIG_NF_CONNTRACK_SNMP=y
CONFIG_NF_CONNTRACK_PPTP=y
CONFIG_NF_CONNTRACK_SANE=y
CONFIG_NF_CONNTRACK_SIP=y
CONFIG_NF_CONNTRACK_TFTP=y
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
CONFIG_NF_CONNTRACK_IPV4=y
CONFIG_NF_CONNTRACK_IPV6=y
Please let me know if you need any other information.
Thanks.
^ permalink raw reply
* Re: 319554f284dd ("inet: don't use sk_v6_rcv_saddr directly") causes bind port regression
From: Josef Bacik @ 2017-09-12 23:12 UTC (permalink / raw)
To: Laura Abbott, David S. Miller, Alexey Kuznetsov,
Hideaki YOSHIFUJI
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Cole Robinson
In-Reply-To: <1a8ef376-387e-e0fc-7362-e1fd2c2c45d3@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1611 bytes --]
First I’m super sorry for the top post, I’m at plumbers and I forgot to upload my muttrc to my new cloud instance, so I’m screwed using outlook.
I have a completely untested, uncompiled patch that I think will fix the problem, would you mind giving it a go? Thanks,
Josef
On 9/12/17, 3:36 PM, "Laura Abbott" <labbott@redhat.com> wrote:
Hi,
Fedora got a bug report
https://bugzilla.redhat.com/show_bug.cgi?id=1432684 of a regression with
automatic spice port
assignment. The libvirt team reduced this to the attached test
case run as follows:
In a separate terminal, qemu-kvm -vnc 127.0.0.1:0 to grab port 5900.
Then do this:
$ gcc bind-collision.c && ./a.out
bind: Address already in use
AF_INET check failed.
$ gcc -D CHECK_IPV6 bind-collision.c && ./a.out
AF_INET6 success
AF_INET success
$ gcc bind-collision.c && ./a.out
AF_INET success
Bisection showed this behavior to be caused by
commit 319554f284dda9f2737d09df82ba3610bd8ddea3
Author: Josef Bacik <jbacik@fb.com>
Date: Thu Jan 19 17:47:46 2017 -0500
inet: don't use sk_v6_rcv_saddr directly
When comparing two sockets we need to use inet6_rcv_saddr so we get
a NULL
sk_v6_rcv_saddr if the socket isn't AF_INET6, otherwise our
comparison function
can be wrong.
Fixes: 637bc8b ("inet: reset tb->fastreuseport when adding a
reuseport sk")
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
And reverting fixed both the standalone test case and the spice issue.
Any ideas?
Thanks,
Laura
[-- Attachment #2: 0001-net-set-tb-fast_sk_family.patch --]
[-- Type: application/octet-stream, Size: 1307 bytes --]
From b3c0458435d87911f1f99d314013b268e6c850a9 Mon Sep 17 00:00:00 2001
From: Josef Bacik <josef@toxicpanda.com>
Date: Tue, 12 Sep 2017 16:07:00 -0700
Subject: [PATCH] net: set tb->fast_sk_family
We need to set the tb->fast_sk_family properly so we can use the proper
comparison function for all subsequent reuseport bind requests.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
net/ipv4/inet_connection_sock.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 4089c013cb03..3cff95f10995 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -328,6 +328,7 @@ int inet_csk_get_port(struct sock *sk, unsigned short snum)
tb->fastuid = uid;
tb->fast_rcv_saddr = sk->sk_rcv_saddr;
tb->fast_ipv6_only = ipv6_only_sock(sk);
+ tb->fast_sk_family = sk->sk_family;
#if IS_ENABLED(CONFIG_IPV6)
tb->fast_v6_rcv_saddr = sk->sk_v6_rcv_saddr;
#endif
@@ -354,6 +355,7 @@ int inet_csk_get_port(struct sock *sk, unsigned short snum)
tb->fastuid = uid;
tb->fast_rcv_saddr = sk->sk_rcv_saddr;
tb->fast_ipv6_only = ipv6_only_sock(sk);
+ tb->fast_sk_family = sk->sk_family;
#if IS_ENABLED(CONFIG_IPV6)
tb->fast_v6_rcv_saddr = sk->sk_v6_rcv_saddr;
#endif
--
2.13.5
^ permalink raw reply related
* Re: [RFC PATCH] net: Introduce a socket option to enable picking tx queue based on rx queue.
From: Tom Herbert @ 2017-09-12 22:53 UTC (permalink / raw)
To: Samudrala, Sridhar
Cc: Eric Dumazet, Alexander Duyck, Linux Kernel Network Developers
In-Reply-To: <ef594f90-0f76-bdf5-63ce-e8750ee0d60f@intel.com>
On Tue, Sep 12, 2017 at 3:31 PM, Samudrala, Sridhar
<sridhar.samudrala@intel.com> wrote:
>
>
> On 9/12/2017 8:47 AM, Eric Dumazet wrote:
>>
>> On Mon, 2017-09-11 at 23:27 -0700, Samudrala, Sridhar wrote:
>>>
>>> On 9/11/2017 8:53 PM, Eric Dumazet wrote:
>>>>
>>>> On Mon, 2017-09-11 at 20:12 -0700, Tom Herbert wrote:
>>>>
>>>>> Two ints in sock_common for this purpose is quite expensive and the
>>>>> use case for this is limited-- even if a RX->TX queue mapping were
>>>>> introduced to eliminate the queue pair assumption this still won't
>>>>> help if the receive and transmit interfaces are different for the
>>>>> connection. I think we really need to see some very compelling results
>>>>> to be able to justify this.
>>>
>>> Will try to collect and post some perf data with symmetric queue
>>> configuration.
>>>
>>>> Yes, this is unreasonable cost.
>>>>
>>>> XPS should really cover the case already.
>>>>
>>>
>>> Eric,
>>>
>>> Can you clarify how XPS covers the RX-> TX queue mapping case?
>>> Is it possible to configure XPS to select TX queue based on the RX queue
>>> of a flow?
>>> IIUC, it is based on the CPU of the thread doing the transmit OR based
>>> on skb->priority to TC mapping?
>>> It may be possible to get this effect if the the threads are pinned to a
>>> core, but if the app threads are
>>> freely moving, i am not sure how XPS can be configured to select the TX
>>> queue based on the RX queue of a flow.
>>
>> If application is freely moving, how NIC can properly select the RX
>> queue so that packets are coming to the appropriate queue ?
>
> The RX queue is selected via RSS and we don't want to move the flow based on
> where the thread is running.
Unless flow director is enabled on the Intel device... This was, I
believe, one of the first attempts to introduce a queue pair notion to
general purpose NICs. The idea was that the device records the TX
queue for a flow and then uses that to determine receive queue in a
symmetric fashion. aRFS is similar, but was under SW control how the
mapping is done. As Eric mentioned there are scalability issues with
these mechanisms, but we also found that flow director can easily
reorder packets whenever the thread moves.
>>
>>
>> This is called aRFS, and it does not scale to millions of flows.
>> We tried in the past, and this went nowhere really, since the setup cost
>> is prohibitive and DDOS vulnerable.
>>
>> XPS will follow the thread, since selection is done on current cpu.
>>
>> The problem is RX side. If application is free to migrate, then special
>> support (aRFS) is needed from the hardware.
>
> This may be true if most of the rx processing is happening in the interrupt
> context.
> But with busy polling, i think we don't need aRFS as a thread should be
> able to poll
> any queue irrespective of where it is running.
It's not just a problem with interrupt processing, in general we like
to have all receive processing an subsequent transmit of a reply to be
done on one CPU. Silo'ing is good for performance and parallelism.
This can sometimes be relaxed in situations where CPUs share a cache
so crossing CPUs is not not costly.
>>
>>
>> At least for passive connections, we already have all the support in the
>> kernel so that you can have one thread per NIC queue, dealing with
>> sockets that have incoming packets all received on one NIC RX queue.
>> (And of course all TX packets will use the symmetric TX queue)
>>
>> SO_REUSEPORT plus appropriate BPF filter can achieve that.
>>
>> Say you have 32 queues, 32 cpus.
>>
>> Simply use 32 listeners, 32 threads (or 32 pools of threads)
>
> Yes. This will work if each thread is pinned to a core associated with the
> RX interrupt.
> It may not be possible to pin the threads to a core.
> Instead we want to associate a thread to a queue and do all the RX and TX
> completion
> of a queue in the same thread context via busy polling.
>
When that happens it's possible for RX to be done on the completely
wrong CPU which we know is suboptimal. However, this shouldn't
negatively affect TX side since XPS will just use the queue
appropriate for running CPU. Like Eric said, this is really a receive
problem more than a transmit problem. Keeping them as independent
paths seems to be a good approach.
Tom
^ permalink raw reply
* Re: [PATCH] datapath: Fix an error handling path in 'ovs_nla_init_match_and_action()'
From: Greg Rose @ 2017-09-12 22:48 UTC (permalink / raw)
To: Christophe JAILLET, pshelar, davem, xiangxia.m.yue
Cc: netdev, dev, linux-kernel, kernel-janitors
In-Reply-To: <20170911192015.17553-1-christophe.jaillet@wanadoo.fr>
On 09/11/2017 12:20 PM, Christophe JAILLET 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.
Having a large stack frame isn't really a bug per se. But the Linux kernel
warns about stack frames that are too large so reordering the code to
get the warning to go away seems fine to me.
>
> Instead of fixing the code with the proposed patch, reverting the initial
> commit could also be considered.
Then the warning will come back.
- Greg
> ---
> 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;
> }
>
> *acts = get_flow_actions(net, a[OVS_FLOW_ATTR_ACTIONS], key,
>
^ 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