* 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: 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-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 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 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: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 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: [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: [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
* 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: [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
* 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 07/58] net/usb/usbnet: Convert timers to use timer_setup()
From: Oliver Neukum @ 2017-10-17 10:30 UTC (permalink / raw)
To: Kees Cook, David S. Miller
Cc: Thomas Gleixner, linux-kernel, linux-usb, netdev
In-Reply-To: <1508200182-104605-8-git-send-email-keescook@chromium.org>
Am Montag, den 16.10.2017, 17:28 -0700 schrieb Kees Cook:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly. Since the callback is called from
> both a timer and a tasklet, adjust the tasklet to pass the timer address
> too. When tasklets have their .data field removed, this can be refactored
> to call a central function after resolving the correct container_of() for a
> separate callback function for timer and tasklet.
>
> Cc: Oliver Neukum <oneukum@suse.com>
> Cc: netdev@vger.kernel.org
> Cc: linux-usb@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Oliver Neukum <oneukum@suse.com>
^ permalink raw reply
* Re: [PATCH] bpf: devmap: Check attr->max_entries more carefully
From: Mark Rutland @ 2017-10-17 10:29 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Richard Weinberger, netdev, linux-kernel, ast, sp3485, tj,
john.fastabend
In-Reply-To: <59E4FFDD.7010402@iogearbox.net>
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.
> 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.
Thanks,
Mark.
>
> [1] https://patchwork.kernel.org/patch/9975851/
>
> Thanks,
> Daniel
>
> mm/percpu.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/mm/percpu.c b/mm/percpu.c
> index 59d44d6..5d9414e 100644
> --- a/mm/percpu.c
> +++ b/mm/percpu.c
> @@ -1357,7 +1357,8 @@ static void __percpu *pcpu_alloc(size_t size, size_t align, bool reserved,
>
> if (unlikely(!size || size > PCPU_MIN_UNIT_SIZE || align > PAGE_SIZE ||
> !is_power_of_2(align))) {
> - WARN(true, "illegal size (%zu) or align (%zu) for percpu allocation\n",
> + WARN(!(gfp & __GFP_NOWARN),
> + "illegal size (%zu) or align (%zu) for percpu allocation\n",
> size, align);
> return NULL;
> }
> @@ -1478,7 +1479,7 @@ static void __percpu *pcpu_alloc(size_t size, size_t align, bool reserved,
> fail:
> trace_percpu_alloc_percpu_fail(reserved, is_atomic, size, align);
>
> - if (!is_atomic && warn_limit) {
> + if (!is_atomic && warn_limit && !(gfp & __GFP_NOWARN)) {
> pr_warn("allocation failed, size=%zu align=%zu atomic=%d, %s\n",
> size, align, is_atomic, err);
> dump_stack();
> --
> 1.9.3
^ permalink raw reply
* Re: [PATCH net 0/3] bonding: void calling rtmsg_ifinfo for netlink notifications
From: Xin Long @ 2017-10-17 10:28 UTC (permalink / raw)
To: Jiri Pirko; +Cc: network dev, davem
In-Reply-To: <20171017095943.GE2112@nanopsycho>
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 ?
>
>
>>
>>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: linux-next: net/sched/cls_flower.c
From: Mark Brown @ 2017-10-17 10:27 UTC (permalink / raw)
To: Jiri Pirko
Cc: David Miller, Networking, Or Gerlitz, Roi Dayan, Jiri Pirko,
Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20171017102107.GF2112@nanopsycho>
[-- Attachment #1: Type: text/plain, Size: 934 bytes --]
On Tue, Oct 17, 2017 at 12:21:07PM +0200, Jiri Pirko wrote:
> Tue, Oct 17, 2017 at 12:15:09PM CEST, broonie@kernel.org wrote:
> >/home/broonie/tmpfs/next/net/sched/cls_flower.c:270:27: error: 'struct cls_fl_filter' has no member named 'hw_dev'
> > cls_flower.egress_dev = f->hw_dev != tp->q->dev_queue->dev;
> This fix ("net/sched: cls_flower: Set egress_dev mark when calling into the HW driver")
> went to -net tree, should not go to -next. Apparently there is some mixup.
> DaveM?
The issue is that:
> > 7578d7b45ed870b1 ("net: sched: remove unused tcf_exts_get_dev helper and cls_flower->egress_dev")
> >both in the net-next tree. Falling back to previous net-next trees
> >introduced other issues so I reverted that commit for today.
the removal happened in the net-next tree, breaking the commit that was
previously introduced in the net tree (sorry, didn't notice that the
immediate commit was in there not net-next).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: net/sched/cls_flower.c
From: Mark Brown @ 2017-10-17 10:26 UTC (permalink / raw)
To: David Miller, Networking, Or Gerlitz, Roi Dayan, Jiri Pirko
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20171017101509.soy55d4ipx3dusbo@sirena.co.uk>
[-- Attachment #1: Type: text/plain, Size: 315 bytes --]
On Tue, Oct 17, 2017 at 11:15:09AM +0100, Mark Brown wrote:
> Caused by commit
>
> 7578d7b45ed870b13a8ace57e32feaed623c2a94 ("net/sched: cls_flower: Set egress_dev mark when calling into the HW driver")
Cut'n'paste error, this should be
c019b5166e11faaf9ed3b64316ed338eaa19de60
Sorry about that.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 11/15] stm class: make config_item_type const
From: Greg KH @ 2017-10-17 10:25 UTC (permalink / raw)
To: Bhumika Goyal
Cc: julia.lawall, rjw, lenb, alexander.shishkin, jic23, knaack.h,
lars, pmeerw, dledford, sean.hefty, hal.rosenstock, hch, sagi,
kishon, bhelgaas, nab, balbi, laurent.pinchart, jlbec, ccaulfie,
teigland, mfasheh, linux-acpi, linux-kernel, linux-iio,
linux-rdma, netdev, linux-nvme, linux-pci, linux-scsi,
target-devel, linux-usb, cluster-devel, ocfs2-devel
In-Reply-To: <1508167134-6243-12-git-send-email-bhumirks@gmail.com>
On Mon, Oct 16, 2017 at 05:18:50PM +0200, Bhumika Goyal wrote:
> Make config_item_type structures const as they are either passed to a
> function having the argument as const or used inside a if statement or
> stored in the const "ci_type" field of a config_item structure.
>
> Done using Coccinelle.
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
> ---
> * Changes in v2- Combine all the followup patches and the constification
> patches into a series.
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH v2 01/15] configfs: make ci_type field, some pointers and function arguments const
From: Greg KH @ 2017-10-17 10:24 UTC (permalink / raw)
To: Bhumika Goyal
Cc: julia.lawall, rjw, lenb, alexander.shishkin, jic23, knaack.h,
lars, pmeerw, dledford, sean.hefty, hal.rosenstock, hch, sagi,
kishon, bhelgaas, nab, balbi, laurent.pinchart, jlbec, ccaulfie,
teigland, mfasheh, linux-acpi, linux-kernel, linux-iio,
linux-rdma, netdev, linux-nvme, linux-pci, linux-scsi,
target-devel, linux-usb, cluster-devel, ocfs2-devel
In-Reply-To: <1508167134-6243-2-git-send-email-bhumirks@gmail.com>
On Mon, Oct 16, 2017 at 05:18:40PM +0200, Bhumika Goyal wrote:
> The ci_type field of the config_item structure do not modify the fields
> of the config_item_type structure it points to. And the other pointers
> initialized with ci_type do not modify the fields as well.
> So, make the ci_type field and the pointers initialized with ci_type
> as const.
>
> Make the struct config_item_type *type function argument of functions
> config_{item/group}_init_type_name const as the argument in both the
> functions is only stored in the ci_type field of a config_item structure
> which is now made const.
> Make the argument of configfs_register_default_group const as it is
> only passed to the argument of the function config_group_init_type_name
> which is now const.
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
> ---
> * Changes in v2- Combine all the followup patches and the constification
> patches into a series.
>
> fs/configfs/dir.c | 10 +++++-----
> fs/configfs/item.c | 6 +++---
> fs/configfs/symlink.c | 4 ++--
> include/linux/configfs.h | 8 ++++----
> 4 files changed, 14 insertions(+), 14 deletions(-)
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH v2 00/15] make structure field, function arguments and structures const
From: Greg KH @ 2017-10-17 10:23 UTC (permalink / raw)
To: Julia Lawall
Cc: Bhumika Goyal, 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,
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-H+wXaHxf7aLQT0dZR+AlfA, ocfs2-
In-Reply-To: <alpine.DEB.2.20.1710171216060.5035@hadrien>
On Tue, Oct 17, 2017 at 12:16:18PM +0200, Julia Lawall wrote:
>
>
> On Tue, 17 Oct 2017, Greg KH wrote:
>
> > On Mon, Oct 16, 2017 at 05:18:39PM +0200, Bhumika Goyal wrote:
> > > Make the ci_type field and some function arguments as const. After this
> > > change, make config_item_type structures as const.
> > >
> > > * Changes in v2- Combine all the followup patches and the constification
> > > patches into a series.
> >
> > Who do you want to take these patches? If you want, I can take them
> > through my driver-core tree, which has done other configfs stuff like
> > this in the past.
>
> Christoph Hellwig proposed to take care of it.
Great! I'll go ack the individual ones that I might need to...
thanks,
greg k-h
^ permalink raw reply
* [PATCH, net-next] i40e: avoid 64-bit division where possible
From: Arnd Bergmann @ 2017-10-17 10:23 UTC (permalink / raw)
To: Jeff Kirsher
Cc: Arnd Bergmann, Jacob Keller, Mitch Williams, Alexander Duyck,
Amritha Nambiar, Filip Sadowski, David S. Miller,
Björn Töpel, intel-wired-lan, netdev, linux-kernel
The new bandwidth calculation causes a link error on 32-bit
architectures, like
ERROR: "__aeabi_uldivmod" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!
The problem is the max_tx_rate calculation that uses 64-bit integers.
This is not really necessary since the numbers are in MBit/s so
they won't be higher than 40000 for the highest support rate, and
are guaranteed to not exceed 2^32 in future generations either.
This changes the representation to 'u32' when dealing with MBit/s
and uses div_u64() to convert from u64 numbers in byte/s.
Fixes: 2027d4deacb1 ("i40e: Add support setting TC max bandwidth rates")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/intel/i40e/i40e.h | 4 ++--
drivers/net/ethernet/intel/i40e/i40e_main.c | 27 ++++++++++++++-------------
2 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e.h b/drivers/net/ethernet/intel/i40e/i40e.h
index 266e1dc5e786..45155ef15d24 100644
--- a/drivers/net/ethernet/intel/i40e/i40e.h
+++ b/drivers/net/ethernet/intel/i40e/i40e.h
@@ -359,7 +359,7 @@ struct i40e_channel {
u8 enabled_tc;
struct i40e_aqc_vsi_properties_data info;
- u64 max_tx_rate;
+ u32 max_tx_rate; /* in Mbits/s */
/* track this channel belongs to which VSI */
struct i40e_vsi *parent_vsi;
@@ -1045,5 +1045,5 @@ static inline bool i40e_enabled_xdp_vsi(struct i40e_vsi *vsi)
}
int i40e_create_queue_channel(struct i40e_vsi *vsi, struct i40e_channel *ch);
-int i40e_set_bw_limit(struct i40e_vsi *vsi, u16 seid, u64 max_tx_rate);
+int i40e_set_bw_limit(struct i40e_vsi *vsi, u16 seid, u32 max_tx_rate);
#endif /* _I40E_H_ */
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 624a2bc8a1df..e71fece72506 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -5439,7 +5439,7 @@ int i40e_get_link_speed(struct i40e_vsi *vsi)
*
* Helper function to set BW limit for a given VSI
**/
-int i40e_set_bw_limit(struct i40e_vsi *vsi, u16 seid, u64 max_tx_rate)
+int i40e_set_bw_limit(struct i40e_vsi *vsi, u16 seid, u32 max_tx_rate)
{
struct i40e_pf *pf = vsi->back;
int speed = 0;
@@ -5448,7 +5448,7 @@ int i40e_set_bw_limit(struct i40e_vsi *vsi, u16 seid, u64 max_tx_rate)
speed = i40e_get_link_speed(vsi);
if (max_tx_rate > speed) {
dev_err(&pf->pdev->dev,
- "Invalid max tx rate %llu specified for VSI seid %d.",
+ "Invalid max tx rate %u specified for VSI seid %d.",
max_tx_rate, seid);
return -EINVAL;
}
@@ -5464,7 +5464,7 @@ int i40e_set_bw_limit(struct i40e_vsi *vsi, u16 seid, u64 max_tx_rate)
I40E_MAX_BW_INACTIVE_ACCUM, NULL);
if (ret)
dev_err(&pf->pdev->dev,
- "Failed set tx rate (%llu Mbps) for vsi->seid %u, err %s aq_err %s\n",
+ "Failed set tx rate (%u Mbps) for vsi->seid %u, err %s aq_err %s\n",
max_tx_rate, seid, i40e_stat_str(&pf->hw, ret),
i40e_aq_str(&pf->hw, pf->hw.aq.asq_last_status));
return ret;
@@ -6067,7 +6067,7 @@ int i40e_create_queue_channel(struct i40e_vsi *vsi,
return -EINVAL;
dev_dbg(&pf->pdev->dev,
- "Set tx rate of %llu Mbps (count of 50Mbps %llu) for vsi->seid %u\n",
+ "Set tx rate of %u Mbps (count of 50Mbps %u) for vsi->seid %u\n",
ch->max_tx_rate,
ch->max_tx_rate / I40E_BW_CREDIT_DIVISOR, ch->seid);
}
@@ -6110,8 +6110,8 @@ static int i40e_configure_queue_channels(struct i40e_vsi *vsi)
/* Bandwidth limit through tc interface is in bytes/s,
* change to Mbit/s
*/
- ch->max_tx_rate =
- vsi->mqprio_qopt.max_rate[i] / (1000000 / 8);
+ ch->max_tx_rate = div_u64(vsi->mqprio_qopt.max_rate[i],
+ 1000000 / 8);
list_add_tail(&ch->list, &vsi->ch_list);
@@ -6554,7 +6554,7 @@ static int i40e_validate_mqprio_qopt(struct i40e_vsi *vsi,
"Invalid min tx rate (greater than 0) specified\n");
return -EINVAL;
}
- sum_max_rate += (mqprio_qopt->max_rate[i] / (1000000 / 8));
+ sum_max_rate += div_u64(mqprio_qopt->max_rate[i], 1000000 / 8);
if (i >= mqprio_qopt->qopt.num_tc - 1)
break;
@@ -6698,12 +6698,12 @@ static int i40e_setup_tc(struct net_device *netdev, void *type_data)
if (pf->flags & I40E_FLAG_TC_MQPRIO) {
if (vsi->mqprio_qopt.max_rate[0]) {
- u64 max_tx_rate = vsi->mqprio_qopt.max_rate[0] /
- (1000000 / 8);
+ u32 max_tx_rate = div_u64(vsi->mqprio_qopt.max_rate[0],
+ 1000000 / 8);
ret = i40e_set_bw_limit(vsi, vsi->seid, max_tx_rate);
if (!ret) {
dev_dbg(&vsi->back->pdev->dev,
- "Set tx rate of %llu Mbps (count of 50Mbps %llu) for vsi->seid %u\n",
+ "Set tx rate of %u Mbps (count of 50Mbps %u) for vsi->seid %u\n",
max_tx_rate,
max_tx_rate / I40E_BW_CREDIT_DIVISOR,
vsi->seid);
@@ -8171,7 +8171,7 @@ static int i40e_rebuild_channels(struct i40e_vsi *vsi)
return -EINVAL;
dev_dbg(&vsi->back->pdev->dev,
- "Set tx rate of %llu Mbps (count of 50Mbps %llu) for vsi->seid %u\n",
+ "Set tx rate of %u Mbps (count of 50Mbps %u) for vsi->seid %u\n",
ch->max_tx_rate,
ch->max_tx_rate / I40E_BW_CREDIT_DIVISOR,
ch->seid);
@@ -8446,12 +8446,13 @@ static void i40e_rebuild(struct i40e_pf *pf, bool reinit, bool lock_acquired)
}
if (vsi->mqprio_qopt.max_rate[0]) {
- u64 max_tx_rate = vsi->mqprio_qopt.max_rate[0] / (1000000 / 8);
+ u32 max_tx_rate = div_u64(vsi->mqprio_qopt.max_rate[0],
+ 1000000 / 8);
ret = i40e_set_bw_limit(vsi, vsi->seid, max_tx_rate);
if (!ret)
dev_dbg(&vsi->back->pdev->dev,
- "Set tx rate of %llu Mbps (count of 50Mbps %llu) for vsi->seid %u\n",
+ "Set tx rate of %u Mbps (count of 50Mbps %u) for vsi->seid %u\n",
max_tx_rate,
max_tx_rate / I40E_BW_CREDIT_DIVISOR,
vsi->seid);
--
2.9.0
^ permalink raw reply related
* Re: linux-next: net/sched/cls_flower.c
From: Jiri Pirko @ 2017-10-17 10:21 UTC (permalink / raw)
To: Mark Brown
Cc: David Miller, Networking, Or Gerlitz, Roi Dayan, Jiri Pirko,
Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20171017101509.soy55d4ipx3dusbo@sirena.co.uk>
Tue, Oct 17, 2017 at 12:15:09PM CEST, broonie@kernel.org wrote:
>Hi all,
>
>After merging the net-next tree, today's linux-next build
>(x86_allmodconfig) failed like this:
>
>/home/broonie/tmpfs/next/net/sched/cls_flower.c: In function 'fl_hw_destroy_filter':
>/home/broonie/tmpfs/next/net/sched/cls_flower.c:208:12: error: 'struct tc_cls_flower_offload' has no member named 'egress_dev'
> cls_flower.egress_dev = f->hw_dev != tp->q->dev_queue->dev;
> ^
>/home/broonie/tmpfs/next/net/sched/cls_flower.c:208:27: error: 'struct cls_fl_filter' has no member named 'hw_dev'
> cls_flower.egress_dev = f->hw_dev != tp->q->dev_queue->dev;
> ^
>/home/broonie/tmpfs/next/net/sched/cls_flower.c: In function 'fl_hw_update_stats':
>/home/broonie/tmpfs/next/net/sched/cls_flower.c:270:12: error: 'struct tc_cls_flower_offload' has no member named 'egress_dev'
> cls_flower.egress_dev = f->hw_dev != tp->q->dev_queue->dev;
> ^
>/home/broonie/tmpfs/next/net/sched/cls_flower.c:270:27: error: 'struct cls_fl_filter' has no member named 'hw_dev'
> cls_flower.egress_dev = f->hw_dev != tp->q->dev_queue->dev;
This fix ("net/sched: cls_flower: Set egress_dev mark when calling into the HW driver")
went to -net tree, should not go to -next. Apparently there is some mixup.
DaveM?
> ^
>/home/broonie/tmpfs/next/scripts/Makefile.build:319: recipe for target 'net/sched/cls_flower.o' failed
>
>Caused by commit
>
> 7578d7b45ed870b13a8ace57e32feaed623c2a94 ("net/sched: cls_flower: Set egress_dev mark when calling into the HW driver")
>
>interacting with
>
> 7578d7b45ed870b1 ("net: sched: remove unused tcf_exts_get_dev helper and cls_flower->egress_dev")
>
>both in the net-next tree. Falling back to previous net-next trees
>introduced other issues so I reverted that commit for today.
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: sh_eth: implement R-Car Gen[12] fallback compatibility strings
From: Sergei Shtylyov @ 2017-10-17 10:20 UTC (permalink / raw)
To: Simon Horman, David Miller; +Cc: Magnus Damm, netdev, linux-renesas-soc
In-Reply-To: <20171017074747.24159-4-horms+renesas@verge.net.au>
On 10/17/2017 10:47 AM, Simon Horman wrote:
> Implement fallback compatibility strings for R-Car Gen 1 and 2.
>
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship
> between IP blocks might be. For example, I believe that r8a7790 is older
> than r8a7791 but that doesn't imply that the latter is a descendant of the
> former or vice versa.
>
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
>
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
> drivers for Renesas SoCs.
>
> Note that R-Car Gen2 and RZ/G1 have many compatible IP blocks. The
> approach that has been consistently taken for other IP blocks is to name
> common code, compatibility strings and so on after Rcar Gen2.
R-Car again. :-)
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* Re: Linux 4.12+ memory leak on router with i40e NICs
From: Paweł Staszewski @ 2017-10-17 10:20 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: <f6e2208a-4cdf-3303-5999-92186b437b62@itcare.pl>
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
^ permalink raw reply
* Re: [PATCH net-next 1/3] dt-bindings: net: sh_eth: add R-Car Gen[12] fallback compatibility strings
From: Sergei Shtylyov @ 2017-10-17 10:18 UTC (permalink / raw)
To: Simon Horman, David Miller; +Cc: Magnus Damm, netdev, linux-renesas-soc
In-Reply-To: <20171017074747.24159-2-horms+renesas@verge.net.au>
On 10/17/2017 10:47 AM, Simon Horman wrote:
> Add fallback compatibility strings for R-Car Gen 1 and 2.
>
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship
> between IP blocks might be. For example, I believe that r8a7790 is older
> than r8a7791 but that doesn't imply that the latter is a descendant of the
> former or vice versa.
>
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
>
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
> drivers for Renesas SoCs.
>
> Note that R-Car Gen2 and RZ/G1 have many compatible IP blocks. The
> approach that has been consistently taken for other IP blocks is to name
> common code, compatibility strings and so on after Rcar Gen2.
R-Car here too. :-)
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
MBR, Sergei
^ 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