* [PATCH rdma-next] net/mlx5: Use flow counter pointer as input to the query function
From: Or Gerlitz @ 2018-05-30 6:35 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: Leon Romanovsky, raeds, linux-rdma, netdev, Or Gerlitz
This allows to un-expose the details of struct mlx5_fc and keep
it internal to the core driver as it used to be.
Change-Id: I780cd74863fa2beccdd52e7d0cdd1e117a5aa353
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
Jason,
As you asked, I am sending a fixup in case you intend to apply
V2 of the flow counter series [1], if there's going to be V3,
Leon, please apply it from the begining.
Or.
[1] https://marc.info/?l=linux-netdev&m=152759937829994&w=2
drivers/infiniband/hw/mlx5/main.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 15 ++++++--------
drivers/net/ethernet/mellanox/mlx5/core/fs_core.h | 22 +++++++++++++++++---
.../net/ethernet/mellanox/mlx5/core/fs_counters.c | 4 ++--
include/linux/mlx5/fs.h | 24 ++++------------------
5 files changed, 32 insertions(+), 35 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
index ac99125..4b09dcd 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -3151,7 +3151,7 @@ static int read_flow_counters(struct ib_device *ibdev,
struct mlx5_fc *fc = read_attr->hw_cntrs_hndl;
struct mlx5_ib_dev *dev = to_mdev(ibdev);
- return mlx5_fc_query(dev->mdev, fc->id,
+ return mlx5_fc_query(dev->mdev, fc,
&read_attr->out[IB_COUNTER_PACKETS],
&read_attr->out[IB_COUNTER_BYTES]);
}
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
index 6cab1dd..f63dfbc 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
@@ -2104,21 +2104,18 @@ static int mlx5_eswitch_query_vport_drop_stats(struct mlx5_core_dev *dev,
struct mlx5_vport *vport = &esw->vports[vport_idx];
u64 rx_discard_vport_down, tx_discard_vport_down;
u64 bytes = 0;
- u16 idx = 0;
int err = 0;
if (!vport->enabled || esw->mode != SRIOV_LEGACY)
return 0;
- if (vport->egress.drop_counter) {
- idx = vport->egress.drop_counter->id;
- mlx5_fc_query(dev, idx, &stats->rx_dropped, &bytes);
- }
+ if (vport->egress.drop_counter)
+ mlx5_fc_query(dev, vport->egress.drop_counter,
+ &stats->rx_dropped, &bytes);
- if (vport->ingress.drop_counter) {
- idx = vport->ingress.drop_counter->id;
- mlx5_fc_query(dev, idx, &stats->tx_dropped, &bytes);
- }
+ if (vport->ingress.drop_counter)
+ mlx5_fc_query(dev, vport->ingress.drop_counter,
+ &stats->tx_dropped, &bytes);
if (!MLX5_CAP_GEN(dev, receive_discard_vport_down) &&
!MLX5_CAP_GEN(dev, transmit_discard_vport_down))
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h
index 40992ae..0211d77 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h
@@ -131,6 +131,25 @@ struct mlx5_flow_table {
struct rhltable fgs_hash;
};
+struct mlx5_fc_cache {
+ u64 packets;
+ u64 bytes;
+ u64 lastuse;
+};
+
+struct mlx5_fc {
+ struct rb_node node;
+ struct list_head list;
+
+ u64 lastpackets;
+ u64 lastbytes;
+
+ u32 id;
+ bool deleted;
+ bool aging;
+ struct mlx5_fc_cache cache ____cacheline_aligned_in_smp;
+};
+
struct mlx5_ft_underlay_qp {
struct list_head list;
u32 qpn;
@@ -210,9 +229,6 @@ void mlx5_fc_queue_stats_work(struct mlx5_core_dev *dev,
unsigned long delay);
void mlx5_fc_update_sampling_interval(struct mlx5_core_dev *dev,
unsigned long interval);
-int mlx5_fc_query(struct mlx5_core_dev *dev, u16 id,
- u64 *packets, u64 *bytes);
-
int mlx5_init_fs(struct mlx5_core_dev *dev);
void mlx5_cleanup_fs(struct mlx5_core_dev *dev);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c b/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c
index 10f4078..58af6be 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c
@@ -314,10 +314,10 @@ void mlx5_cleanup_fc_stats(struct mlx5_core_dev *dev)
}
}
-int mlx5_fc_query(struct mlx5_core_dev *dev, u16 id,
+int mlx5_fc_query(struct mlx5_core_dev *dev, struct mlx5_fc *counter,
u64 *packets, u64 *bytes)
{
- return mlx5_cmd_fc_query(dev, id, packets, bytes);
+ return mlx5_cmd_fc_query(dev, counter->id, packets, bytes);
}
EXPORT_SYMBOL(mlx5_fc_query);
diff --git a/include/linux/mlx5/fs.h b/include/linux/mlx5/fs.h
index 4612e0a..ef2f3bf 100644
--- a/include/linux/mlx5/fs.h
+++ b/include/linux/mlx5/fs.h
@@ -185,30 +185,14 @@ int mlx5_modify_rule_destination(struct mlx5_flow_handle *handler,
struct mlx5_fc *mlx5_flow_rule_counter(struct mlx5_flow_handle *handler);
struct mlx5_fc *mlx5_fc_create(struct mlx5_core_dev *dev, bool aging);
void mlx5_fc_destroy(struct mlx5_core_dev *dev, struct mlx5_fc *counter);
+
+struct mlx5_fc *counter;
+
void mlx5_fc_query_cached(struct mlx5_fc *counter,
u64 *bytes, u64 *packets, u64 *lastuse);
-int mlx5_fc_query(struct mlx5_core_dev *dev, u16 id,
+int mlx5_fc_query(struct mlx5_core_dev *dev, struct mlx5_fc *counter,
u64 *packets, u64 *bytes);
-struct mlx5_fc_cache {
- u64 packets;
- u64 bytes;
- u64 lastuse;
-};
-
-struct mlx5_fc {
- struct rb_node node;
- struct list_head list;
-
- u64 lastpackets;
- u64 lastbytes;
-
- u32 id;
- bool deleted;
- bool aging;
- struct mlx5_fc_cache cache ____cacheline_aligned_in_smp;
-};
-
int mlx5_fs_add_rx_underlay_qpn(struct mlx5_core_dev *dev, u32 underlay_qpn);
int mlx5_fs_remove_rx_underlay_qpn(struct mlx5_core_dev *dev, u32 underlay_qpn);
--
2.3.7
^ permalink raw reply related
* [PATCH RESEND rdma-next] net/mlx5: Use flow counter pointer as input to the query function
From: Or Gerlitz @ 2018-05-30 6:44 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: Leon Romanovsky, raeds, linux-rdma, netdev, Or Gerlitz
This allows to un-expose the details of struct mlx5_fc and keep
it internal to the core driver as it used to be.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
Jason,
As you asked, I am sending a fixup in case you intend to apply
V2 of the flow counter series [1], if there's going to be V3,
Leon, please apply it from the begining.
Fixed Jason's address @ my git aliases, he's with MLNX by now..
Or.
[1] https://marc.info/?l=linux-netdev&m=152759937829994&w=2
drivers/infiniband/hw/mlx5/main.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 15 ++++++--------
drivers/net/ethernet/mellanox/mlx5/core/fs_core.h | 22 +++++++++++++++++---
.../net/ethernet/mellanox/mlx5/core/fs_counters.c | 4 ++--
include/linux/mlx5/fs.h | 24 ++++------------------
5 files changed, 32 insertions(+), 35 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
index ac99125..4b09dcd 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -3151,7 +3151,7 @@ static int read_flow_counters(struct ib_device *ibdev,
struct mlx5_fc *fc = read_attr->hw_cntrs_hndl;
struct mlx5_ib_dev *dev = to_mdev(ibdev);
- return mlx5_fc_query(dev->mdev, fc->id,
+ return mlx5_fc_query(dev->mdev, fc,
&read_attr->out[IB_COUNTER_PACKETS],
&read_attr->out[IB_COUNTER_BYTES]);
}
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
index 6cab1dd..f63dfbc 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
@@ -2104,21 +2104,18 @@ static int mlx5_eswitch_query_vport_drop_stats(struct mlx5_core_dev *dev,
struct mlx5_vport *vport = &esw->vports[vport_idx];
u64 rx_discard_vport_down, tx_discard_vport_down;
u64 bytes = 0;
- u16 idx = 0;
int err = 0;
if (!vport->enabled || esw->mode != SRIOV_LEGACY)
return 0;
- if (vport->egress.drop_counter) {
- idx = vport->egress.drop_counter->id;
- mlx5_fc_query(dev, idx, &stats->rx_dropped, &bytes);
- }
+ if (vport->egress.drop_counter)
+ mlx5_fc_query(dev, vport->egress.drop_counter,
+ &stats->rx_dropped, &bytes);
- if (vport->ingress.drop_counter) {
- idx = vport->ingress.drop_counter->id;
- mlx5_fc_query(dev, idx, &stats->tx_dropped, &bytes);
- }
+ if (vport->ingress.drop_counter)
+ mlx5_fc_query(dev, vport->ingress.drop_counter,
+ &stats->tx_dropped, &bytes);
if (!MLX5_CAP_GEN(dev, receive_discard_vport_down) &&
!MLX5_CAP_GEN(dev, transmit_discard_vport_down))
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h
index 40992ae..0211d77 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h
@@ -131,6 +131,25 @@ struct mlx5_flow_table {
struct rhltable fgs_hash;
};
+struct mlx5_fc_cache {
+ u64 packets;
+ u64 bytes;
+ u64 lastuse;
+};
+
+struct mlx5_fc {
+ struct rb_node node;
+ struct list_head list;
+
+ u64 lastpackets;
+ u64 lastbytes;
+
+ u32 id;
+ bool deleted;
+ bool aging;
+ struct mlx5_fc_cache cache ____cacheline_aligned_in_smp;
+};
+
struct mlx5_ft_underlay_qp {
struct list_head list;
u32 qpn;
@@ -210,9 +229,6 @@ void mlx5_fc_queue_stats_work(struct mlx5_core_dev *dev,
unsigned long delay);
void mlx5_fc_update_sampling_interval(struct mlx5_core_dev *dev,
unsigned long interval);
-int mlx5_fc_query(struct mlx5_core_dev *dev, u16 id,
- u64 *packets, u64 *bytes);
-
int mlx5_init_fs(struct mlx5_core_dev *dev);
void mlx5_cleanup_fs(struct mlx5_core_dev *dev);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c b/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c
index 10f4078..58af6be 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c
@@ -314,10 +314,10 @@ void mlx5_cleanup_fc_stats(struct mlx5_core_dev *dev)
}
}
-int mlx5_fc_query(struct mlx5_core_dev *dev, u16 id,
+int mlx5_fc_query(struct mlx5_core_dev *dev, struct mlx5_fc *counter,
u64 *packets, u64 *bytes)
{
- return mlx5_cmd_fc_query(dev, id, packets, bytes);
+ return mlx5_cmd_fc_query(dev, counter->id, packets, bytes);
}
EXPORT_SYMBOL(mlx5_fc_query);
diff --git a/include/linux/mlx5/fs.h b/include/linux/mlx5/fs.h
index 4612e0a..ef2f3bf 100644
--- a/include/linux/mlx5/fs.h
+++ b/include/linux/mlx5/fs.h
@@ -185,30 +185,14 @@ int mlx5_modify_rule_destination(struct mlx5_flow_handle *handler,
struct mlx5_fc *mlx5_flow_rule_counter(struct mlx5_flow_handle *handler);
struct mlx5_fc *mlx5_fc_create(struct mlx5_core_dev *dev, bool aging);
void mlx5_fc_destroy(struct mlx5_core_dev *dev, struct mlx5_fc *counter);
+
+struct mlx5_fc *counter;
+
void mlx5_fc_query_cached(struct mlx5_fc *counter,
u64 *bytes, u64 *packets, u64 *lastuse);
-int mlx5_fc_query(struct mlx5_core_dev *dev, u16 id,
+int mlx5_fc_query(struct mlx5_core_dev *dev, struct mlx5_fc *counter,
u64 *packets, u64 *bytes);
-struct mlx5_fc_cache {
- u64 packets;
- u64 bytes;
- u64 lastuse;
-};
-
-struct mlx5_fc {
- struct rb_node node;
- struct list_head list;
-
- u64 lastpackets;
- u64 lastbytes;
-
- u32 id;
- bool deleted;
- bool aging;
- struct mlx5_fc_cache cache ____cacheline_aligned_in_smp;
-};
-
int mlx5_fs_add_rx_underlay_qpn(struct mlx5_core_dev *dev, u32 underlay_qpn);
int mlx5_fs_remove_rx_underlay_qpn(struct mlx5_core_dev *dev, u32 underlay_qpn);
--
2.3.7
^ permalink raw reply related
* Re: [PATCH RESEND rdma-next] net/mlx5: Use flow counter pointer as input to the query function
From: Leon Romanovsky @ 2018-05-30 6:59 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Jason Gunthorpe, raeds, linux-rdma, netdev
In-Reply-To: <1527662674-16546-1-git-send-email-ogerlitz@mellanox.com>
[-- Attachment #1: Type: text/plain, Size: 7931 bytes --]
On Wed, May 30, 2018 at 09:44:34AM +0300, Or Gerlitz wrote:
> This allows to un-expose the details of struct mlx5_fc and keep
> it internal to the core driver as it used to be.
>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
> ---
>
> Jason,
>
> As you asked, I am sending a fixup in case you intend to apply
> V2 of the flow counter series [1], if there's going to be V3,
> Leon, please apply it from the begining.
>
> Fixed Jason's address @ my git aliases, he's with MLNX by now..
>
> Or.
>
> [1] https://marc.info/?l=linux-netdev&m=152759937829994&w=2
>
> drivers/infiniband/hw/mlx5/main.c | 2 +-
> drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 15 ++++++--------
> drivers/net/ethernet/mellanox/mlx5/core/fs_core.h | 22 +++++++++++++++++---
> .../net/ethernet/mellanox/mlx5/core/fs_counters.c | 4 ++--
> include/linux/mlx5/fs.h | 24 ++++------------------
> 5 files changed, 32 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
> index ac99125..4b09dcd 100644
> --- a/drivers/infiniband/hw/mlx5/main.c
> +++ b/drivers/infiniband/hw/mlx5/main.c
> @@ -3151,7 +3151,7 @@ static int read_flow_counters(struct ib_device *ibdev,
> struct mlx5_fc *fc = read_attr->hw_cntrs_hndl;
> struct mlx5_ib_dev *dev = to_mdev(ibdev);
>
> - return mlx5_fc_query(dev->mdev, fc->id,
> + return mlx5_fc_query(dev->mdev, fc,
> &read_attr->out[IB_COUNTER_PACKETS],
> &read_attr->out[IB_COUNTER_BYTES]);
> }
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> index 6cab1dd..f63dfbc 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> @@ -2104,21 +2104,18 @@ static int mlx5_eswitch_query_vport_drop_stats(struct mlx5_core_dev *dev,
> struct mlx5_vport *vport = &esw->vports[vport_idx];
> u64 rx_discard_vport_down, tx_discard_vport_down;
> u64 bytes = 0;
> - u16 idx = 0;
> int err = 0;
>
> if (!vport->enabled || esw->mode != SRIOV_LEGACY)
> return 0;
>
> - if (vport->egress.drop_counter) {
> - idx = vport->egress.drop_counter->id;
> - mlx5_fc_query(dev, idx, &stats->rx_dropped, &bytes);
> - }
> + if (vport->egress.drop_counter)
> + mlx5_fc_query(dev, vport->egress.drop_counter,
> + &stats->rx_dropped, &bytes);
>
> - if (vport->ingress.drop_counter) {
> - idx = vport->ingress.drop_counter->id;
> - mlx5_fc_query(dev, idx, &stats->tx_dropped, &bytes);
> - }
> + if (vport->ingress.drop_counter)
> + mlx5_fc_query(dev, vport->ingress.drop_counter,
> + &stats->tx_dropped, &bytes);
>
> if (!MLX5_CAP_GEN(dev, receive_discard_vport_down) &&
> !MLX5_CAP_GEN(dev, transmit_discard_vport_down))
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h
> index 40992ae..0211d77 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h
> @@ -131,6 +131,25 @@ struct mlx5_flow_table {
> struct rhltable fgs_hash;
> };
>
> +struct mlx5_fc_cache {
> + u64 packets;
> + u64 bytes;
> + u64 lastuse;
> +};
> +
> +struct mlx5_fc {
> + struct rb_node node;
> + struct list_head list;
> +
> + u64 lastpackets;
> + u64 lastbytes;
> +
> + u32 id;
> + bool deleted;
> + bool aging;
> + struct mlx5_fc_cache cache ____cacheline_aligned_in_smp;
> +};
> +
> struct mlx5_ft_underlay_qp {
> struct list_head list;
> u32 qpn;
> @@ -210,9 +229,6 @@ void mlx5_fc_queue_stats_work(struct mlx5_core_dev *dev,
> unsigned long delay);
> void mlx5_fc_update_sampling_interval(struct mlx5_core_dev *dev,
> unsigned long interval);
> -int mlx5_fc_query(struct mlx5_core_dev *dev, u16 id,
> - u64 *packets, u64 *bytes);
> -
> int mlx5_init_fs(struct mlx5_core_dev *dev);
> void mlx5_cleanup_fs(struct mlx5_core_dev *dev);
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c b/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c
> index 10f4078..58af6be 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c
> @@ -314,10 +314,10 @@ void mlx5_cleanup_fc_stats(struct mlx5_core_dev *dev)
> }
> }
>
> -int mlx5_fc_query(struct mlx5_core_dev *dev, u16 id,
> +int mlx5_fc_query(struct mlx5_core_dev *dev, struct mlx5_fc *counter,
> u64 *packets, u64 *bytes)
> {
> - return mlx5_cmd_fc_query(dev, id, packets, bytes);
> + return mlx5_cmd_fc_query(dev, counter->id, packets, bytes);
> }
> EXPORT_SYMBOL(mlx5_fc_query);
>
> diff --git a/include/linux/mlx5/fs.h b/include/linux/mlx5/fs.h
> index 4612e0a..ef2f3bf 100644
> --- a/include/linux/mlx5/fs.h
> +++ b/include/linux/mlx5/fs.h
> @@ -185,30 +185,14 @@ int mlx5_modify_rule_destination(struct mlx5_flow_handle *handler,
> struct mlx5_fc *mlx5_flow_rule_counter(struct mlx5_flow_handle *handler);
> struct mlx5_fc *mlx5_fc_create(struct mlx5_core_dev *dev, bool aging);
> void mlx5_fc_destroy(struct mlx5_core_dev *dev, struct mlx5_fc *counter);
> +
> +struct mlx5_fc *counter;
> +
> void mlx5_fc_query_cached(struct mlx5_fc *counter,
> u64 *bytes, u64 *packets, u64 *lastuse);
> -int mlx5_fc_query(struct mlx5_core_dev *dev, u16 id,
> +int mlx5_fc_query(struct mlx5_core_dev *dev, struct mlx5_fc *counter,
> u64 *packets, u64 *bytes);
I grabbed this patch and tried to compile, as expected it doesn't compile, because flow counters
code needs "struct mlx5_fc".
_ kernel git:(rdma-next) make -j64 -s
drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.o:(.bss+0x0): multiple definition of `counter'
drivers/net/ethernet/mellanox/mlx5/core/main.o:(.bss+0x140): first defined here
drivers/net/ethernet/mellanox/mlx5/core/fs_core.o:(.bss+0x160): multiple definition of `counter'
drivers/net/ethernet/mellanox/mlx5/core/main.o:(.bss+0x140): first defined here
drivers/net/ethernet/mellanox/mlx5/core/fs_counters.o:(.bss+0x0): multiple definition of `counter'
drivers/net/ethernet/mellanox/mlx5/core/main.o:(.bss+0x140): first defined here
drivers/net/ethernet/mellanox/mlx5/core/lib/clock.o:(.bss+0x0): multiple definition of `counter'
drivers/net/ethernet/mellanox/mlx5/core/main.o:(.bss+0x140): first defined here
drivers/net/ethernet/mellanox/mlx5/core/diag/fs_tracepoint.o:(.bss+0x0): multiple definition of `counter'
drivers/net/ethernet/mellanox/mlx5/core/main.o:(.bss+0x140): first defined here
drivers/net/ethernet/mellanox/mlx5/core/accel/ipsec.o:(.bss+0x0): multiple definition of `counter'
drivers/net/ethernet/mellanox/mlx5/core/main.o:(.bss+0x140): first defined here
drivers/net/ethernet/mellanox/mlx5/core/fpga/ipsec.o:(.bss+0x180): multiple definition of `counter'
drivers/net/ethernet/mellanox/mlx5/core/main.o:(.bss+0x140): first defined here
drivers/net/ethernet/mellanox/mlx5/core/en_main.o:(.bss+0x20): multiple definition of `counter'
drivers/net/ethernet/mellanox/mlx5/core/main.o:(.bss+0x140): first defined here
drivers/net/ethernet/mellanox/mlx5/core/en_common.o:(.bss+0x0): multiple definition of `counter'
.....
Care to pass it through our usual submission channel?
Thanks
>
> -struct mlx5_fc_cache {
> - u64 packets;
> - u64 bytes;
> - u64 lastuse;
> -};
> -
> -struct mlx5_fc {
> - struct rb_node node;
> - struct list_head list;
> -
> - u64 lastpackets;
> - u64 lastbytes;
> -
> - u32 id;
> - bool deleted;
> - bool aging;
> - struct mlx5_fc_cache cache ____cacheline_aligned_in_smp;
> -};
> -
> int mlx5_fs_add_rx_underlay_qpn(struct mlx5_core_dev *dev, u32 underlay_qpn);
> int mlx5_fs_remove_rx_underlay_qpn(struct mlx5_core_dev *dev, u32 underlay_qpn);
>
> --
> 2.3.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH RESEND rdma-next] net/mlx5: Use flow counter pointer as input to the query function
From: Or Gerlitz @ 2018-05-30 7:13 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Or Gerlitz, Jason Gunthorpe, Raed Salem, RDMA mailing list,
Linux Netdev List
In-Reply-To: <20180530065927.GO3697@mtr-leonro.mtl.com>
On Wed, May 30, 2018 at 9:59 AM, Leon Romanovsky <leonro@mellanox.com> wrote:
>
> Care to pass it through our usual submission channel?
sure, Jason asked for a fixup, I will push it internally
Or.
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: Add support to configure SR-IOV VF minimum and maximum queues.
From: Michael Chan @ 2018-05-30 7:18 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Samudrala, Sridhar, David Miller, Netdev, Or Gerlitz
In-Reply-To: <CAJpBn1yyyJueWrtR3frO1NkntTCZxsEZ4heW_sx5--7vpfF_Qw@mail.gmail.com>
On Tue, May 29, 2018 at 11:33 PM, Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
>
> At some points you (Broadcom) were working whole bunch of devlink
> configuration options for the PCIe side of the ASIC. The number of
> queues relates to things like number of allocated MSI-X vectors, which
> if memory serves me was in your devlink patch set. In an ideal world
> we would try to keep all those in one place :)
Yeah, another colleague is now working with Mellanox on something similar.
One difference between those devlink parameters and these queue
parameters is that the former are more permanent and global settings.
For example, number of VFs or number of MSIX per VF are persistent
settings once they are set and after PCIe reset. On the other hand,
these queue settings are pure run-time settings and may be unique for
each VF. These are not stored as there is no room in NVRAM to store
128 sets or more of these parameters.
Anyway, let me discuss this with my colleague to see if there is a
natural fit for these queue parameters in the devlink infrastructure
that they are working on.
>
> For PCIe config there is always the question of what can be configured
> at runtime, and what requires a HW reset. Therefore that devlink API
> which could configure current as well as persistent device settings was
> quite nice. I'm not sure if reallocating queues would ever require
> PCIe block reset but maybe... Certainly it seems the notion of min
> queues would make more sense in PCIe configuration devlink API than
> ethtool channel API to me as well.
>
> Queues are in the grey area between netdev and non-netdev constructs.
> They make sense both from PCIe resource allocation perspective (i.e.
> devlink PCIe settings) and netdev perspective (ethtool) because they
> feed into things like qdisc offloads, maybe per-queue stats etc.
>
> So yes... IMHO it would be nice to add this to a devlink SR-IOV config
> API and/or switchdev representors. But neither of those are really an
> option for you today so IDK :)
^ permalink raw reply
* Re: [PATCH v4 net-next 00/19] inet: frags: bring rhashtables to IP defrag
From: Tariq Toukan @ 2018-05-30 7:20 UTC (permalink / raw)
To: Eric Dumazet, Alexander Aring, Tariq Toukan, Moshe Shemesh
Cc: David Miller, edumazet, netdev, fw, herbert, tgraf, brouer,
alex.aring, stefan, ktkhai, Eran Ben Elisha
In-Reply-To: <13bf3889-4426-b17a-d8d7-e843038a2a82@gmail.com>
On 28/05/2018 7:09 PM, Eric Dumazet wrote:
>
>
> On 05/28/2018 07:52 AM, Alexander Aring wrote:
>
>> as somebody who had similar issues with this patch series I can tell you
>> about what happened for the 6LoWPAN fragmentation.
>>
>> The issue sounds similar, but there is too much missing information here
>> to say something about if you have exactly the issue which we had.
>>
>> Our problem:
>>
>> The patch series uses memcmp() to compare hash keys, we had some padding
>> bytes in our hash key and it occurs that we had sometimes random bytes
>> in this structure when it's put on stack. We solved it by a struct
>> foo_key bar = {}, which in case of gcc it _seems_ it makes a whole
>> memset(bar, 0, ..) on the structure.
>>
>> I asked on the netdev mailinglist how to deal with this problem in
>> general, because = {} works in case of gcc, others compilers may have a
>> different handling or even gcc will changes this behaviour in future.
>> I got no reply so I did what it works for me. :-)
>>
>> At least maybe a memcmp() on structures should never be used, it should
>> be compared by field. I would recommend this way when the compiler is
>> always clever enough to optimize it in some cases, but I am not so a
>> compiler expert to say anything about that.
>>
>> I checked the hash key structures for x86_64 and pahole, so far I didn't
>> find any padding bytes there, but it might be different on
>> architectures or ?compiler?.
>>
>> Additional useful information to check if you running into the same problem
>> would be:
>>
>> - Which architecture do you use?
>>
>> - Do you have similar problems with a veth setup?
>>
>> You could also try this:
>>
>> diff --git a/net/ipv6/reassembly.c b/net/ipv6/reassembly.c
>> index b939b94e7e91..40ece9ab8b12 100644
>> --- a/net/ipv6/reassembly.c
>> +++ b/net/ipv6/reassembly.c
>> @@ -142,19 +142,19 @@ static void ip6_frag_expire(struct timer_list *t)
>> static struct frag_queue *
>> fq_find(struct net *net, __be32 id, const struct ipv6hdr *hdr, int iif)
>> {
>> - struct frag_v6_compare_key key = {
>> - .id = id,
>> - .saddr = hdr->saddr,
>> - .daddr = hdr->daddr,
>> - .user = IP6_DEFRAG_LOCAL_DELIVER,
>> - .iif = iif,
>> - };
>> + struct frag_v6_compare_key key = {};
>> struct inet_frag_queue *q;
>>
>> if (!(ipv6_addr_type(&hdr->daddr) & (IPV6_ADDR_MULTICAST |
>> IPV6_ADDR_LINKLOCAL)))
>> key.iif = 0;
>>
>> + key.id = id;
>> + key.saddr = hdr->saddr;
>> + key.daddr = hdr->daddr;
>> + key.user = IP6_DEFRAG_LOCAL_DELIVER;
>> + key.iif = iif;
>> +
>> q = inet_frag_find(&net->ipv6.frags, &key);
>> if (!q)
>> return NULL;
>>
>> - Alex
>>
>
> Hi Alex.
>
> This patch makes no sense, since struct frag_v6_compare_key has no hole.
>
> Only 6LoWPAN had a problem really, because of its way of having unions (and holes).
>
> Also note that your patch would break the case when we force key.iif to be zero.
>
>
> Tariq, here are my test results : No drops for me.
>
> # ./netperf -H 2607:f8b0:8099:e18:: -t UDP_STREAM
> MIGRATED UDP STREAM TEST from ::0 (::) port 0 AF_INET6 to 2607:f8b0:8099:e18:: () port 0 AF_INET6
> Socket Message Elapsed Messages
> Size Size Time Okay Errors Throughput
> bytes bytes secs # # 10^6bits/sec
>
> 212992 65507 10.00 202117 0 10592.00
> 212992 10.00 0 0.00
>
> Somehow, you might send packets too fast and receiver has a problem with that ?
Not sure, the transmit BW you get is higher than what we saw.
Anyway, we'll check this.
> For particular needs, you might need to adjust :
>
> /proc/sys/net/ipv6/ip6frag_time (to 2 seconds instead of the default of 60)
> /proc/sys/net/ipv6/ip6frag_low_thresh
> /proc/sys/net/ipv6/ip6frag_high_thresh
>
> Once your receiver has filled its capacity with frags, the default of 60 seconds to garbage collect
> might be the reason you notice a problem.
>
> Check :
> grep FRAG6 /proc/net/sockstat6
>
> On Google servers we multiply by 25 the limits for ipv6 frags memory usage :
>
> /proc/sys/net/ipv6/ip6frag_high_thresh:104857600 (instead of 4MB)
> /proc/sys/net/ipv6/ip6frag_low_thresh:78643200 (instead of 3 MB)
>
> When using 64KB datagrams, note that the truesize of the datagram would be about 44 * 2 = 88 KB,
> so after ~40 lost packets in the network, you no longer can accept ipv6 fragments, until garbage
> collector evicted old datagrams.
>
Great.
Moshe, please try the suggested above.
In case these values dramatically improve performance, maybe its time to
change the default.
Thanks,
Tariq
>
>
>
>
>
>
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: clean up eBPF helpers documentation
From: Quentin Monnet @ 2018-05-30 7:28 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Song Liu, Alexei Starovoitov, Networking, oss-drivers
In-Reply-To: <b8f12a25-59ae-b463-9fa8-be9378f83089@iogearbox.net>
On 29 May 2018 at 20:44, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 05/29/2018 08:27 PM, Song Liu wrote:
>> On Tue, May 29, 2018 at 4:27 AM, Quentin Monnet
>> <quentin.monnet@netronome.com> wrote:
>>> These are minor edits for the eBPF helpers documentation in
>>> include/uapi/linux/bpf.h.
>>>
>>> The main fix consists in removing "BPF_FIB_LOOKUP_", because it ends
>>> with a non-escaped underscore that gets interpreted by rst2man and
>>> produces the following message in the resulting manual page:
>>>
>>> DOCUTILS SYSTEM MESSAGES
>>> System Message: ERROR/3 (/tmp/bpf-helpers.rst:, line 1514)
>>> Unknown target name: "bpf_fib_lookup".
>>>
>>> Other edits consist in:
>>>
>>> - Improving formatting for flag values for "bpf_fib_lookup()" helper.
>>> - Emphasising a parameter name in description of the return value for
>>> "bpf_get_stack()" helper.
>>> - Removing unnecessary blank lines between "Description" and "Return"
>>> sections for the few helpers that would use it, for consistency.
>>>
>>> Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
> [...]
>>
>> Please also apply the same changes to tools/include/uapi/linux/bpf.h.
Ah, true, I forgot it... Thanks for the reminder.
> Just did while applying to bpf-next, thanks guys!
>
>> Other than this, it looks to me.
>>
>> Acked-by: Song Liu <songliubraving@fb.com>
Thanks a lot Song, Daniel!
Quentin
^ permalink raw reply
* Re: [PATCH v4 net-next 00/19] inet: frags: bring rhashtables to IP defrag
From: Eric Dumazet @ 2018-05-30 7:36 UTC (permalink / raw)
To: Tariq Toukan
Cc: Eric Dumazet, aring, moshe, David Miller, netdev,
Florian Westphal, Herbert Xu, Thomas Graf, Jesper Dangaard Brouer,
Alexander Aring, Stefan Schmidt, Kirill Tkhai, Eran Ben Elisha
In-Reply-To: <11b2baca-c810-3f61-38d1-415099783129@mellanox.com>
On Wed, May 30, 2018 at 3:20 AM Tariq Toukan <tariqt@mellanox.com> wrote:
> Not sure, the transmit BW you get is higher than what we saw.
> Anyway, we'll check this.
That is on a 40Gbit test bed (mlx4 cx/3), maybe you were using a 10Gbit NIC
?
^ permalink raw reply
* [PATCH net-next 1/2] cls_flower: Fix missing free of rhashtable
From: Paul Blakey @ 2018-05-30 8:17 UTC (permalink / raw)
To: Jiri Pirko, Cong Wang, Jamal Hadi Salim, David Miller, netdev
Cc: Yevgeny Kliteynik, Roi Dayan, Shahar Klein, Mark Bloch,
Or Gerlitz, Paul Blakey
In-Reply-To: <1527668258-27174-1-git-send-email-paulb@mellanox.com>
When destroying the instance, destroy the head rhashtable.
Fixes: 05cd271fd61a ("cls_flower: Support multiple masks per priority")
Reported-by: Vlad Buslov <vladbu@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Paul Blakey <paulb@mellanox.com>
---
net/sched/cls_flower.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index d06e398..ce5983b 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -338,6 +338,8 @@ static void fl_destroy_sleepable(struct work_struct *work)
{
struct cls_fl_head *head = container_of(work, struct cls_fl_head,
work);
+
+ rhashtable_destroy(&head->ht);
kfree(head);
module_put(THIS_MODULE);
}
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 0/2] cls_flower: Various fixes
From: Paul Blakey @ 2018-05-30 8:17 UTC (permalink / raw)
To: Jiri Pirko, Cong Wang, Jamal Hadi Salim, David Miller, netdev
Cc: Yevgeny Kliteynik, Roi Dayan, Shahar Klein, Mark Bloch,
Or Gerlitz, Paul Blakey
Two of the fixes are for my multiple mask patch
Paul Blakey (2):
cls_flower: Fix missing free of rhashtable
cls_flower: Fix comparing of old filter mask with new filter
net/sched/cls_flower.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--
2.7.4
^ permalink raw reply
* [PATCH net-next 2/2] cls_flower: Fix comparing of old filter mask with new filter
From: Paul Blakey @ 2018-05-30 8:17 UTC (permalink / raw)
To: Jiri Pirko, Cong Wang, Jamal Hadi Salim, David Miller, netdev
Cc: Yevgeny Kliteynik, Roi Dayan, Shahar Klein, Mark Bloch,
Or Gerlitz, Paul Blakey
In-Reply-To: <1527668258-27174-1-git-send-email-paulb@mellanox.com>
We incorrectly compare the mask and the result is that we can't modify
an already existing rule.
Fix that by comparing correctly.
Fixes: 05cd271fd61a ("cls_flower: Support multiple masks per priority")
Reported-by: Vlad Buslov <vladbu@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Paul Blakey <paulb@mellanox.com>
---
net/sched/cls_flower.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index ce5983b..3dc9a66 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -897,7 +897,7 @@ static int fl_check_assign_mask(struct cls_fl_head *head,
return PTR_ERR(newmask);
fnew->mask = newmask;
- } else if (fold && fold->mask == fnew->mask) {
+ } else if (fold && fold->mask != fnew->mask) {
return -EINVAL;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] netfilter: nfnetlink: Remove VLA usage
From: Florian Westphal @ 2018-05-30 8:19 UTC (permalink / raw)
To: Kees Cook
Cc: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
David S. Miller, netfilter-devel, coreteam, netdev, linux-kernel
In-Reply-To: <20180530003525.GA18642@beast>
Kees Cook <keescook@chromium.org> wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> allocates the maximum size expected for all possible attrs and adds
> a sanity-check to make sure nothing gets out of sync.
>
> [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> net/netfilter/nfnetlink.c | 22 ++++++++++++++++++++--
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/net/netfilter/nfnetlink.c b/net/netfilter/nfnetlink.c
> index 03ead8a9e90c..0cb395f9627e 100644
> --- a/net/netfilter/nfnetlink.c
> +++ b/net/netfilter/nfnetlink.c
> @@ -28,6 +28,7 @@
>
> #include <net/netlink.h>
> #include <linux/netfilter/nfnetlink.h>
> +#include <linux/netfilter/nf_tables.h>
>
> const struct nfnetlink_subsystem __rcu *subsys;
> @@ -185,11 +191,17 @@ static int nfnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh,
> {
> int min_len = nlmsg_total_size(sizeof(struct nfgenmsg));
> u8 cb_id = NFNL_MSG_TYPE(nlh->nlmsg_type);
> - struct nlattr *cda[ss->cb[cb_id].attr_count + 1];
> + struct nlattr *cda[NFTA_MAX_ATTR + 1];
> struct nlattr *attr = (void *)nlh + min_len;
> int attrlen = nlh->nlmsg_len - min_len;
> __u8 subsys_id = NFNL_SUBSYS_ID(type);
>
> + /* Sanity-check NFTA_MAX_ATTR */
> + if (ss->cb[cb_id].attr_count > NFTA_MAX_ATTR) {
> + rcu_read_unlock();
> + return -ENOMEM;
> + }
Would you mind also adding check to nfnetlink_subsys_register, plus WARN()?
That way we'll see that NFTA_MAX_ATTR isn't large enough by virtue
of registration rather than actual use.
Other than that this looks fine to me.
^ permalink raw reply
* [PATCH net] cls_flower: Fix incorrect idr release when failing to modify rule
From: Paul Blakey @ 2018-05-30 8:29 UTC (permalink / raw)
To: Jiri Pirko, Cong Wang, Jamal Hadi Salim, David Miller, netdev
Cc: Yevgeny Kliteynik, Roi Dayan, Shahar Klein, Mark Bloch,
Or Gerlitz, Paul Blakey
When we fail to modify a rule, we incorrectly release the idr handle
of the unmodified old rule.
Fix that by checking if we need to release it.
Fixes: fe2502e49b58 ("net_sched: remove cls_flower idr on failure")
Reported-by: Vlad Buslov <vladbu@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Paul Blakey <paulb@mellanox.com>
---
net/sched/cls_flower.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index d964e60..c79f6e7 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -977,7 +977,7 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
return 0;
errout_idr:
- if (fnew->handle)
+ if (!fold)
idr_remove(&head->handle_idr, fnew->handle);
errout:
tcf_exts_destroy(&fnew->exts);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next v16 4/8] netfilter: Add nf_ct_get_tuple_skb callback
From: kbuild test robot @ 2018-05-30 8:33 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: kbuild-all, netdev, cake, netfilter-devel
In-Reply-To: <152751766686.30935.14644567905547700823.stgit@alrua-kau>
[-- Attachment #1: Type: text/plain, Size: 2346 bytes --]
Hi Toke,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net/master]
[also build test ERROR on v4.17-rc7]
[cannot apply to net-next/master next-20180529]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Toke-H-iland-J-rgensen/sched-Add-Common-Applications-Kept-Enhanced-cake-qdisc/20180530-125240
config: x86_64-randconfig-x015-201821 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
net/netfilter/core.c: In function 'nf_ct_get_tuple_skb':
>> net/netfilter/core.c:586:12: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types]
get_tuple = rcu_dereference(skb_ct_get_tuple);
^
>> net/netfilter/core.c:589:18: error: passing argument 1 of 'get_tuple' from incompatible pointer type [-Werror=incompatible-pointer-types]
ret = get_tuple(dst_tuple, skb);
^~~~~~~~~
net/netfilter/core.c:589:18: note: expected 'const struct sk_buff *' but argument is of type 'struct nf_conntrack_tuple *'
net/netfilter/core.c:589:29: error: passing argument 2 of 'get_tuple' from incompatible pointer type [-Werror=incompatible-pointer-types]
ret = get_tuple(dst_tuple, skb);
^~~
net/netfilter/core.c:589:29: note: expected 'struct nf_conntrack_tuple *' but argument is of type 'const struct sk_buff *'
cc1: some warnings being treated as errors
vim +586 net/netfilter/core.c
578
579 bool nf_ct_get_tuple_skb(struct nf_conntrack_tuple *dst_tuple,
580 const struct sk_buff *skb)
581 {
582 bool (*get_tuple)(const struct sk_buff *, struct nf_conntrack_tuple *);
583 bool ret = false;
584
585 rcu_read_lock();
> 586 get_tuple = rcu_dereference(skb_ct_get_tuple);
587 if (!get_tuple)
588 goto out;
> 589 ret = get_tuple(dst_tuple, skb);
590 out:
591 rcu_read_unlock();
592 return ret;
593 }
594 EXPORT_SYMBOL(nf_ct_get_tuple_skb);
595
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28422 bytes --]
^ permalink raw reply
* [PATCH net 0/2] ip[6] tunnels: fix mtu calculations
From: Nicolas Dichtel @ 2018-05-30 8:28 UTC (permalink / raw)
To: davem, petrm, idosch; +Cc: netdev
The first patch restores the possibility to bind an ip4 tunnel to an
interface whith a large mtu.
The second patch was spotted after the first fix. I also target it to net
because it fixes the max mtu value that can be used for ipv6 tunnels.
net/ipv4/ip_tunnel.c | 6 +++---
net/ipv6/ip6_tunnel.c | 11 ++++++++---
net/ipv6/sit.c | 5 +++--
3 files changed, 14 insertions(+), 8 deletions(-)
Comments are welcomed,
Regards,
Nicolas
^ permalink raw reply
* [PATCH net 1/2] ip_tunnel: restore binding to ifaces with a large mtu
From: Nicolas Dichtel @ 2018-05-30 8:28 UTC (permalink / raw)
To: davem, petrm, idosch; +Cc: netdev, Nicolas Dichtel
In-Reply-To: <20180530082843.6076-1-nicolas.dichtel@6wind.com>
After commit f6cc9c054e77, the following conf is broken (note that the
default loopback mtu is 65536, ie IP_MAX_MTU + 1):
$ ip tunnel add gre1 mode gre local 10.125.0.1 remote 10.125.0.2 dev lo
add tunnel "gre0" failed: Invalid argument
$ ip l a type dummy
$ ip l s dummy1 up
$ ip l s dummy1 mtu 65535
$ ip tunnel add gre1 mode gre local 10.125.0.1 remote 10.125.0.2 dev dummy1
add tunnel "gre0" failed: Invalid argument
dev_set_mtu() doesn't allow to set a mtu which is too large.
First, let's cap the mtu returned by ip_tunnel_bind_dev(). Second, remove
the magic value 0xFFF8 and use IP_MAX_MTU instead.
0xFFF8 seems to be there for ages, I don't know why this value was used.
With a recent kernel, it's also possible to set a mtu > IP_MAX_MTU:
$ ip l s dummy1 mtu 66000
After that patch, it's also possible to bind an ip tunnel on that kind of
interface.
CC: Petr Machata <petrm@mellanox.com>
CC: Ido Schimmel <idosch@mellanox.com>
Link: https://git.kernel.org/pub/scm/linux/kernel/git/davem/netdev-vger-cvs.git/commit/?id=e5afd356a411a
Fixes: f6cc9c054e77 ("ip_tunnel: Emit events for post-register MTU changes")
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv4/ip_tunnel.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 6b0e362cc99b..3b39c72a1029 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -328,7 +328,7 @@ static int ip_tunnel_bind_dev(struct net_device *dev)
if (tdev) {
hlen = tdev->hard_header_len + tdev->needed_headroom;
- mtu = tdev->mtu;
+ mtu = min(tdev->mtu, IP_MAX_MTU);
}
dev->needed_headroom = t_hlen + hlen;
@@ -362,7 +362,7 @@ static struct ip_tunnel *ip_tunnel_create(struct net *net,
nt = netdev_priv(dev);
t_hlen = nt->hlen + sizeof(struct iphdr);
dev->min_mtu = ETH_MIN_MTU;
- dev->max_mtu = 0xFFF8 - dev->hard_header_len - t_hlen;
+ dev->max_mtu = IP_MAX_MTU - dev->hard_header_len - t_hlen;
ip_tunnel_add(itn, nt);
return nt;
@@ -930,7 +930,7 @@ int __ip_tunnel_change_mtu(struct net_device *dev, int new_mtu, bool strict)
{
struct ip_tunnel *tunnel = netdev_priv(dev);
int t_hlen = tunnel->hlen + sizeof(struct iphdr);
- int max_mtu = 0xFFF8 - dev->hard_header_len - t_hlen;
+ int max_mtu = IP_MAX_MTU - dev->hard_header_len - t_hlen;
if (new_mtu < ETH_MIN_MTU)
return -EINVAL;
--
2.15.1
^ permalink raw reply related
* [PATCH net 2/2] ip6_tunnel: remove magic mtu value 0xFFF8
From: Nicolas Dichtel @ 2018-05-30 8:28 UTC (permalink / raw)
To: davem, petrm, idosch; +Cc: netdev, Nicolas Dichtel
In-Reply-To: <20180530082843.6076-1-nicolas.dichtel@6wind.com>
I don't know where this value comes from (probably a copy and paste and
paste and paste ...).
Let's use standard values which are a bit greater.
Link: https://git.kernel.org/pub/scm/linux/kernel/git/davem/netdev-vger-cvs.git/commit/?id=e5afd356a411a
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv6/ip6_tunnel.c | 11 ++++++++---
net/ipv6/sit.c | 5 +++--
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index da66aaac51ce..00e138a44cbb 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1692,8 +1692,13 @@ int ip6_tnl_change_mtu(struct net_device *dev, int new_mtu)
if (new_mtu < ETH_MIN_MTU)
return -EINVAL;
}
- if (new_mtu > 0xFFF8 - dev->hard_header_len)
- return -EINVAL;
+ if (tnl->parms.proto == IPPROTO_IPV6 || tnl->parms.proto == 0) {
+ if (new_mtu > IP6_MAX_MTU - dev->hard_header_len)
+ return -EINVAL;
+ } else {
+ if (new_mtu > IP_MAX_MTU - dev->hard_header_len)
+ return -EINVAL;
+ }
dev->mtu = new_mtu;
return 0;
}
@@ -1841,7 +1846,7 @@ ip6_tnl_dev_init_gen(struct net_device *dev)
if (!(t->parms.flags & IP6_TNL_F_IGN_ENCAP_LIMIT))
dev->mtu -= 8;
dev->min_mtu = ETH_MIN_MTU;
- dev->max_mtu = 0xFFF8 - dev->hard_header_len;
+ dev->max_mtu = IP6_MAX_MTU - dev->hard_header_len;
return 0;
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 2afce37a7177..e9400ffa7875 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -1371,7 +1371,7 @@ static void ipip6_tunnel_setup(struct net_device *dev)
dev->hard_header_len = LL_MAX_HEADER + t_hlen;
dev->mtu = ETH_DATA_LEN - t_hlen;
dev->min_mtu = IPV6_MIN_MTU;
- dev->max_mtu = 0xFFF8 - t_hlen;
+ dev->max_mtu = IP6_MAX_MTU - t_hlen;
dev->flags = IFF_NOARP;
netif_keep_dst(dev);
dev->addr_len = 4;
@@ -1583,7 +1583,8 @@ static int ipip6_newlink(struct net *src_net, struct net_device *dev,
if (tb[IFLA_MTU]) {
u32 mtu = nla_get_u32(tb[IFLA_MTU]);
- if (mtu >= IPV6_MIN_MTU && mtu <= 0xFFF8 - dev->hard_header_len)
+ if (mtu >= IPV6_MIN_MTU &&
+ mtu <= IP6_MAX_MTU - dev->hard_header_len)
dev->mtu = mtu;
}
--
2.15.1
^ permalink raw reply related
* Re: [PATCH net] net/sonic: Use dma_mapping_error()
From: Tom Bogendoerfer @ 2018-05-30 9:01 UTC (permalink / raw)
To: Finn Thain; +Cc: David S. Miller, netdev, linux-kernel
In-Reply-To: <cba8175deaf9d631ae000088aea1ccf1c444909b.1527649393.git.fthain@telegraphics.com.au>
On Wed, May 30, 2018 at 01:03:51PM +1000, Finn Thain wrote:
> With CONFIG_DMA_API_DEBUG=y, calling sonic_open() produces the
> message, "DMA-API: device driver failed to check map error".
> Add the missing dma_mapping_error() call.
>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
> ---
> drivers/net/ethernet/natsemi/sonic.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/natsemi/sonic.c b/drivers/net/ethernet/natsemi/sonic.c
> index 7ed08486ae23..c805dcbebd02 100644
> --- a/drivers/net/ethernet/natsemi/sonic.c
> +++ b/drivers/net/ethernet/natsemi/sonic.c
> @@ -84,7 +84,7 @@ static int sonic_open(struct net_device *dev)
> for (i = 0; i < SONIC_NUM_RRS; i++) {
> dma_addr_t laddr = dma_map_single(lp->device, skb_put(lp->rx_skb[i], SONIC_RBSIZE),
> SONIC_RBSIZE, DMA_FROM_DEVICE);
> - if (!laddr) {
> + if (dma_mapping_error(lp->device, laddr)) {
> while(i > 0) { /* free any that were mapped successfully */
> i--;
> dma_unmap_single(lp->device, lp->rx_laddr[i], SONIC_RBSIZE, DMA_FROM_DEVICE);
> --
> 2.16.1
looks good
Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* [PATCH V2] brcmfmac: stop watchdog before detach and free everything
From: Michael Trimarchi @ 2018-05-30 9:06 UTC (permalink / raw)
To: Arend van Spriel
Cc: Franky Lin, Hante Meuleman, Chi-Hsien Lin, Wright Feng,
Kalle Valo, David S. Miller, Pieter-Paul Giesberts, Ian Molton,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
netdev, linux-kernel
In-Reply-To: <5B0D1C9E.4000800@broadcom.com>
Using built-in in kernel image without a firmware in filesystem
or in the kernel image can lead to a kernel NULL pointer deference.
Watchdog need to be stopped in brcmf_sdio_remove
The system is going down NOW!
[ 1348.110759] Unable to handle kernel NULL pointer dereference at virtual address 000002f8
Sent SIGTERM to all processes
[ 1348.121412] Mem abort info:
[ 1348.126962] ESR = 0x96000004
[ 1348.130023] Exception class = DABT (current EL), IL = 32 bits
[ 1348.135948] SET = 0, FnV = 0
[ 1348.138997] EA = 0, S1PTW = 0
[ 1348.142154] Data abort info:
[ 1348.145045] ISV = 0, ISS = 0x00000004
[ 1348.148884] CM = 0, WnR = 0
[ 1348.151861] user pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____)
[ 1348.158475] [00000000000002f8] pgd=0000000000000000
[ 1348.163364] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 1348.168927] Modules linked in: ipv6
[ 1348.172421] CPU: 3 PID: 1421 Comm: brcmf_wdog/mmc0 Not tainted 4.17.0-rc5-next-20180517 #18
[ 1348.180757] Hardware name: Amarula A64-Relic (DT)
[ 1348.185455] pstate: 60000005 (nZCv daif -PAN -UAO)
[ 1348.190251] pc : brcmf_sdiod_freezer_count+0x0/0x20
[ 1348.195124] lr : brcmf_sdio_watchdog_thread+0x64/0x290
[ 1348.200253] sp : ffff00000b85be30
[ 1348.203561] x29: ffff00000b85be30 x28: 0000000000000000
[ 1348.208868] x27: ffff00000b6cb918 x26: ffff80003b990638
[ 1348.214176] x25: ffff0000087b1a20 x24: ffff80003b94f800
[ 1348.219483] x23: ffff000008e620c8 x22: ffff000008f0b660
[ 1348.224790] x21: ffff000008c6a858 x20: 00000000fffffe00
[ 1348.230097] x19: ffff80003b94f800 x18: 0000000000000001
[ 1348.235404] x17: 0000ffffab2e8a74 x16: ffff0000080d7de8
[ 1348.240711] x15: 0000000000000000 x14: 0000000000000400
[ 1348.246018] x13: 0000000000000400 x12: 0000000000000001
[ 1348.251324] x11: 00000000000002c4 x10: 0000000000000a10
[ 1348.256631] x9 : ffff00000b85bc40 x8 : ffff80003be11870
[ 1348.261937] x7 : ffff80003dfc7308 x6 : 000000078ff08b55
[ 1348.267243] x5 : 00000139e1058400 x4 : 0000000000000000
[ 1348.272550] x3 : dead000000000100 x2 : 958f2788d6618100
[ 1348.277856] x1 : 00000000fffffe00 x0 : 0000000000000000
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 412a05b..061f69d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -4294,6 +4294,13 @@ void brcmf_sdio_remove(struct brcmf_sdio *bus)
brcmf_dbg(TRACE, "Enter\n");
if (bus) {
+ /* Stop watchdog task */
+ if (bus->watchdog_tsk) {
+ send_sig(SIGTERM, bus->watchdog_tsk, 1);
+ kthread_stop(bus->watchdog_tsk);
+ bus->watchdog_tsk = NULL;
+ }
+
/* De-register interrupt handler */
brcmf_sdiod_intr_unregister(bus->sdiodev);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net] VSOCK: check sk state before receive
From: Stefan Hajnoczi @ 2018-05-30 9:17 UTC (permalink / raw)
To: Hangbin Liu; +Cc: netdev, Jorgen Hansen, David S. Miller
In-Reply-To: <20180527152945.GQ8958@leo.usersys.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 4964 bytes --]
On Sun, May 27, 2018 at 11:29:45PM +0800, Hangbin Liu wrote:
> Hmm...Although I won't reproduce this bug with my reproducer after
> apply my patch. I could still get a similiar issue with syzkaller sock vnet test.
>
> It looks this patch is not complete. Here is the KASAN call trace with my patch.
> I can also reproduce it without my patch.
Seems like a race between vmci_datagram_destroy_handle() and the
delayed callback, vmci_transport_recv_dgram_cb().
I don't know the VMCI transport well so I'll leave this to Jorgen.
> ==================================================================
> BUG: KASAN: use-after-free in vmci_transport_allow_dgram.part.7+0x155/0x1a0 [vmw_vsock_vmci_transport]
> Read of size 4 at addr ffff880026a3a914 by task kworker/0:2/96
>
> CPU: 0 PID: 96 Comm: kworker/0:2 Not tainted 4.17.0-rc6.vsock+ #28
> Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
> Workqueue: events dg_delayed_dispatch [vmw_vmci]
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0xdd/0x18e lib/dump_stack.c:113
> print_address_description+0x7a/0x3e0 mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report+0x1dd/0x460 mm/kasan/report.c:412
> vmci_transport_allow_dgram.part.7+0x155/0x1a0 [vmw_vsock_vmci_transport]
> vmci_transport_recv_dgram_cb+0x5d/0x200 [vmw_vsock_vmci_transport]
> dg_delayed_dispatch+0x99/0x1b0 [vmw_vmci]
> process_one_work+0xa4e/0x1720 kernel/workqueue.c:2145
> worker_thread+0x1df/0x1400 kernel/workqueue.c:2279
> kthread+0x343/0x4b0 kernel/kthread.c:240
> ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:412
>
> Allocated by task 2684:
> set_track mm/kasan/kasan.c:460 [inline]
> kasan_kmalloc+0xa0/0xd0 mm/kasan/kasan.c:553
> slab_post_alloc_hook mm/slab.h:444 [inline]
> slab_alloc_node mm/slub.c:2741 [inline]
> slab_alloc mm/slub.c:2749 [inline]
> kmem_cache_alloc+0x105/0x330 mm/slub.c:2754
> sk_prot_alloc+0x6a/0x2c0 net/core/sock.c:1468
> sk_alloc+0xc9/0xbb0 net/core/sock.c:1528
> __vsock_create+0xc8/0x9b0 [vsock]
> vsock_create+0xfd/0x1a0 [vsock]
> __sock_create+0x310/0x690 net/socket.c:1285
> sock_create net/socket.c:1325 [inline]
> __sys_socket+0x101/0x240 net/socket.c:1355
> __do_sys_socket net/socket.c:1364 [inline]
> __se_sys_socket net/socket.c:1362 [inline]
> __x64_sys_socket+0x7d/0xd0 net/socket.c:1362
> do_syscall_64+0x175/0x630 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Freed by task 2684:
> set_track mm/kasan/kasan.c:460 [inline]
> __kasan_slab_free+0x130/0x180 mm/kasan/kasan.c:521
> slab_free_hook mm/slub.c:1388 [inline]
> slab_free_freelist_hook mm/slub.c:1415 [inline]
> slab_free mm/slub.c:2988 [inline]
> kmem_cache_free+0xce/0x410 mm/slub.c:3004
> sk_prot_free net/core/sock.c:1509 [inline]
> __sk_destruct+0x629/0x940 net/core/sock.c:1593
> sk_destruct+0x4e/0x90 net/core/sock.c:1601
> __sk_free+0xd3/0x320 net/core/sock.c:1612
> sk_free+0x2a/0x30 net/core/sock.c:1623
> __vsock_release+0x431/0x610 [vsock]
> vsock_release+0x3c/0xc0 [vsock]
> sock_release+0x91/0x200 net/socket.c:594
> sock_close+0x17/0x20 net/socket.c:1149
> __fput+0x368/0xa20 fs/file_table.c:209
> task_work_run+0x1c5/0x2a0 kernel/task_work.c:113
> exit_task_work include/linux/task_work.h:22 [inline]
> do_exit+0x1876/0x26c0 kernel/exit.c:865
> do_group_exit+0x159/0x3e0 kernel/exit.c:968
> get_signal+0x65a/0x1780 kernel/signal.c:2482
> do_signal+0xa4/0x1fe0 arch/x86/kernel/signal.c:810
> exit_to_usermode_loop+0x1b8/0x260 arch/x86/entry/common.c:162
> prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
> syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
> do_syscall_64+0x505/0x630 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> The buggy address belongs to the object at ffff880026a3a600
> which belongs to the cache AF_VSOCK of size 1056
> The buggy address is located 788 bytes inside of
> 1056-byte region [ffff880026a3a600, ffff880026a3aa20)
> The buggy address belongs to the page:
> page:ffffea00009a8e00 count:1 mapcount:0 mapping:0000000000000000 index:0x0 compound_mapcount: 0
> flags: 0xfffffc0008100(slab|head)
> raw: 000fffffc0008100 0000000000000000 0000000000000000 00000001000d000d
> raw: dead000000000100 dead000000000200 ffff880034471a40 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff880026a3a800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff880026a3a880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >ffff880026a3a900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff880026a3a980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff880026a3aa00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc
> ==================================================================
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH v4 net-next 00/19] inet: frags: bring rhashtables to IP defrag
From: Jesper Dangaard Brouer @ 2018-05-30 9:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alexander Aring, Tariq Toukan, David Miller, edumazet, netdev, fw,
herbert, tgraf, alex.aring, stefan, ktkhai, Moshe Shemesh,
Eran Ben Elisha, brouer, Rick Jones
In-Reply-To: <13bf3889-4426-b17a-d8d7-e843038a2a82@gmail.com>
On Mon, 28 May 2018 09:09:17 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Tariq, here are my test results : No drops for me.
>
> # ./netperf -H 2607:f8b0:8099:e18:: -t UDP_STREAM
> MIGRATED UDP STREAM TEST from ::0 (::) port 0 AF_INET6 to 2607:f8b0:8099:e18:: () port 0 AF_INET6
> Socket Message Elapsed Messages
> Size Size Time Okay Errors Throughput
> bytes bytes secs # # 10^6bits/sec
>
> 212992 65507 10.00 202117 0 10592.00
> 212992 10.00 0 0.00
Hmm... Eric the above result show that ALL your UDP packets were dropped!
You have 0 okay messages and 0.00 Mbit/s throughput.
It needs to look like below (test on i40e NIC):
$ netperf -t UDP_STREAM -H fee0:cafe::1
MIGRATED UDP STREAM TEST from ::0 (::) port 0 AF_INET6 to fee0:cafe::1 () port 0 AF_INET6 : histogram : demo
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
212992 65507 10.00 186385 0 9767.08
212992 10.00 186385 9767.08
If I manually instruct ip6tables to drop all UDP packets, then I get
what you see... so, something on your test system are likely dropping
your UDP packets, but letting regular netperf (TCP) control
communication through.
# ip6tables -I INPUT -p udp -j DROP
$ netperf -t UDP_STREAM -H fee0:cafe::1
MIGRATED UDP STREAM TEST from ::0 (::) port 0 AF_INET6 to fee0:cafe::1 () port 0 AF_INET6 : histogram : demo
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
212992 65507 10.00 182095 0 9542.41
212992 10.00 0 0.00
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH] ath9k: debug: fix spelling mistake "WATHDOG" -> "WATCHDOG"
From: Colin King @ 2018-05-30 9:25 UTC (permalink / raw)
To: QCA ath9k Development, Kalle Valo, David S . Miller,
linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in PR_IS message text.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/ath/ath9k/debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index f685843a2ff3..0a6eb8a8c1ed 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -538,7 +538,7 @@ static int read_file_interrupt(struct seq_file *file, void *data)
if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_EDMA) {
PR_IS("RXLP", rxlp);
PR_IS("RXHP", rxhp);
- PR_IS("WATHDOG", bb_watchdog);
+ PR_IS("WATCHDOG", bb_watchdog);
} else {
PR_IS("RX", rxok);
}
--
2.17.0
^ permalink raw reply related
* Re: [PATCH net-next 0/8] nfp: offload LAG for tc flower egress
From: John Hurley @ 2018-05-30 9:26 UTC (permalink / raw)
To: Jiri Pirko
Cc: Jakub Kicinski, David Miller, Linux Netdev List, oss-drivers,
Jay Vosburgh, Veaceslav Falico, Andy Gospodarek
In-Reply-To: <20180529220947.GC2367@nanopsycho>
On Tue, May 29, 2018 at 11:09 PM, Jiri Pirko <jiri@resnulli.us> wrote:
> Tue, May 29, 2018 at 04:08:48PM CEST, john.hurley@netronome.com wrote:
>>On Sat, May 26, 2018 at 3:47 AM, Jakub Kicinski
>><jakub.kicinski@netronome.com> wrote:
>>> On Fri, 25 May 2018 08:48:09 +0200, Jiri Pirko wrote:
>>>> Thu, May 24, 2018 at 04:22:47AM CEST, jakub.kicinski@netronome.com wrote:
>>>> >Hi!
>>>> >
>>>> >This series from John adds bond offload to the nfp driver. Patch 5
>>>> >exposes the hash type for NETDEV_LAG_TX_TYPE_HASH to make sure nfp
>>>> >hashing matches that of the software LAG. This may be unnecessarily
>>>> >conservative, let's see what LAG maintainers think :)
>>>>
>>>> So you need to restrict offload to only certain hash algo? In mlxsw, we
>>>> just ignore the lag setting and do some hw default hashing. Would not be
>>>> enough? Note that there's a good reason for it, as you see, in team, the
>>>> hashing is done in a BPF function and could be totally arbitrary.
>>>> Your patchset effectively disables team offload for nfp.
>>>
>>> My understanding is that the project requirements only called for L3/L4
>>> hash algorithm offload, hence the temptation to err on the side of
>>> caution and not offload all the bond configurations. John can provide
>>> more details. Not being able to offload team is unfortunate indeed.
>>
>>Hi Jiri,
>>Yes, as Jakub mentions, we restrict ourselves to L3/L4 hash algorithm
>>as this is currently what is supported in fw.
>
> In mlxsw, a default l3/l4 is used always, no matter what the
> bonding/team sets. It is not correct, but it works with team as well.
> Perhaps we can have NETDEV_LAG_HASH_UNKNOWN to indicate to the driver to
> do some default? That would make the "team" offload functional.
>
yes, I would agree with that.
Thanks
>>Hopefully this will change as fw features are expanded.
>>I understand the issue this presents with offloading team.
>>Perhaps resorting to a default hw hash for team is acceptable.
>>John
^ permalink raw reply
* Re: [PATCH] netfilter: nfnetlink: Remove VLA usage
From: Pablo Neira Ayuso @ 2018-05-30 9:52 UTC (permalink / raw)
To: Kees Cook
Cc: Jozsef Kadlecsik, Florian Westphal, David S. Miller,
netfilter-devel, coreteam, netdev, linux-kernel
In-Reply-To: <20180530003525.GA18642@beast>
On Tue, May 29, 2018 at 05:35:25PM -0700, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> allocates the maximum size expected for all possible attrs and adds
> a sanity-check to make sure nothing gets out of sync.
>
> [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> net/netfilter/nfnetlink.c | 22 ++++++++++++++++++++--
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/net/netfilter/nfnetlink.c b/net/netfilter/nfnetlink.c
> index 03ead8a9e90c..0cb395f9627e 100644
> --- a/net/netfilter/nfnetlink.c
> +++ b/net/netfilter/nfnetlink.c
> @@ -28,6 +28,7 @@
>
> #include <net/netlink.h>
> #include <linux/netfilter/nfnetlink.h>
> +#include <linux/netfilter/nf_tables.h>
>
> MODULE_LICENSE("GPL");
> MODULE_AUTHOR("Harald Welte <laforge@netfilter.org>");
> @@ -37,6 +38,11 @@ MODULE_ALIAS_NET_PF_PROTO(PF_NETLINK, NETLINK_NETFILTER);
> rcu_dereference_protected(table[(id)].subsys, \
> lockdep_nfnl_is_held((id)))
>
> +#define NFTA_MAX_ATTR max(max(max(NFTA_CHAIN_MAX, NFTA_FLOWTABLE_MAX),\
> + max(NFTA_OBJ_MAX, NFTA_RULE_MAX)), \
> + max(NFTA_TABLE_MAX, \
> + max(NFTA_SET_ELEM_LIST_MAX, NFTA_SET_MAX)))
This is very specific of nftables, there are other nf subsystems using
nfnetlink that may go over this maximum attribute value (grep from
"struct nfnetlink_subsystem").
To remove the VLA, I think we need an artificial maximum attribute
that reasonably large enough.
^ permalink raw reply
* Feature Request : iface may be allowed as datatype in all ipset
From: Akshat Kakkar @ 2018-05-30 10:03 UTC (permalink / raw)
To: netdev
Is there a reason why iface is allowed to be paired only with net to
create an ipset?
I think with feature of skbinfo in every ipset, it should be allowed
to add iface in all ipset. As skbinfo can store tc classes, it might
make more sense if I can pin point on which outgoing interface this
class should be applied.
One direct way of doing could be adding iface in skbinfo itself, but I
dont think its a good suggestion.
So, other thing left is to have ipset storing interface too. Besides,
when I create a tc class, I create it on a known interface, so I know
beforehand on which interface this class is created. So I can easily
specify while adding entry in ipset.
^ 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