* Re: [PATCH] bpf: devmap: Check attr->max_entries more carefully
From: Daniel Borkmann @ 2017-10-17 10:32 UTC (permalink / raw)
To: Mark Rutland
Cc: Richard Weinberger, netdev, linux-kernel, ast, sp3485, tj,
john.fastabend
In-Reply-To: <20171017102935.5i4dqa7h44v4acft@lakrids.cambridge.arm.com>
On 10/17/2017 12:29 PM, Mark Rutland wrote:
> On Mon, Oct 16, 2017 at 08:52:13PM +0200, Daniel Borkmann wrote:
>> [ +Tejun, Mark, John ]
>>
>> On 10/16/2017 12:00 AM, Richard Weinberger wrote:
>>> max_entries is user controlled and used as input for __alloc_percpu().
>>> This function expects that the allocation size is a power of two and
>>> less than PCPU_MIN_UNIT_SIZE.
>>> Otherwise a WARN() is triggered.
>>>
>>> Fixes: 11393cc9b9be ("xdp: Add batching support to redirect map")
>>> Reported-by: Shankara Pailoor <sp3485@columbia.edu>
>>> Reported-by: syzkaller <syzkaller@googlegroups.com>
>>> Signed-off-by: Richard Weinberger <richard@nod.at>
>>
>> Thanks for the patch, Richard. There was a prior discussion here [1] on
>> the same issue, I thought this would have been resolved by now, but looks
>> like it's still open and there was never a follow-up, at least I don't see
>> it in the percpu tree if I didn't miss anything.
>
> Sorry, this was on my todo list, but I've been bogged down with some
> other work.
Ok, no problem.
>> I would suggest, we do the following below and pass __GFP_NOWARN from BPF
>> side to the per-cpu allocs. This is kind of a generic 'issue' and we shouldn't
>> add more code which bails out anyway just to work around the WARN(). Lets
>> handle it properly instead.
>
> Agreed. The below patch looks good to me, (with the suggested change to
> the BPF side).
>
>> If Tejun is fine with the one below, I could cook and official patch and
>> cleanup the remaining call-sites from BPF which have similar pattern.
>
> That would be great; thanks for taking this on.
I'll prepare a set including BPF side for today.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH net 0/3] bonding: void calling rtmsg_ifinfo for netlink notifications
From: Jiri Pirko @ 2017-10-17 10:38 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, davem
In-Reply-To: <CADvbK_c7R2OJNq=DyXOCSNVzD2aU2qxBO6UiitGbCYS=icwxTQ@mail.gmail.com>
Tue, Oct 17, 2017 at 12:28:45PM CEST, lucien.xin@gmail.com wrote:
>On Tue, Oct 17, 2017 at 5:59 PM, Jiri Pirko <jiri@resnulli.us> wrote:
>> Tue, Oct 17, 2017 at 11:39:38AM CEST, lucien.xin@gmail.com wrote:
>>>It's better to send notifications to userspace by the events
>>>in rtnetlink_event, instead of calling rtmsg_ifinfo directly.
>>>
>>>This patcheset is to remove rtmsg_ifinfo called in bonding,
>>>the notifications can be handled by NETDEV_CHANGEUPPER and
>>>NETDEV_CHANGELOWERSTATE events in rtnetlink_event.
>>>
>>>It could also fix some redundant notifications from bonding.
>>
>> This should go to net-next.
>
>NETDEV_CHANGEUPPER is not yet in rtnetlink_event in net-next tree.
>patches can only work on net tree by now.
>
>Hi, David, you want me to hold them until the patches for NETDEV_CHANGEUPPER
>are copied to net-next, or you would apply them to net ?
This patchset is not fix right? I see no "Fixes" line. You should wait
until the dependency is merged to net-next, rebase, post for net-next.
>
>>
>>
>>>
>>>Xin Long (3):
>>> bonding: remove rtmsg_ifinfo called in bond_master_upper_dev_link
>>> rtnetlink: bring NETDEV_CHANGELOWERSTATE event process back to
>>> rtnetlink_event
>>> bonding: remove rtmsg_ifinfo called after bond_lower_state_changed
>>>
>>> drivers/net/bonding/bond_main.c | 11 +++--------
>>> include/net/bonding.h | 4 ----
>>> net/core/rtnetlink.c | 2 +-
>>> 3 files changed, 4 insertions(+), 13 deletions(-)
>>>
>>>--
>>>2.1.0
>>>
^ permalink raw reply
* linux-next: net/sched/sch_mqprio.c
From: Mark Brown @ 2017-10-17 10:43 UTC (permalink / raw)
To: David Miller, Networking, Jesus Sanchez-Palencia, Alexander Duyck
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 578 bytes --]
Hi all,
After merging the net-next tree, today's linux-next build (KCONFIG_NAME)
failed like this:
ERROR: "netdev_txq_to_tc" [net/sched/sch_mqprio.ko] undefined!
/home/broonie/tmpfs/next/scripts/Makefile.modpost:91: recipe for target '__modpo
st' failed
Caused by commit
32302902ff093 ("mqprio: Reserve last 32 classid values for HW traffic classes and misc IDs")
which adds a user of that function in a module but that function is not
exported. As noted on the previous report reverting to a previous
net-next caused other errors so I've reverted that specific commit.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [net-next V8 PATCH 1/5] bpf: introduce new bpf cpu map type BPF_MAP_TYPE_CPUMAP
From: Jesper Dangaard Brouer @ 2017-10-17 10:47 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: netdev, jakub.kicinski, Michael S. Tsirkin, pavel.odintsov,
Jason Wang, mchan, John Fastabend, peter.waskiewicz.jr, ast,
Daniel Borkmann, Andy Gospodarek, brouer
In-Reply-To: <20171016214951.bia3esapu5o2niva@ast-mbp.dhcp.thefacebook.com>
On Mon, 16 Oct 2017 14:49:53 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> On Mon, Oct 16, 2017 at 12:19:28PM +0200, Jesper Dangaard Brouer wrote:
> > The 'cpumap' is primarily used as a backend map for XDP BPF helper
> > call bpf_redirect_map() and XDP_REDIRECT action, like 'devmap'.
> >
> > This patch implement the main part of the map. It is not connected to
> > the XDP redirect system yet, and no SKB allocation are done yet.
> >
> > The main concern in this patch is to ensure the datapath can run
> > without any locking. This adds complexity to the setup and tear-down
> > procedure, which assumptions are extra carefully documented in the
> > code comments.
> >
> > V2:
> > - make sure array isn't larger than NR_CPUS
> > - make sure CPUs added is a valid possible CPU
> >
> > V3: fix nitpicks from Jakub Kicinski <kubakici@wp.pl>
> >
> > V5:
> > - Restrict map allocation to root / CAP_SYS_ADMIN
> > - WARN_ON_ONCE if queue is not empty on tear-down
> > - Return -EPERM on memlock limit instead of -ENOMEM
> > - Error code in __cpu_map_entry_alloc() also handle ptr_ring_cleanup()
> > - Moved cpu_map_enqueue() to next patch
> >
> > V6: all notice by Daniel Borkmann
> > - Fix err return code in cpu_map_alloc() introduced in V5
> > - Move cpu_possible() check after max_entries boundary check
> > - Forbid usage initially in check_map_func_compatibility()
> >
> > V7:
> > - Fix alloc error path spotted by Daniel Borkmann
> > - Did stress test adding+removing CPUs from the map concurrently
> > - Fixed refcnt issue on cpu_map_entry, kthread started too soon
> > - Make sure packets are flushed during tear-down, involved use of
> > rcu_barrier() and kthread_run only exit after queue is empty
> > - Fix alloc error path in __cpu_map_entry_alloc() for ptr_ring
> >
> > V8:
> > - Nitpicking comments and gramma by Edward Cree
> > - Fix missing semi-colon introduced in V7 due to rebasing
> > - Move struct bpf_cpu_map_entry members cpu+map_id to tracepoint patch
> >
> > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> > ---
> > include/linux/bpf_types.h | 1
> > include/uapi/linux/bpf.h | 1
> > kernel/bpf/Makefile | 1
> > kernel/bpf/cpumap.c | 560 ++++++++++++++++++++++++++++++++++++++++
> > kernel/bpf/syscall.c | 8 +
> > kernel/bpf/verifier.c | 5
> > tools/include/uapi/linux/bpf.h | 1
> > 7 files changed, 576 insertions(+), 1 deletion(-)
> > create mode 100644 kernel/bpf/cpumap.c
>
> Looks good to me
> I like the idea of running networking stack from kthread
> and hope adding GRO won't change the api.
> Acked-by: Alexei Starovoitov <ast@kernel.org>
Thanks!
I think adding GRO is still safe API-wise after this patchset. I
imagine that the GRO API will be tied to how we implement/expose the
RX-hash to the eBPF program. Thus, the API will be the eBPF prog can
change the RX-hash, to influence the GRO aggregation/partial-sort. If
the map need to behave differently for GRO then we have the map_flags
to adjust this behavior (but I assume this would not be needed).
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net 0/3] bonding: void calling rtmsg_ifinfo for netlink notifications
From: Xin Long @ 2017-10-17 10:48 UTC (permalink / raw)
To: Jiri Pirko; +Cc: network dev, davem
In-Reply-To: <20171017103806.GG2112@nanopsycho>
On Tue, Oct 17, 2017 at 6:38 PM, Jiri Pirko <jiri@resnulli.us> wrote:
> Tue, Oct 17, 2017 at 12:28:45PM CEST, lucien.xin@gmail.com wrote:
>>On Tue, Oct 17, 2017 at 5:59 PM, Jiri Pirko <jiri@resnulli.us> wrote:
>>> Tue, Oct 17, 2017 at 11:39:38AM CEST, lucien.xin@gmail.com wrote:
>>>>It's better to send notifications to userspace by the events
>>>>in rtnetlink_event, instead of calling rtmsg_ifinfo directly.
>>>>
>>>>This patcheset is to remove rtmsg_ifinfo called in bonding,
>>>>the notifications can be handled by NETDEV_CHANGEUPPER and
>>>>NETDEV_CHANGELOWERSTATE events in rtnetlink_event.
>>>>
>>>>It could also fix some redundant notifications from bonding.
>>>
>>> This should go to net-next.
>>
>>NETDEV_CHANGEUPPER is not yet in rtnetlink_event in net-next tree.
>>patches can only work on net tree by now.
>>
>>Hi, David, you want me to hold them until the patches for NETDEV_CHANGEUPPER
>>are copied to net-next, or you would apply them to net ?
>
> This patchset is not fix right? I see no "Fixes" line. You should wait
> until the dependency is merged to net-next, rebase, post for net-next.
Copy, thanks Jiri.
>
>
>
>>
>>>
>>>
>>>>
>>>>Xin Long (3):
>>>> bonding: remove rtmsg_ifinfo called in bond_master_upper_dev_link
>>>> rtnetlink: bring NETDEV_CHANGELOWERSTATE event process back to
>>>> rtnetlink_event
>>>> bonding: remove rtmsg_ifinfo called after bond_lower_state_changed
>>>>
>>>> drivers/net/bonding/bond_main.c | 11 +++--------
>>>> include/net/bonding.h | 4 ----
>>>> net/core/rtnetlink.c | 2 +-
>>>> 3 files changed, 4 insertions(+), 13 deletions(-)
>>>>
>>>>--
>>>>2.1.0
>>>>
^ permalink raw reply
* Re: [PATCH v9 17/20] crypto: talitos: move to generic async completion
From: Christophe LEROY @ 2017-10-17 10:50 UTC (permalink / raw)
To: Gilad Ben-Yossef, Herbert Xu, David S. Miller, Jonathan Corbet,
David Howells, Tom Lendacky, Gary Hook, Boris Brezillon,
Arnaud Ebalard, Matthias Brugger, Alasdair Kergon, Mike Snitzer,
dm-devel, Steve French, Theodore Y. Ts'o, Jaegeuk Kim,
Steffen Klassert, Alexey Kuznetsov, Hideaki YOSHIFUJI, Mimi Zohar
Cc: Ofir Drang, linux-crypto, linux-doc, linux-kernel, keyrings,
linux-arm-kernel, linux-mediatek, linux-cifs, samba-technical,
linux-fscrypt, netdev, linux-ima-devel, linux-ima-user,
linux-security-module
In-Reply-To: <1508059209-25529-18-git-send-email-gilad@benyossef.com>
Le 15/10/2017 à 11:20, Gilad Ben-Yossef a écrit :
> The talitos driver starts several async crypto ops and waits for their
> completions. Move it over to generic code doing the same.
>
> Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
Tested-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> drivers/crypto/talitos.c | 38 +++++---------------------------------
> 1 file changed, 5 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
> index 5bd8191..9c80e0c 100644
> --- a/drivers/crypto/talitos.c
> +++ b/drivers/crypto/talitos.c
> @@ -2160,22 +2160,6 @@ static int ahash_import(struct ahash_request *areq, const void *in)
> return 0;
> }
>
> -struct keyhash_result {
> - struct completion completion;
> - int err;
> -};
> -
> -static void keyhash_complete(struct crypto_async_request *req, int err)
> -{
> - struct keyhash_result *res = req->data;
> -
> - if (err == -EINPROGRESS)
> - return;
> -
> - res->err = err;
> - complete(&res->completion);
> -}
> -
> static int keyhash(struct crypto_ahash *tfm, const u8 *key, unsigned int keylen,
> u8 *hash)
> {
> @@ -2183,10 +2167,10 @@ static int keyhash(struct crypto_ahash *tfm, const u8 *key, unsigned int keylen,
>
> struct scatterlist sg[1];
> struct ahash_request *req;
> - struct keyhash_result hresult;
> + struct crypto_wait wait;
> int ret;
>
> - init_completion(&hresult.completion);
> + crypto_init_wait(&wait);
>
> req = ahash_request_alloc(tfm, GFP_KERNEL);
> if (!req)
> @@ -2195,25 +2179,13 @@ static int keyhash(struct crypto_ahash *tfm, const u8 *key, unsigned int keylen,
> /* Keep tfm keylen == 0 during hash of the long key */
> ctx->keylen = 0;
> ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
> - keyhash_complete, &hresult);
> + crypto_req_done, &wait);
>
> sg_init_one(&sg[0], key, keylen);
>
> ahash_request_set_crypt(req, sg, hash, keylen);
> - ret = crypto_ahash_digest(req);
> - switch (ret) {
> - case 0:
> - break;
> - case -EINPROGRESS:
> - case -EBUSY:
> - ret = wait_for_completion_interruptible(
> - &hresult.completion);
> - if (!ret)
> - ret = hresult.err;
> - break;
> - default:
> - break;
> - }
> + ret = crypto_wait_req(crypto_ahash_digest(req), &wait);
> +
> ahash_request_free(req);
>
> return ret;
>
^ permalink raw reply
* Re: Linux 4.12+ memory leak on router with i40e NICs
From: Paweł Staszewski @ 2017-10-17 10:51 UTC (permalink / raw)
To: Alexander Duyck
Cc: Pavlos Parissis, Anders K. Pedersen | Cohaesio,
netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
alexander.h.duyck@intel.com
In-Reply-To: <1704eb26-c4c5-b196-ca7a-5265e92ae4e6@itcare.pl>
W dniu 2017-10-17 o 12:20, Paweł Staszewski pisze:
>
>
> W dniu 2017-10-17 o 11:48, Paweł Staszewski pisze:
>>
>>
>> W dniu 2017-10-17 o 02:44, Paweł Staszewski pisze:
>>>
>>>
>>> W dniu 2017-10-17 o 01:56, Alexander Duyck pisze:
>>>> On Mon, Oct 16, 2017 at 4:34 PM, Paweł Staszewski
>>>> <pstaszewski@itcare.pl> wrote:
>>>>>
>>>>> W dniu 2017-10-16 o 18:26, Paweł Staszewski pisze:
>>>>>
>>>>>>
>>>>>> W dniu 2017-10-16 o 13:20, Pavlos Parissis pisze:
>>>>>>> On 15/10/2017 02:58 πμ, Alexander Duyck wrote:
>>>>>>>> Hi Pawel,
>>>>>>>>
>>>>>>>> To clarify is that Dave Miller's tree or Linus's that you are
>>>>>>>> talking
>>>>>>>> about? If it is Dave's tree how long ago was it you pulled it
>>>>>>>> since I
>>>>>>>> think the fix was just pushed by Jeff Kirsher a few days ago.
>>>>>>>>
>>>>>>>> The issue should be fixed in the following commit:
>>>>>>>>
>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/drivers/net/ethernet/intel/i40e/i40e_txrx.c?id=2b9478ffc550f17c6cd8c69057234e91150f5972
>>>>>>>>
>>>>>>>>
>>>>>>> Do you know when it is going to be available on net-next and
>>>>>>> linux-stable
>>>>>>> repos?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Pavlos
>>>>>>>
>>>>>>>
>>>>>> I will make some tests today night with "net" git tree where this
>>>>>> patch is
>>>>>> included.
>>>>>> Starting from 0:00 CET
>>>>>> :)
>>>>>>
>>>>>>
>>>>> Upgraded and looks like problem is not solved with that patch
>>>>> Currently running system with
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/
>>>>> kernel
>>>>>
>>>>> Still about 0.5GB of memory is leaking somewhere
>>>>>
>>>>> Also can confirm that the latest kernel where memory is not
>>>>> leaking (with
>>>>> use i40e driver intel 710 cards) is 4.11.12
>>>>> With kernel 4.11.12 - after hour no change in memory usage.
>>>>>
>>>>> also checked that with ixgbe instead of i40e with same net.git
>>>>> kernel there
>>>>> is no memleak - after hour same memory usage - so for 100% this is
>>>>> i40e
>>>>> driver problem.
>>>> So how long was the run to get the .5GB of memory leaking?
>>> 1 hour
>>>
>>>>
>>>> Also is there any chance of you being able to bisect to determine
>>>> where the memory leak was introduced since as you pointed out it
>>>> didn't exist in 4.11.12 so odds are it was introduced somewhere
>>>> between 4.11 and the latest kernel release.
>>> Can be hard cause currently need to back to 4.11.12 - this is
>>> production host/router
>>> Will try to find some free/test router for tests/bicects with i40e
>>> driver (intel 710 cards)
>>>
>>>>
>>>> Thanks.
>>>>
>>>> - Alex
>>>>
>>>
>>>
>> Also forgoto to add errors for i40e when driver initialize:
>> [ 15.760569] i40e 0000:02:00.1: Error I40E_AQ_RC_ENOSPC adding RX
>> filters on PF, promiscuous mode forced on
>> [ 16.365587] i40e 0000:03:00.3: Error I40E_AQ_RC_ENOSPC adding RX
>> filters on PF, promiscuous mode forced on
>> [ 16.367686] i40e 0000:02:00.2: Error I40E_AQ_RC_ENOSPC adding RX
>> filters on PF, promiscuous mode forced on
>> [ 16.368816] i40e 0000:03:00.0: Error I40E_AQ_RC_ENOSPC adding RX
>> filters on PF, promiscuous mode forced on
>> [ 16.369877] i40e 0000:03:00.2: Error I40E_AQ_RC_ENOSPC adding RX
>> filters on PF, promiscuous mode forced on
>> [ 16.370941] i40e 0000:02:00.3: Error I40E_AQ_RC_ENOSPC adding RX
>> filters on PF, promiscuous mode forced on
>> [ 16.372005] i40e 0000:02:00.0: Error I40E_AQ_RC_ENOSPC adding RX
>> filters on PF, promiscuous mode forced on
>> [ 16.373029] i40e 0000:03:00.1: Error I40E_AQ_RC_ENOSPC adding RX
>> filters on PF, promiscuous mode forced on
>>
>> some params that are set for this nic's
>> ip link set up dev $i
>> ethtool -A $i autoneg off rx off tx off
>> ethtool -G $i rx 1024 tx 2048
>> ip link set $i txqueuelen 1000
>> ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 512
>> tx-usecs 128
>> ethtool -L $i combined 6
>> #ethtool -N $i rx-flow-hash udp4 sdfn
>> ethtool -K $i ntuple on
>> ethtool -K $i gro off
>> ethtool -K $i tso off
>>
>>
>>
>>
> Also after TSO/GRO on there is memory usage change - and leaking faster
> Below image from memory usage before change with TSO/GRO OFF and after
> enabling TSO/GRO
>
> https://ibb.co/dTqBY6
>
>
> Thanks
> Pawel
>
>
>
With settings like this:
ifc='enp2s0f0 enp2s0f1 enp2s0f2 enp2s0f3 enp3s0f0 enp3s0f1 enp3s0f2
enp3s0f3'
for i in $ifc
do
ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 512
tx-usecs 128
ethtool -K $i gro on
ethtool -K $i tso on
done
Server is leaking about 4-6MB per each 10 seconds
MEMLEAK:
5 MB/10sec
6 MB/10sec
4 MB/10sec
4 MB/10sec
Other settings TSO/GRO off
ifc='enp2s0f0 enp2s0f1 enp2s0f2 enp2s0f3 enp3s0f0 enp3s0f1 enp3s0f2
enp3s0f3'
for i in $ifc
do
ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 512
tx-usecs 128
ethtool -K $i gro off
ethtool -K $i tso off
done
Same leak about 5MB per 10 seconds
MEMLEAK:
5 MB/10sec
5 MB/10sec
5 MB/10sec
Other settings rx-usecs change from 512 to 1024:
ifc='enp2s0f0 enp2s0f1 enp2s0f2 enp2s0f3 enp3s0f0 enp3s0f1 enp3s0f2
enp3s0f3'
for i in $ifc
do
ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 1024
tx-usecs 128
ethtool -K $i gro off
ethtool -K $i tso off
done
MEMLEAK:
4 MB/10sec
3 MB/10sec
4 MB/10sec
4 MB/10sec
So memleak have something to do with rx-usecs (less interrupts but
bigger latency for traffic)
But also enabling TSO/GRO making leak about 1MB bigger for each 10 seconds
^ permalink raw reply
* Re: [PATCH v2 12/15] RDMA/cma: make config_item_type const
From: Leon Romanovsky @ 2017-10-17 10:56 UTC (permalink / raw)
To: Bhumika Goyal
Cc: julia.lawall-L2FTfq7BK8M, rjw-LthD3rsA81gm4RdzfppkhA,
lenb-DgEjT+Ai2ygdnm+yROfE0A,
alexander.shishkin-VuQAYsv1563Yd54FQh9/CA,
jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w, hch-jcswGhMUV9g,
sagi-NQWnxTmZq1alnMjI0IkVqw, kishon-l0cyMroinI0,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, nab-IzHhD5pYlfBP7FQvKIMDCQ,
balbi-DgEjT+Ai2ygdnm+yROfE0A,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
jlbec-aKy9MeLSZ9dg9hUCZPvPmw, ccaulfie-H+wXaHxf7aLQT0dZR+AlfA,
teigland-H+wXaHxf7aLQT0dZR+AlfA, mfasheh-rOS7oXVqrJRBDgjK7y7TUQ,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
target-devel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, cluster-devel
In-Reply-To: <1508167134-6243-13-git-send-email-bhumirks-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 638 bytes --]
On Mon, Oct 16, 2017 at 05:18:51PM +0200, Bhumika Goyal wrote:
> Make these structures const as they are either passed to the functions
> having the argument as const or stored as a reference in the "ci_type"
> const field of a config_item structure.
>
> Signed-off-by: Bhumika Goyal <bhumirks-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> * Changes in v2- Combine all the followup patches and the constification
> patches into a series.
>
> drivers/infiniband/core/cma_configfs.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
Thanks,
Reviewed-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: Linux 4.12+ memory leak on router with i40e NICs
From: Paweł Staszewski @ 2017-10-17 10:59 UTC (permalink / raw)
To: Alexander Duyck
Cc: Pavlos Parissis, Anders K. Pedersen | Cohaesio,
netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
alexander.h.duyck@intel.com
In-Reply-To: <bd82f85a-f9b8-a09a-beab-67667b58f36a@itcare.pl>
W dniu 2017-10-17 o 12:51, Paweł Staszewski pisze:
>
>
> W dniu 2017-10-17 o 12:20, Paweł Staszewski pisze:
>>
>>
>> W dniu 2017-10-17 o 11:48, Paweł Staszewski pisze:
>>>
>>>
>>> W dniu 2017-10-17 o 02:44, Paweł Staszewski pisze:
>>>>
>>>>
>>>> W dniu 2017-10-17 o 01:56, Alexander Duyck pisze:
>>>>> On Mon, Oct 16, 2017 at 4:34 PM, Paweł Staszewski
>>>>> <pstaszewski@itcare.pl> wrote:
>>>>>>
>>>>>> W dniu 2017-10-16 o 18:26, Paweł Staszewski pisze:
>>>>>>
>>>>>>>
>>>>>>> W dniu 2017-10-16 o 13:20, Pavlos Parissis pisze:
>>>>>>>> On 15/10/2017 02:58 πμ, Alexander Duyck wrote:
>>>>>>>>> Hi Pawel,
>>>>>>>>>
>>>>>>>>> To clarify is that Dave Miller's tree or Linus's that you are
>>>>>>>>> talking
>>>>>>>>> about? If it is Dave's tree how long ago was it you pulled it
>>>>>>>>> since I
>>>>>>>>> think the fix was just pushed by Jeff Kirsher a few days ago.
>>>>>>>>>
>>>>>>>>> The issue should be fixed in the following commit:
>>>>>>>>>
>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/drivers/net/ethernet/intel/i40e/i40e_txrx.c?id=2b9478ffc550f17c6cd8c69057234e91150f5972
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Do you know when it is going to be available on net-next and
>>>>>>>> linux-stable
>>>>>>>> repos?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Pavlos
>>>>>>>>
>>>>>>>>
>>>>>>> I will make some tests today night with "net" git tree where
>>>>>>> this patch is
>>>>>>> included.
>>>>>>> Starting from 0:00 CET
>>>>>>> :)
>>>>>>>
>>>>>>>
>>>>>> Upgraded and looks like problem is not solved with that patch
>>>>>> Currently running system with
>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/
>>>>>> kernel
>>>>>>
>>>>>> Still about 0.5GB of memory is leaking somewhere
>>>>>>
>>>>>> Also can confirm that the latest kernel where memory is not
>>>>>> leaking (with
>>>>>> use i40e driver intel 710 cards) is 4.11.12
>>>>>> With kernel 4.11.12 - after hour no change in memory usage.
>>>>>>
>>>>>> also checked that with ixgbe instead of i40e with same net.git
>>>>>> kernel there
>>>>>> is no memleak - after hour same memory usage - so for 100% this
>>>>>> is i40e
>>>>>> driver problem.
>>>>> So how long was the run to get the .5GB of memory leaking?
>>>> 1 hour
>>>>
>>>>>
>>>>> Also is there any chance of you being able to bisect to determine
>>>>> where the memory leak was introduced since as you pointed out it
>>>>> didn't exist in 4.11.12 so odds are it was introduced somewhere
>>>>> between 4.11 and the latest kernel release.
>>>> Can be hard cause currently need to back to 4.11.12 - this is
>>>> production host/router
>>>> Will try to find some free/test router for tests/bicects with i40e
>>>> driver (intel 710 cards)
>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> - Alex
>>>>>
>>>>
>>>>
>>> Also forgoto to add errors for i40e when driver initialize:
>>> [ 15.760569] i40e 0000:02:00.1: Error I40E_AQ_RC_ENOSPC adding RX
>>> filters on PF, promiscuous mode forced on
>>> [ 16.365587] i40e 0000:03:00.3: Error I40E_AQ_RC_ENOSPC adding RX
>>> filters on PF, promiscuous mode forced on
>>> [ 16.367686] i40e 0000:02:00.2: Error I40E_AQ_RC_ENOSPC adding RX
>>> filters on PF, promiscuous mode forced on
>>> [ 16.368816] i40e 0000:03:00.0: Error I40E_AQ_RC_ENOSPC adding RX
>>> filters on PF, promiscuous mode forced on
>>> [ 16.369877] i40e 0000:03:00.2: Error I40E_AQ_RC_ENOSPC adding RX
>>> filters on PF, promiscuous mode forced on
>>> [ 16.370941] i40e 0000:02:00.3: Error I40E_AQ_RC_ENOSPC adding RX
>>> filters on PF, promiscuous mode forced on
>>> [ 16.372005] i40e 0000:02:00.0: Error I40E_AQ_RC_ENOSPC adding RX
>>> filters on PF, promiscuous mode forced on
>>> [ 16.373029] i40e 0000:03:00.1: Error I40E_AQ_RC_ENOSPC adding RX
>>> filters on PF, promiscuous mode forced on
>>>
>>> some params that are set for this nic's
>>> ip link set up dev $i
>>> ethtool -A $i autoneg off rx off tx off
>>> ethtool -G $i rx 1024 tx 2048
>>> ip link set $i txqueuelen 1000
>>> ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 512
>>> tx-usecs 128
>>> ethtool -L $i combined 6
>>> #ethtool -N $i rx-flow-hash udp4 sdfn
>>> ethtool -K $i ntuple on
>>> ethtool -K $i gro off
>>> ethtool -K $i tso off
>>>
>>>
>>>
>>>
>> Also after TSO/GRO on there is memory usage change - and leaking faster
>> Below image from memory usage before change with TSO/GRO OFF and
>> after enabling TSO/GRO
>>
>> https://ibb.co/dTqBY6
>>
>>
>> Thanks
>> Pawel
>>
>>
>>
> With settings like this:
> ifc='enp2s0f0 enp2s0f1 enp2s0f2 enp2s0f3 enp3s0f0 enp3s0f1 enp3s0f2
> enp3s0f3'
> for i in $ifc
> do
> ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 512
> tx-usecs 128
> ethtool -K $i gro on
> ethtool -K $i tso on
>
> done
>
> Server is leaking about 4-6MB per each 10 seconds
> MEMLEAK:
> 5 MB/10sec
> 6 MB/10sec
> 4 MB/10sec
> 4 MB/10sec
>
>
> Other settings TSO/GRO off
> ifc='enp2s0f0 enp2s0f1 enp2s0f2 enp2s0f3 enp3s0f0 enp3s0f1 enp3s0f2
> enp3s0f3'
> for i in $ifc
> do
> ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 512
> tx-usecs 128
> ethtool -K $i gro off
> ethtool -K $i tso off
>
> done
>
> Same leak about 5MB per 10 seconds
> MEMLEAK:
> 5 MB/10sec
> 5 MB/10sec
> 5 MB/10sec
>
>
> Other settings rx-usecs change from 512 to 1024:
> ifc='enp2s0f0 enp2s0f1 enp2s0f2 enp2s0f3 enp3s0f0 enp3s0f1 enp3s0f2
> enp3s0f3'
> for i in $ifc
> do
> ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 1024
> tx-usecs 128
> ethtool -K $i gro off
> ethtool -K $i tso off
>
> done
>
> MEMLEAK:
> 4 MB/10sec
> 3 MB/10sec
> 4 MB/10sec
> 4 MB/10sec
>
>
> So memleak have something to do with rx-usecs (less interrupts but
> bigger latency for traffic)
>
>
> But also enabling TSO/GRO making leak about 1MB bigger for each 10
> seconds
>
>
>
So far best config is:
ifc='enp2s0f0 enp2s0f1 enp2s0f2 enp2s0f3 enp3s0f0 enp3s0f1 enp3s0f2
enp3s0f3'
for i in $ifc
do
ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 64
tx-usecs 512
ethtool -K $i gro off
ethtool -K $i tso on
done
MEMLEAK - about 2MB/10secs
2 MB/10sec
2 MB/10sec
2 MB/10sec
With - rx-usecs set to 256 (about 7-9MB/10secs memleak)
ifc='enp2s0f0 enp2s0f1 enp2s0f2 enp2s0f3 enp3s0f0 enp3s0f1 enp3s0f2
enp3s0f3'
for i in $ifc
do
ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 256
tx-usecs 512
ethtool -K $i gro off
ethtool -K $i tso on
done
MEMLEAK:
7 MB/10sec
7 MB/10sec
8 MB/10sec
9 MB/10sec
^ permalink raw reply
* Re: [PATCH net-next] tcp: Enable TFO without a cookie on a per-socket basis
From: Eric Dumazet @ 2017-10-17 11:00 UTC (permalink / raw)
To: Christoph Paasch; +Cc: David Miller, netdev, Yuchung Cheng
In-Reply-To: <20171017063714.17346-1-cpaasch@apple.com>
On Mon, Oct 16, 2017 at 11:37 PM, Christoph Paasch <cpaasch@apple.com> wrote:
> We already allow to enable TFO without a cookie by using the
> fastopen-sysctl and setting it to TFO_SERVER_COOKIE_NOT_REQD (0x200).
> This is safe to do in certain environments where we know that there
> isn't a malicous host (aka., data-centers).
>
> A server however might be talking to both sides (public Internet and
> data-center). So, this server would want to enable cookie-less TFO for
> the connections that go to the data-center while enforcing cookies for
> the traffic from the Internet.
>
> This patch exposes a socket-option to enable this (protected by
> CAP_NET_ADMIN).
Have you thought instead of a route attribute ?
CAP_NET_ADMIN restriction is not really practical IMO.
^ permalink raw reply
* Re: Linux 4.12+ memory leak on router with i40e NICs
From: Paweł Staszewski @ 2017-10-17 11:05 UTC (permalink / raw)
To: Alexander Duyck
Cc: Pavlos Parissis, Anders K. Pedersen | Cohaesio,
netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
alexander.h.duyck@intel.com
In-Reply-To: <7fd828d7-c586-2c32-3ba6-e0575bf9958c@itcare.pl>
W dniu 2017-10-17 o 12:59, Paweł Staszewski pisze:
>
>
> W dniu 2017-10-17 o 12:51, Paweł Staszewski pisze:
>>
>>
>> W dniu 2017-10-17 o 12:20, Paweł Staszewski pisze:
>>>
>>>
>>> W dniu 2017-10-17 o 11:48, Paweł Staszewski pisze:
>>>>
>>>>
>>>> W dniu 2017-10-17 o 02:44, Paweł Staszewski pisze:
>>>>>
>>>>>
>>>>> W dniu 2017-10-17 o 01:56, Alexander Duyck pisze:
>>>>>> On Mon, Oct 16, 2017 at 4:34 PM, Paweł Staszewski
>>>>>> <pstaszewski@itcare.pl> wrote:
>>>>>>>
>>>>>>> W dniu 2017-10-16 o 18:26, Paweł Staszewski pisze:
>>>>>>>
>>>>>>>>
>>>>>>>> W dniu 2017-10-16 o 13:20, Pavlos Parissis pisze:
>>>>>>>>> On 15/10/2017 02:58 πμ, Alexander Duyck wrote:
>>>>>>>>>> Hi Pawel,
>>>>>>>>>>
>>>>>>>>>> To clarify is that Dave Miller's tree or Linus's that you are
>>>>>>>>>> talking
>>>>>>>>>> about? If it is Dave's tree how long ago was it you pulled it
>>>>>>>>>> since I
>>>>>>>>>> think the fix was just pushed by Jeff Kirsher a few days ago.
>>>>>>>>>>
>>>>>>>>>> The issue should be fixed in the following commit:
>>>>>>>>>>
>>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/drivers/net/ethernet/intel/i40e/i40e_txrx.c?id=2b9478ffc550f17c6cd8c69057234e91150f5972
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Do you know when it is going to be available on net-next and
>>>>>>>>> linux-stable
>>>>>>>>> repos?
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Pavlos
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I will make some tests today night with "net" git tree where
>>>>>>>> this patch is
>>>>>>>> included.
>>>>>>>> Starting from 0:00 CET
>>>>>>>> :)
>>>>>>>>
>>>>>>>>
>>>>>>> Upgraded and looks like problem is not solved with that patch
>>>>>>> Currently running system with
>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/
>>>>>>> kernel
>>>>>>>
>>>>>>> Still about 0.5GB of memory is leaking somewhere
>>>>>>>
>>>>>>> Also can confirm that the latest kernel where memory is not
>>>>>>> leaking (with
>>>>>>> use i40e driver intel 710 cards) is 4.11.12
>>>>>>> With kernel 4.11.12 - after hour no change in memory usage.
>>>>>>>
>>>>>>> also checked that with ixgbe instead of i40e with same net.git
>>>>>>> kernel there
>>>>>>> is no memleak - after hour same memory usage - so for 100% this
>>>>>>> is i40e
>>>>>>> driver problem.
>>>>>> So how long was the run to get the .5GB of memory leaking?
>>>>> 1 hour
>>>>>
>>>>>>
>>>>>> Also is there any chance of you being able to bisect to determine
>>>>>> where the memory leak was introduced since as you pointed out it
>>>>>> didn't exist in 4.11.12 so odds are it was introduced somewhere
>>>>>> between 4.11 and the latest kernel release.
>>>>> Can be hard cause currently need to back to 4.11.12 - this is
>>>>> production host/router
>>>>> Will try to find some free/test router for tests/bicects with i40e
>>>>> driver (intel 710 cards)
>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> - Alex
>>>>>>
>>>>>
>>>>>
>>>> Also forgoto to add errors for i40e when driver initialize:
>>>> [ 15.760569] i40e 0000:02:00.1: Error I40E_AQ_RC_ENOSPC adding RX
>>>> filters on PF, promiscuous mode forced on
>>>> [ 16.365587] i40e 0000:03:00.3: Error I40E_AQ_RC_ENOSPC adding RX
>>>> filters on PF, promiscuous mode forced on
>>>> [ 16.367686] i40e 0000:02:00.2: Error I40E_AQ_RC_ENOSPC adding RX
>>>> filters on PF, promiscuous mode forced on
>>>> [ 16.368816] i40e 0000:03:00.0: Error I40E_AQ_RC_ENOSPC adding RX
>>>> filters on PF, promiscuous mode forced on
>>>> [ 16.369877] i40e 0000:03:00.2: Error I40E_AQ_RC_ENOSPC adding RX
>>>> filters on PF, promiscuous mode forced on
>>>> [ 16.370941] i40e 0000:02:00.3: Error I40E_AQ_RC_ENOSPC adding RX
>>>> filters on PF, promiscuous mode forced on
>>>> [ 16.372005] i40e 0000:02:00.0: Error I40E_AQ_RC_ENOSPC adding RX
>>>> filters on PF, promiscuous mode forced on
>>>> [ 16.373029] i40e 0000:03:00.1: Error I40E_AQ_RC_ENOSPC adding RX
>>>> filters on PF, promiscuous mode forced on
>>>>
>>>> some params that are set for this nic's
>>>> ip link set up dev $i
>>>> ethtool -A $i autoneg off rx off tx off
>>>> ethtool -G $i rx 1024 tx 2048
>>>> ip link set $i txqueuelen 1000
>>>> ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 512
>>>> tx-usecs 128
>>>> ethtool -L $i combined 6
>>>> #ethtool -N $i rx-flow-hash udp4 sdfn
>>>> ethtool -K $i ntuple on
>>>> ethtool -K $i gro off
>>>> ethtool -K $i tso off
>>>>
>>>>
>>>>
>>>>
>>> Also after TSO/GRO on there is memory usage change - and leaking faster
>>> Below image from memory usage before change with TSO/GRO OFF and
>>> after enabling TSO/GRO
>>>
>>> https://ibb.co/dTqBY6
>>>
>>>
>>> Thanks
>>> Pawel
>>>
>>>
>>>
>> With settings like this:
>> ifc='enp2s0f0 enp2s0f1 enp2s0f2 enp2s0f3 enp3s0f0 enp3s0f1 enp3s0f2
>> enp3s0f3'
>> for i in $ifc
>> do
>> ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 512
>> tx-usecs 128
>> ethtool -K $i gro on
>> ethtool -K $i tso on
>>
>> done
>>
>> Server is leaking about 4-6MB per each 10 seconds
>> MEMLEAK:
>> 5 MB/10sec
>> 6 MB/10sec
>> 4 MB/10sec
>> 4 MB/10sec
>>
>>
>> Other settings TSO/GRO off
>> ifc='enp2s0f0 enp2s0f1 enp2s0f2 enp2s0f3 enp3s0f0 enp3s0f1 enp3s0f2
>> enp3s0f3'
>> for i in $ifc
>> do
>> ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 512
>> tx-usecs 128
>> ethtool -K $i gro off
>> ethtool -K $i tso off
>>
>> done
>>
>> Same leak about 5MB per 10 seconds
>> MEMLEAK:
>> 5 MB/10sec
>> 5 MB/10sec
>> 5 MB/10sec
>>
>>
>> Other settings rx-usecs change from 512 to 1024:
>> ifc='enp2s0f0 enp2s0f1 enp2s0f2 enp2s0f3 enp3s0f0 enp3s0f1 enp3s0f2
>> enp3s0f3'
>> for i in $ifc
>> do
>> ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 1024
>> tx-usecs 128
>> ethtool -K $i gro off
>> ethtool -K $i tso off
>>
>> done
>>
>> MEMLEAK:
>> 4 MB/10sec
>> 3 MB/10sec
>> 4 MB/10sec
>> 4 MB/10sec
>>
>>
>> So memleak have something to do with rx-usecs (less interrupts but
>> bigger latency for traffic)
>>
>>
>> But also enabling TSO/GRO making leak about 1MB bigger for each 10
>> seconds
>>
>>
>>
> So far best config is:
> ifc='enp2s0f0 enp2s0f1 enp2s0f2 enp2s0f3 enp3s0f0 enp3s0f1 enp3s0f2
> enp3s0f3'
> for i in $ifc
> do
> ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 64
> tx-usecs 512
> ethtool -K $i gro off
> ethtool -K $i tso on
>
> done
>
> MEMLEAK - about 2MB/10secs
> 2 MB/10sec
> 2 MB/10sec
> 2 MB/10sec
>
>
> With - rx-usecs set to 256 (about 7-9MB/10secs memleak)
> ifc='enp2s0f0 enp2s0f1 enp2s0f2 enp2s0f3 enp3s0f0 enp3s0f1 enp3s0f2
> enp3s0f3'
> for i in $ifc
> do
> ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 256
> tx-usecs 512
> ethtool -K $i gro off
> ethtool -K $i tso on
>
> done
>
> MEMLEAK:
> 7 MB/10sec
> 7 MB/10sec
> 8 MB/10sec
> 9 MB/10sec
>
>
And even less memleak with rx-usecs set to 32
ifc='enp2s0f0 enp2s0f1 enp2s0f2 enp2s0f3 enp3s0f0 enp3s0f1 enp3s0f2
enp3s0f3'
for i in $ifc
do
ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 32
tx-usecs 512
ethtool -K $i gro off
ethtool -K $i tso on
done
MEMLEAK - about 0-2MB for each 10 seconds
0 MB/10sec
1 MB/10sec
0 MB/10sec
2 MB/10sec
1 MB/10sec
^ permalink raw reply
* Re: [PATCH net] sock_diag: request _diag module only when the family or proto has been registered
From: Eric Dumazet @ 2017-10-17 11:16 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, davem, Marcelo Ricardo Leitner, Sabrina Dubroca
In-Reply-To: <69c0824505548e733f2f7be3ff288f2c4e461afa.1508217236.git.lucien.xin@gmail.com>
On Tue, 2017-10-17 at 13:13 +0800, Xin Long wrote:
> +bool sock_is_registered(int family)
> +{
> + return family < NPROTO && rcu_access_pointer(net_families[family]);
> +}
EXPORT_SYMBOL() ?
^ permalink raw reply
* Re: [PATCH] net: export netdev_txq_to_tc to allow sch_mqprio to compile as module
From: Eric Dumazet @ 2017-10-17 11:21 UTC (permalink / raw)
To: Henrik Austad
Cc: netdev, David S . Miller, Daniel Borkmann, David Ahern,
Alexander Duyck, Willem de Bruijn, John Fastabend, tcharding,
LKML, Henrik Austad, Jesus Sanchez-Palencia
In-Reply-To: <1508235010-4056-1-git-send-email-haustad@cisco.com>
On Tue, Oct 17, 2017 at 3:10 AM, Henrik Austad <henrik@austad.us> wrote:
> In commit 32302902ff09 ("mqprio: Reserve last 32 classid values for HW
> traffic classes and misc IDs") sch_mqprio started using netdev_txq_to_tc
> to find the correct tc instead of dev->tc_to_txq[]
>
> However, when mqprio is compiled as a module, it cannot resolve the
> symbol, leading to this error:
>
> ERROR: "netdev_txq_to_tc" [net/sched/sch_mqprio.ko] undefined!
>
> This adds an EXPORT_SYMBOL() since the other user in the kernel
> (netif_set_xps_queue) is also EXPORT_SYMBOL() (and not _GPL) or in a
> sysfs-callback.
>
> Cc: Alexander Duyck <alexander.h.duyck@intel.com>
> Cc: Jesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Henrik Austad <haustad@cisco.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH net] sock_diag: request _diag module only when the family or proto has been registered
From: Eric Dumazet @ 2017-10-17 11:24 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, davem, Marcelo Ricardo Leitner, Sabrina Dubroca
In-Reply-To: <1508238974.31614.91.camel@edumazet-glaptop3.roam.corp.google.com>
On Tue, 2017-10-17 at 04:16 -0700, Eric Dumazet wrote:
> On Tue, 2017-10-17 at 13:13 +0800, Xin Long wrote:
>
> > +bool sock_is_registered(int family)
> > +{
> > + return family < NPROTO && rcu_access_pointer(net_families[family]);
> > +}
>
> EXPORT_SYMBOL() ?
>
Or move it in net/core/sock_diag.c so that it can be static.
^ permalink raw reply
* Re: [PATCH net] net/sched: cls_flower: Set egress_dev mark when calling into the HW driver
From: Sergei Shtylyov @ 2017-10-17 11:29 UTC (permalink / raw)
To: Or Gerlitz, David S. Miller; +Cc: Jiri Pirko, netdev, mlxsw, Roi Dayan
In-Reply-To: <1508145588-29959-1-git-send-email-ogerlitz@mellanox.com>
Hello!
On 10/16/2017 12:19 PM, Or Gerlitz wrote:
> Commit 7091d8c '(net/sched: cls_flower: Add offload support using egress
At least 12 digits are needed.
> Hardware device') made sure (when fl_hw_replace_filter is called) to put
> the egress_dev mark on persisent structure instance. Hence, following calls
Persistent.
> into the HW driver for stats and deletion will note it and act accordingly.
>
> With commit de4784ca030f this property is lost and hence when called,
> the HW driver failes to operate (stats, delete) on the offloaded flow.
Fails.
> Fix it by setting the egress_dev flag whenever the ingress device is
> different from the hw device since this is exactly the condition under
> which we're calling into the HW driver through the egress port net-device.
>
> Fixes: de4784ca030f ('net: sched: get rid of struct tc_to_netdev')
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
> Signed-off-by: Roi Dayan <roid@mellanox.com>
[...]
MBR, Sergei
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the net tree
From: Sergei Shtylyov @ 2017-10-17 11:30 UTC (permalink / raw)
To: Mark Brown, David Miller, Networking, Vivien Didelot
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20171016093635.zxyyq2px4hdewse3@sirena.co.uk>
Hello!
On 10/16/2017 12:36 PM, Mark Brown wrote:
> Today's linux-next merge of the net-next tree got a conflict in:
>
> drivers/net/dsa/mv88e6060.c
>
> between commit:
>
> 3efc93c2bc243 ("net: dsa: mv88e6060: fix switch MAC address")
>
> from the net tree and commit:
>
> 56c3ff9bf23e1 ("net: dsa: mv88e6060: setup random mac address")
>
> from the net-next tree.
>
> I fixed it up (see below, the relevant code was deleted in net-next) and
> can carry the fix as necessary. This is now fixed as far as linux-next
> is concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
>
> diff --cc drivers/net/dsa/mv88e6060.c
> index f123ed57630d,6173be889d95..000000000000
> --- a/drivers/net/dsa/mv88e6060.c
> +++ b/drivers/net/dsa/mv88e6060.c
Your mail ends here.
MBR, Sergei
^ permalink raw reply
* Re: [PATCH net] sock_diag: request _diag module only when the family or proto has been registered
From: Eric Dumazet @ 2017-10-17 11:35 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, davem, Marcelo Ricardo Leitner, Sabrina Dubroca
In-Reply-To: <1508238974.31614.91.camel@edumazet-glaptop3.roam.corp.google.com>
On Tue, 2017-10-17 at 04:16 -0700, Eric Dumazet wrote:
> On Tue, 2017-10-17 at 13:13 +0800, Xin Long wrote:
>
> > +bool sock_is_registered(int family)
> > +{
> > + return family < NPROTO && rcu_access_pointer(net_families[family]);
> > +}
>
> EXPORT_SYMBOL() ?
I take this back. Since there is one single user in vmlinux, no need yet
Reviewed-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [next-queue PATCH v9 0/6] TSN: Add qdisc based config interface for CBS
From: Henrik Austad @ 2017-10-17 11:35 UTC (permalink / raw)
To: Vinicius Costa Gomes
Cc: netdev, intel-wired-lan, jhs, xiyou.wangcong, jiri, andre.guedes,
ivan.briano, jesus.sanchez-palencia, boon.leong.ong,
richardcochran, levipearson, rodney.cummings
In-Reply-To: <20171017010128.22141-1-vinicius.gomes@intel.com>
[-- Attachment #1: Type: text/plain, Size: 967 bytes --]
On Mon, Oct 16, 2017 at 06:01:22PM -0700, Vinicius Costa Gomes wrote:
> Hi,
Vinicius; this looks really good to me, testing shows no errors and
behavior is as expected. I see some differences in received bw for
offload=1 and 0 though
Just using tsn_talker and tsn_listener:
tc qdisc add dev eth2 parent 8001:1 cbs idleslope 20000 sendslope -980000 \
hicredit 30 locredit -1470 offload 1
with offload=1 (20Mbps BW)
Receiving data rate: 19420 kbps
Receiving data rate: 19410 kbps
Similarly, but with offload=0 (SW, 20Mbps BW)
Receiving data rate: 19980 kbps
Receiving data rate: 20170 kbps
So slightly higer variance in rate when doing SW, which is as expected.
I plan to run this through some more tests tomorrow and measure variance on the
receiver etc, I'll keep you posted on my findings.
Feel free to add a tested-by though
Tested-by: Henrik Austad <henrik@austad.us>
and a Vehemently-supported-by: Henrik .. :)
-Henrik
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH net] sock_diag: request _diag module only when the family or proto has been registered
From: Marcelo Ricardo Leitner @ 2017-10-17 11:39 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, davem, Sabrina Dubroca
In-Reply-To: <69c0824505548e733f2f7be3ff288f2c4e461afa.1508217236.git.lucien.xin@gmail.com>
On Tue, Oct 17, 2017 at 01:13:56PM +0800, Xin Long wrote:
> Now when using 'ss' in iproute, kernel would try to load all _diag
> modules. It causes the corresponding family or proto modules to be
> loaded as well.
>
> Like after 'ss -a', sctp, dccp, af_packet(if it works as a moudle)
> will be loaded.
>
> As these family or proto modules are loaded unexpectly, this might
> have some security implications.
>
> This patch is to introduce sock_diag_request_module() in which we
> only request the _diag module when it's corresponding family or
> proto has been registered.
>
> Note that we can't just load _diag module without the family or
> proto loaded, as some symbols in _diag module are from the family
> or proto moudle.
>
> Reported-by: Sabrina Dubroca <sd@queasysnail.net>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> ---
> include/linux/net.h | 1 +
> include/linux/sock_diag.h | 1 +
> net/core/sock_diag.c | 32 ++++++++++++++++++++++++--------
> net/ipv4/inet_diag.c | 3 +--
> net/socket.c | 5 +++++
> 5 files changed, 32 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/net.h b/include/linux/net.h
> index d97d80d..6c7cf09 100644
> --- a/include/linux/net.h
> +++ b/include/linux/net.h
> @@ -225,6 +225,7 @@ enum {
> int sock_wake_async(struct socket_wq *sk_wq, int how, int band);
> int sock_register(const struct net_proto_family *fam);
> void sock_unregister(int family);
> +bool sock_is_registered(int family);
> int __sock_create(struct net *net, int family, int type, int proto,
> struct socket **res, int kern);
> int sock_create(int family, int type, int proto, struct socket **res);
> diff --git a/include/linux/sock_diag.h b/include/linux/sock_diag.h
> index a2f8109..e9a1b8d 100644
> --- a/include/linux/sock_diag.h
> +++ b/include/linux/sock_diag.h
> @@ -77,4 +77,5 @@ bool sock_diag_has_destroy_listeners(const struct sock *sk)
> void sock_diag_broadcast_destroy(struct sock *sk);
>
> int sock_diag_destroy(struct sock *sk, int err);
> +int sock_diag_request_module(int family, int protocol);
> #endif
> diff --git a/net/core/sock_diag.c b/net/core/sock_diag.c
> index 217f4e3..caad6b6 100644
> --- a/net/core/sock_diag.c
> +++ b/net/core/sock_diag.c
> @@ -7,6 +7,7 @@
> #include <net/net_namespace.h>
> #include <linux/module.h>
> #include <net/sock.h>
> +#include <net/protocol.h>
> #include <linux/kernel.h>
> #include <linux/tcp.h>
> #include <linux/workqueue.h>
> @@ -207,6 +208,25 @@ void sock_diag_unregister(const struct sock_diag_handler *hnld)
> }
> EXPORT_SYMBOL_GPL(sock_diag_unregister);
>
> +int sock_diag_request_module(int family, int protocol)
> +{
> + if (!protocol) {
> + if (!sock_is_registered(family))
> + return -ENOENT;
> +
> + return request_module("net-pf-%d-proto-%d-type-%d", PF_NETLINK,
> + NETLINK_SOCK_DIAG, family);
> + }
> +
> + if (family == AF_INET &&
> + !rcu_access_pointer(inet_protos[protocol]))
> + return -ENOENT;
> +
> + return request_module("net-pf-%d-proto-%d-type-%d-%d", PF_NETLINK,
> + NETLINK_SOCK_DIAG, family, protocol);
> +}
> +EXPORT_SYMBOL_GPL(sock_diag_request_module);
> +
> static int __sock_diag_cmd(struct sk_buff *skb, struct nlmsghdr *nlh)
> {
> int err;
> @@ -220,8 +240,7 @@ static int __sock_diag_cmd(struct sk_buff *skb, struct nlmsghdr *nlh)
> return -EINVAL;
>
> if (sock_diag_handlers[req->sdiag_family] == NULL)
> - request_module("net-pf-%d-proto-%d-type-%d", PF_NETLINK,
> - NETLINK_SOCK_DIAG, req->sdiag_family);
> + sock_diag_request_module(req->sdiag_family, 0);
>
> mutex_lock(&sock_diag_table_mutex);
> hndl = sock_diag_handlers[req->sdiag_family];
> @@ -247,8 +266,7 @@ static int sock_diag_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh,
> case TCPDIAG_GETSOCK:
> case DCCPDIAG_GETSOCK:
> if (inet_rcv_compat == NULL)
> - request_module("net-pf-%d-proto-%d-type-%d", PF_NETLINK,
> - NETLINK_SOCK_DIAG, AF_INET);
> + sock_diag_request_module(AF_INET, 0);
>
> mutex_lock(&sock_diag_table_mutex);
> if (inet_rcv_compat != NULL)
> @@ -281,14 +299,12 @@ static int sock_diag_bind(struct net *net, int group)
> case SKNLGRP_INET_TCP_DESTROY:
> case SKNLGRP_INET_UDP_DESTROY:
> if (!sock_diag_handlers[AF_INET])
> - request_module("net-pf-%d-proto-%d-type-%d", PF_NETLINK,
> - NETLINK_SOCK_DIAG, AF_INET);
> + sock_diag_request_module(AF_INET, 0);
> break;
> case SKNLGRP_INET6_TCP_DESTROY:
> case SKNLGRP_INET6_UDP_DESTROY:
> if (!sock_diag_handlers[AF_INET6])
> - request_module("net-pf-%d-proto-%d-type-%d", PF_NETLINK,
> - NETLINK_SOCK_DIAG, AF_INET);
> + sock_diag_request_module(AF_INET, 0);
> break;
> }
> return 0;
> diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c
> index c9c35b6..d10c8fa 100644
> --- a/net/ipv4/inet_diag.c
> +++ b/net/ipv4/inet_diag.c
> @@ -53,8 +53,7 @@ static DEFINE_MUTEX(inet_diag_table_mutex);
> static const struct inet_diag_handler *inet_diag_lock_handler(int proto)
> {
> if (!inet_diag_table[proto])
> - request_module("net-pf-%d-proto-%d-type-%d-%d", PF_NETLINK,
> - NETLINK_SOCK_DIAG, AF_INET, proto);
> + sock_diag_request_module(AF_INET, proto);
>
> mutex_lock(&inet_diag_table_mutex);
> if (!inet_diag_table[proto])
> diff --git a/net/socket.c b/net/socket.c
> index c729625..733d657 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -2590,6 +2590,11 @@ void sock_unregister(int family)
> }
> EXPORT_SYMBOL(sock_unregister);
>
> +bool sock_is_registered(int family)
> +{
> + return family < NPROTO && rcu_access_pointer(net_families[family]);
> +}
> +
> static int __init sock_init(void)
> {
> int err;
> --
> 2.1.0
>
^ permalink raw reply
* Re: Linux 4.12+ memory leak on router with i40e NICs
From: Paweł Staszewski @ 2017-10-17 11:52 UTC (permalink / raw)
To: Alexander Duyck
Cc: Pavlos Parissis, Anders K. Pedersen | Cohaesio,
netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
alexander.h.duyck@intel.com
In-Reply-To: <99eba19f-327e-e01f-4f4a-87540b176e40@itcare.pl>
W dniu 2017-10-17 o 13:05, Paweł Staszewski pisze:
>
>
> W dniu 2017-10-17 o 12:59, Paweł Staszewski pisze:
>>
>>
>> W dniu 2017-10-17 o 12:51, Paweł Staszewski pisze:
>>>
>>>
>>> W dniu 2017-10-17 o 12:20, Paweł Staszewski pisze:
>>>>
>>>>
>>>> W dniu 2017-10-17 o 11:48, Paweł Staszewski pisze:
>>>>>
>>>>>
>>>>> W dniu 2017-10-17 o 02:44, Paweł Staszewski pisze:
>>>>>>
>>>>>>
>>>>>> W dniu 2017-10-17 o 01:56, Alexander Duyck pisze:
>>>>>>> On Mon, Oct 16, 2017 at 4:34 PM, Paweł Staszewski
>>>>>>> <pstaszewski@itcare.pl> wrote:
>>>>>>>>
>>>>>>>> W dniu 2017-10-16 o 18:26, Paweł Staszewski pisze:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> W dniu 2017-10-16 o 13:20, Pavlos Parissis pisze:
>>>>>>>>>> On 15/10/2017 02:58 πμ, Alexander Duyck wrote:
>>>>>>>>>>> Hi Pawel,
>>>>>>>>>>>
>>>>>>>>>>> To clarify is that Dave Miller's tree or Linus's that you
>>>>>>>>>>> are talking
>>>>>>>>>>> about? If it is Dave's tree how long ago was it you pulled
>>>>>>>>>>> it since I
>>>>>>>>>>> think the fix was just pushed by Jeff Kirsher a few days ago.
>>>>>>>>>>>
>>>>>>>>>>> The issue should be fixed in the following commit:
>>>>>>>>>>>
>>>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/drivers/net/ethernet/intel/i40e/i40e_txrx.c?id=2b9478ffc550f17c6cd8c69057234e91150f5972
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Do you know when it is going to be available on net-next and
>>>>>>>>>> linux-stable
>>>>>>>>>> repos?
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Pavlos
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> I will make some tests today night with "net" git tree where
>>>>>>>>> this patch is
>>>>>>>>> included.
>>>>>>>>> Starting from 0:00 CET
>>>>>>>>> :)
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Upgraded and looks like problem is not solved with that patch
>>>>>>>> Currently running system with
>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/
>>>>>>>> kernel
>>>>>>>>
>>>>>>>> Still about 0.5GB of memory is leaking somewhere
>>>>>>>>
>>>>>>>> Also can confirm that the latest kernel where memory is not
>>>>>>>> leaking (with
>>>>>>>> use i40e driver intel 710 cards) is 4.11.12
>>>>>>>> With kernel 4.11.12 - after hour no change in memory usage.
>>>>>>>>
>>>>>>>> also checked that with ixgbe instead of i40e with same net.git
>>>>>>>> kernel there
>>>>>>>> is no memleak - after hour same memory usage - so for 100% this
>>>>>>>> is i40e
>>>>>>>> driver problem.
>>>>>>> So how long was the run to get the .5GB of memory leaking?
>>>>>> 1 hour
>>>>>>
>>>>>>>
>>>>>>> Also is there any chance of you being able to bisect to determine
>>>>>>> where the memory leak was introduced since as you pointed out it
>>>>>>> didn't exist in 4.11.12 so odds are it was introduced somewhere
>>>>>>> between 4.11 and the latest kernel release.
>>>>>> Can be hard cause currently need to back to 4.11.12 - this is
>>>>>> production host/router
>>>>>> Will try to find some free/test router for tests/bicects with
>>>>>> i40e driver (intel 710 cards)
>>>>>>
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> - Alex
>>>>>>>
>>>>>>
>>>>>>
>>>>> Also forgoto to add errors for i40e when driver initialize:
>>>>> [ 15.760569] i40e 0000:02:00.1: Error I40E_AQ_RC_ENOSPC adding
>>>>> RX filters on PF, promiscuous mode forced on
>>>>> [ 16.365587] i40e 0000:03:00.3: Error I40E_AQ_RC_ENOSPC adding
>>>>> RX filters on PF, promiscuous mode forced on
>>>>> [ 16.367686] i40e 0000:02:00.2: Error I40E_AQ_RC_ENOSPC adding
>>>>> RX filters on PF, promiscuous mode forced on
>>>>> [ 16.368816] i40e 0000:03:00.0: Error I40E_AQ_RC_ENOSPC adding
>>>>> RX filters on PF, promiscuous mode forced on
>>>>> [ 16.369877] i40e 0000:03:00.2: Error I40E_AQ_RC_ENOSPC adding
>>>>> RX filters on PF, promiscuous mode forced on
>>>>> [ 16.370941] i40e 0000:02:00.3: Error I40E_AQ_RC_ENOSPC adding
>>>>> RX filters on PF, promiscuous mode forced on
>>>>> [ 16.372005] i40e 0000:02:00.0: Error I40E_AQ_RC_ENOSPC adding
>>>>> RX filters on PF, promiscuous mode forced on
>>>>> [ 16.373029] i40e 0000:03:00.1: Error I40E_AQ_RC_ENOSPC adding
>>>>> RX filters on PF, promiscuous mode forced on
>>>>>
>>>>> some params that are set for this nic's
>>>>> ip link set up dev $i
>>>>> ethtool -A $i autoneg off rx off tx off
>>>>> ethtool -G $i rx 1024 tx 2048
>>>>> ip link set $i txqueuelen 1000
>>>>> ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 512
>>>>> tx-usecs 128
>>>>> ethtool -L $i combined 6
>>>>> #ethtool -N $i rx-flow-hash udp4 sdfn
>>>>> ethtool -K $i ntuple on
>>>>> ethtool -K $i gro off
>>>>> ethtool -K $i tso off
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Also after TSO/GRO on there is memory usage change - and leaking
>>>> faster
>>>> Below image from memory usage before change with TSO/GRO OFF and
>>>> after enabling TSO/GRO
>>>>
>>>> https://ibb.co/dTqBY6
>>>>
>>>>
>>>> Thanks
>>>> Pawel
>>>>
>>>>
>>>>
>>> With settings like this:
>>> ifc='enp2s0f0 enp2s0f1 enp2s0f2 enp2s0f3 enp3s0f0 enp3s0f1 enp3s0f2
>>> enp3s0f3'
>>> for i in $ifc
>>> do
>>> ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 512
>>> tx-usecs 128
>>> ethtool -K $i gro on
>>> ethtool -K $i tso on
>>>
>>> done
>>>
>>> Server is leaking about 4-6MB per each 10 seconds
>>> MEMLEAK:
>>> 5 MB/10sec
>>> 6 MB/10sec
>>> 4 MB/10sec
>>> 4 MB/10sec
>>>
>>>
>>> Other settings TSO/GRO off
>>> ifc='enp2s0f0 enp2s0f1 enp2s0f2 enp2s0f3 enp3s0f0 enp3s0f1 enp3s0f2
>>> enp3s0f3'
>>> for i in $ifc
>>> do
>>> ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 512
>>> tx-usecs 128
>>> ethtool -K $i gro off
>>> ethtool -K $i tso off
>>>
>>> done
>>>
>>> Same leak about 5MB per 10 seconds
>>> MEMLEAK:
>>> 5 MB/10sec
>>> 5 MB/10sec
>>> 5 MB/10sec
>>>
>>>
>>> Other settings rx-usecs change from 512 to 1024:
>>> ifc='enp2s0f0 enp2s0f1 enp2s0f2 enp2s0f3 enp3s0f0 enp3s0f1 enp3s0f2
>>> enp3s0f3'
>>> for i in $ifc
>>> do
>>> ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 1024
>>> tx-usecs 128
>>> ethtool -K $i gro off
>>> ethtool -K $i tso off
>>>
>>> done
>>>
>>> MEMLEAK:
>>> 4 MB/10sec
>>> 3 MB/10sec
>>> 4 MB/10sec
>>> 4 MB/10sec
>>>
>>>
>>> So memleak have something to do with rx-usecs (less interrupts but
>>> bigger latency for traffic)
>>>
>>>
>>> But also enabling TSO/GRO making leak about 1MB bigger for each 10
>>> seconds
>>>
>>>
>>>
>> So far best config is:
>> ifc='enp2s0f0 enp2s0f1 enp2s0f2 enp2s0f3 enp3s0f0 enp3s0f1 enp3s0f2
>> enp3s0f3'
>> for i in $ifc
>> do
>> ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 64
>> tx-usecs 512
>> ethtool -K $i gro off
>> ethtool -K $i tso on
>>
>> done
>>
>> MEMLEAK - about 2MB/10secs
>> 2 MB/10sec
>> 2 MB/10sec
>> 2 MB/10sec
>>
>>
>> With - rx-usecs set to 256 (about 7-9MB/10secs memleak)
>> ifc='enp2s0f0 enp2s0f1 enp2s0f2 enp2s0f3 enp3s0f0 enp3s0f1 enp3s0f2
>> enp3s0f3'
>> for i in $ifc
>> do
>> ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 256
>> tx-usecs 512
>> ethtool -K $i gro off
>> ethtool -K $i tso on
>>
>> done
>>
>> MEMLEAK:
>> 7 MB/10sec
>> 7 MB/10sec
>> 8 MB/10sec
>> 9 MB/10sec
>>
>>
>
> And even less memleak with rx-usecs set to 32
> ifc='enp2s0f0 enp2s0f1 enp2s0f2 enp2s0f3 enp3s0f0 enp3s0f1 enp3s0f2
> enp3s0f3'
> for i in $ifc
> do
> ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 32
> tx-usecs 512
> ethtool -K $i gro off
> ethtool -K $i tso on
>
> done
>
>
> MEMLEAK - about 0-2MB for each 10 seconds
> 0 MB/10sec
> 1 MB/10sec
> 0 MB/10sec
> 2 MB/10sec
> 1 MB/10sec
>
>
>
So best settings - to have as less leak as possible for now (rx-usecs
set to 16):
ifc='enp2s0f0 enp2s0f1 enp2s0f2 enp2s0f3 enp3s0f0 enp3s0f1 enp3s0f2
enp3s0f3'
for i in $ifc
do
ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 16
tx-usecs 768
ethtool -K $i gro on
ethtool -K $i tso on
done
MEMLEAK: (0-1MB/10seconds)
0 MB/10sec
0 MB/10sec
0 MB/10sec
1 MB/10sec
1 MB/10sec
-1 MB/10sec
1 MB/10sec
1 MB/10sec
0 MB/10sec
(there are some memory recycles - so this is good :) )
Compared to(rx-usecs 512):
ifc='enp2s0f0 enp2s0f1 enp2s0f2 enp2s0f3 enp3s0f0 enp3s0f1 enp3s0f2
enp3s0f3'
for i in $ifc
do
ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 512
tx-usecs 128
ethtool -K $i gro on
ethtool -K $i tso on
done
Server is leaking about 4-6MB per each 10 seconds
MEMLEAK:
5 MB/10sec
6 MB/10sec
4 MB/10sec
4 MB/10sec
^ permalink raw reply
* Re: [PATCH v9 00/20] simplify crypto wait for async op
From: Gilad Ben-Yossef @ 2017-10-17 11:55 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, Jonathan Corbet, David Howells, Tom Lendacky,
Gary Hook, Boris Brezillon, Arnaud Ebalard, Matthias Brugger,
Alasdair Kergon, Mike Snitzer, device-mapper development,
Steve French, Theodore Y. Ts'o, Jaegeuk Kim, Steffen Klassert,
Alexey Kuznetsov, Hideaki YOSHIFUJI, Mimi Zohar, Dmitry Kasatkin
In-Reply-To: <20171015153831.GA22867-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
On Sun, Oct 15, 2017 at 6:38 PM, Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org> wrote:
>
> On Sun, Oct 15, 2017 at 10:19:45AM +0100, Gilad Ben-Yossef wrote:
> >
> > Changes from v8:
> > - Remove the translation of EAGAIN return code to the
> > previous return code of EBUSY for the user space
> > interface of algif as no one seems to rely on it as
> > requested by Herbert Xu.
>
> Sorry, but I forgot to mention that EAGAIN is not a good value
> to use because it's used by the network system calls for other
> meanings (interrupted by a signal).
>
> So if we stop doing the translation then we also need to pick
> a different value, perhaps E2BIG or something similar that have
> no current use within the crypto API or network API.
Yes, I see what you mean. With a netlink based interface this can
be confusing to debug.
Would you mind if we used ENOSPC instead of E2BIG?
"No space left on device" seems more appropriate than
"Argument list too long".
Thanks,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
^ permalink raw reply
* [PATCH] netfilter: ip6_tables: remove redundant assignment to e
From: Colin King @ 2017-10-17 12:02 UTC (permalink / raw)
To: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
David S . Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
netfilter-devel, coreteam, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The assignment to variable e is redundant since the same assignment
occurs just a few lines later, hence it can be removed. Cleans up
clang warning: warning: Value stored to 'e' is never read
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
net/ipv6/netfilter/ip6_tables.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/ipv6/netfilter/ip6_tables.c b/net/ipv6/netfilter/ip6_tables.c
index 01bd3ee5ebc6..702e483d38b0 100644
--- a/net/ipv6/netfilter/ip6_tables.c
+++ b/net/ipv6/netfilter/ip6_tables.c
@@ -458,7 +458,6 @@ mark_source_chains(const struct xt_table_info *newinfo,
if (!xt_find_jump_offset(offsets, newpos,
newinfo->number))
return 0;
- e = entry0 + newpos;
} else {
/* ... this is a fallthru */
newpos = pos + e->next_offset;
--
2.14.1
^ permalink raw reply related
* Re: RFC(v2): Audit Kernel Container IDs
From: Simo Sorce @ 2017-10-17 12:31 UTC (permalink / raw)
To: Steve Grubb, linux-audit
Cc: Richard Guy Briggs, Casey Schaufler, mszeredi, Eric W. Biederman,
jlayton, Carlos O'Donell, Linux API, Linux Containers,
Linux Kernel, Eric Paris, David Howells, Al Viro, Andy Lutomirski,
Linux Network Development, Linux FS Devel, cgroups,
Serge E. Hallyn, trondmy
In-Reply-To: <2319693.5l3M4ZINGd@x2>
On Mon, 2017-10-16 at 21:42 -0400, Steve Grubb wrote:
> On Monday, October 16, 2017 8:33:40 PM EDT Richard Guy Briggs wrote:
> > There is such a thing, but the kernel doesn't know about it
> > yet. This same situation exists for loginuid and sessionid which
> > are userspace concepts that the kernel tracks for the convenience
> > of userspace. As for its name, I'm not particularly picky, so if
> > you don't like CAP_CONTAINER_* then I'm fine with
> > CAP_AUDIT_CONTAINERID. It really needs to be distinct from
> > CAP_AUDIT_WRITE and CAP_AUDIT_CONTROL since we don't want to give
> > the ability to set a containerID to any process that is able to do
> > audit logging (such as vsftpd) and similarly we don't want to give
> > the orchestrator the ability to control the setup of the audit
> > daemon.
>
> A long time ago, we were debating what should guard against rouge
> processes from setting the loginuid. Casey argued that the ability to
> set the loginuid means they have the ability to control the audit
> trail. That means that it should be guarded by CAP_AUDIT_CONTROL. I
> think the same logic applies today.
The difference is that with loginuid you needed to give processes able
to audit also the ability to change it. You do not want to tie the
ability to change container ids to the ability to audit. You want to be
able to do audit stuff (within the container) without allowing it to
change the container id.
Of course if we made container id a write-once property maybe there is
no need for controls at all, but I'm pretty sure there will be
situations where write-once may not be usable in practice.
> The ability to arbitrarily set a container ID means the process has
> the ability to indirectly control the audit trail.
The container Id can be used also for authorization purposes (by other
processes on the host), not just audit, I think this is why a separate
control has been proposed.
Simo.
--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
^ permalink raw reply
* [PATCH 1/2 v2 net-next] thunderbolt: Fix a couple right shifting to zero bugs
From: Dan Carpenter @ 2017-10-17 12:32 UTC (permalink / raw)
To: Andreas Noever
Cc: Michael Jamet, Mika Westerberg, Yehezkel Bernat, netdev,
kernel-janitors
In-Reply-To: <20171013112959.sc2pwazrpk7fxbtw@mwanda>
The problematic code looks like this:
res_seq = res_hdr->xd_hdr.length_sn & TB_XDOMAIN_SN_MASK;
res_seq >>= TB_XDOMAIN_SN_SHIFT;
TB_XDOMAIN_SN_SHIFT is 27, and right shifting a u8 27 bits is always
going to result in zero. The fix is to declare these variables as u32.
Fixes: d1ff70241a27 ("thunderbolt: Add support for XDomain discovery protocol")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
v2: I accidentally sent this through the wrong list, so I'm resending to
netdev. Also Mika asked me to split it up because the Fixes tags
are different for these patches.
diff --git a/drivers/thunderbolt/xdomain.c b/drivers/thunderbolt/xdomain.c
index 138027537d29..ff8d91189e99 100644
--- a/drivers/thunderbolt/xdomain.c
+++ b/drivers/thunderbolt/xdomain.c
@@ -56,7 +56,7 @@ static bool tb_xdomain_match(const struct tb_cfg_request *req,
case TB_CFG_PKG_XDOMAIN_RESP: {
const struct tb_xdp_header *res_hdr = pkg->buffer;
const struct tb_xdp_header *req_hdr = req->request;
- u8 req_seq, res_seq;
+ u32 req_seq, res_seq;
if (pkg->frame.size < req->response_size / 4)
return false;
@@ -476,7 +476,7 @@ static void tb_xdp_handle_request(struct work_struct *work)
struct tb_ctl *ctl = tb->ctl;
const uuid_t *uuid;
int ret = 0;
- u8 sequence;
+ u32 sequence;
u64 route;
route = ((u64)xhdr->route_hi << 32 | xhdr->route_lo) & ~BIT_ULL(63);
^ permalink raw reply related
* [PATCH 2/2 net-next] thunderbolt: Right shifting to zero bug in tbnet_handle_packet()
From: Dan Carpenter @ 2017-10-17 12:33 UTC (permalink / raw)
To: Michael Jamet, Amir Levy
Cc: Mika Westerberg, Yehezkel Bernat, netdev, kernel-janitors
In-Reply-To: <20171013112959.sc2pwazrpk7fxbtw@mwanda>
There is a problem when we do:
sequence = pkg->hdr.length_sn & TBIP_HDR_SN_MASK;
sequence >>= TBIP_HDR_SN_SHIFT;
TBIP_HDR_SN_SHIFT is 27, and right shifting a u8 27 bits is always
going to result in zero. The fix is to declare these variables as u32.
Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/thunderbolt.c b/drivers/net/thunderbolt.c
index 1a7bc0bf4598..435854688a7a 100644
--- a/drivers/net/thunderbolt.c
+++ b/drivers/net/thunderbolt.c
@@ -394,7 +394,7 @@ static int tbnet_handle_packet(const void *buf, size_t size, void *data)
struct tbnet *net = data;
u32 command_id;
int ret = 0;
- u8 sequence;
+ u32 sequence;
u64 route;
/* Make sure the packet is for us */
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox