* 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
* Re: [PATCH 06/10] drivers:ethernet: return -ENOMEM on allocation failure.
From: David Miller @ 2017-09-13 16:20 UTC (permalink / raw)
To: allen.lkml
Cc: linux-kernel, nouveau, linux-crypto, dri-devel,
MPT-FusionLinux.pdl, linux-scsi, netdev, megaraidlinux.pdl,
target-devel, linux-fbdev, linux-btrfs
In-Reply-To: <1505287939-14106-6-git-send-email-allen.lkml@gmail.com>
From: Allen Pais <allen.lkml@gmail.com>
Date: Wed, 13 Sep 2017 13:02:15 +0530
> Signed-off-by: Allen Pais <allen.lkml@gmail.com>
This is quite pointless as the caller doesn't do anything with
the value, it just tests whether a negative value is returned
or not.
^ 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:16 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: Linux Kernel Network Developers
In-Reply-To: <d2aee52fda21d8f668ca012333ef3677@nuclearcat.com>
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
^ permalink raw reply
* Re: [PATCH] dt-bindings: net: renesas-ravb: Add support for R8A77995 RAVB
From: Sergei Shtylyov @ 2017-09-13 16:08 UTC (permalink / raw)
To: Yoshihiro Shimoda, davem, robh+dt, mark.rutland
Cc: netdev, linux-renesas-soc, devicetree
In-Reply-To: <1f4763ea-9f8a-03a6-1215-69b96c404590@cogentembedded.com>
On 09/13/2017 07:02 PM, Sergei Shtylyov wrote:
>> Add a new compatible string for the R8A77995 (R-Car D3) RAVB.
>>
>> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>> ---
>> Documentation/devicetree/bindings/net/renesas,ravb.txt | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt
>> b/Documentation/devicetree/bindings/net/renesas,ravb.txt
>> index 1672353..ae2213f 100644
>> --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt
>> +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt
>> @@ -17,6 +17,7 @@ Required properties:
>> - "renesas,etheravb-r8a7795" for the R8A7795 SoC.
>> - "renesas,etheravb-r8a7796" for the R8A7796 SoC.
>> + - "renesas,etheravb-r8a77995" for the R8A77995 SoC.
>
> That would conflict with the R8A77970 bindings patch posted by me
> yesterday. Please respin atop of it.
Here's the link for your convenience:
https://marc.info/?l=linux-renesas-soc&m=150524655515476
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] dt-bindings: net: renesas-ravb: Add support for R8A77995 RAVB
From: Sergei Shtylyov @ 2017-09-13 16:02 UTC (permalink / raw)
To: Yoshihiro Shimoda, davem, robh+dt, mark.rutland
Cc: netdev, linux-renesas-soc, devicetree
In-Reply-To: <1505305060-4192-1-git-send-email-yoshihiro.shimoda.uh@renesas.com>
Hello!
On 09/13/2017 03:17 PM, Yoshihiro Shimoda wrote:
> Add a new compatible string for the R8A77995 (R-Car D3) RAVB.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> ---
> Documentation/devicetree/bindings/net/renesas,ravb.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt b/Documentation/devicetree/bindings/net/renesas,ravb.txt
> index 1672353..ae2213f 100644
> --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt
> +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt
> @@ -17,6 +17,7 @@ Required properties:
>
> - "renesas,etheravb-r8a7795" for the R8A7795 SoC.
> - "renesas,etheravb-r8a7796" for the R8A7796 SoC.
> + - "renesas,etheravb-r8a77995" for the R8A77995 SoC.
That would conflict with the R8A77970 bindings patch posted by me
yesterday. Please respin atop of it.
> - "renesas,etheravb-rcar-gen3" as a fallback for the above
> R-Car Gen3 devices.
>
One more fragment is needed here, about the mandatory 'interrupt-names"
prop. My patch makes this change unnecessary, however...
MBR, Sergei
^ 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 15:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Kernel Network Developers, netdev-owner
In-Reply-To: <1505317903.15310.167.camel@edumazet-glaptop3.roam.corp.google.com>
On 2017-09-13 18:51, Eric Dumazet wrote:
> On Wed, 2017-09-13 at 18:20 +0300, Denys Fedoryshchenko wrote:
>> Hi,
>>
>> I noticed after increasing bandwidth over some amount HTB started to
>> throttle classes it should not throttle.
>> Also estimated rate in htb totally wrong, while byte counters is
>> correct.
>>
>> Is there any overflow or something?
>
> Thanks Denys for the report, I will take a look at this, since I
> probably introduced some regression.
It's definitely not something recent, this system was on older kernel
with uptime over 200 days, and this bottleneck was present, i noticed it
long time before.
But never tried to remove estimators (increasing burst/cburst to insane
values saved me for a while).
^ permalink raw reply
* [PATCH net 3/3] nfp: wait for the NSP resource to appear on boot
From: Jakub Kicinski @ 2017-09-13 15:51 UTC (permalink / raw)
To: netdev; +Cc: oss-drivers, Jakub Kicinski
In-Reply-To: <20170913155131.18090-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>
Reviewed-by: Simon Horman <simon.horman@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..1c17b261a21c 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_main.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_main.c
@@ -390,6 +390,10 @@ static void nfp_fw_unload(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)) {
nfp_err(pf->cpp, "Reset failed, can't open NSP\n");
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
* Re: HTB going crazy over ~5Gbit/s (4.12.9, but problem present in older kernels as well)
From: Eric Dumazet @ 2017-09-13 15:51 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: Linux Kernel Network Developers
In-Reply-To: <4cd23914d8cc2cf5caf78cb5654fb245@nuclearcat.com>
On Wed, 2017-09-13 at 18:20 +0300, Denys Fedoryshchenko wrote:
> Hi,
>
> I noticed after increasing bandwidth over some amount HTB started to
> throttle classes it should not throttle.
> Also estimated rate in htb totally wrong, while byte counters is
> correct.
>
> Is there any overflow or something?
Thanks Denys for the report, I will take a look at this, since I
probably introduced some regression.
^ permalink raw reply
* [PATCH net 2/3] nfp: wait for board state before talking to the NSP
From: Jakub Kicinski @ 2017-09-13 15:51 UTC (permalink / raw)
To: netdev; +Cc: oss-drivers, Jakub Kicinski
In-Reply-To: <20170913155131.18090-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>
Reviewed-by: Simon Horman <simon.horman@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 1/3] nfp: add whitelist of supported flow dissector
From: Jakub Kicinski @ 2017-09-13 15:51 UTC (permalink / raw)
To: netdev; +Cc: oss-drivers, Pieter Jansen van Vuuren
In-Reply-To: <20170913155131.18090-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 0/3] nfp: wait more carefully for card init
From: Jakub Kicinski @ 2017-09-13 15:51 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).
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
* Re: 319554f284dd ("inet: don't use sk_v6_rcv_saddr directly") causes bind port regression
From: Laura Abbott @ 2017-09-13 15:44 UTC (permalink / raw)
To: Josef Bacik, David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Cole Robinson
In-Reply-To: <AF16C126-99CA-401A-B803-AA05CDFBFF93@fb.com>
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
^ permalink raw reply
* Re: Memory leaks in conntrack
From: Florian Westphal @ 2017-09-13 15:37 UTC (permalink / raw)
To: Florian Westphal
Cc: Cong Wang, netfilter-devel, Linux Kernel Network Developers
In-Reply-To: <20170913080516.GD25977@breakpoint.cc>
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).
>
> 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.
FWIW i managed to obtain a similar backtrace, but in that case it was a
false positive (peeking at the address content showed it was my ssh connection
to the vm and timeout and tcp conntrackk struct fields were changing;
i.e. the nf_conn reported was still in the conntrack hash.
Why this address was reported i do not know, afaik kmemleak
does scan for addresses anywhere in the object (we use
container_of() to get back nf_conn from the hlist_node), so it
should have found the address linked via the main conntrack hash table.
Right now I don't have enough info to dig any further, sorry :-/
^ permalink raw reply
* Re: netfilter: xt_bpf: ABI issue in xt_bpf_info_v1?
From: Willem de Bruijn @ 2017-09-13 15:35 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Shmulik Ladkani, netfilter-devel, Pablo Neira Ayuso,
Network Development, Willem de Bruijn, Rafael Buchbinder,
Shmulik Ladkani, eyal
In-Reply-To: <CAF=yD-LUCCLSXuPNKPgEY695ej+T-2s=zhmw6CJwK6tFyY+_dg@mail.gmail.com>
On Wed, Sep 13, 2017 at 11:05 AM, Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
> On Wed, Sep 13, 2017 at 10:22 AM, Jan Engelhardt <jengelh@inai.de> wrote:
>>
>> On Wednesday 2017-09-13 15:24, Shmulik Ladkani wrote:
>>>
>>>One way to fix is to have iptables open the object (using the stored
>>>xt_bpf_info_v1->path), gaining a new process local fd for the object,
>>>just after getting the rules from IPT_SO_GET_ENTRIES.
>>>However we didn't see any other extensions doing something like that in
>>>iptables.
>
> The binary should call bpf_obj_get on the filepath each time. These are
> not regular files, but references to a pinned object in the bpf filesystem.
>
> Blindly passing back the fd received from the kernel is clearly wrong. I'm
> really surprised that I did not run into this problem when I wrote the
> feature.
>
>>>
>>>Another way to solve is to fix the ABI (or have a v2 one), that does NOT
>>>pass the fd from userspace, only the path of the pinned object.
>>>Then, 'bpf_mt_check_v1' will open the file from the given path in order
>>>to get the bpf_prog.
>>
>> But a path has a similar problem like a file descriptor - it is local to a
>> certain mount namespace.
>
> Because these are pinned objects in the bpf filesystem, and there is
> only one of those, it may be possible to lookup the object in the kernel
> without relying on a process-local view of mount points.
It would be preferable to fix this for the existing v1 users as well.
That said, the new bpf identifier feature allows passing a globally
unique id instead of a filepath.
>
>>
>> To load "large" blobs into the kernel, a pointer to user memory is a possible
>> option. The downside is that such extra data is not retrievable from the kernel
>> via the iptables setsockopts anymore - one could work around it with procfs, or
>> just let it be.
>>
>> https://sourceforge.net/p/xtables-addons/xtables-addons/ci/master/tree/extensions/xt_geoip.c
>> line 64+.
^ 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