* Re: Memory leaks in conntrack
From: Cong Wang @ 2017-09-13 17:58 UTC (permalink / raw)
To: Florian Westphal; +Cc: netfilter-devel, Linux Kernel Network Developers
In-Reply-To: <CAM_iQpVk1X+ZV2Nzi28G0HJu+RZWJ-_=0AO+EF4HVZnqSjVQ8w@mail.gmail.com>
On Wed, Sep 13, 2017 at 9:45 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Wed, Sep 13, 2017 at 1:05 AM, Florian Westphal <fw@strlen.de> wrote:
>> Cong Wang <xiyou.wangcong@gmail.com> wrote:
>>> 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
>>>
>>> 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.
>>
>> You probably do, can you try "cat /proc/net/nf_conntrack" instead?
>>
>> (otherwise there should be no ipv4_conntrack_local() invocation
>> since we would not register this hook at all).
>
> Yeah it is very weird but it is true:
>
> [root@localhost ~]# echo scan > /sys/kernel/debug/kmemleak
> [ 133.450823] kmemleak: 18 new suspected memory leaks (see
> /sys/kernel/debug/kmemleak)
> [root@localhost ~]# cat /proc/net/ip_conntrack
> cat: /proc/net/ip_conntrack: No such file or directory
> [root@localhost ~]# cat /sys/kernel/debug/kmemleak
> unreferenced object 0xffff95c1e0b24040 (size 336):
> ...
Oops, you mean nf_conntrack... Here we go:
[root@localhost ~]# cat /proc/net/nf_conntrack
ipv4 2 udp 17 116 src=192.168.124.6 dst=204.2.134.162
sport=123 dport=123 src=204.2.134.162 dst=192.168.124.6 sport=123
dport=123 [ASSURED] mark=0 zone=0 use=2
ipv4 2 udp 17 117 src=192.168.124.6 dst=45.79.187.10
sport=123 dport=123 src=45.79.187.10 dst=192.168.124.6 sport=123
dport=123 [ASSURED] mark=0 zone=0 use=2
ipv4 2 udp 17 110 src=192.168.124.6 dst=192.168.124.1
sport=35486 dport=53 src=192.168.124.1 dst=192.168.124.6 sport=53
dport=35486 [ASSURED] mark=0 zone=0 use=2
ipv4 2 udp 17 110 src=192.168.124.6 dst=192.168.124.1
sport=52373 dport=53 src=192.168.124.1 dst=192.168.124.6 sport=53
dport=52373 [ASSURED] mark=0 zone=0 use=2
ipv4 2 unknown 2 518 src=192.168.124.6 dst=224.0.0.22 [UNREPLIED]
src=224.0.0.22 dst=192.168.124.6 mark=0 zone=0 use=2
ipv4 2 udp 17 110 src=192.168.124.6 dst=192.168.124.1
sport=43242 dport=53 src=192.168.124.1 dst=192.168.124.6 sport=53
dport=43242 [ASSURED] mark=0 zone=0 use=2
ipv4 2 udp 17 116 src=192.168.124.6 dst=96.226.123.196
sport=123 dport=123 src=96.226.123.196 dst=192.168.124.6 sport=123
dport=123 [ASSURED] mark=0 zone=0 use=2
ipv4 2 udp 17 110 src=192.168.124.6 dst=192.168.124.1
sport=42838 dport=53 src=192.168.124.1 dst=192.168.124.6 sport=53
dport=42838 [ASSURED] mark=0 zone=0 use=2
ipv4 2 udp 17 117 src=192.168.124.6 dst=97.127.104.4
sport=123 dport=123 src=97.127.104.4 dst=192.168.124.6 sport=123
dport=123 [ASSURED] mark=0 zone=0 use=2
^ permalink raw reply
* Re: [PATCH/RFC net-next] ravb: RX checksum offload
From: Sergei Shtylyov @ 2017-09-13 17:54 UTC (permalink / raw)
To: Simon Horman, David Miller; +Cc: Magnus Damm, netdev, linux-renesas-soc
In-Reply-To: <1505221489-12870-1-git-send-email-horms+renesas@verge.net.au>
Hello!
On 09/12/2017 04:04 PM, Simon Horman wrote:
> Add support for RX checksum offload. This is enabled by default and
> may be disabled and re-enabled using ethtool:
>
> # ethtool -K eth0 rx off
> # ethtool -K eth0 rx on
>
> The RAVB provides a simple checksumming scheme which appears to be
> completely compatible with CHECKSUM_COMPLETE: a 1's complement sum of
Hm, the gen2/3 manuals say calculation doesn't involve bit inversion...
> all packet data after the L2 header is appended to packet data; this may
> be trivially read by the driver and used to update the skb accordingly.
>
> In terms of performance throughput is close to gigabit line-rate both with
> and without RX checksum offload enabled. Perf output, however, appears to
> indicate that significantly less time is spent in do_csum(). This is as
> expected.
[...]
> By inspection this also appears to be compatible with the ravb found
> on R-Car Gen 2 SoCs, however, this patch is currently untested on such
> hardware.
I probably won't be able to test it on gen2 too...
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
I'm generally OK with the patch but have some questions/comments below...
> ---
> drivers/net/ethernet/renesas/ravb_main.c | 58 +++++++++++++++++++++++++++++++-
> 1 file changed, 57 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
> index fdf30bfa403b..7c6438cd7de7 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
[...]
> @@ -1842,6 +1859,41 @@ static int ravb_do_ioctl(struct net_device *ndev, struct ifreq *req, int cmd)
> return phy_mii_ioctl(phydev, req, cmd);
> }
>
> +static void ravb_set_rx_csum(struct net_device *ndev, bool enable)
> +{
> + struct ravb_private *priv = netdev_priv(ndev);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&priv->lock, flags);
> +
> + /* Disable TX and RX */
> + ravb_rcv_snd_disable(ndev);
> +
> + /* Modify RX Checksum setting */
> + if (enable)
> + ravb_modify(ndev, ECMR, 0, ECMR_RCSC);
Please use ECMR_RCSC as the 3rd argument too to conform the common driver
style.
> + else
> + ravb_modify(ndev, ECMR, ECMR_RCSC, 0);
This *if* can easily be folded into a single ravb_modify() call...
[...]
> @@ -2004,6 +2057,9 @@ static int ravb_probe(struct platform_device *pdev)
> if (!ndev)
> return -ENOMEM;
>
> + ndev->features |= NETIF_F_RXCSUM;
> + ndev->hw_features |= ndev->features;
Hum, both fields are 0 before this? Then why not use '=' instead of '|='?
Even if not, why not just use the same value as both the rvalues?
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH v2] net: smsc911x: Quieten netif during suspend
From: Geert Uytterhoeven @ 2017-09-13 17:42 UTC (permalink / raw)
To: David S . Miller, Steve Glendinning
Cc: Andrew Lunn, Florian Fainelli, netdev, linux-pm,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
If the network interface is kept running during suspend, the net core
may call net_device_ops.ndo_start_xmit() while the Ethernet device is
still suspended, which may lead to a system crash.
E.g. on sh73a0/kzm9g and r8a73a4/ape6evm, the external Ethernet chip is
driven by a PM controlled clock. If the Ethernet registers are accessed
while the clock is not running, the system will crash with an imprecise
external abort.
As this is a race condition with a small time window, it is not so easy
to trigger at will. Using pm_test may increase your chances:
# echo 0 > /sys/module/printk/parameters/console_suspend
# echo platform > /sys/power/pm_test
# echo mem > /sys/power/state
To fix this, make sure the network interface is quietened during
suspend.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
This is v2 of the series "[PATCH 0/2] net: Fix crashes due to activity
during suspend", which degenerated into a single patch after commit
ebc8254aeae34226 ("Revert "net: phy: Correctly process PHY_HALTED in
phy_stop_machine()"") made "[PATCH 1/2] net: phy: Freeze PHY polling before
suspending devices" no longer needed.
v2:
- Spelling s/quit/quiet/g.
No stacktrace is provided, as the imprecise external abort is usually
reported from an innocent looking and unrelated function like
__loop_delay(), cpu_idle_poll(), or arch_timer_read_counter_long().
---
drivers/net/ethernet/smsc/smsc911x.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
index 0b6a39b003a4e188..012fb66eed8dd618 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -2595,6 +2595,11 @@ static int smsc911x_suspend(struct device *dev)
struct net_device *ndev = dev_get_drvdata(dev);
struct smsc911x_data *pdata = netdev_priv(ndev);
+ if (netif_running(ndev)) {
+ netif_stop_queue(ndev);
+ netif_device_detach(ndev);
+ }
+
/* enable wake on LAN, energy detection and the external PME
* signal. */
smsc911x_reg_write(pdata, PMT_CTRL,
@@ -2628,7 +2633,15 @@ static int smsc911x_resume(struct device *dev)
while (!(smsc911x_reg_read(pdata, PMT_CTRL) & PMT_CTRL_READY_) && --to)
udelay(1000);
- return (to == 0) ? -EIO : 0;
+ if (to == 0)
+ return -EIO;
+
+ if (netif_running(ndev)) {
+ netif_device_attach(ndev);
+ netif_start_queue(ndev);
+ }
+
+ return 0;
}
static const struct dev_pm_ops smsc911x_pm_ops = {
--
2.7.4
^ permalink raw reply related
* Re: 319554f284dd ("inet: don't use sk_v6_rcv_saddr directly") causes bind port regression
From: Cole Robinson @ 2017-09-13 17:40 UTC (permalink / raw)
To: Josef Bacik, Laura Abbott, David S. Miller, Alexey Kuznetsov,
Hideaki YOSHIFUJI
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <EF55EF02-AD40-4F06-8C07-4F9F4221BFE6@fb.com>
On 09/13/2017 01:28 PM, Josef Bacik wrote:
> Sorry I thought I had made this other fix, can you apply this on top of the other one and try that? I have more things to try if this doesn’t work, sorry you are playing go between, but I want to make sure I know _which_ fix actually fixes the problem, and then clean up in followup patches. Thanks,
>
I'm the bug reporter. I'll combine the two patches and report back
Thanks,
Cole
^ permalink raw reply
* Re: HTB going crazy over ~5Gbit/s (4.12.9, but problem present in older kernels as well)
From: Denys Fedoryshchenko @ 2017-09-13 17:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Kernel Network Developers, netdev-owner
In-Reply-To: <1505323222.15310.177.camel@edumazet-glaptop3.roam.corp.google.com>
On 2017-09-13 20:20, Eric Dumazet wrote:
> On Wed, 2017-09-13 at 20:12 +0300, Denys Fedoryshchenko wrote:
>
>> For my case, as load increased now, i am hitting same issue (i tried
>> to
>> play with quantum / bursts as well, didnt helped):
>>
>> tc -s -d class show dev eth3.777 classid 1:111;sleep 5;tc -s -d class
>> show dev eth3.777 classid 1:111
>> class htb 1:111 parent 1:1 leaf 111: prio 0 quantum 50000 rate 20Gbit
>> ceil 100Gbit linklayer ethernet burst 100000b/1 mpu 0b cburst
>> 100000b/1
>> mpu 0b level 0
>> Sent 864151559 bytes 730566 pkt (dropped 15111, overlimits 0
>> requeues
>> 0)
>> backlog 73968000b 39934p requeues 0
>> lended: 499867 borrowed: 0 giants: 0
>> tokens: 608 ctokens: 121
>>
>
> You have drops (and ~40,000 packets in backlog)
>
>
>> class htb 1:111 parent 1:1 leaf 111: prio 0 quantum 50000 rate 20Gbit
>> ceil 100Gbit linklayer ethernet burst 100000b/1 mpu 0b cburst
>> 100000b/1
>> mpu 0b level 0
>> Sent 1469352160 bytes 1243649 pkt (dropped 42933, overlimits 0
>> requeues
>> 0)
>> backlog 82536047b 39963p requeues 0
>> lended: 810475 borrowed: 0 giants: 0
>> tokens: 612 ctokens: 122
>>
>> (1469352160-864151559)/5*8
>> 968320961.60000000000000000000
>> Less than 1Gbit and it's being throttled
>
> It is not : "overlimits 0" means this class was not throttled.
Overlimits never appear in HTB as i know, here is simulation on this
class that have constant "at least" 1G traffic, i throttled it to 1Kbit
to simulate forced drops:
shapernew ~ # sh /etc/shaper.cfg;sleep 1;tc -s -d class show dev
eth3.777 classid 1:111;tc qdisc del dev eth3.777 root
class htb 1:111 parent 1:1 leaf 111: prio 0 quantum 50000 rate 1Kbit
ceil 1Kbit linklayer ethernet burst 31280b/1 mpu 0b cburst 31280b/1 mpu
0b level 0
Sent 134350019 bytes 117520 pkt (dropped 7819, overlimits 0 requeues 0)
backlog 7902126b 4976p requeues 0
lended: 86694 borrowed: 0 giants: 0
tokens: -937500000 ctokens: -937500000
^ permalink raw reply
* Re: [PATCH 0/2] net: Fix crashes due to activity during suspend
From: Geert Uytterhoeven @ 2017-09-13 17:33 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, marc_gonzalez, Mason, Geert Uytterhoeven,
David S . Miller, Steve Glendinning, Lukas Wunner,
Rafael J . Wysocki, netdev@vger.kernel.org, Linux PM list,
Linux-Renesas, linux-kernel@vger.kernel.org
In-Reply-To: <af7d0675-0cf2-1345-f137-59346e6f962c@gmail.com>
Hi Florian,
On Thu, Sep 7, 2017 at 3:09 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 08/23/2017 10:13 AM, Florian Fainelli wrote:
>> On 08/23/2017 04:45 AM, Geert Uytterhoeven wrote:
>>> On Tue, Aug 22, 2017 at 8:49 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>>> On 08/22/2017 11:37 AM, Geert Uytterhoeven wrote:
>>>>> If an Ethernet device is used while the device is suspended, the system may
>>>>> crash.
>>>>>
>>>>> E.g. on sh73a0/kzm9g and r8a73a4/ape6evm, the external Ethernet chip is
>>>>> driven by a PM controlled clock. If the Ethernet registers are accessed
>>>>> while the clock is not running, the system will crash with an imprecise
>>>>> external abort.
>>>>>
>>>>> This patch series fixes two of such crashes:
>>>>> 1. The first patch prevents the PHY polling state machine from accessing
>>>>> PHY registers while a device is suspended,
>>>>> 2. The second patch prevents the net core from trying to transmit packets
>>>>> when an smsc911x device is suspended.
>>>>>
>>>>> Both crashes can be reproduced on sh73a0/kzm9g and r8a73a4/ape6evm during
>>>>> s2ram (rarely), or by using pm_test (more likely to trigger):
>>>>>
>>>>> # echo 0 > /sys/module/printk/parameters/console_suspend
>>>>> # echo platform > /sys/power/pm_test
>>>>> # echo mem > /sys/power/state
>>>>>
>>>>> With this series applied, my test systems survive a loop of 100 test
>>>>> suspends.
>>>>
>>>> It seems to me like part, if not the entire problem is that smsc91xx's
>>>> suspend and resume functions are way too simplistic and absolutely do
>>>> not manage the PHY during suspend/resume, the PHY state machine is not
>>>> even stopped, so of course, this will cause bus errors if you access
>>>> those registers.
>>>>
>>>> You are addressing this as part of patch 2, but this seems to me like
>>>> this is still a bit incomplete and you'd need at least phy_stop() and/or
>>>> phy_suspend() (does a power down of the PHY) and phy_start() and/or
>>>> phy_resume() calls to complete the PHY state machine shutdown during
>>>> suspend.
>>>>
>>>> Have you tried that?
>>>
>>> Unfortunately that doesn't help.
>>> In state PHY_HALTED, the PHY state machine still calls the .adjust_link()
>>> callback while the device is suspended.
>>
>> Humm that is correct yes.
>>
>>> Do you have a clue? This is too far beyond my phy-foo...
>>
>> I was initially contemplating a revert of
>> 7ad813f208533cebfcc32d3d7474dc1677d1b09a ("net: phy: Correctly process
>> PHY_HALTED in phy_stop_machine()") but this is not the root of the
>> problem. The problem really is that phy_stop() does not wait for the PHY
>> state machine to be stopped so you cannot rely on that and past the
>> function return be offered any guarantees that adjust_link is not called.
>>
>> We seem to be getting away with that in most drivers because when we see
>> phydev->link = 0, we either do nothing or actually turn of the HW block.
>>
>> How about we export phy_stop_machine() to drivers which would provide a
>> synchronization point that would ensure that no HW accesses are done
>> past this point?
>>
>> I am absolutely not clear on the implications of using a freezable
>> workqueue with respect to the PHY state machine and how devices are
>> going to wind-up being powered down or not...
>
> Geert, as you may have notice a revert of the change was sent so 4.13
> should be fine, but ultimately I would like to put the non-reverted code
> back in after we add a few safeguards:
With the revert, I no longer need "[PATCH 1/2] net: phy: Freeze PHY polling
before suspending devices".
I just did more than 50 successful suspend/resume cycles to verify that.
I still need "[PATCH 2/2] net: smsc911x: Quiten netif during suspend", so
I'll submit a v2 for that.
> - and you reported the bus errors on smsc911x when we call adjust_link
> during suspend, and due to a lack of hard synchronization so phy_stop()
> here does not give you enough guarantees to let you turn off power to
> the smsc911x block
>
> If that seems accurate then we can work on something that should be
> working again (famous last words).
Sounds accurate to me.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: 319554f284dd ("inet: don't use sk_v6_rcv_saddr directly") causes bind port regression
From: Josef Bacik @ 2017-09-13 17:28 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: <588f3795-931e-7779-4ec7-5fe7d4437927@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 858 bytes --]
Sorry I thought I had made this other fix, can you apply this on top of the other one and try that? I have more things to try if this doesn’t work, sorry you are playing go between, but I want to make sure I know _which_ fix actually fixes the problem, and then clean up in followup patches. Thanks,
Josef
On 9/13/17, 8:45 AM, "Laura Abbott" <labbott@redhat.com> wrote:
On 09/12/2017 04:12 PM, Josef Bacik wrote:
> 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
Thanks for the quick turnaround. Unfortunately, the problem is still
reproducible according to the reporter.
Thanks,
Laura
[-- Attachment #2: 0001-net-use-inet6_rcv_saddr-to-compare-sockets.patch --]
[-- Type: application/octet-stream, Size: 1085 bytes --]
From 380968f58d543ac9ec0cb1aa11db3979f3aee69d Mon Sep 17 00:00:00 2001
From: Josef Bacik <josef@toxicpanda.com>
Date: Wed, 13 Sep 2017 10:24:22 -0700
Subject: [PATCH] net: use inet6_rcv_saddr to compare sockets
In ipv6_rcv_saddr_equal() we need to use inet6_rcv_saddr(sk) for the
ipv6 compare with the fast socket information to make sure we're doing
the proper comparisons.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
net/ipv4/inet_connection_sock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 3cff95f10995..ff8b15a99e42 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -266,7 +266,7 @@ static inline int sk_reuseport_match(struct inet_bind_bucket *tb,
#if IS_ENABLED(CONFIG_IPV6)
if (tb->fast_sk_family == AF_INET6)
return ipv6_rcv_saddr_equal(&tb->fast_v6_rcv_saddr,
- &sk->sk_v6_rcv_saddr,
+ inet6_rcv_saddr(sk),
tb->fast_rcv_saddr,
sk->sk_rcv_saddr,
tb->fast_ipv6_only,
--
2.13.5
^ permalink raw reply related
* Re: [PATCH net] perf/bpf: fix a clang compilation issue
From: Nick Desaulniers @ 2017-09-13 17:26 UTC (permalink / raw)
To: David Miller; +Cc: yhs, peterz, rostedt, ast, daniel, netdev, kernel-team
In-Reply-To: <20170911.142857.1205848546110018404.davem@davemloft.net>
great, thanks!
On Mon, Sep 11, 2017 at 2:28 PM, David Miller <davem@davemloft.net> wrote:
> From: Yonghong Song <yhs@fb.com>
> Date: Thu, 7 Sep 2017 18:36:15 -0700
>
>> clang does not support variable length array for structure member.
>> It has the following error during compilation:
>>
>> kernel/trace/trace_syscalls.c:568:17: error: fields must have a constant size:
>> 'variable length array in structure' extension will never be supported
>> unsigned long args[sys_data->nb_args];
>> ^
>>
>> The fix is to use a fixed array length instead.
>>
>> Reported-by: Nick Desaulniers <ndesaulniers@google.com>
>> Signed-off-by: Yonghong Song <yhs@fb.com>
>
> Applied.
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: HTB going crazy over ~5Gbit/s (4.12.9, but problem present in older kernels as well)
From: Eric Dumazet @ 2017-09-13 17:20 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: Linux Kernel Network Developers, netdev-owner
In-Reply-To: <57baf3c3ea2544ed4d53967b7a2d0e36@nuclearcat.com>
On Wed, 2017-09-13 at 20:12 +0300, Denys Fedoryshchenko wrote:
> For my case, as load increased now, i am hitting same issue (i tried to
> play with quantum / bursts as well, didnt helped):
>
> tc -s -d class show dev eth3.777 classid 1:111;sleep 5;tc -s -d class
> show dev eth3.777 classid 1:111
> class htb 1:111 parent 1:1 leaf 111: prio 0 quantum 50000 rate 20Gbit
> ceil 100Gbit linklayer ethernet burst 100000b/1 mpu 0b cburst 100000b/1
> mpu 0b level 0
> Sent 864151559 bytes 730566 pkt (dropped 15111, overlimits 0 requeues
> 0)
> backlog 73968000b 39934p requeues 0
> lended: 499867 borrowed: 0 giants: 0
> tokens: 608 ctokens: 121
>
You have drops (and ~40,000 packets in backlog)
> class htb 1:111 parent 1:1 leaf 111: prio 0 quantum 50000 rate 20Gbit
> ceil 100Gbit linklayer ethernet burst 100000b/1 mpu 0b cburst 100000b/1
> mpu 0b level 0
> Sent 1469352160 bytes 1243649 pkt (dropped 42933, overlimits 0 requeues
> 0)
> backlog 82536047b 39963p requeues 0
> lended: 810475 borrowed: 0 giants: 0
> tokens: 612 ctokens: 122
>
> (1469352160-864151559)/5*8
> 968320961.60000000000000000000
> Less than 1Gbit and it's being throttled
It is not : "overlimits 0" means this class was not throttled.
^ permalink raw reply
* [PATCH net v2 3/3] nfp: wait for the NSP resource to appear on boot
From: Jakub Kicinski @ 2017-09-13 17:16 UTC (permalink / raw)
To: netdev; +Cc: oss-drivers, Jakub Kicinski
In-Reply-To: <20170913171600.31049-1-jakub.kicinski@netronome.com>
The control process (NSP) may take some time to complete its
initialization. This is not a problem on most servers, but
on very fast-booting machines it may not be ready for operation
when driver probes the device. There is also a version of the
flash in the wild where NSP tries to train the links as part
of init. To wait for NSP initialization we should make sure
its resource has already been added to the resource table.
NSP adds itself there as last step of init.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfp_main.c | 4 ++
drivers/net/ethernet/netronome/nfp/nfpcore/nfp.h | 2 +
.../ethernet/netronome/nfp/nfpcore/nfp_resource.c | 45 ++++++++++++++++++++++
3 files changed, 51 insertions(+)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_main.c b/drivers/net/ethernet/netronome/nfp/nfp_main.c
index 424707d41fbd..f8fa63b66739 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_main.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_main.c
@@ -351,6 +351,10 @@ static int nfp_nsp_init(struct pci_dev *pdev, struct nfp_pf *pf)
struct nfp_nsp *nsp;
int err;
+ err = nfp_resource_wait(pf->cpp, NFP_RESOURCE_NSP, 30);
+ if (err)
+ return err;
+
nsp = nfp_nsp_open(pf->cpp);
if (IS_ERR(nsp)) {
err = PTR_ERR(nsp);
diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp.h b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp.h
index 1a8d04a1e113..3ce51f03126f 100644
--- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp.h
+++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp.h
@@ -97,6 +97,8 @@ nfp_resource_acquire(struct nfp_cpp *cpp, const char *name);
void nfp_resource_release(struct nfp_resource *res);
+int nfp_resource_wait(struct nfp_cpp *cpp, const char *name, unsigned int secs);
+
u32 nfp_resource_cpp_id(struct nfp_resource *res);
const char *nfp_resource_name(struct nfp_resource *res);
diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_resource.c b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_resource.c
index 072612263dab..b1dd13ff282b 100644
--- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_resource.c
+++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_resource.c
@@ -249,6 +249,51 @@ void nfp_resource_release(struct nfp_resource *res)
kfree(res);
}
+/**
+ * nfp_resource_wait() - Wait for resource to appear
+ * @cpp: NFP CPP handle
+ * @name: Name of the resource
+ * @secs: Number of seconds to wait
+ *
+ * Wait for resource to appear in the resource table, grab and release
+ * its lock. The wait is jiffies-based, don't expect fine granularity.
+ *
+ * Return: 0 on success, errno otherwise.
+ */
+int nfp_resource_wait(struct nfp_cpp *cpp, const char *name, unsigned int secs)
+{
+ unsigned long warn_at = jiffies + NFP_MUTEX_WAIT_FIRST_WARN * HZ;
+ unsigned long err_at = jiffies + secs * HZ;
+ struct nfp_resource *res;
+
+ while (true) {
+ res = nfp_resource_acquire(cpp, name);
+ if (!IS_ERR(res)) {
+ nfp_resource_release(res);
+ return 0;
+ }
+
+ if (PTR_ERR(res) != -ENOENT) {
+ nfp_err(cpp, "error waiting for resource %s: %ld\n",
+ name, PTR_ERR(res));
+ return PTR_ERR(res);
+ }
+ if (time_is_before_eq_jiffies(err_at)) {
+ nfp_err(cpp, "timeout waiting for resource %s\n", name);
+ return -ETIMEDOUT;
+ }
+ if (time_is_before_eq_jiffies(warn_at)) {
+ warn_at = jiffies + NFP_MUTEX_WAIT_NEXT_WARN * HZ;
+ nfp_info(cpp, "waiting for NFP resource %s\n", name);
+ }
+ if (msleep_interruptible(10)) {
+ nfp_err(cpp, "wait for resource %s interrupted\n",
+ name);
+ return -ERESTARTSYS;
+ }
+ }
+}
+
/**
* nfp_resource_cpp_id() - Return the cpp_id of a resource handle
* @res: NFP Resource handle
--
2.14.1
^ permalink raw reply related
* [PATCH net v2 2/3] nfp: wait for board state before talking to the NSP
From: Jakub Kicinski @ 2017-09-13 17:15 UTC (permalink / raw)
To: netdev; +Cc: oss-drivers, Jakub Kicinski
In-Reply-To: <20170913171600.31049-1-jakub.kicinski@netronome.com>
Board state informs us which low-level initialization stages the card
has completed. We should wait for the card to be fully initialized
before trying to communicate with it, not only before we configure
passing traffic.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfp_main.c | 43 +++++++++++++++++++++++
drivers/net/ethernet/netronome/nfp/nfp_net_main.c | 23 ------------
2 files changed, 43 insertions(+), 23 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_main.c b/drivers/net/ethernet/netronome/nfp/nfp_main.c
index f055b1774d65..424707d41fbd 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_main.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_main.c
@@ -74,6 +74,45 @@ static const struct pci_device_id nfp_pci_device_ids[] = {
};
MODULE_DEVICE_TABLE(pci, nfp_pci_device_ids);
+static bool nfp_board_ready(struct nfp_pf *pf)
+{
+ const char *cp;
+ long state;
+ int err;
+
+ cp = nfp_hwinfo_lookup(pf->hwinfo, "board.state");
+ if (!cp)
+ return false;
+
+ err = kstrtol(cp, 0, &state);
+ if (err < 0)
+ return false;
+
+ return state == 15;
+}
+
+static int nfp_pf_board_state_wait(struct nfp_pf *pf)
+{
+ const unsigned long wait_until = jiffies + 10 * HZ;
+
+ while (!nfp_board_ready(pf)) {
+ if (time_is_before_eq_jiffies(wait_until)) {
+ nfp_err(pf->cpp, "NFP board initialization timeout\n");
+ return -EINVAL;
+ }
+
+ nfp_info(pf->cpp, "waiting for board initialization\n");
+ if (msleep_interruptible(500))
+ return -ERESTARTSYS;
+
+ /* Refresh cached information */
+ kfree(pf->hwinfo);
+ pf->hwinfo = nfp_hwinfo_read(pf->cpp);
+ }
+
+ return 0;
+}
+
static int nfp_pcie_sriov_read_nfd_limit(struct nfp_pf *pf)
{
int err;
@@ -425,6 +464,10 @@ static int nfp_pci_probe(struct pci_dev *pdev,
nfp_hwinfo_lookup(pf->hwinfo, "assembly.revision"),
nfp_hwinfo_lookup(pf->hwinfo, "cpld.version"));
+ err = nfp_pf_board_state_wait(pf);
+ if (err)
+ goto err_hwinfo_free;
+
err = devlink_register(devlink, &pdev->dev);
if (err)
goto err_hwinfo_free;
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_main.c b/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
index 5abb9ba31e7d..ff373acd28f3 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
@@ -64,23 +64,6 @@
#define NFP_PF_CSR_SLICE_SIZE (32 * 1024)
-static int nfp_is_ready(struct nfp_pf *pf)
-{
- const char *cp;
- long state;
- int err;
-
- cp = nfp_hwinfo_lookup(pf->hwinfo, "board.state");
- if (!cp)
- return 0;
-
- err = kstrtol(cp, 0, &state);
- if (err < 0)
- return 0;
-
- return state == 15;
-}
-
/**
* nfp_net_get_mac_addr() - Get the MAC address.
* @pf: NFP PF handle
@@ -725,12 +708,6 @@ int nfp_net_pci_probe(struct nfp_pf *pf)
INIT_WORK(&pf->port_refresh_work, nfp_net_refresh_vnics);
- /* Verify that the board has completed initialization */
- if (!nfp_is_ready(pf)) {
- nfp_err(pf->cpp, "NFP is not ready for NIC operation.\n");
- return -EINVAL;
- }
-
if (!pf->rtbl) {
nfp_err(pf->cpp, "No %s, giving up.\n",
pf->fw_loaded ? "symbol table" : "firmware found");
--
2.14.1
^ permalink raw reply related
* [PATCH net v2 1/3] nfp: add whitelist of supported flow dissector
From: Jakub Kicinski @ 2017-09-13 17:15 UTC (permalink / raw)
To: netdev; +Cc: oss-drivers, Pieter Jansen van Vuuren
In-Reply-To: <20170913171600.31049-1-jakub.kicinski@netronome.com>
From: Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
Previously we did not check the flow dissector against a list of allowed
and supported flow key dissectors. This patch introduces such a list and
correctly rejects unsupported flow keys.
Fixes: 43f84b72c50d ("nfp: add metadata to each flow offload")
Signed-off-by: Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
drivers/net/ethernet/netronome/nfp/flower/offload.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/net/ethernet/netronome/nfp/flower/offload.c b/drivers/net/ethernet/netronome/nfp/flower/offload.c
index d396183108f7..a18b4d2b1d3e 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/offload.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/offload.c
@@ -44,6 +44,16 @@
#include "../nfp_net.h"
#include "../nfp_port.h"
+#define NFP_FLOWER_WHITELIST_DISSECTOR \
+ (BIT(FLOW_DISSECTOR_KEY_CONTROL) | \
+ BIT(FLOW_DISSECTOR_KEY_BASIC) | \
+ BIT(FLOW_DISSECTOR_KEY_IPV4_ADDRS) | \
+ BIT(FLOW_DISSECTOR_KEY_IPV6_ADDRS) | \
+ BIT(FLOW_DISSECTOR_KEY_PORTS) | \
+ BIT(FLOW_DISSECTOR_KEY_ETH_ADDRS) | \
+ BIT(FLOW_DISSECTOR_KEY_VLAN) | \
+ BIT(FLOW_DISSECTOR_KEY_IP))
+
static int
nfp_flower_xmit_flow(struct net_device *netdev,
struct nfp_fl_payload *nfp_flow, u8 mtype)
@@ -112,6 +122,9 @@ nfp_flower_calculate_key_layers(struct nfp_fl_key_ls *ret_key_ls,
u8 key_layer;
int key_size;
+ if (flow->dissector->used_keys & ~NFP_FLOWER_WHITELIST_DISSECTOR)
+ return -EOPNOTSUPP;
+
if (dissector_uses_key(flow->dissector,
FLOW_DISSECTOR_KEY_ENC_CONTROL)) {
struct flow_dissector_key_control *mask_enc_ctl =
--
2.14.1
^ permalink raw reply related
* [PATCH net v2 0/3] nfp: wait more carefully for card init
From: Jakub Kicinski @ 2017-09-13 17:15 UTC (permalink / raw)
To: netdev; +Cc: oss-drivers, Jakub Kicinski
Hi!
The first patch is a small fix for flower offload, we need a whitelist
of supported matches, otherwise the unsupported ones will be ignored.
The second and the third patch are adding wait/polling to the probe path.
We had reports of driver failing probe because it couldn't find the
control process (NSP) on the card. Turns out the NSP will only announce
its existence after it's fully initialized. Until now we assumed it
will be reachable, just not processing commands (hence we wait for
a NOOP command to execute successfully).
v2:
- fix a bad merge which resulted in a build warning and retest.
Jakub Kicinski (2):
nfp: wait for board state before talking to the NSP
nfp: wait for the NSP resource to appear on boot
Pieter Jansen van Vuuren (1):
nfp: add whitelist of supported flow dissector
.../net/ethernet/netronome/nfp/flower/offload.c | 13 ++++++
drivers/net/ethernet/netronome/nfp/nfp_main.c | 47 ++++++++++++++++++++++
drivers/net/ethernet/netronome/nfp/nfp_net_main.c | 23 -----------
drivers/net/ethernet/netronome/nfp/nfpcore/nfp.h | 2 +
.../ethernet/netronome/nfp/nfpcore/nfp_resource.c | 45 +++++++++++++++++++++
5 files changed, 107 insertions(+), 23 deletions(-)
--
2.14.1
^ permalink raw reply
* RFC: Audit Kernel Container IDs
From: Richard Guy Briggs @ 2017-09-13 17:13 UTC (permalink / raw)
To: cgroups-u79uwXL29TY76Z2rM5mHXA, Linux Containers, Linux API,
Linux Audit, Linux FS Devel, Linux Kernel,
Linux Network Development
Cc: Aristeu Rozanski, David Howells, Eric W. Biederman, Eric Paris,
jlayton-H+wXaHxf7aLQT0dZR+AlfA, Andy Lutomirski,
mszeredi-H+wXaHxf7aLQT0dZR+AlfA, Paul Moore, Serge E. Hallyn,
Steve Grubb, trondmy-7I+n7zu2hftEKMMhf/gKZA, Al Viro
Containers are a userspace concept. The kernel knows nothing of them.
The Linux audit system needs a way to be able to track the container
provenance of events and actions. Audit needs the kernel's help to do
this.
Since the concept of a container is entirely a userspace concept, a
trigger signal from the userspace container orchestration system
initiates this. This will define a point in time and a set of resources
associated with a particular container with an audit container ID.
The trigger is a pseudo filesystem (proc, since PID tree already exists)
write of a u64 representing the container ID to a file representing a
process that will become the first process in a new container.
This might place restrictions on mount namespaces required to define a
container, or at least careful checking of namespaces in the kernel to
verify permissions of the orchestrator so it can't change its own
container ID.
A bind mount of nsfs may be necessary in the container orchestrator's
mntNS.
Require a new CAP_CONTAINER_ADMIN to be able to write to the pseudo
filesystem to have this action permitted. At that time, record the
child container's user-supplied 64-bit container identifier along with
the child container's first process (which may become the container's
"init" process) process ID (referenced from the initial PID namespace),
all namespace IDs (in the form of a nsfs device number and inode number
tuple) in a new auxilliary record AUDIT_CONTAINER with a qualifying
op=$action field.
Issue a new auxilliary record AUDIT_CONTAINER_INFO for each valid
container ID present on an auditable action or event.
Forked and cloned processes inherit their parent's container ID,
referenced in the process' audit_context struct.
Log the creation of every namespace, inheriting/adding its spawning
process' containerID(s), if applicable. Include the spawning and
spawned namespace IDs (device and inode number tuples).
[AUDIT_NS_CREATE, AUDIT_NS_DESTROY] [clone(2), unshare(2), setns(2)]
Note: At this point it appears only network namespaces may need to track
container IDs apart from processes since incoming packets may cause an
auditable event before being associated with a process.
Log the destruction of every namespace when it is no longer used by any
process, include the namespace IDs (device and inode number tuples).
[AUDIT_NS_DESTROY] [process exit, unshare(2), setns(2)]
Issue a new auxilliary record AUDIT_NS_CHANGE listing (opt: op=$action)
the parent and child namespace IDs for any changes to a process'
namespaces. [setns(2)]
Note: It may be possible to combine AUDIT_NS_* record formats and
distinguish them with an op=$action field depending on the fields
required for each message type.
A process can be moved from one container to another by using the
container assignment method outlined above a second time.
When a container ceases to exist because the last process in that
container has exited and hence the last namespace has been destroyed and
its refcount dropping to zero, log the fact.
(This latter is likely needed for certification accountability.) A
container object may need a list of processes and/or namespaces.
A namespace cannot directly migrate from one container to another but
could be assigned to a newly spawned container. A namespace can be
moved from one container to another indirectly by having that namespace
used in a second process in another container and then ending all the
processes in the first container.
Feedback please.
- RGB
--
Richard Guy Briggs <rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: HTB going crazy over ~5Gbit/s (4.12.9, but problem present in older kernels as well)
From: Denys Fedoryshchenko @ 2017-09-13 17:12 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Kernel Network Developers, netdev-owner
In-Reply-To: <1505321747.15310.175.camel@edumazet-glaptop3.roam.corp.google.com>
On 2017-09-13 19:55, Eric Dumazet wrote:
> On Wed, 2017-09-13 at 09:42 -0700, Eric Dumazet wrote:
>> On Wed, 2017-09-13 at 19:27 +0300, Denys Fedoryshchenko wrote:
>> > On 2017-09-13 19:16, Eric Dumazet wrote:
>> > > On Wed, 2017-09-13 at 18:34 +0300, Denys Fedoryshchenko wrote:
>> > >> Well, probably i am answering my own question, removing estimator from
>> > >> classes seems drastically improve situation.
>> > >> It seems estimator has some issues that cause shaper to behave
>> > >> incorrectly (throttling traffic while it should not).
>> > >> But i guess thats a bug?
>> > >> As i was not able to predict such bottleneck by CPU load measurements.
>> > >
>> > > Well, there was a reason we disabled HTB class estimators by default ;)
>> > >
>> > >
>> > > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=64153ce0a7b61b2a5cacb01805cbf670142339e9
>> >
>> > As soon as disabling it solve my problem - i'm fine, hehe, but i guess
>> > other people who might hit this problem, should be aware how to find
>> > reason.
>> > They should not be disappointed in Linux :)
>>
>> Well, if they enable rate estimators while kernel does not set them by
>> default, they get what they want, at a cost.
>>
>> > Because i can't measure this bottleneck before it happens, i'm seeing on
>> > mpstat all cpu's are idle, and same time traffic is throttled.
>>
>> Normally things were supposed to get much better in linux-4.10
>>
>> (
>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=1c0d32fde5bdf1184bc274f864c09799278a1114
>> )
>>
>> But I apparently added a scaling bug.
>>
>> I will try :
>>
>> diff --git a/net/core/gen_estimator.c b/net/core/gen_estimator.c
>> index
>> 0385dece1f6fe5e26df1ce5f40956a79a2eebbf4..7c1ffd6f950172c1915d8e5fa2b5e3f77e4f4c78
>> 100644
>> --- a/net/core/gen_estimator.c
>> +++ b/net/core/gen_estimator.c
>> @@ -83,10 +83,10 @@ static void est_timer(unsigned long arg)
>> u64 rate, brate;
>>
>> est_fetch_counters(est, &b);
>> - brate = (b.bytes - est->last_bytes) << (8 - est->ewma_log);
>> + brate = (b.bytes - est->last_bytes) << (10 - est->ewma_log -
>> est->intvl_log);
>> brate -= (est->avbps >> est->ewma_log);
>>
>> - rate = (u64)(b.packets - est->last_packets) << (8 -
>> est->ewma_log);
>> + rate = (u64)(b.packets - est->last_packets) << (10 -
>> est->ewma_log - est->intvl_log);
>> rate -= (est->avpps >> est->ewma_log);
>>
>> write_seqcount_begin(&est->seq);
>
>
> Much better indeed
>
> # tc -s -d class sh dev eth0 classid 7002:11 ; sleep 10 ;tc -s -d class
> sh dev eth0 classid 7002:11
>
> class htb 7002:11 parent 7002:1 prio 5 quantum 200000 rate 5Gbit ceil
> 5Gbit linklayer ethernet burst 80000b/1 mpu 0b cburst 80000b/1 mpu 0b
> level 0 rate_handle 1
> Sent 389085117074 bytes 256991500 pkt (dropped 0, overlimits 5926926
> requeues 0)
> rate 4999Mbit 412762pps backlog 136260b 2p requeues 0
> TCP pkts/rtx 256991584/0 bytes 389085252840/0
> lended: 5961250 borrowed: 0 giants: 0
> tokens: -1664 ctokens: -1664
>
> class htb 7002:11 parent 7002:1 prio 5 quantum 200000 rate 5Gbit ceil
> 5Gbit linklayer ethernet burst 80000b/1 mpu 0b cburst 80000b/1 mpu 0b
> level 0 rate_handle 1
> Sent 395336315580 bytes 261120429 pkt (dropped 0, overlimits 6021776
> requeues 0)
> rate 4999Mbit 412788pps backlog 68Kb 2p requeues 0
> TCP pkts/rtx 261120469/0 bytes 395336384730/0
> lended: 6056793 borrowed: 0 giants: 0
> tokens: -1478 ctokens: -1478
>
>
> echo "(395336315580-389085117074)/10*8" | bc
> 5000958800
For my case, as load increased now, i am hitting same issue (i tried to
play with quantum / bursts as well, didnt helped):
tc -s -d class show dev eth3.777 classid 1:111;sleep 5;tc -s -d class
show dev eth3.777 classid 1:111
class htb 1:111 parent 1:1 leaf 111: prio 0 quantum 50000 rate 20Gbit
ceil 100Gbit linklayer ethernet burst 100000b/1 mpu 0b cburst 100000b/1
mpu 0b level 0
Sent 864151559 bytes 730566 pkt (dropped 15111, overlimits 0 requeues
0)
backlog 73968000b 39934p requeues 0
lended: 499867 borrowed: 0 giants: 0
tokens: 608 ctokens: 121
class htb 1:111 parent 1:1 leaf 111: prio 0 quantum 50000 rate 20Gbit
ceil 100Gbit linklayer ethernet burst 100000b/1 mpu 0b cburst 100000b/1
mpu 0b level 0
Sent 1469352160 bytes 1243649 pkt (dropped 42933, overlimits 0 requeues
0)
backlog 82536047b 39963p requeues 0
lended: 810475 borrowed: 0 giants: 0
tokens: 612 ctokens: 122
(1469352160-864151559)/5*8
968320961.60000000000000000000
Less than 1Gbit and it's being throttled
Total bandwidth:
class htb 1:1 root rate 100Gbit ceil 100Gbit linklayer ethernet burst
100000b/1 mpu 0b cburst 100000b/1 mpu 0b level 7
Sent 7839730635 bytes 8537393 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
lended: 0 borrowed: 0 giants: 0
tokens: 123 ctokens: 123
class htb 1:1 root rate 100Gbit ceil 100Gbit linklayer ethernet burst
100000b/1 mpu 0b cburst 100000b/1 mpu 0b level 7
Sent 11043190453 bytes 12008366 pkt (dropped 0, overlimits 0 requeues
0)
backlog 0b 0p requeues 0
lended: 0 borrowed: 0 giants: 0
tokens: 124 ctokens: 124
694kpps
5.1Gbit
^ permalink raw reply
* Re: Regression in throughput between kvm guests over virtual bridge
From: Matthew Rosato @ 2017-09-13 16:59 UTC (permalink / raw)
To: Jason Wang, netdev; +Cc: davem, mst
In-Reply-To: <e022cfa7-ef65-550f-06e8-f6e29f1d68a0@redhat.com>
On 09/13/2017 04:13 AM, Jason Wang wrote:
>
>
> On 2017年09月13日 09:16, Jason Wang wrote:
>>
>>
>> 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?
Original runs were done with guest kernel 4.4 (from ubuntu 16.04.3 -
4.4.0-93-generic specifically). Here's a throughput report (uperf) and
#pkts and average packet size (tcpstat) for one of the uperf clients:
host 4.12 / guest 4.4:
throughput: 29.98Gb/s
#pkts=33465571 avg packet size=33755.70
host 4.13 / guest 4.4:
throughput: 20.36Gb/s
#pkts=21233399 avg packet size=36130.69
I ran the test again using net-next.git as guest kernel, with and
without napi_tx=true. napi_tx did not seem to have any significant
impact on throughput. However, the guest kernel shift from
4.4->net-next improved things. I can still see a regression between
host 4.12 and 4.13, but it's more on the order of 10-15% - another sample:
host 4.12 / guest net-next (without napi_tx):
throughput: 28.88Gb/s
#pkts=31743116 avg packet size=33779.78
host 4.13 / guest net-next (without napi_tx):
throughput: 24.34Gb/s
#pkts=25532724 avg packet size=35963.20
>>
>> Thanks
>
> Unfortunately, I could not reproduce it locally. I'm using net-next.git
> as guest. I can get ~42Gb/s on Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
> for both before and after the commit. I use 1 vcpu and 1 queue, and pin
> vcpu and vhost threads into separate cpu on host manually (in same numa
> node).
The environment is quite a bit different -- I'm running in an LPAR on a
z13 (s390x). We've seen the issue in various configurations, the
smallest thus far was a host partition w/ 40G and 20 CPUs defined (the
numbers above were gathered w/ this configuration). Each guest has 4GB
and 4 vcpus. No pinning / affinity configured.
>
> Can you hit this regression constantly and what's you qemu command line
Yes, the regression seems consistent. I can try tweaking some of the
host and guest definitions to see if it makes a difference.
The guests are instantiated from libvirt - Here's one of the resulting
qemu command lines:
/usr/bin/qemu-system-s390x -name guest=mjrs34g1,debug-threads=on -S
-object
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-mjrs34g1/master-key.aes
-machine s390-ccw-virtio-2.10,accel=kvm,usb=off,dump-guest-core=off -m
4096 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid
44710587-e783-4bd8-8590-55ff421431b1 -display none -no-user-config
-nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-mjrs34g1/monitor.sock,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc
-no-shutdown -boot strict=on -drive
file=/dev/disk/by-id/scsi-3600507630bffc0380000000000001803,format=raw,if=none,id=drive-virtio-disk0
-device
virtio-blk-ccw,scsi=off,devno=fe.0.0000,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=27 -device
virtio-net-ccw,netdev=hostnet0,id=net0,mac=02:de:26:53:14:01,devno=fe.0.0001
-netdev tap,fd=28,id=hostnet1,vhost=on,vhostfd=29 -device
virtio-net-ccw,netdev=hostnet1,id=net1,mac=02:54:00:89:d4:01,devno=fe.0.00a1
-chardev pty,id=charconsole0 -device
sclpconsole,chardev=charconsole0,id=console0 -device
virtio-balloon-ccw,id=balloon0,devno=fe.0.0002 -msg timestamp=on
In the above, net0 is used for a macvtap connection (not used in the
experiment, just for a reliable ssh connection - can remove if needed).
net1 is the bridge connection used for the uperf tests.
> and #cpus on host? Is zerocopy enabled?
Host info provided above.
cat /sys/module/vhost_net/parameters/experimental_zcopytx
1
^ permalink raw reply
* Re: HTB going crazy over ~5Gbit/s (4.12.9, but problem present in older kernels as well)
From: Eric Dumazet @ 2017-09-13 16:55 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: Linux Kernel Network Developers
In-Reply-To: <1505320949.15310.173.camel@edumazet-glaptop3.roam.corp.google.com>
On Wed, 2017-09-13 at 09:42 -0700, Eric Dumazet wrote:
> On Wed, 2017-09-13 at 19:27 +0300, Denys Fedoryshchenko wrote:
> > On 2017-09-13 19:16, Eric Dumazet wrote:
> > > On Wed, 2017-09-13 at 18:34 +0300, Denys Fedoryshchenko wrote:
> > >> Well, probably i am answering my own question, removing estimator from
> > >> classes seems drastically improve situation.
> > >> It seems estimator has some issues that cause shaper to behave
> > >> incorrectly (throttling traffic while it should not).
> > >> But i guess thats a bug?
> > >> As i was not able to predict such bottleneck by CPU load measurements.
> > >
> > > Well, there was a reason we disabled HTB class estimators by default ;)
> > >
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=64153ce0a7b61b2a5cacb01805cbf670142339e9
> >
> > As soon as disabling it solve my problem - i'm fine, hehe, but i guess
> > other people who might hit this problem, should be aware how to find
> > reason.
> > They should not be disappointed in Linux :)
>
> Well, if they enable rate estimators while kernel does not set them by
> default, they get what they want, at a cost.
>
> > Because i can't measure this bottleneck before it happens, i'm seeing on
> > mpstat all cpu's are idle, and same time traffic is throttled.
>
> Normally things were supposed to get much better in linux-4.10
>
> ( https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=1c0d32fde5bdf1184bc274f864c09799278a1114 )
>
> But I apparently added a scaling bug.
>
> I will try :
>
> diff --git a/net/core/gen_estimator.c b/net/core/gen_estimator.c
> index 0385dece1f6fe5e26df1ce5f40956a79a2eebbf4..7c1ffd6f950172c1915d8e5fa2b5e3f77e4f4c78 100644
> --- a/net/core/gen_estimator.c
> +++ b/net/core/gen_estimator.c
> @@ -83,10 +83,10 @@ static void est_timer(unsigned long arg)
> u64 rate, brate;
>
> est_fetch_counters(est, &b);
> - brate = (b.bytes - est->last_bytes) << (8 - est->ewma_log);
> + brate = (b.bytes - est->last_bytes) << (10 - est->ewma_log - est->intvl_log);
> brate -= (est->avbps >> est->ewma_log);
>
> - rate = (u64)(b.packets - est->last_packets) << (8 - est->ewma_log);
> + rate = (u64)(b.packets - est->last_packets) << (10 - est->ewma_log - est->intvl_log);
> rate -= (est->avpps >> est->ewma_log);
>
> write_seqcount_begin(&est->seq);
Much better indeed
# tc -s -d class sh dev eth0 classid 7002:11 ; sleep 10 ;tc -s -d class
sh dev eth0 classid 7002:11
class htb 7002:11 parent 7002:1 prio 5 quantum 200000 rate 5Gbit ceil
5Gbit linklayer ethernet burst 80000b/1 mpu 0b cburst 80000b/1 mpu 0b
level 0 rate_handle 1
Sent 389085117074 bytes 256991500 pkt (dropped 0, overlimits 5926926
requeues 0)
rate 4999Mbit 412762pps backlog 136260b 2p requeues 0
TCP pkts/rtx 256991584/0 bytes 389085252840/0
lended: 5961250 borrowed: 0 giants: 0
tokens: -1664 ctokens: -1664
class htb 7002:11 parent 7002:1 prio 5 quantum 200000 rate 5Gbit ceil
5Gbit linklayer ethernet burst 80000b/1 mpu 0b cburst 80000b/1 mpu 0b
level 0 rate_handle 1
Sent 395336315580 bytes 261120429 pkt (dropped 0, overlimits 6021776
requeues 0)
rate 4999Mbit 412788pps backlog 68Kb 2p requeues 0
TCP pkts/rtx 261120469/0 bytes 395336384730/0
lended: 6056793 borrowed: 0 giants: 0
tokens: -1478 ctokens: -1478
echo "(395336315580-389085117074)/10*8" | bc
5000958800
^ permalink raw reply
* Re: [PATCH net 0/3] nfp: wait more carefully for card init
From: Jakub Kicinski @ 2017-09-13 16:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev, oss-drivers
In-Reply-To: <20170913.093902.570914704132982694.davem@davemloft.net>
On Wed, 13 Sep 2017 09:39:02 -0700 (PDT), David Miller wrote:
> From: Jakub Kicinski <jakub.kicinski@netronome.com>
> Date: Wed, 13 Sep 2017 08:51:28 -0700
>
> > The first patch is a small fix for flower offload, we need a whitelist
> > of supported matches, otherwise the unsupported ones will be ignored.
> >
> > The second and the third patch are adding wait/polling to the probe path.
> > We had reports of driver failing probe because it couldn't find the
> > control process (NSP) on the card. Turns out the NSP will only announce
> > its existence after it's fully initialized. Until now we assumed it
> > will be reachable, just not processing commands (hence we wait for
> > a NOOP command to execute successfully).
>
> Please build test your changes and look at what the compiler says:
>
> drivers/net/ethernet/netronome/nfp/nfp_main.c: In function ‘nfp_fw_unload’:
> drivers/net/ethernet/netronome/nfp/nfp_main.c:395:10: warning: ‘return’ with a value, in function returning void
> return err;
> ^~~
> drivers/net/ethernet/netronome/nfp/nfp_main.c:388:13: note: declared here
> static void nfp_fw_unload(struct nfp_pf *pf)
> ^~~~~~~~~~~~~
Sorry about that!
^ permalink raw reply
* Re: Memory leaks in conntrack
From: Cong Wang @ 2017-09-13 16:45 UTC (permalink / raw)
To: Florian Westphal; +Cc: netfilter-devel, Linux Kernel Network Developers
In-Reply-To: <20170913080516.GD25977@breakpoint.cc>
On Wed, Sep 13, 2017 at 1:05 AM, Florian Westphal <fw@strlen.de> wrote:
> Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> 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
>>
>> 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.
>
> You probably do, can you try "cat /proc/net/nf_conntrack" instead?
>
> (otherwise there should be no ipv4_conntrack_local() invocation
> since we would not register this hook at all).
Yeah it is very weird but it is true:
[root@localhost ~]# echo scan > /sys/kernel/debug/kmemleak
[ 133.450823] kmemleak: 18 new suspected memory leaks (see
/sys/kernel/debug/kmemleak)
[root@localhost ~]# cat /proc/net/ip_conntrack
cat: /proc/net/ip_conntrack: No such file or directory
[root@localhost ~]# cat /sys/kernel/debug/kmemleak
unreferenced object 0xffff95c1e0b24040 (size 336):
...
>
> I tried to reproduce this but so far I had no success.
> If you can identify something that could give a hint when this
> is happening (only once after boot, periodically, only with udp, etc)
> please let us know.
>
> (A reproducer would be even better of course ;-) )
Actually, it is even simpler to reproduce, nothing is needed
but wait. I thought it is somewhat triggered by my tests, but
actually no. For me, just boot the VM and wait for several
seconds, memleak will show up.
(chronyd is started by systemd during boot, not me.)
>
> Is this with current net tree?
Yes, I just pulled DaveM's net tree and recompiled the kernel,
still 100% reproducible here.
^ permalink raw reply
* Re: HTB going crazy over ~5Gbit/s (4.12.9, but problem present in older kernels as well)
From: Eric Dumazet @ 2017-09-13 16:42 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: Linux Kernel Network Developers
In-Reply-To: <9b8cdc2b39fdd2d0be7b5f559b2034e7@nuclearcat.com>
On Wed, 2017-09-13 at 19:27 +0300, Denys Fedoryshchenko wrote:
> On 2017-09-13 19:16, Eric Dumazet wrote:
> > On Wed, 2017-09-13 at 18:34 +0300, Denys Fedoryshchenko wrote:
> >> Well, probably i am answering my own question, removing estimator from
> >> classes seems drastically improve situation.
> >> It seems estimator has some issues that cause shaper to behave
> >> incorrectly (throttling traffic while it should not).
> >> But i guess thats a bug?
> >> As i was not able to predict such bottleneck by CPU load measurements.
> >
> > Well, there was a reason we disabled HTB class estimators by default ;)
> >
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=64153ce0a7b61b2a5cacb01805cbf670142339e9
>
> As soon as disabling it solve my problem - i'm fine, hehe, but i guess
> other people who might hit this problem, should be aware how to find
> reason.
> They should not be disappointed in Linux :)
Well, if they enable rate estimators while kernel does not set them by
default, they get what they want, at a cost.
> Because i can't measure this bottleneck before it happens, i'm seeing on
> mpstat all cpu's are idle, and same time traffic is throttled.
Normally things were supposed to get much better in linux-4.10
( https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=1c0d32fde5bdf1184bc274f864c09799278a1114 )
But I apparently added a scaling bug.
I will try :
diff --git a/net/core/gen_estimator.c b/net/core/gen_estimator.c
index 0385dece1f6fe5e26df1ce5f40956a79a2eebbf4..7c1ffd6f950172c1915d8e5fa2b5e3f77e4f4c78 100644
--- a/net/core/gen_estimator.c
+++ b/net/core/gen_estimator.c
@@ -83,10 +83,10 @@ static void est_timer(unsigned long arg)
u64 rate, brate;
est_fetch_counters(est, &b);
- brate = (b.bytes - est->last_bytes) << (8 - est->ewma_log);
+ brate = (b.bytes - est->last_bytes) << (10 - est->ewma_log - est->intvl_log);
brate -= (est->avbps >> est->ewma_log);
- rate = (u64)(b.packets - est->last_packets) << (8 - est->ewma_log);
+ rate = (u64)(b.packets - est->last_packets) << (10 - est->ewma_log - est->intvl_log);
rate -= (est->avpps >> est->ewma_log);
write_seqcount_begin(&est->seq);
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
^ permalink raw reply related
* Re: [PATCH net 0/3] nfp: wait more carefully for card init
From: David Miller @ 2017-09-13 16:39 UTC (permalink / raw)
To: jakub.kicinski; +Cc: netdev, oss-drivers
In-Reply-To: <20170913155131.18090-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Wed, 13 Sep 2017 08:51:28 -0700
> The first patch is a small fix for flower offload, we need a whitelist
> of supported matches, otherwise the unsupported ones will be ignored.
>
> The second and the third patch are adding wait/polling to the probe path.
> We had reports of driver failing probe because it couldn't find the
> control process (NSP) on the card. Turns out the NSP will only announce
> its existence after it's fully initialized. Until now we assumed it
> will be reachable, just not processing commands (hence we wait for
> a NOOP command to execute successfully).
Please build test your changes and look at what the compiler says:
drivers/net/ethernet/netronome/nfp/nfp_main.c: In function ‘nfp_fw_unload’:
drivers/net/ethernet/netronome/nfp/nfp_main.c:395:10: warning: ‘return’ with a value, in function returning void
return err;
^~~
drivers/net/ethernet/netronome/nfp/nfp_main.c:388:13: note: declared here
static void nfp_fw_unload(struct nfp_pf *pf)
^~~~~~~~~~~~~
^ permalink raw reply
* Re: [patch net] net: sched: fix use-after-free in tcf_action_destroy and tcf_del_walker
From: David Miller @ 2017-09-13 16:34 UTC (permalink / raw)
To: jiri; +Cc: netdev, jhs, xiyou.wangcong, kubakici, mlxsw
In-Reply-To: <20170913153237.26408-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Wed, 13 Sep 2017 17:32:37 +0200
> From: Jiri Pirko <jiri@mellanox.com>
>
> Recent commit d7fb60b9cafb ("net_sched: get rid of tcfa_rcu") removed
> freeing in call_rcu, which changed already existing hard-to-hit
> race condition into 100% hit:
>
> [ 598.599825] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
> [ 598.607782] IP: tcf_action_destroy+0xc0/0x140
>
> Or:
>
> [ 40.858924] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
> [ 40.862840] IP: tcf_generic_walker+0x534/0x820
>
> Fix this by storing the ops and use them directly for module_put call.
>
> Fixes: a85a970af265 ("net_sched: move tc_action into tcf_common")
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCH net] be2net: fix TSO6/GSO issue causing TX-stall on Lancer/BEx
From: David Miller @ 2017-09-13 16:33 UTC (permalink / raw)
To: suresh.reddy; +Cc: netdev
In-Reply-To: <20170913151242.16303-1-suresh.reddy@broadcom.com>
From: Suresh Reddy <suresh.reddy@broadcom.com>
Date: Wed, 13 Sep 2017 11:12:42 -0400
> IPv6 TSO requests with extension hdrs are a problem to the
> Lancer and BEx chips. Workaround is to disable TSO6 feature
> for such packets.
>
> Also in Lancer chips, MSS less than 256 was resulting in TX stall.
> Fix this by disabling GSO when MSS less than 256.
>
> Signed-off-by: Suresh Reddy <suresh.reddy@broadcom.com>
Applied.
^ permalink raw reply
* Re: HTB going crazy over ~5Gbit/s (4.12.9, but problem present in older kernels as well)
From: Denys Fedoryshchenko @ 2017-09-13 16:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Kernel Network Developers
In-Reply-To: <1505319370.15310.169.camel@edumazet-glaptop3.roam.corp.google.com>
On 2017-09-13 19:16, Eric Dumazet wrote:
> On Wed, 2017-09-13 at 18:34 +0300, Denys Fedoryshchenko wrote:
>> Well, probably i am answering my own question, removing estimator from
>> classes seems drastically improve situation.
>> It seems estimator has some issues that cause shaper to behave
>> incorrectly (throttling traffic while it should not).
>> But i guess thats a bug?
>> As i was not able to predict such bottleneck by CPU load measurements.
>
> Well, there was a reason we disabled HTB class estimators by default ;)
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=64153ce0a7b61b2a5cacb01805cbf670142339e9
As soon as disabling it solve my problem - i'm fine, hehe, but i guess
other people who might hit this problem, should be aware how to find
reason.
They should not be disappointed in Linux :)
Because i can't measure this bottleneck before it happens, i'm seeing on
mpstat all cpu's are idle, and same time traffic is throttled.
^ permalink raw reply
* Re: [PATCH net] sctp: potential read out of bounds in sctp_ulpevent_type_enabled()
From: David Miller @ 2017-09-13 16:25 UTC (permalink / raw)
To: dan.carpenter; +Cc: vyasevich, nhorman, linux-sctp, netdev, kernel-janitors
In-Reply-To: <20170913092028.idzvduj7ran4li6b@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 13 Sep 2017 12:20:28 +0300
> @@ -154,7 +154,11 @@ static inline int sctp_ulpevent_type_enabled(__u16 sn_type,
> struct sctp_event_subscribe *mask)
> {
> char *amask = (char *) mask;
> - return amask[sn_type - SCTP_SN_TYPE_BASE];
> + int offset = sn_type - SCTP_SN_TYPE_BASE;
Please use reverse-christmas-tree local variable ordering.
Thank you.
^ 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