From: Ido Schimmel
When we remove the neighbour associated with a nexthop we should always
refuse to write the nexthop to the adjacency table. Regardless if it is
already present in the table or not.
Otherwise, we risk dereferencing the NULL pointer that was set instead
of the neighbour.
Fixes:
Commit 582442d6d5bc ("ipv6: Allow the MTU of ipip6 tunnel to be set
below 1280") fixed a mtu setting issue. It works for ipip6 tunnel.
But ip6gre dev updates the mtu also with ip6_tnl_change_mtu. Since
the inner packet over ip6gre can be ipv4 and it's mtu should also
be allowed to set below 1280,
Commit a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path") has fixed
a performance issue caused by the change of lower dev's mtu for vxlan.
The same thing needs to be done for geneve as well.
Note that geneve cannot adjust it's mtu according to lower dev's mtu
when creating it. The performance
When dev_requeue_skb() is called with bluked skb list, only the
first skb of the list will be requeued to qdisc layer, and leak
the others without free them.
TCP is broken due to skb leak since no free skb will be considered
as still in the host queue and never be retransmitted. This happend
when
> When dev_requeue_skb() is called with bluked skb list, only the
> first skb of the list will be requeued to qdisc layer, and leak
> the others without free them.
>
> TCP is broken due to skb leak since no free skb will be considered
> as still in the host queue and never be retransmitted. This h
When dev_requeue_skb() is called with bluked skb list, only the
first skb of the list will be requeued to qdisc layer, and leak
the others without free them.
TCP is broken due to skb leak since no free skb will be considered
as still in the host queue and never be retransmitted. This happend
when
When an ip6_tunnel is in mode 'any', where the transport layer
protocol can be either 4 or 41, dst_cache must be disabled.
This is because xfrm policies might apply to only one of the two
protocols. Caching dst would cause xfrm policies for one protocol
incorrectly used for the other.
Cc: sta...@
On 2017/12/23 21:45, Greg KH wrote:
> On Sat, Dec 23, 2017 at 07:02:59PM +0800, Yisheng Xie wrote:
>> --- a/lib/devres.c
>> +++ b/lib/devres.c
>> @@ -44,35 +44,6 @@ void __iomem *devm_ioremap(struct device *dev,
>> resource_size_t offset,
>> EXPORT_SYMBOL(devm_ioremap);
>>
>> /**
>> - * devm
On 2017/12/24 17:05, christophe leroy wrote:
>
>
> Le 23/12/2017 à 14:48, Greg KH a écrit :
>> On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote:
>>> Hi all,
>>>
>>> When I tried to use devm_ioremap function and review related code, I found
>>> devm_ioremap and devm_ioremap_nocache is
DT bindings for the AVE ethernet controller found on Socionext's
UniPhier platforms.
Signed-off-by: Kunihiko Hayashi
Signed-off-by: Jassi Brar
Acked-by: Rob Herring
---
.../bindings/net/socionext,uniphier-ave4.txt | 47 ++
1 file changed, 47 insertions(+)
create mode
The UniPhier platform from Socionext provides the AVE ethernet
controller that includes MAC and MDIO bus supporting RGMII/RMII
modes. The controller is named AVE.
Signed-off-by: Kunihiko Hayashi
Signed-off-by: Jassi Brar
Reviewed-by: Andrew Lunn
---
drivers/net/ethernet/Kconfig |
This series adds support for Socionext AVE ethernet controller implemented
on UniPhier SoCs. This driver supports RGMII/RMII modes.
v7: https://www.spinics.net/lists/netdev/msg473896.html
The PHY patch included in v1 has already separated in:
http://www.spinics.net/lists/netdev/msg454595.html
Ch
hi Christophe and Greg,
On 2017/12/24 16:55, christophe leroy wrote:
>
>
> Le 23/12/2017 à 16:57, Guenter Roeck a écrit :
>> On 12/23/2017 05:48 AM, Greg KH wrote:
>>> On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote:
Hi all,
When I tried to use devm_ioremap function an
Hi,
Found weird issue starting from 4.14 kernels.
IPSec tunnels with IPComp enabled are not working.
There are a couple of similar reports in strongSwan's wiki and mailing
list.
Resolution is simple - disable compression.
I have tested all kernels from 4.14 to 4.14.8 - does not work. But works
On Sun, Dec 24, 2017 at 11:24 AM, Andreas Hartmann
wrote:
> On 12/20/2017 at 04:56 PM Andreas Hartmann wrote:
>> On 12/18/2017 at 06:11 PM Andreas Hartmann wrote:
>>> On 12/17/2017 at 11:33 PM Willem de Bruijn wrote:
>> [...]
I have been able to reproduce the hang by sending a UFO packet
On Sun 2017-12-10 21:17:55, Ben Whitten wrote:
> This commit introduces a NETDEV trigger for named device
> activity. Available triggers are link, rx, and tx.
>
> Signed-off-by: Ben Whitten
Acked-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://a
On Wed, 20 Dec 2017 13:40:37 +0900
Toshiaki Makita wrote:
> +
> +static const struct virtnet_gstats virtnet_gstrings_stats[] = {
> + { "rx_packets", VIRTNET_NETDEV_STAT(rx_packets) },
> + { "tx_packets", VIRTNET_NETDEV_STAT(tx_packets) },
> + { "rx_bytes", VI
If -S is not used in the command line, we should
be binding to *.. Similarly, cfg_port should be
used to connect to the remote host even if it is processed
after -D. Thus we need to make sure that the cfg_port in
cfg_src_addr and cfg_dst_addr are always initialized
after all other command line opti
On 12/24/17 1:19 AM, Jiri Pirko wrote:
> Sun, Dec 24, 2017 at 02:54:47AM CET, dsah...@gmail.com wrote:
>> On 12/23/17 9:54 AM, Jiri Pirko wrote:
>>> So back to the example. First, we create 2 qdiscs. Both will share
>>> block number 22. "22" is just an identification. If we don't pass any
>>> block
On 12/20/2017 at 04:56 PM Andreas Hartmann wrote:
> On 12/18/2017 at 06:11 PM Andreas Hartmann wrote:
>> On 12/17/2017 at 11:33 PM Willem de Bruijn wrote:
> [...]
>>> I have been able to reproduce the hang by sending a UFO packet
>>> between two guests running v4.13 on a host running v4.15-rc1.
>>>
There's a space character missed in the printk messages.
Put the message into one line could simplify searching for
the messages in the kernel source.
Fixes: 563e0bb0dc74("net: tracepoint: replace tcp_set_state tracepoint with
inet_sock_set_state tracepoint")
Cc: Sergei Shtylyov
Signed-off-by: Y
From: Mark Bloch
Refactor the load/unload stages for better code reuse.
Signed-off-by: Mark Bloch
Reviewed-by: Or Gerlitz
Signed-off-by: Saeed Mahameed
---
.../ethernet/mellanox/mlx5/core/eswitch_offloads.c | 66 +-
1 file changed, 40 insertions(+), 26 deletions(-)
diff
From: Mark Bloch
In order for representors to send packets directly to VFs we use an
E-Switch function which insert special rules into the HW. For symmetry
create an E-Switch function that deletes these rules as well.
Signed-off-by: Mark Bloch
Reviewed-by: Or Gerlitz
Signed-off-by: Saeed Maham
From: Gal Pressman
Using the address of a static array is the same as using its name (in
this specific use-case), but it's confusing and makes the code less
readable.
Fixes: 1bd27b11c1df ("net/mlx5: Introduce E-switch QoS management")
Fixes: bd77bf1cb595 ("net/mlx5: Add SRIOV VF max rate configu
From: Mark Bloch
In our pursuit to cleanup e-switch sub-module from mlx5e specific code,
we move the functions that insert/remove the flow steering rules that
allow mlx5e representors to send packets directly to VFs into the EN
driver code.
Signed-off-by: Mark Bloch
Reviewed-by: Or Gerlitz
Sig
Hi Dave and Doug,
==
This series includes updates for mlx5 E-Switch infrastructures,
to be merged into net-next and rdma-next trees.
Mark's patches provide E-Switch refactoring that generalize the mlx5
E-Switch vf representors interfaces and data structures. The serious is
mainly focu
From: Gal Pressman
The functions names do not represent their actions, switch the mistaken
ingress/egress naming.
Fixes: fba53f7b5719 ("net/mlx5: Introduce mlx5_flow_steering structure")
Signed-off-by: Gal Pressman
Signed-off-by: Saeed Mahameed
---
drivers/net/ethernet/mellanox/mlx5/core/fs_c
From: Mark Bloch
Ethernet representors have a need to store data which is applicable
only for them. Create a priv void pointer in struct mlx5_eswitch_rep
and move mlx5e to store the relevant data there. As part of this change
we also initialize rep_if in mlx5e_rep_register_vf_vports() as otherwis
From: Mark Bloch
Now that we don't store type dependent data in struct mlx5_eswitch_rep
we can create a generic interface, and representor type.
struct mlx5_eswitch_rep will store an array of interfaces, each
interface is used by a different representor type.
Once we moved to a more generic int
From: Mark Bloch
Refactor the init stage of vport representors registration.
vport number and hw id can be assigned by the E-Switch driver and not by
the netdevice driver. While here, make the error path of mlx5_eswitch_init()
a reverse order of the good path, also use kcalloc to allocate an arra
From: Mark Bloch
Move struct mlx5_esw_sq which keeps send-to-vport rule to from the eswitch
code to mlx5e and rename it to better reflect where it belongs
Signed-off-by: Mark Bloch
Reviewed-by: Or Gerlitz
Signed-off-by: Saeed Mahameed
---
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 2
From: Gal Pressman
Each vport has its own root flow table for the ACL flow tables and root
flow table is per namespace, therefore we should create a namespace for
each vport.
Fixes: efdc810ba39d ("net/mlx5: Flow steering, Add vport ACL support")
Signed-off-by: Gal Pressman
Signed-off-by: Saeed
From: Mark Bloch
In the load() callback for loading representors we don't really need
struct mlx5_eswitch but struct mlx5_core_dev, pass it directly.
In the unload() callback for unloading representors we don't need the
struct mlx5_eswitch argument, remove it.
Signed-off-by: Mark Bloch
Reviewe
On 22/12/2017 7:12 PM, Jesper Dangaard Brouer wrote:
Driver hook points for xdp_rxq_info:
* reg : mlx4_en_create_rx_ring
* unreg: mlx4_en_destroy_rx_ring
Tested on actual hardware.
Cc: Tariq Toukan
Signed-off-by: Jesper Dangaard Brouer
Reviewed-by: Tariq Toukan
Thanks.
On Thu, Dec 21, 2017 at 5:03 PM, David Miller wrote:
> From: Saeed Mahameed
> Date: Thu, 21 Dec 2017 06:19:09 +
>
>> On Wed, 2017-12-20 at 12:56 -0500, David Miller wrote:
>>> From: Saeed Mahameed
>>> Date: Tue, 19 Dec 2017 12:33:29 -0800
>>>
>>> > This patchset is based on rc4 and I see tha
On 23.12.2017 21:10, Mathias Tillman wrote:
Thank you, I will test that patch and see if I can find anything interesting in the log. Will have to be some time later next week due to
the holidays, but I will get back to you with the results.
Ok, I'll be waiting.
Probably you could share your ke
Le 23/12/2017 à 14:48, Greg KH a écrit :
On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote:
Hi all,
When I tried to use devm_ioremap function and review related code, I found
devm_ioremap and devm_ioremap_nocache is almost the same with each other,
except one use ioremap while the o
Le 23/12/2017 à 16:57, Guenter Roeck a écrit :
On 12/23/2017 05:48 AM, Greg KH wrote:
On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote:
Hi all,
When I tried to use devm_ioremap function and review related code, I
found
devm_ioremap and devm_ioremap_nocache is almost the same with
38 matches
Mail list logo
