* [net-next 9/9] net/mlx5e: Fill advertised and supported port data from Hardware info
From: Saeed Mahameed @ 2017-06-11 14:55 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Saeed Mahameed
In-Reply-To: <20170611145553.14180-1-saeedm@mellanox.com>
From: Eran Ben Elisha <eranbe@mellanox.com>
Translate hardware port connector type data into link mode supported and
advertised info instead of caching it in driver.
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
.../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 90 ++++++++++++++++++----
1 file changed, 74 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
index f03c2d088d0c..b4514f247402 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
@@ -723,24 +723,81 @@ static void ptys2ethtool_adver_link(unsigned long *advertising_modes,
__ETHTOOL_LINK_MODE_MASK_NBITS);
}
-static void ptys2ethtool_supported_port(struct ethtool_link_ksettings *link_ksettings,
- u32 eth_proto_cap)
+static void ptys2ethtool_supported_advertised_port(struct ethtool_link_ksettings *link_ksettings,
+ u32 eth_proto_cap,
+ u8 connector_type)
{
- if (eth_proto_cap & (MLX5E_PROT_MASK(MLX5E_10GBASE_CR)
- | MLX5E_PROT_MASK(MLX5E_10GBASE_SR)
- | MLX5E_PROT_MASK(MLX5E_40GBASE_CR4)
- | MLX5E_PROT_MASK(MLX5E_40GBASE_SR4)
- | MLX5E_PROT_MASK(MLX5E_100GBASE_SR4)
- | MLX5E_PROT_MASK(MLX5E_1000BASE_CX_SGMII))) {
- ethtool_link_ksettings_add_link_mode(link_ksettings, supported, FIBRE);
+ if (!connector_type || connector_type >= MLX5E_CONNECTOR_TYPE_NUMBER) {
+ if (eth_proto_cap & (MLX5E_PROT_MASK(MLX5E_10GBASE_CR)
+ | MLX5E_PROT_MASK(MLX5E_10GBASE_SR)
+ | MLX5E_PROT_MASK(MLX5E_40GBASE_CR4)
+ | MLX5E_PROT_MASK(MLX5E_40GBASE_SR4)
+ | MLX5E_PROT_MASK(MLX5E_100GBASE_SR4)
+ | MLX5E_PROT_MASK(MLX5E_1000BASE_CX_SGMII))) {
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+ supported,
+ FIBRE);
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+ advertising,
+ FIBRE);
+ }
+
+ if (eth_proto_cap & (MLX5E_PROT_MASK(MLX5E_100GBASE_KR4)
+ | MLX5E_PROT_MASK(MLX5E_40GBASE_KR4)
+ | MLX5E_PROT_MASK(MLX5E_10GBASE_KR)
+ | MLX5E_PROT_MASK(MLX5E_10GBASE_KX4)
+ | MLX5E_PROT_MASK(MLX5E_1000BASE_KX))) {
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+ supported,
+ Backplane);
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+ advertising,
+ Backplane);
+ }
+ return;
}
- if (eth_proto_cap & (MLX5E_PROT_MASK(MLX5E_100GBASE_KR4)
- | MLX5E_PROT_MASK(MLX5E_40GBASE_KR4)
- | MLX5E_PROT_MASK(MLX5E_10GBASE_KR)
- | MLX5E_PROT_MASK(MLX5E_10GBASE_KX4)
- | MLX5E_PROT_MASK(MLX5E_1000BASE_KX))) {
- ethtool_link_ksettings_add_link_mode(link_ksettings, supported, Backplane);
+ switch (connector_type) {
+ case MLX5E_PORT_TP:
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+ supported, TP);
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+ advertising, TP);
+ break;
+ case MLX5E_PORT_AUI:
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+ supported, AUI);
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+ advertising, AUI);
+ break;
+ case MLX5E_PORT_BNC:
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+ supported, BNC);
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+ advertising, BNC);
+ break;
+ case MLX5E_PORT_MII:
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+ supported, MII);
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+ advertising, MII);
+ break;
+ case MLX5E_PORT_FIBRE:
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+ supported, FIBRE);
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+ advertising, FIBRE);
+ break;
+ case MLX5E_PORT_DA:
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+ supported, Backplane);
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+ advertising, Backplane);
+ break;
+ case MLX5E_PORT_NONE:
+ case MLX5E_PORT_OTHER:
+ default:
+ break;
}
}
@@ -791,7 +848,6 @@ static void get_supported(u32 eth_proto_cap,
{
unsigned long *supported = link_ksettings->link_modes.supported;
- ptys2ethtool_supported_port(link_ksettings, eth_proto_cap);
ptys2ethtool_supported_link(supported, eth_proto_cap);
ethtool_link_ksettings_add_link_mode(link_ksettings, supported, Pause);
}
@@ -902,6 +958,8 @@ static int mlx5e_get_link_ksettings(struct net_device *netdev,
link_ksettings->base.port = get_connector_port(eth_proto_oper,
connector_type);
+ ptys2ethtool_supported_advertised_port(link_ksettings, eth_proto_admin,
+ connector_type);
get_lp_advertising(eth_proto_lp, link_ksettings);
if (an_status == MLX5_AN_COMPLETE)
--
2.11.0
^ permalink raw reply related
* [net-next 8/9] net/mlx5e: Add support for reading connector type from PTYS
From: Saeed Mahameed @ 2017-06-11 14:55 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Saeed Mahameed
In-Reply-To: <20170611145553.14180-1-saeedm@mellanox.com>
From: Eran Ben Elisha <eranbe@mellanox.com>
Read port connector type from the firmware instead of caching it in the
driver metadata.
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
.../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 22 ++++++++++++++++++++--
include/linux/mlx5/mlx5_ifc.h | 7 +++++--
include/linux/mlx5/port.h | 13 +++++++++++++
3 files changed, 38 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
index e9e33fd68279..f03c2d088d0c 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
@@ -809,8 +809,23 @@ static void get_advertising(u32 eth_proto_cap, u8 tx_pause,
ethtool_link_ksettings_add_link_mode(link_ksettings, advertising, Asym_Pause);
}
-static u8 get_connector_port(u32 eth_proto)
+static int ptys2connector_type[MLX5E_CONNECTOR_TYPE_NUMBER] = {
+ [MLX5E_PORT_UNKNOWN] = PORT_OTHER,
+ [MLX5E_PORT_NONE] = PORT_NONE,
+ [MLX5E_PORT_TP] = PORT_TP,
+ [MLX5E_PORT_AUI] = PORT_AUI,
+ [MLX5E_PORT_BNC] = PORT_BNC,
+ [MLX5E_PORT_MII] = PORT_MII,
+ [MLX5E_PORT_FIBRE] = PORT_FIBRE,
+ [MLX5E_PORT_DA] = PORT_DA,
+ [MLX5E_PORT_OTHER] = PORT_OTHER,
+ };
+
+static u8 get_connector_port(u32 eth_proto, u8 connector_type)
{
+ if (connector_type && connector_type < MLX5E_CONNECTOR_TYPE_NUMBER)
+ return ptys2connector_type[connector_type];
+
if (eth_proto & (MLX5E_PROT_MASK(MLX5E_10GBASE_SR)
| MLX5E_PROT_MASK(MLX5E_40GBASE_SR4)
| MLX5E_PROT_MASK(MLX5E_100GBASE_SR4)
@@ -856,6 +871,7 @@ static int mlx5e_get_link_ksettings(struct net_device *netdev,
u32 eth_proto_oper;
u8 an_disable_admin;
u8 an_status;
+ u8 connector_type;
int err;
err = mlx5_query_port_ptys(mdev, out, sizeof(out), MLX5_PTYS_EN, 1);
@@ -871,6 +887,7 @@ static int mlx5e_get_link_ksettings(struct net_device *netdev,
eth_proto_lp = MLX5_GET(ptys_reg, out, eth_proto_lp_advertise);
an_disable_admin = MLX5_GET(ptys_reg, out, an_disable_admin);
an_status = MLX5_GET(ptys_reg, out, an_status);
+ connector_type = MLX5_GET(ptys_reg, out, connector_type);
mlx5_query_port_pause(mdev, &rx_pause, &tx_pause);
@@ -883,7 +900,8 @@ static int mlx5e_get_link_ksettings(struct net_device *netdev,
eth_proto_oper = eth_proto_oper ? eth_proto_oper : eth_proto_cap;
- link_ksettings->base.port = get_connector_port(eth_proto_oper);
+ link_ksettings->base.port = get_connector_port(eth_proto_oper,
+ connector_type);
get_lp_advertising(eth_proto_lp, link_ksettings);
if (an_status == MLX5_AN_COMPLETE)
diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index ec308657af3b..32b044e953d2 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -7295,7 +7295,8 @@ struct mlx5_ifc_ptys_reg_bits {
u8 ib_link_width_oper[0x10];
u8 ib_proto_oper[0x10];
- u8 reserved_at_160[0x20];
+ u8 reserved_at_160[0x1c];
+ u8 connector_type[0x4];
u8 eth_proto_lp_advertise[0x20];
@@ -7698,8 +7699,10 @@ struct mlx5_ifc_peir_reg_bits {
};
struct mlx5_ifc_pcam_enhanced_features_bits {
- u8 reserved_at_0[0x7e];
+ u8 reserved_at_0[0x7c];
+ u8 ptys_connector_type[0x1];
+ u8 reserved_at_7d[0x1];
u8 ppcnt_discard_group[0x1];
u8 ppcnt_statistical_group[0x1];
};
diff --git a/include/linux/mlx5/port.h b/include/linux/mlx5/port.h
index e527732fb31b..c57d4b7de3a8 100644
--- a/include/linux/mlx5/port.h
+++ b/include/linux/mlx5/port.h
@@ -92,6 +92,19 @@ enum mlx5e_link_mode {
MLX5E_LINK_MODES_NUMBER,
};
+enum mlx5e_connector_type {
+ MLX5E_PORT_UNKNOWN = 0,
+ MLX5E_PORT_NONE = 1,
+ MLX5E_PORT_TP = 2,
+ MLX5E_PORT_AUI = 3,
+ MLX5E_PORT_BNC = 4,
+ MLX5E_PORT_MII = 5,
+ MLX5E_PORT_FIBRE = 6,
+ MLX5E_PORT_DA = 7,
+ MLX5E_PORT_OTHER = 8,
+ MLX5E_CONNECTOR_TYPE_NUMBER,
+};
+
#define MLX5E_PROT_MASK(link_mode) (1 << link_mode)
#define PORT_MODULE_EVENT_MODULE_STATUS_MASK 0xF
--
2.11.0
^ permalink raw reply related
* [pull request][net-next 0/9] Mellanox mlx5 updates 2017-06-11
From: Saeed Mahameed @ 2017-06-11 14:55 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Saeed Mahameed
Hi Dave,
This series provides updates to mlx5 header rewrite feature, from Or Gerlitz.
and three more small updates From Maor and Eran.
For more details please see below.
Please pull and let me know if there's any problem.
*This series doesn't introduce any conflict with the ongoing net
pull request.
Thanks,
Saeed.
---
The following changes since commit 50dffe7fad6c156c2928e45c19ff7b86eb951f4c:
Merge branch 'mlx4-drivers-version-update' (2017-06-07 15:33:02 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git tags/mlx5-updates-2017-06-11
for you to fetch changes up to 46e9d0b61e27a3a9286002311f349f0c33dcb18f:
net/mlx5e: Fill advertised and supported port data from Hardware info (2017-06-08 14:12:00 +0300)
----------------------------------------------------------------
mlx5-updates-2017-06-11
This series provides updates to mlx5 header rewrite feature, from Or Gerlitz.
and three more small updates From maor and eran.
-------
Or says:
Packets belonging to flows which are different by matching may still need
to go through the same header re-writes (e.g set the current routing hop
MACs and issue TTL decrement). To minimize the number of modify header
IDs, we add a cache for header re-write IDs which is keyed by the binary
chain of modify header actions.
The caching is supported for both eswitch and NIC use-cases, where the
actual conversion of the code to use caching comes in separate patches,
one per use-case.
Using a per field mask field, the TC pedit action supports modifying
partial fields. The last patch enables offloading that.
-------
>From Maor, update flow table commands layout to the latest HW spec.
>From Eran, ethtool connector type reporting updates.
Thanks,
Saeed.
----------------------------------------------------------------
Eran Ben Elisha (2):
net/mlx5e: Add support for reading connector type from PTYS
net/mlx5e: Fill advertised and supported port data from Hardware info
Maor Gottlieb (1):
net/mlx5: Update flow table commands layout
Or Gerlitz (6):
net/mlx5e: Remove limitation of single NIC offloaded TC action per rule
net/mlx5e: Use short attribute form when adding/deleting offloaded TC flows
net/mlx5e: Add cache for HW modify header IDs
net/mlx5e: Use modify header ID cache for offloaded TC E-Switch flows
net/mlx5e: Use modify header ID cache for offloaded TC NIC flows
net/mlx5e: Support header re-write of partial fields in TC pedit offload
drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 +
.../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 112 ++++++++++--
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 203 +++++++++++++++++----
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 1 +
drivers/net/ethernet/mellanox/mlx5/core/eswitch.h | 1 +
drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c | 32 ++--
include/linux/mlx5/mlx5_ifc.h | 53 +++---
include/linux/mlx5/port.h | 13 ++
8 files changed, 322 insertions(+), 95 deletions(-)
^ permalink raw reply
* [net-next 6/9] net/mlx5e: Support header re-write of partial fields in TC pedit offload
From: Saeed Mahameed @ 2017-06-11 14:55 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Or Gerlitz, Saeed Mahameed
In-Reply-To: <20170611145553.14180-1-saeedm@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Using a per field mask field, the TC pedit action supports modifying
partial fields. E.g if using the TC tool, the following example would
make the kernel to only re-write two bytes of the src ip address:
tc filter add dev enp1s0 protocol ip parent ffff: prio 30
flower skip_sw ip_proto udp dst_port 8001
action pedit ex munge ip src set 10.1.0.0 retain 0xffff0000
We add driver support for offload these partial re-writes, by setting
the per FW action offset-in-field and length-from-offset attributes.
The 1st bit set in the mask specifies both the offset and the right
shift to apply on the value such that the 1st bit which needs to be
set will reside in bit 0 of the FW data field.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reviewed-by: Paul Blakey <paulb@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 28 +++++++++++++++++--------
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index 0c7a0872b22b..f5afacfbe914 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -1091,12 +1091,14 @@ static int offload_pedit_fields(struct pedit_headers *masks,
struct mlx5e_tc_flow_parse_attr *parse_attr)
{
struct pedit_headers *set_masks, *add_masks, *set_vals, *add_vals;
- int i, action_size, nactions, max_actions, first, last, first_z;
+ int i, action_size, nactions, max_actions, first, last, next_z;
void *s_masks_p, *a_masks_p, *vals_p;
struct mlx5_fields *f;
u8 cmd, field_bsize;
u32 s_mask, a_mask;
unsigned long mask;
+ __be32 mask_be32;
+ __be16 mask_be16;
void *action;
set_masks = &masks[TCA_PEDIT_KEY_EX_CMD_SET];
@@ -1150,11 +1152,19 @@ static int offload_pedit_fields(struct pedit_headers *masks,
field_bsize = f->size * BITS_PER_BYTE;
- first_z = find_first_zero_bit(&mask, field_bsize);
+ if (field_bsize == 32) {
+ mask_be32 = *(__be32 *)&mask;
+ mask = (__force unsigned long)cpu_to_le32(be32_to_cpu(mask_be32));
+ } else if (field_bsize == 16) {
+ mask_be16 = *(__be16 *)&mask;
+ mask = (__force unsigned long)cpu_to_le16(be16_to_cpu(mask_be16));
+ }
+
first = find_first_bit(&mask, field_bsize);
+ next_z = find_next_zero_bit(&mask, field_bsize, first);
last = find_last_bit(&mask, field_bsize);
- if (first > 0 || last != (field_bsize - 1) || first_z < last) {
- printk(KERN_WARNING "mlx5: partial rewrite (mask %lx) is currently not offloaded\n",
+ if (first < next_z && next_z < last) {
+ printk(KERN_WARNING "mlx5: rewrite of few sub-fields (mask %lx) isn't offloaded\n",
mask);
return -EOPNOTSUPP;
}
@@ -1163,17 +1173,17 @@ static int offload_pedit_fields(struct pedit_headers *masks,
MLX5_SET(set_action_in, action, field, f->field);
if (cmd == MLX5_ACTION_TYPE_SET) {
- MLX5_SET(set_action_in, action, offset, 0);
+ MLX5_SET(set_action_in, action, offset, first);
/* length is num of bits to be written, zero means length of 32 */
- MLX5_SET(set_action_in, action, length, field_bsize);
+ MLX5_SET(set_action_in, action, length, (last - first + 1));
}
if (field_bsize == 32)
- MLX5_SET(set_action_in, action, data, ntohl(*(__be32 *)vals_p));
+ MLX5_SET(set_action_in, action, data, ntohl(*(__be32 *)vals_p) >> first);
else if (field_bsize == 16)
- MLX5_SET(set_action_in, action, data, ntohs(*(__be16 *)vals_p));
+ MLX5_SET(set_action_in, action, data, ntohs(*(__be16 *)vals_p) >> first);
else if (field_bsize == 8)
- MLX5_SET(set_action_in, action, data, *(u8 *)vals_p);
+ MLX5_SET(set_action_in, action, data, *(u8 *)vals_p >> first);
action += action_size;
nactions++;
--
2.11.0
^ permalink raw reply related
* [net-next 7/9] net/mlx5: Update flow table commands layout
From: Saeed Mahameed @ 2017-06-11 14:55 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Maor Gottlieb, Saeed Mahameed
In-Reply-To: <20170611145553.14180-1-saeedm@mellanox.com>
From: Maor Gottlieb <maorg@mellanox.com>
Update struct mlx5_ifc_create(modify)_flow_table_bits according to
the last device specification.
Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c | 32 ++++++++++-------
include/linux/mlx5/mlx5_ifc.h | 46 +++++++++++-------------
2 files changed, 40 insertions(+), 38 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c b/drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c
index abb44a268563..e750f07793b8 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c
@@ -78,28 +78,33 @@ int mlx5_cmd_create_flow_table(struct mlx5_core_dev *dev,
MLX5_CMD_OP_CREATE_FLOW_TABLE);
MLX5_SET(create_flow_table_in, in, table_type, type);
- MLX5_SET(create_flow_table_in, in, level, level);
- MLX5_SET(create_flow_table_in, in, log_size, log_size);
+ MLX5_SET(create_flow_table_in, in, flow_table_context.level, level);
+ MLX5_SET(create_flow_table_in, in, flow_table_context.log_size, log_size);
if (vport) {
MLX5_SET(create_flow_table_in, in, vport_number, vport);
MLX5_SET(create_flow_table_in, in, other_vport, 1);
}
- MLX5_SET(create_flow_table_in, in, decap_en, en_encap_decap);
- MLX5_SET(create_flow_table_in, in, encap_en, en_encap_decap);
+ MLX5_SET(create_flow_table_in, in, flow_table_context.decap_en,
+ en_encap_decap);
+ MLX5_SET(create_flow_table_in, in, flow_table_context.encap_en,
+ en_encap_decap);
switch (op_mod) {
case FS_FT_OP_MOD_NORMAL:
if (next_ft) {
- MLX5_SET(create_flow_table_in, in, table_miss_mode, 1);
- MLX5_SET(create_flow_table_in, in, table_miss_id, next_ft->id);
+ MLX5_SET(create_flow_table_in, in,
+ flow_table_context.table_miss_action, 1);
+ MLX5_SET(create_flow_table_in, in,
+ flow_table_context.table_miss_id, next_ft->id);
}
break;
case FS_FT_OP_MOD_LAG_DEMUX:
MLX5_SET(create_flow_table_in, in, op_mod, 0x1);
if (next_ft)
- MLX5_SET(create_flow_table_in, in, lag_master_next_table_id,
+ MLX5_SET(create_flow_table_in, in,
+ flow_table_context.lag_master_next_table_id,
next_ft->id);
break;
}
@@ -146,10 +151,10 @@ int mlx5_cmd_modify_flow_table(struct mlx5_core_dev *dev,
MLX5_MODIFY_FLOW_TABLE_LAG_NEXT_TABLE_ID);
if (next_ft) {
MLX5_SET(modify_flow_table_in, in,
- lag_master_next_table_id, next_ft->id);
+ flow_table_context.lag_master_next_table_id, next_ft->id);
} else {
MLX5_SET(modify_flow_table_in, in,
- lag_master_next_table_id, 0);
+ flow_table_context.lag_master_next_table_id, 0);
}
} else {
if (ft->vport) {
@@ -160,11 +165,14 @@ int mlx5_cmd_modify_flow_table(struct mlx5_core_dev *dev,
MLX5_SET(modify_flow_table_in, in, modify_field_select,
MLX5_MODIFY_FLOW_TABLE_MISS_TABLE_ID);
if (next_ft) {
- MLX5_SET(modify_flow_table_in, in, table_miss_mode, 1);
- MLX5_SET(modify_flow_table_in, in, table_miss_id,
+ MLX5_SET(modify_flow_table_in, in,
+ flow_table_context.table_miss_action, 1);
+ MLX5_SET(modify_flow_table_in, in,
+ flow_table_context.table_miss_id,
next_ft->id);
} else {
- MLX5_SET(modify_flow_table_in, in, table_miss_mode, 0);
+ MLX5_SET(modify_flow_table_in, in,
+ flow_table_context.table_miss_action, 0);
}
}
diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index 56e96f6a0a45..ec308657af3b 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -6627,6 +6627,24 @@ struct mlx5_ifc_create_flow_table_out_bits {
u8 reserved_at_60[0x20];
};
+struct mlx5_ifc_flow_table_context_bits {
+ u8 encap_en[0x1];
+ u8 decap_en[0x1];
+ u8 reserved_at_2[0x2];
+ u8 table_miss_action[0x4];
+ u8 level[0x8];
+ u8 reserved_at_10[0x8];
+ u8 log_size[0x8];
+
+ u8 reserved_at_20[0x8];
+ u8 table_miss_id[0x18];
+
+ u8 reserved_at_40[0x8];
+ u8 lag_master_next_table_id[0x18];
+
+ u8 reserved_at_60[0xe0];
+};
+
struct mlx5_ifc_create_flow_table_in_bits {
u8 opcode[0x10];
u8 reserved_at_10[0x10];
@@ -6645,21 +6663,7 @@ struct mlx5_ifc_create_flow_table_in_bits {
u8 reserved_at_a0[0x20];
- u8 encap_en[0x1];
- u8 decap_en[0x1];
- u8 reserved_at_c2[0x2];
- u8 table_miss_mode[0x4];
- u8 level[0x8];
- u8 reserved_at_d0[0x8];
- u8 log_size[0x8];
-
- u8 reserved_at_e0[0x8];
- u8 table_miss_id[0x18];
-
- u8 reserved_at_100[0x8];
- u8 lag_master_next_table_id[0x18];
-
- u8 reserved_at_120[0x80];
+ struct mlx5_ifc_flow_table_context_bits flow_table_context;
};
struct mlx5_ifc_create_flow_group_out_bits {
@@ -8277,17 +8281,7 @@ struct mlx5_ifc_modify_flow_table_in_bits {
u8 reserved_at_a0[0x8];
u8 table_id[0x18];
- u8 reserved_at_c0[0x4];
- u8 table_miss_mode[0x4];
- u8 reserved_at_c8[0x18];
-
- u8 reserved_at_e0[0x8];
- u8 table_miss_id[0x18];
-
- u8 reserved_at_100[0x8];
- u8 lag_master_next_table_id[0x18];
-
- u8 reserved_at_120[0x80];
+ struct mlx5_ifc_flow_table_context_bits flow_table_context;
};
struct mlx5_ifc_ets_tcn_config_reg_bits {
--
2.11.0
^ permalink raw reply related
* Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
From: Andrew Lunn @ 2017-06-11 15:21 UTC (permalink / raw)
To: crow; +Cc: netdev, linux-amlogic
In-Reply-To: <CAG_g8w71SWc_X2U9pNWLVheO9Jf4ydPznAVp1x-Y9kwU3qhf1A@mail.gmail.com>
> Thank your for the suggestion, and thanks Martin to explaining me over
> IRC what actually I should do.
>
> I recompiled mainline kernel 4.12-rc4 with the Amlogic driver:
> replaced drivers/net/phy/meson-gxl.c with
> https://github.com/khadas/linux/blob/ubuntu-4.9/drivers/amlogic/ethernet/phy/amlogic.c
>
> But this did not solve the issue. As soon as i start git clone i lose
> network connection to device (no session timeout/disconnect this time,
> but I am unable to reconnect over SSH or to get OK ping replay back).
So this shows it is more than a PHY problem. The Ethernet MAC driver
is probably also part of the problem.
Are there any mainline kernels which work O.K?
Andrew
^ permalink raw reply
* Re: ipmr: MFC routes when VIF deleted
From: Nikolay Aleksandrov @ 2017-06-11 16:34 UTC (permalink / raw)
To: Yotam Gigi, netdev@vger.kernel.org; +Cc: Donald Sharp
In-Reply-To: <67ef0899-928a-d2cb-bf12-4bea80240dbe@mellanox.com>
On 11/06/17 11:55, Yotam Gigi wrote:
> I have been looking into some weird behavior, and I am not sure whether it is
> a bug or a feature.
>
> When a VIF with index v gets deleted, the MFC routes does not get updated, which
> means that there can be routes pointing to that VIF. On datapath, when packet
> hits that route, the VIF validity will be checked and will not be sent to that
> device (but still, the route does not get updated). Now, if the user creates
> another VIF with the same index v but different underlay device, the same route
> will forward the traffic to that device.
>
> It is relevant to mention that when user adds a MFC route, only the active VIFs
> are used, so the flow of adding a route with dummy VIF indices and then
> connecting those VIF indices to real device is not supported. The only way to
> create a MFC route that has non existing VIFs is to create one with existing
> VIFs and then delete them.
>
> Do we really want to support that? To me, it looks like a buggy flow and I
> suggest that upon VIF deletion, the MFC routes will be updated to not point to
> any non existing VIF indices.
>
Hi Yotam,
I'm not strongly against such change but my feeling is that we shouldn't change it.
I think we shouldn't change it because we cannot guarantee that we won't break some
user-space app that relies on this behaviour or uses it as an optimization.
User-space ipmr apps work in sync with the kernel and are usually the only ones
doing such changes so their internal state will be always valid, and I'd guess
they already deal with this one way or another.
My second argument is a minor one and is about performance. There are some apps
(e.g. pimd) which use interface add/del on interface state change (up/down) and
this could make these ops slower on large setups.
Again I see how this could be helpful and should've probably been like that from the
start, so if other people feel confident we won't break anything then I wouldn't
mind the change.
Thanks,
Nik
^ permalink raw reply
* Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
From: crow @ 2017-06-11 17:03 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, linux-amlogic
In-Reply-To: <20170611152102.GA16021@lunn.ch>
Hi Andrew,
On Sun, Jun 11, 2017 at 5:21 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> Thank your for the suggestion, and thanks Martin to explaining me over
>> IRC what actually I should do.
>>
>> I recompiled mainline kernel 4.12-rc4 with the Amlogic driver:
>> replaced drivers/net/phy/meson-gxl.c with
>> https://github.com/khadas/linux/blob/ubuntu-4.9/drivers/amlogic/ethernet/phy/amlogic.c
>>
>> But this did not solve the issue. As soon as i start git clone i lose
>> network connection to device (no session timeout/disconnect this time,
>> but I am unable to reconnect over SSH or to get OK ping replay back).
>
1) First problem reported I can't reproduce anymore, every reboot/cold
boot with mainline kernel the Ethernet speed is detected as
"100Mbps/Full" , but as seen in first post there was this issue.
2) see below
> So this shows it is more than a PHY problem. The Ethernet MAC driver
> is probably also part of the problem.
There are some stmmac fixes [1] in soon to be rc5, compiled current
master (without amlogic.c) with the fixes but for me the issue still
persist. I will compile once released rc5 with amlogic.c and report
back.
> Are there any mainline kernels which work O.K?
Khadas VIM support was added in 4.12-rc1. And I did test all four rc's
but without success.
> Andrew
[1] https://github.com/torvalds/linux/commit/426849e6611f2092553f8d53372ae310818a6292
^ permalink raw reply
* I Would love to discuse something with you.
From: Dave Dawes @ 2017-06-11 17:22 UTC (permalink / raw)
To: Recipients
^ permalink raw reply
* Re:
From: Sai al @ 2017-06-11 17:35 UTC (permalink / raw)
I need your partnership in a transaction that will benefit you,
details will disclose to you once i receive your reply.
Kind regards
Saif.
^ permalink raw reply
* Re: [PATCH net-next v10 1/4] net netlink: Add new type NLA_FLAG_BITS
From: Jamal Hadi Salim @ 2017-06-11 17:38 UTC (permalink / raw)
To: Jiri Pirko; +Cc: davem, netdev, xiyou.wangcong, eric.dumazet, simon.horman, mrv
In-Reply-To: <20170611134924.GA1896@nanopsycho.orion>
On 17-06-11 09:49 AM, Jiri Pirko wrote:
> Sun, Jun 11, 2017 at 01:53:43PM CEST, jhs@mojatatu.com wrote:
>> From: Jamal Hadi Salim <jhs@mojatatu.com>
>> This patch also provides an extra feature: a validation callback
>> that could be speaciliazed for other types.
>
> s/speaciliazed/speciliazed/
>
Will fix.
>>
>> [ATTR_GOO] = { .type = MYTYPE,
>> .validation_data = &myvalidation_data,
>> .validate_content = mycontent_validator },
>
> Indent is wrong. (Does not matter really in desc, but anyway)
>
I cant find out how it got indented that way; my source
or email dont show it as such (but really doesnt matter).
> Suggested-by: Jiri Pirko <jiri@mellanox.com>
>
Will add.
>
>> ---
>> include/net/netlink.h | 11 +++++++++++
>> include/uapi/linux/rtnetlink.h | 17 +++++++++++++++++
>> lib/nlattr.c | 25 +++++++++++++++++++++++++
>> 3 files changed, 53 insertions(+)
>>
>> diff --git a/include/net/netlink.h b/include/net/netlink.h
>> index 0170917..8ab9784 100644
>> --- a/include/net/netlink.h
>> +++ b/include/net/netlink.h
>> @@ -6,6 +6,11 @@
>> #include <linux/jiffies.h>
>> #include <linux/in6.h>
>>
>> +struct nla_bit_flags {
>> + u32 nla_flag_values;
>> + u32 nla_flag_selector;
>> +};
>
> I don't understand why you redefine the struct here. You already have it
> defined in the uapi: struct __nla_bit_flags
>
> Just move this (struct nla_bit_flags) to the uapi and remove
> __nla_bit_flags ?
>
I am not sure that will compile since the type is defined in netlink.h
Also, note: uapi uses _u32 and kernel uses u32 as types i.e it is pretty
common approach; i will try to move it to uapi and keep that uapi
format. If it doesnt compile without acrobatics I will keep it as is.
>
>
>> +
>> diff --git a/lib/nlattr.c b/lib/nlattr.c
>> index a7e0b16..78fed43 100644
>> --- a/lib/nlattr.c
>> +++ b/lib/nlattr.c
>> @@ -27,6 +27,21 @@
>> [NLA_S64] = sizeof(s64),
>> };
>>
>> +static int validate_nla_bit_flags(const struct nlattr *nla, void *valid_data)
>> +{
>> + const struct nla_bit_flags *nbf = nla_data(nla);
>> + u32 *valid_flags_mask = valid_data;
>> +
>> + if (!valid_data)
>> + return -EINVAL;
>> +
>> +
>
> Avoid one empty line here (you have 2)
>
Will fix.
>
>> + if (nbf->nla_flag_values & ~*valid_flags_mask)
>> + return -EINVAL;
>> +
>> + return 0;
>> +}
>> +
>> static int validate_nla(const struct nlattr *nla, int maxtype,
>> const struct nla_policy *policy)
>> {
>> @@ -46,6 +61,13 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
>> return -ERANGE;
>> break;
>>
>> + case NLA_FLAG_BITS:
>> + if (attrlen != 8) /* 2 x 32 bits */
>
> sizeof(struct nla_bit_flags) instead of 8 please, you can skip the
> comment then.
>
Good point.
>
>> + return -ERANGE;
>> +
>> + return validate_nla_bit_flags(nla, pt->validation_data);
>> + break;
>> +
>> case NLA_NUL_STRING:
>> if (pt->len)
>> minlen = min_t(int, attrlen, pt->len + 1);
>> @@ -103,6 +125,9 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
>> return -ERANGE;
>> }
>>
>> + if (pt->validate_content)
>> + return pt->validate_content(nla, pt->validation_data);
>
> This validation mechanism is completely independent from the added NLA_FLAG_BITS
> attr as it could be used with other attribute types. Please have it as a
> separate patch.
>
Ok - so one more patch then ;->
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net-next v10 3/4] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch
From: Jamal Hadi Salim @ 2017-06-11 17:45 UTC (permalink / raw)
To: Jiri Pirko; +Cc: davem, netdev, xiyou.wangcong, eric.dumazet, simon.horman, mrv
In-Reply-To: <20170611141303.GC1896@nanopsycho.orion>
On 17-06-11 10:13 AM, Jiri Pirko wrote:
> Sun, Jun 11, 2017 at 01:53:45PM CEST, jhs@mojatatu.com wrote:
>> From: Jamal Hadi Salim <jhs@mojatatu.com>
>>
>> When you dump hundreds of thousands of actions, getting only 32 per
>> dump batch even when the socket buffer and memory allocations allow
>> is inefficient.
>>
>> With this change, the user will get as many as possibly fitting
>> within the given constraints available to the kernel.
>>
>> The top level action TLV space is extended. An attribute
>> TCA_ROOT_FLAGS is used to carry flags; flag TCA_FLAG_LARGE_DUMP_ON
>> is set by the user indicating the user is capable of processing
>> these large dumps. Older user space which doesnt set this flag
>> doesnt get the large (than 32) batches.
>> The kernel uses the TCA_ROOT_COUNT attribute to tell the user how many
>> actions are put in a single batch. As such user space app knows how long
>> to iterate (independent of the type of action being dumped)
>> instead of hardcoded maximum of 32 thus maintaining backward compat.
>>
>> Some results dumping 1.5M actions below:
>> first an unpatched tc which doesnt understand these features...
>>
>> prompt$ time -p tc actions ls action gact | grep index | wc -l
>> 1500000
>> real 1388.43
>> user 2.07
>> sys 1386.79
>>
>> Now lets see a patched tc which sets the correct flags when requesting
>> a dump:
>>
>> prompt$ time -p updatedtc actions ls action gact | grep index | wc -l
>> 1500000
>> real 178.13
>> user 2.02
>> sys 176.96
>>
>> That is about 8x performance improvement for tc app which sets its
>> receive buffer to about 32K.
>>
>> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
>> ---
>> include/uapi/linux/rtnetlink.h | 22 +++++++++++++++++--
>> net/sched/act_api.c | 50 +++++++++++++++++++++++++++++++++---------
>> 2 files changed, 60 insertions(+), 12 deletions(-)
>>
>> diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
>> index 8f07957..7d2030f 100644
>> --- a/include/uapi/linux/rtnetlink.h
>> +++ b/include/uapi/linux/rtnetlink.h
>> @@ -693,10 +693,28 @@ struct tcamsg {
>> unsigned char tca__pad1;
>> unsigned short tca__pad2;
>> };
>> +
>> +enum {
>> + TCA_ROOT_UNSPEC,
>> + TCA_ROOT_TAB,
>> +#define TCA_ACT_TAB TCA_ROOT_TAB
>> +#define TCAA_MAX TCA_ROOT_TAB
>> + TCA_ROOT_FLAGS,
>> + TCA_ROOT_COUNT,
>> + __TCA_ROOT_MAX,
>> +#define TCA_ROOT_MAX (__TCA_ROOT_MAX - 1)
>> +};
>> +
>> #define TA_RTA(r) ((struct rtattr*)(((char*)(r)) + NLMSG_ALIGN(sizeof(struct tcamsg))))
>> #define TA_PAYLOAD(n) NLMSG_PAYLOAD(n,sizeof(struct tcamsg))
>> -#define TCA_ACT_TAB 1 /* attr type must be >=1 */
>> -#define TCAA_MAX 1
>> +/* tcamsg flags stored in attribute TCA_ROOT_FLAGS
>> + *
>> + * TCA_FLAG_LARGE_DUMP_ON user->kernel to request for larger than TCA_ACT_MAX_PRIO
>> + * actions in a dump. All dump responses will contain the number of actions
>> + * being dumped stored in for user app's consumption in TCA_ROOT_COUNT
>> + *
>> + */
>> +#define TCA_FLAG_LARGE_DUMP_ON (1 << 0)
>>
>> /* New extended info filters for IFLA_EXT_MASK */
>> #define RTEXT_FILTER_VF (1 << 0)
>> diff --git a/net/sched/act_api.c b/net/sched/act_api.c
>> index 400eb6e..935dc19 100644
>> --- a/net/sched/act_api.c
>> +++ b/net/sched/act_api.c
>> @@ -110,6 +110,7 @@ static int tcf_dump_walker(struct tcf_hashinfo *hinfo, struct sk_buff *skb,
>> struct netlink_callback *cb)
>> {
>> int err = 0, index = -1, i = 0, s_i = 0, n_i = 0;
>> + u32 act_flags = cb->args[2];
>> struct nlattr *nest;
>>
>> spin_lock_bh(&hinfo->lock);
>> @@ -138,14 +139,18 @@ static int tcf_dump_walker(struct tcf_hashinfo *hinfo, struct sk_buff *skb,
>> }
>> nla_nest_end(skb, nest);
>> n_i++;
>> - if (n_i >= TCA_ACT_MAX_PRIO)
>> + if (!(act_flags & TCA_FLAG_LARGE_DUMP_ON) &&
>> + n_i >= TCA_ACT_MAX_PRIO)
>> goto done;
>> }
>> }
>> done:
>> spin_unlock_bh(&hinfo->lock);
>> - if (n_i)
>> + if (n_i) {
>> cb->args[0] += n_i;
>> + if (act_flags & TCA_FLAG_LARGE_DUMP_ON)
>> + cb->args[1] = n_i;
>> + }
>> return n_i;
>>
>> nla_put_failure:
>> @@ -1068,11 +1073,17 @@ static int tcf_action_add(struct net *net, struct nlattr *nla,
>> return tcf_add_notify(net, n, &actions, portid);
>> }
>>
>> +static u32 allowed_flags = TCA_FLAG_LARGE_DUMP_ON;
>
> An empty line would be nice. Also, since this is outside a function, some
> context prefix would be nice:
> static u32 tcaa_root_flags_allowed = TCA_FLAG_LARGE_DUMP_ON;
>
You are going to make me exceed the 80 char limit? ;->
>> + if (tb[TCA_ROOT_FLAGS])
>> + nla_memcpy(&select_flags, tb[TCA_ROOT_FLAGS],
>> + sizeof(select_flags));
>
> Please introduce a helper for this attr type in patch 1:
>
> u32 select_flags;
>
> select_flags = nla_get_flag_bits_values(tb[TCA_ROOT_FLAGS])
>
Sure.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net-next v10 1/4] net netlink: Add new type NLA_FLAG_BITS
From: Jamal Hadi Salim @ 2017-06-11 18:37 UTC (permalink / raw)
To: Jiri Pirko; +Cc: davem, netdev, xiyou.wangcong, eric.dumazet, simon.horman, mrv
In-Reply-To: <4c536950-2be3-cc9c-1f77-066624800d07@mojatatu.com>
On 17-06-11 01:38 PM, Jamal Hadi Salim wrote:
> On 17-06-11 09:49 AM, Jiri Pirko wrote:
>> Sun, Jun 11, 2017 at 01:53:43PM CEST, jhs@mojatatu.com wrote:
>>> From: Jamal Hadi Salim <jhs@mojatatu.com>
>
>
>>> This patch also provides an extra feature: a validation callback
>>> that could be speaciliazed for other types.
>>
>> s/speaciliazed/speciliazed/
>>
>
> Will fix.
>
>
>>>
>>> [ATTR_GOO] = { .type = MYTYPE,
>>> .validation_data = &myvalidation_data,
>>> .validate_content = mycontent_validator },
>>
>> Indent is wrong. (Does not matter really in desc, but anyway)
>>
>
> I cant find out how it got indented that way; my source
> or email dont show it as such (but really doesnt matter).
>
>
>> Suggested-by: Jiri Pirko <jiri@mellanox.com>
>>
>
> Will add.
>
>>
>>> ---
>>> include/net/netlink.h | 11 +++++++++++
>>> include/uapi/linux/rtnetlink.h | 17 +++++++++++++++++
>>> lib/nlattr.c | 25 +++++++++++++++++++++++++
>>> 3 files changed, 53 insertions(+)
>>>
>>> diff --git a/include/net/netlink.h b/include/net/netlink.h
>>> index 0170917..8ab9784 100644
>>> --- a/include/net/netlink.h
>>> +++ b/include/net/netlink.h
>>> @@ -6,6 +6,11 @@
>>> #include <linux/jiffies.h>
>>> #include <linux/in6.h>
>>>
>>> +struct nla_bit_flags {
>>> + u32 nla_flag_values;
>>> + u32 nla_flag_selector;
>>> +};
>>
>> I don't understand why you redefine the struct here. You already have it
>> defined in the uapi: struct __nla_bit_flags
>>
>> Just move this (struct nla_bit_flags) to the uapi and remove
>> __nla_bit_flags ?
>>
>
> I am not sure that will compile since the type is defined in netlink.h
> Also, note: uapi uses _u32 and kernel uses u32 as types i.e it is pretty
> common approach; i will try to move it to uapi and keep that uapi
> format. If it doesnt compile without acrobatics I will keep it as is.
>
It doesnt compile - I could move it to linux/netlink.h but it seems
so out of place.
so i will keep things as is for now unless you can think of something
else.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net 0/9] Bugs fixes in ena ethernet driver
From: David Miller @ 2017-06-11 20:38 UTC (permalink / raw)
To: netanel; +Cc: netdev, dwmw, zorik, matua, saeedb, msw, aliguori, nafea, evgenys
In-Reply-To: <1497184971-28178-1-git-send-email-netanel@amazon.com>
From: <netanel@amazon.com>
Date: Sun, 11 Jun 2017 15:42:42 +0300
> This patchset contains fixes for the bugs that were discovered so far.
Series applied.
^ permalink raw reply
* Re: [pull request][net 0/6] Mellanox mlx5 fixes 2017-06-11
From: David Miller @ 2017-06-11 20:42 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20170611140028.12467-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Sun, 11 Jun 2017 17:00:22 +0300
> This series contains some fixes for the mlx5 core and netdev driver.
>
> Please pull and let me know if there's any problem.
Pulled, thanks.
> For -stable:
> ("net/mlx5e: Added BW check for DIM decision mechanism") kernels >= 4.9
> ("net/mlx5e: Fix wrong indications in DIM due to counter wraparound") kernels >= 4.9
> ("net/mlx5: Remove several module events out of ethtool stats") kernels >= 4.10
> ("net/mlx5: Enable 4K UAR only when page size is bigger than 4K") kernels >= 4.11
>
> *all patches apply with no issue on their -stable.
>
> BTW I never asked you if this way of marking patches to -stable is good for you ?
> if you prefer another format please let me know.
It works fine for now, I'll let you know if it causes problems :)
^ permalink raw reply
* Re: [PATCH 0/6] Constant Time Memory Comparisons Are Important
From: Emmanuel Grumbach @ 2017-06-11 20:48 UTC (permalink / raw)
To: Kees Cook
Cc: Kalle Valo, Jason A. Donenfeld, LKML,
kernel-hardening@lists.openwall.com, Anna Schumaker,
David Howells, David Safford, David S. Miller, Gilad Ben-Yossef,
Greg Kroah-Hartman, Gustavo Padovan, J. Bruce Fields, Jeff Layton,
Johan Hedberg, Johannes Berg, Marcel Holtmann, Mimi Zohar,
Trond Myklebust <trond.myklebust@
In-Reply-To: <CAGXu5jKp=X7-eKo+HgzS3uqncx5yy-u=tJNqV9K8GOgJ=-C7iA@mail.gmail.com>
On Sun, Jun 11, 2017 at 4:36 PM, Kees Cook <keescook@chromium.org> wrote:
>
> On Sun, Jun 11, 2017 at 1:13 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
> > "Jason A. Donenfeld" <Jason@zx2c4.com> writes:
> >
> >> Whenever you're comparing two MACs, it's important to do this using
> >> crypto_memneq instead of memcmp. With memcmp, you leak timing information,
> >> which could then be used to iteratively forge a MAC.
> >
> > Do you have any pointers where I could learn more about this?
>
> While not using C specifically, this talks about the problem generally:
> https://www.chosenplaintext.ca/articles/beginners-guide-constant-time-cryptography.html
>
Sorry for the stupid question, but the MAC address is in plaintext in
the air anyway or easily accessible via user space tools. I fail to
see what it is so secret about a MAC address in that code where that
same MAC address is accessible via myriads of ways.
^ permalink raw reply
* Re: [PATCH 0/6] Constant Time Memory Comparisons Are Important
From: Stephan Müller @ 2017-06-11 21:06 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-hardening-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8, Anna Schumaker,
David Howells, David Safford, David S. Miller, Gilad Ben-Yossef,
Greg Kroah-Hartman, Gustavo Padovan, J. Bruce Fields, Jeff Layton,
Johan Hedberg, Johannes Berg, Marcel Holtmann, Mimi Zohar,
Trond Myklebust, keyrings-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170610025912.6499-1-Jason-OnJsPKxuuEcAvxtiuMwx3w@public.gmane.org>
Am Samstag, 10. Juni 2017, 04:59:06 CEST schrieb Jason A. Donenfeld:
Hi Jason,
> Whenever you're comparing two MACs, it's important to do this using
> crypto_memneq instead of memcmp. With memcmp, you leak timing information,
> which could then be used to iteratively forge a MAC. This is far too basic
> of a mistake for us to have so pervasively in the year 2017, so let's begin
> cleaning this stuff up. The following 6 locations were found with some
> simple regex greps, but I'm sure more lurk below the surface. If you
> maintain some code or know somebody who maintains some code that deals
> with MACs, tell them to double check which comparison function they're
> using.
Are you planning to send an update to your patch set? If yes, there is another
one which should be converted too: crypto/rsa-pkcs1pad.c.
Otherwise, I will send a patch converting this one.
Thanks.
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/6] Constant Time Memory Comparisons Are Important
From: Jason A. Donenfeld @ 2017-06-11 21:21 UTC (permalink / raw)
To: Stephan Müller
Cc: LKML, kernel-hardening, Anna Schumaker, David Howells,
David Safford, David S. Miller, Gilad Ben-Yossef,
Greg Kroah-Hartman, Gustavo Padovan, J. Bruce Fields, Jeff Layton,
Johan Hedberg, Johannes Berg, Marcel Holtmann, Mimi Zohar,
Trond Myklebust, keyrings, linux-bluetooth, linux-nfs,
linux-wireless
In-Reply-To: <20235732.W6WmnKk6cl@tauon.chronox.de>
Hi Stephan,
On Sun, Jun 11, 2017 at 11:06 PM, Stephan Müller <smueller@chronox.de> wrote:
> Are you planning to send an update to your patch set? If yes, there is another
> one which should be converted too: crypto/rsa-pkcs1pad.c.
I just sent an update to this thread patching that, per your
suggestion. Since these issues are expected to be cherry picked by
their respective committer, I figure we can just pile on the patches
here, listing the 0/6 intro email as each patch's parent.
Jason
^ permalink raw reply
* Re: [PATCH 0/6] Constant Time Memory Comparisons Are Important
From: Emil Lenngren @ 2017-06-11 21:30 UTC (permalink / raw)
To: Emmanuel Grumbach
Cc: Kees Cook, Kalle Valo, Jason A. Donenfeld, LKML,
kernel-hardening-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org,
Anna Schumaker, David Howells, David Safford, David S. Miller,
Gilad Ben-Yossef, Greg Kroah-Hartman, Gustavo Padovan,
J. Bruce Fields, Jeff Layton, Johan Hedberg, Johannes Berg,
Marcel Holtmann, Mimi Zohar
In-Reply-To: <CANUX_P2b0Bx+-E_OBQ0reGW0=d6819qc=r83K0kTv0xMo8mtLQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-11 22:48 GMT+02:00 Emmanuel Grumbach <egrumbach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> On Sun, Jun 11, 2017 at 4:36 PM, Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
>>
>> On Sun, Jun 11, 2017 at 1:13 AM, Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
>> > "Jason A. Donenfeld" <Jason-OnJsPKxuuEcAvxtiuMwx3w@public.gmane.org> writes:
>> >
>> >> Whenever you're comparing two MACs, it's important to do this using
>> >> crypto_memneq instead of memcmp. With memcmp, you leak timing information,
>> >> which could then be used to iteratively forge a MAC.
>> >
>> > Do you have any pointers where I could learn more about this?
>>
>> While not using C specifically, this talks about the problem generally:
>> https://www.chosenplaintext.ca/articles/beginners-guide-constant-time-cryptography.html
>>
>
> Sorry for the stupid question, but the MAC address is in plaintext in
> the air anyway or easily accessible via user space tools. I fail to
> see what it is so secret about a MAC address in that code where that
> same MAC address is accessible via myriads of ways.
I think you're mixing up Media Access Control (MAC) addresses with
Message Authentication Code (MAC). The second one is a cryptographic
signature of a message.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [pull request][net-next 0/9] Mellanox mlx5 updates 2017-06-11
From: David Miller @ 2017-06-11 22:13 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20170611145553.14180-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Sun, 11 Jun 2017 17:55:44 +0300
> This series provides updates to mlx5 header rewrite feature, from Or Gerlitz.
> and three more small updates From Maor and Eran.
>
> For more details please see below.
Pulled, thanks.
> Please pull and let me know if there's any problem.
> *This series doesn't introduce any conflict with the ongoing net
> pull request.
Ok, thanks for letting me know.
^ permalink raw reply
* Re: [PATCH net v3] net: ipmr: Fix some mroute forwarding issues in vrf's
From: David Miller @ 2017-06-11 22:15 UTC (permalink / raw)
To: sharpd; +Cc: netdev, dsahern, Thomas.Winter, nikolay, yotamg, idosch, roopa
In-Reply-To: <20170610203017.4085-1-sharpd@cumulusnetworks.com>
From: Donald Sharp <sharpd@cumulusnetworks.com>
Date: Sat, 10 Jun 2017 16:30:17 -0400
> This patch fixes two issues:
>
> 1) When forwarding on *,G mroutes that are in a vrf, the
> kernel was dropping information about the actual incoming
> interface when calling ip_mr_forward from ip_mr_input.
> This caused ip_mr_forward to send the multicast packet
> back out the incoming interface. Fix this by
> modifying ip_mr_forward to be handed the correctly
> resolved dev.
>
> 2) When a unresolved cache entry is created we store
> the incoming skb on the unresolved cache entry and
> upon mroute resolution from the user space daemon,
> we attempt to forward the packet. Again we were
> not resolving to the correct incoming device for
> a vrf scenario, before calling ip_mr_forward.
> Fix this by resolving to the correct interface
> and calling ip_mr_forward with the result.
>
> Fixes: e58e41596811 ("net: Enable support for VRF with ipv4 multicast")
> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
> ---
> v2: Fixed title
> v3: Addressed Review comments by Andrew Lunn and David Ahern
Applied and queued up for -stable, thank you.
^ permalink raw reply
* Re: [PATCH net-next] bpf, arm64: take advantage of stack_depth tracking
From: David Miller @ 2017-06-11 22:18 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev, linux-arm-kernel
In-Reply-To: <afc90487fc573886a44178c2428f3157312128d8.1497145004.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Sun, 11 Jun 2017 03:55:27 +0200
> Make use of recently implemented stack_depth tracking for arm64 JIT,
> so that stack usage can be reduced heavily for programs not using
> tail calls at least.
>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
Applied, thanks Daniel.
^ permalink raw reply
* [PATCH net-next] vxlan: dont migrate permanent fdb entries during learn
From: Roopa Prabhu @ 2017-06-11 22:51 UTC (permalink / raw)
To: davem; +Cc: netdev, jbenc, hannes, nicolas.dichtel, nikolay
From: Roopa Prabhu <roopa@cumulusnetworks.com>
This patch fixes vxlan_snoop to not move permanent fdb entries
on learn events. This is consistent with the bridge fdb
handling of permanent entries.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
drivers/net/vxlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 7cb21a0..e045c34 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -970,7 +970,7 @@ static bool vxlan_snoop(struct net_device *dev,
return false;
/* Don't migrate static entries, drop packets */
- if (f->state & NUD_NOARP)
+ if (f->state & (NUD_PERMANENT | NUD_NOARP))
return true;
if (net_ratelimit())
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net-next] vxlan: dont migrate permanent fdb entries during learn
From: David Miller @ 2017-06-11 23:04 UTC (permalink / raw)
To: roopa; +Cc: netdev, jbenc, hannes, nicolas.dichtel, nikolay
In-Reply-To: <1497221482-33473-1-git-send-email-roopa@cumulusnetworks.com>
From: Roopa Prabhu <roopa@cumulusnetworks.com>
Date: Sun, 11 Jun 2017 15:51:22 -0700
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> This patch fixes vxlan_snoop to not move permanent fdb entries
> on learn events. This is consistent with the bridge fdb
> handling of permanent entries.
>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Is there an appropriate Fixes: tag by chance?
^ permalink raw reply
* Re: [PATCH net-next] vxlan: dont migrate permanent fdb entries during learn
From: Roopa Prabhu @ 2017-06-11 23:26 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, Jiri Benc, hannes@stressinduktion.org,
Nicolas Dichtel, Nikolay Aleksandrov
In-Reply-To: <20170611.190416.1443081184910537296.davem@davemloft.net>
On Sun, Jun 11, 2017 at 4:04 PM, David Miller <davem@davemloft.net> wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
> Date: Sun, 11 Jun 2017 15:51:22 -0700
>
>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>
>> This patch fixes vxlan_snoop to not move permanent fdb entries
>> on learn events. This is consistent with the bridge fdb
>> handling of permanent entries.
>>
>> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> Is there an appropriate Fixes: tag by chance?
Just checked history. It has been that way since beginning of time.
Initial vxlan implementation (year 2012) allowed migration of any
entry via learn. A 2013 commit 26a41ae60438 ("vxlan: only migrate
dynamic FDB entries") tried to fix it, but it added a check for static
entries only (NUD_NOARP) and missed permanent entries (NUD_PERMANENT).
I think we can add:
Fixes: 26a41ae60438 ("vxlan: only migrate dynamic FDB entries")
I can re-spin with this Fixes tag.
^ 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;
as well as URLs for NNTP newsgroup(s).