* [PATCH] atl1c: remove redundant assignment to variable tpd_req
From: Colin King @ 2019-07-03 7:53 UTC (permalink / raw)
To: Jay Cliburn, Chris Snook, David S . Miller, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The variable tpd_req is being initialized with a value that is never
read and it is being updated later with a new value. The
initialization is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
index 25bf085324b8..be7f9cebb675 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
@@ -2201,7 +2201,7 @@ static netdev_tx_t atl1c_xmit_frame(struct sk_buff *skb,
struct net_device *netdev)
{
struct atl1c_adapter *adapter = netdev_priv(netdev);
- u16 tpd_req = 1;
+ u16 tpd_req;
struct atl1c_tpd_desc *tpd;
enum atl1c_trans_queue type = atl1c_trans_normal;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Daniel Drake @ 2019-07-03 7:51 UTC (permalink / raw)
To: Chris Chiu
Cc: Jes Sorensen, Kalle Valo, David Miller, linux-wireless, netdev,
Linux Kernel, Linux Upstreaming Team, Larry Finger
In-Reply-To: <CAB4CAwcVoWffpK8xR_UbXaGyHh8ZrrX_9vvzjAkWGKXQotpmYA@mail.gmail.com>
On Tue, Jul 2, 2019 at 4:01 PM Chris Chiu <chiu@endlessm.com> wrote:
> When the vendor driver invokes rtw_btcoex_HAL_Initialize, which will then
> call halbtc8723b1ant_SetAntPath to configure the registers in this patch.
> From the code, the registers will have different register settings per the
> antenna position and the phase. If the driver is in the InitHwConfig phase,
> the register value is identical to what rtl8xxxu driver does in enable_rf().
> However, the vendor driver will do halbtc8723b1ant_PsTdma() twice by
> halbtc8723b1ant_ActionWifiNotConnected() with the type argument 8 for
> PTA control about 200ms after InitHwConfig. The _ActionWifiNotConnected
> is invoked by the BTCOEXIST. I keep seeing the halbtc8723b1ant_PsTdma
> with type 8 been called every 2 seconds.
I see. So this is a measured step towards consistency with the vendor
driver. Maybe you can mention these details in the commit message.
> Yes, it ends up with 0x0c not matter what antenna position type is. Unless
> it's configured wifi only.
Also worth mentioning in the commit message then, that the 0xc
ACT_CONTROL value is effectively what the working vendor driver uses.
> > > - * 0x280, 0x00, 0x200, 0x80 - not clear
> > > + * Different settings per different antenna position.
> > > + * Antenna switch to BT: 0x280, 0x00 (inverse)
> > > + * Antenna switch to WiFi: 0x0, 0x280 (inverse)
> > > + * Antenna controlled by PTA: 0x200, 0x80 (inverse)
> > > */
> > > - rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x00);
> > > + rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x80);
> >
> > I don't quite follow the comment here. Why are there 2 values listed
> > for each possibility, what do you mean by inverse? You say the
> > register settings were incorrect, but the previous value was 0x00
> > which you now document as "antenna switch to wifi" which sounds like
> > it was already correct?
> >
> > Which value does the vendor driver use?
> >
> The first column means the value for normal antenna installation, wifi
> on the main port. The second column is the value for inverse antenna
> installation. So if I want to manually switch the antenna for BT use,
> and the antenna installation is inverse, I need to set to 0x280. So 0x80
> means I want to switch to PTA and the antenna installation in inverse.
Still not quite clear what you mean by "inverse" here, but maybe I
just don't know anything about antennas. Is it that an antenna
connector has two pins and this one swaps the meaning of each pin?
Does the new value of 0x80 reflect what the vendor driver does in practice?
Thanks
Daniel
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Daniel Drake @ 2019-07-03 7:42 UTC (permalink / raw)
To: Jes Sorensen
Cc: Chris Chiu, Kalle Valo, David Miller, linux-wireless, netdev,
Linux Kernel, Linux Upstreaming Team, Larry Finger
In-Reply-To: <4c99866e-55b7-8852-c078-6b31dce21ee4@gmail.com>
On Tue, Jul 2, 2019 at 8:42 PM Jes Sorensen <jes.sorensen@gmail.com> wrote:
> We definitely don't want to bring over the vendor code, since it's a
> pile of spaghetti, but we probably need to get something sorted. This
> went down the drain when the bluetooth driver was added without taking
> it into account - long after this driver was merged.
Yeah, I didn't mean bring over quite so literally.. Chris is studying
it and figuring out the neatest way to reimplement the required bits.
As for the relationship with bluetooth.. actually the bug that Chris
is working on here is that the rtl8xxxu wifi signal is totally
unusable *until* the bluetooth driver is loaded.
Once the bluetooth driver is loaded, at the point of bluetooth
firmware upload, the rtl8xxxu signal magiaclly strength becomes good.
I think this is consistent with other rtl8xxxu problem reports that we
saw lying around, although they had not been diagnosed in so much
detail.
The rtl8723bu vendor driver does not suffer this problem, it works
fine with or without the bluetooth driver in place.
Daniel
^ permalink raw reply
* [PATCH mlx5-next 5/5] net/mlx5: Properly name the generic WQE control field
From: Saeed Mahameed @ 2019-07-03 7:39 UTC (permalink / raw)
To: Saeed Mahameed, Leon Romanovsky
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org, Tariq Toukan
In-Reply-To: <20190703073909.14965-1-saeedm@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
A generic WQE control field is used for different purposes
in different cases.
Use union to allow using the proper name in each case.
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
include/linux/mlx5/qp.h | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/linux/mlx5/qp.h b/include/linux/mlx5/qp.h
index d1f353c64797..127d224443e3 100644
--- a/include/linux/mlx5/qp.h
+++ b/include/linux/mlx5/qp.h
@@ -202,7 +202,12 @@ struct mlx5_wqe_ctrl_seg {
u8 signature;
u8 rsvd[2];
u8 fm_ce_se;
- __be32 imm;
+ union {
+ __be32 general_id;
+ __be32 imm;
+ __be32 umr_mkey;
+ __be32 tisn;
+ };
};
#define MLX5_WQE_CTRL_DS_MASK 0x3f
--
2.21.0
^ permalink raw reply related
* [PATCH mlx5-next 4/5] net/mlx5: Introduce TLS TX offload hardware bits and structures
From: Saeed Mahameed @ 2019-07-03 7:39 UTC (permalink / raw)
To: Saeed Mahameed, Leon Romanovsky
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
Eran Ben Elisha, Tariq Toukan
In-Reply-To: <20190703073909.14965-1-saeedm@mellanox.com>
From: Eran Ben Elisha <eranbe@mellanox.com>
Add TLS offload related IFC structs, layouts and enumerations.
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
include/linux/mlx5/device.h | 14 +++++
include/linux/mlx5/mlx5_ifc.h | 104 ++++++++++++++++++++++++++++++++--
2 files changed, 114 insertions(+), 4 deletions(-)
diff --git a/include/linux/mlx5/device.h b/include/linux/mlx5/device.h
index 5e760067ac41..5f7d1671ad5a 100644
--- a/include/linux/mlx5/device.h
+++ b/include/linux/mlx5/device.h
@@ -437,6 +437,7 @@ enum {
MLX5_OPCODE_SET_PSV = 0x20,
MLX5_OPCODE_GET_PSV = 0x21,
MLX5_OPCODE_CHECK_PSV = 0x22,
+ MLX5_OPCODE_DUMP = 0x23,
MLX5_OPCODE_RGET_PSV = 0x26,
MLX5_OPCODE_RCHECK_PSV = 0x27,
@@ -444,6 +445,14 @@ enum {
};
+enum {
+ MLX5_OPC_MOD_TLS_TIS_STATIC_PARAMS = 0x20,
+};
+
+enum {
+ MLX5_OPC_MOD_TLS_TIS_PROGRESS_PARAMS = 0x20,
+};
+
enum {
MLX5_SET_PORT_RESET_QKEY = 0,
MLX5_SET_PORT_GUID0 = 16,
@@ -1077,6 +1086,8 @@ enum mlx5_cap_type {
MLX5_CAP_DEBUG,
MLX5_CAP_RESERVED_14,
MLX5_CAP_DEV_MEM,
+ MLX5_CAP_RESERVED_16,
+ MLX5_CAP_TLS,
/* NUM OF CAP Types */
MLX5_CAP_NUM
};
@@ -1255,6 +1266,9 @@ enum mlx5_qcam_feature_groups {
#define MLX5_CAP64_DEV_MEM(mdev, cap)\
MLX5_GET64(device_mem_cap, mdev->caps.hca_cur[MLX5_CAP_DEV_MEM], cap)
+#define MLX5_CAP_TLS(mdev, cap) \
+ MLX5_GET(tls_cap, (mdev)->caps.hca_cur[MLX5_CAP_TLS], cap)
+
enum {
MLX5_CMD_STAT_OK = 0x0,
MLX5_CMD_STAT_INT_ERR = 0x1,
diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index 031db53e94ce..1f77ae1ed250 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -953,6 +953,16 @@ struct mlx5_ifc_vector_calc_cap_bits {
u8 reserved_at_c0[0x720];
};
+struct mlx5_ifc_tls_cap_bits {
+ u8 tls_1_2_aes_gcm_128[0x1];
+ u8 tls_1_3_aes_gcm_128[0x1];
+ u8 tls_1_2_aes_gcm_256[0x1];
+ u8 tls_1_3_aes_gcm_256[0x1];
+ u8 reserved_at_4[0x1c];
+
+ u8 reserved_at_20[0x7e0];
+};
+
enum {
MLX5_WQ_TYPE_LINKED_LIST = 0x0,
MLX5_WQ_TYPE_CYCLIC = 0x1,
@@ -1282,7 +1292,8 @@ struct mlx5_ifc_cmd_hca_cap_bits {
u8 reserved_at_440[0x20];
- u8 reserved_at_460[0x3];
+ u8 tls[0x1];
+ u8 reserved_at_461[0x2];
u8 log_max_uctx[0x5];
u8 reserved_at_468[0x3];
u8 log_max_umem[0x5];
@@ -1307,7 +1318,9 @@ struct mlx5_ifc_cmd_hca_cap_bits {
u8 max_geneve_tlv_option_data_len[0x5];
u8 reserved_at_570[0x10];
- u8 reserved_at_580[0x3c];
+ u8 reserved_at_580[0x33];
+ u8 log_max_dek[0x5];
+ u8 reserved_at_5b8[0x4];
u8 mini_cqe_resp_stride_index[0x1];
u8 cqe_128_always[0x1];
u8 cqe_compression_128[0x1];
@@ -2586,6 +2599,7 @@ union mlx5_ifc_hca_cap_union_bits {
struct mlx5_ifc_qos_cap_bits qos_cap;
struct mlx5_ifc_debug_cap_bits debug_cap;
struct mlx5_ifc_fpga_cap_bits fpga_cap;
+ struct mlx5_ifc_tls_cap_bits tls_cap;
u8 reserved_at_0[0x8000];
};
@@ -2725,7 +2739,8 @@ struct mlx5_ifc_traffic_counter_bits {
struct mlx5_ifc_tisc_bits {
u8 strict_lag_tx_port_affinity[0x1];
- u8 reserved_at_1[0x3];
+ u8 tls_en[0x1];
+ u8 reserved_at_1[0x2];
u8 lag_tx_port_affinity[0x04];
u8 reserved_at_8[0x4];
@@ -2739,7 +2754,11 @@ struct mlx5_ifc_tisc_bits {
u8 reserved_at_140[0x8];
u8 underlay_qpn[0x18];
- u8 reserved_at_160[0x3a0];
+
+ u8 reserved_at_160[0x8];
+ u8 pd[0x18];
+
+ u8 reserved_at_180[0x380];
};
enum {
@@ -9937,4 +9956,81 @@ struct mlx5_ifc_alloc_sf_in_bits {
u8 reserved_at_60[0x20];
};
+enum {
+ MLX5_HCA_CAP_GENERAL_OBJECT_TYPES_ENCRYPTION_KEY = BIT(0xc),
+};
+
+enum {
+ MLX5_GENERAL_OBJECT_TYPES_ENCRYPTION_KEY = 0xc,
+};
+
+struct mlx5_ifc_encryption_key_obj_bits {
+ u8 modify_field_select[0x40];
+
+ u8 reserved_at_40[0x14];
+ u8 key_size[0x4];
+ u8 reserved_at_58[0x4];
+ u8 key_type[0x4];
+
+ u8 reserved_at_60[0x8];
+ u8 pd[0x18];
+
+ u8 reserved_at_80[0x180];
+ u8 key[8][0x20];
+
+ u8 reserved_at_300[0x500];
+};
+
+struct mlx5_ifc_create_encryption_key_in_bits {
+ struct mlx5_ifc_general_obj_in_cmd_hdr_bits general_obj_in_cmd_hdr;
+ struct mlx5_ifc_encryption_key_obj_bits encryption_key_object;
+};
+
+enum {
+ MLX5_GENERAL_OBJECT_TYPE_ENCRYPTION_KEY_KEY_SIZE_128 = 0x0,
+ MLX5_GENERAL_OBJECT_TYPE_ENCRYPTION_KEY_KEY_SIZE_256 = 0x1,
+};
+
+enum {
+ MLX5_GENERAL_OBJECT_TYPE_ENCRYPTION_KEY_TYPE_DEK = 0x1,
+};
+
+struct mlx5_ifc_tls_static_params_bits {
+ u8 const_2[0x2];
+ u8 tls_version[0x4];
+ u8 const_1[0x2];
+ u8 reserved_at_8[0x14];
+ u8 encryption_standard[0x4];
+
+ u8 reserved_at_20[0x20];
+
+ u8 initial_record_number[0x40];
+
+ u8 resync_tcp_sn[0x20];
+
+ u8 gcm_iv[0x20];
+
+ u8 implicit_iv[0x40];
+
+ u8 reserved_at_100[0x8];
+ u8 dek_index[0x18];
+
+ u8 reserved_at_120[0xe0];
+};
+
+struct mlx5_ifc_tls_progress_params_bits {
+ u8 valid[0x1];
+ u8 reserved_at_1[0x7];
+ u8 pd[0x18];
+
+ u8 next_record_tcp_sn[0x20];
+
+ u8 hw_resync_tcp_sn[0x20];
+
+ u8 record_tracker_state[0x2];
+ u8 auth_state[0x2];
+ u8 reserved_at_64[0x4];
+ u8 hw_offset_record_number[0x18];
+};
+
#endif /* MLX5_IFC_H */
--
2.21.0
^ permalink raw reply related
* [PATCH mlx5-next 3/5] net/mlx5: Refactor mlx5_esw_query_functions for modularity
From: Saeed Mahameed @ 2019-07-03 7:39 UTC (permalink / raw)
To: Saeed Mahameed, Leon Romanovsky
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org, Parav Pandit
In-Reply-To: <20190703073909.14965-1-saeedm@mellanox.com>
From: Parav Pandit <parav@mellanox.com>
Functions change event output data size changes when functions other
than VFs will be enabled in HCA CAP.
With current API, multiple callers needs to align, calculate accurate
size of the output data depending on number on non VF functions enabled
in the device.
Instead of duplicating such math at multiple places, refactor
mlx5_esw_query_functions() to return raw output allocated by itself.
Caller must free the allocated memory using kvfree() as described in the
function comment section.
This hides calcuation within mlx5_esw_query_functions() and provides
simpler API.
Signed-off-by: Parav Pandit <parav@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
.../net/ethernet/mellanox/mlx5/core/eswitch.c | 38 +++++++++++++++----
.../net/ethernet/mellanox/mlx5/core/eswitch.h | 7 ++--
.../mellanox/mlx5/core/eswitch_offloads.c | 8 ++--
.../net/ethernet/mellanox/mlx5/core/sriov.c | 15 +++++---
4 files changed, 46 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
index 9137a8390216..62954265b57c 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
@@ -1715,14 +1715,34 @@ static int eswitch_vport_event(struct notifier_block *nb,
return NOTIFY_OK;
}
-int mlx5_esw_query_functions(struct mlx5_core_dev *dev, u32 *out, int outlen)
+/**
+ * mlx5_esw_query_functions - Returns raw output about functions state
+ * @dev: Pointer to device to query
+ *
+ * mlx5_esw_query_functions() allocates and returns functions changed
+ * raw output memory pointer from device on success. Otherwise returns ERR_PTR.
+ * Caller must free the memory using kvfree() when valid pointer is returned.
+ */
+const u32 *mlx5_esw_query_functions(struct mlx5_core_dev *dev)
{
+ int outlen = MLX5_ST_SZ_BYTES(query_esw_functions_out);
u32 in[MLX5_ST_SZ_DW(query_esw_functions_in)] = {};
+ u32 *out;
+ int err;
+
+ out = kvzalloc(outlen, GFP_KERNEL);
+ if (!out)
+ return ERR_PTR(-ENOMEM);
MLX5_SET(query_esw_functions_in, in, opcode,
MLX5_CMD_OP_QUERY_ESW_FUNCTIONS);
- return mlx5_cmd_exec(dev, in, sizeof(in), out, outlen);
+ err = mlx5_cmd_exec(dev, in, sizeof(in), out, outlen);
+ if (!err)
+ return out;
+
+ kvfree(out);
+ return ERR_PTR(err);
}
static void mlx5_eswitch_event_handlers_register(struct mlx5_eswitch *esw)
@@ -2527,8 +2547,7 @@ bool mlx5_esw_multipath_prereq(struct mlx5_core_dev *dev0,
void mlx5_eswitch_update_num_of_vfs(struct mlx5_eswitch *esw, const int num_vfs)
{
- u32 out[MLX5_ST_SZ_DW(query_esw_functions_out)] = {};
- int err;
+ const u32 *out;
WARN_ON_ONCE(esw->mode != MLX5_ESWITCH_NONE);
@@ -2537,8 +2556,11 @@ void mlx5_eswitch_update_num_of_vfs(struct mlx5_eswitch *esw, const int num_vfs)
return;
}
- err = mlx5_esw_query_functions(esw->dev, out, sizeof(out));
- if (!err)
- esw->esw_funcs.num_vfs = MLX5_GET(query_esw_functions_out, out,
- host_params_context.host_num_of_vfs);
+ out = mlx5_esw_query_functions(esw->dev);
+ if (IS_ERR(out))
+ return;
+
+ esw->esw_funcs.num_vfs = MLX5_GET(query_esw_functions_out, out,
+ host_params_context.host_num_of_vfs);
+ kvfree(out);
}
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
index f59183440d7f..d2d33a9893bb 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
@@ -403,7 +403,7 @@ bool mlx5_esw_lag_prereq(struct mlx5_core_dev *dev0,
bool mlx5_esw_multipath_prereq(struct mlx5_core_dev *dev0,
struct mlx5_core_dev *dev1);
-int mlx5_esw_query_functions(struct mlx5_core_dev *dev, u32 *out, int outlen);
+const u32 *mlx5_esw_query_functions(struct mlx5_core_dev *dev);
#define MLX5_DEBUG_ESWITCH_MASK BIT(3)
@@ -560,10 +560,9 @@ static inline int mlx5_eswitch_enable(struct mlx5_eswitch *esw, int mode) { ret
static inline void mlx5_eswitch_disable(struct mlx5_eswitch *esw) {}
static inline bool mlx5_esw_lag_prereq(struct mlx5_core_dev *dev0, struct mlx5_core_dev *dev1) { return true; }
static inline bool mlx5_eswitch_is_funcs_handler(struct mlx5_core_dev *dev) { return false; }
-static inline int
-mlx5_esw_query_functions(struct mlx5_core_dev *dev, u32 *out, int outlen)
+static inline const u32 *mlx5_esw_query_functions(struct mlx5_core_dev *dev)
{
- return -EOPNOTSUPP;
+ return ERR_PTR(-EOPNOTSUPP);
}
static inline void mlx5_eswitch_update_num_of_vfs(struct mlx5_eswitch *esw, const int num_vfs) {}
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
index 42c0db585561..74ab7bd264ed 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
@@ -2075,19 +2075,19 @@ esw_vfs_changed_event_handler(struct mlx5_eswitch *esw, const u32 *out)
static void esw_functions_changed_event_handler(struct work_struct *work)
{
- u32 out[MLX5_ST_SZ_DW(query_esw_functions_out)] = {};
struct mlx5_host_work *host_work;
struct mlx5_eswitch *esw;
- int err;
+ const u32 *out;
host_work = container_of(work, struct mlx5_host_work, work);
esw = host_work->esw;
- err = mlx5_esw_query_functions(esw->dev, out, sizeof(out));
- if (err)
+ out = mlx5_esw_query_functions(esw->dev);
+ if (IS_ERR(out))
goto out;
esw_vfs_changed_event_handler(esw, out);
+ kvfree(out);
out:
kfree(host_work);
}
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/sriov.c b/drivers/net/ethernet/mellanox/mlx5/core/sriov.c
index 547d0be9025e..61fcfd8b39b4 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/sriov.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/sriov.c
@@ -197,22 +197,25 @@ void mlx5_sriov_detach(struct mlx5_core_dev *dev)
static u16 mlx5_get_max_vfs(struct mlx5_core_dev *dev)
{
- u32 out[MLX5_ST_SZ_DW(query_esw_functions_out)] = {};
u16 host_total_vfs;
- int err;
+ const u32 *out;
if (mlx5_core_is_ecpf_esw_manager(dev)) {
- err = mlx5_esw_query_functions(dev, out, sizeof(out));
- host_total_vfs = MLX5_GET(query_esw_functions_out, out,
- host_params_context.host_total_vfs);
+ out = mlx5_esw_query_functions(dev);
/* Old FW doesn't support getting total_vfs from esw func
* but supports getting it from pci_sriov.
*/
- if (!err && host_total_vfs)
+ if (IS_ERR(out))
+ goto done;
+ host_total_vfs = MLX5_GET(query_esw_functions_out, out,
+ host_params_context.host_total_vfs);
+ kvfree(out);
+ if (host_total_vfs)
return host_total_vfs;
}
+done:
return pci_sriov_get_totalvfs(dev->pdev);
}
--
2.21.0
^ permalink raw reply related
* [PATCH mlx5-next 2/5] net/mlx5: E-Switch prepare functions change handler to be modular
From: Saeed Mahameed @ 2019-07-03 7:39 UTC (permalink / raw)
To: Saeed Mahameed, Leon Romanovsky
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org, Parav Pandit
In-Reply-To: <20190703073909.14965-1-saeedm@mellanox.com>
From: Parav Pandit <parav@mellanox.com>
Eswitch function change handler will service multiple type of events for
VFs and non VF functions update.
Hence, introduce and use the helper function
esw_vfs_changed_event_handler() for handling change in num VFs to improve
the code readability.
Signed-off-by: Parav Pandit <parav@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
.../mellanox/mlx5/core/eswitch_offloads.c | 44 ++++++++++++-------
1 file changed, 27 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
index 5c8fb2597bfa..42c0db585561 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
@@ -2046,38 +2046,48 @@ static void esw_offloads_steering_cleanup(struct mlx5_eswitch *esw)
esw_destroy_offloads_acl_tables(esw);
}
-static void esw_functions_changed_event_handler(struct work_struct *work)
+static void
+esw_vfs_changed_event_handler(struct mlx5_eswitch *esw, const u32 *out)
{
- u32 out[MLX5_ST_SZ_DW(query_esw_functions_out)] = {};
- struct mlx5_host_work *host_work;
- struct mlx5_eswitch *esw;
bool host_pf_disabled;
- u16 num_vfs = 0;
- int err;
-
- host_work = container_of(work, struct mlx5_host_work, work);
- esw = host_work->esw;
+ u16 new_num_vfs;
- err = mlx5_esw_query_functions(esw->dev, out, sizeof(out));
- num_vfs = MLX5_GET(query_esw_functions_out, out,
- host_params_context.host_num_of_vfs);
+ new_num_vfs = MLX5_GET(query_esw_functions_out, out,
+ host_params_context.host_num_of_vfs);
host_pf_disabled = MLX5_GET(query_esw_functions_out, out,
host_params_context.host_pf_disabled);
- if (err || host_pf_disabled || num_vfs == esw->esw_funcs.num_vfs)
- goto out;
+
+ if (new_num_vfs == esw->esw_funcs.num_vfs || host_pf_disabled)
+ return;
/* Number of VFs can only change from "0 to x" or "x to 0". */
if (esw->esw_funcs.num_vfs > 0) {
esw_offloads_unload_vf_reps(esw, esw->esw_funcs.num_vfs);
} else {
- err = esw_offloads_load_vf_reps(esw, num_vfs);
+ int err;
+ err = esw_offloads_load_vf_reps(esw, new_num_vfs);
if (err)
- goto out;
+ return;
}
+ esw->esw_funcs.num_vfs = new_num_vfs;
+}
+
+static void esw_functions_changed_event_handler(struct work_struct *work)
+{
+ u32 out[MLX5_ST_SZ_DW(query_esw_functions_out)] = {};
+ struct mlx5_host_work *host_work;
+ struct mlx5_eswitch *esw;
+ int err;
+
+ host_work = container_of(work, struct mlx5_host_work, work);
+ esw = host_work->esw;
- esw->esw_funcs.num_vfs = num_vfs;
+ err = mlx5_esw_query_functions(esw->dev, out, sizeof(out));
+ if (err)
+ goto out;
+ esw_vfs_changed_event_handler(esw, out);
out:
kfree(host_work);
}
--
2.21.0
^ permalink raw reply related
* [PATCH mlx5-next 1/5] net/mlx5: Introduce and use mlx5_eswitch_get_total_vports()
From: Saeed Mahameed @ 2019-07-03 7:39 UTC (permalink / raw)
To: Saeed Mahameed, Leon Romanovsky
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org, Parav Pandit
In-Reply-To: <20190703073909.14965-1-saeedm@mellanox.com>
From: Parav Pandit <parav@mellanox.com>
Instead MLX5_TOTAL_VPORTS, use mlx5_eswitch_get_total_vports().
mlx5_eswitch_get_total_vports() in subsequent patch accounts for SF
vports as well.
Expanding MLX5_TOTAL_VPORTS macro would require exposing SF internals to
more generic vport.h header file. Such exposure is not desired.
Hence a mlx5_eswitch_get_total_vports() is introduced.
Given that mlx5_eswitch_get_total_vports() API wants to work on const
mlx5_core_dev*, change its helper functions also to accept const *dev.
Signed-off-by: Parav Pandit <parav@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/infiniband/hw/mlx5/ib_rep.c | 2 +-
.../net/ethernet/mellanox/mlx5/core/eswitch.c | 4 ++-
.../mellanox/mlx5/core/eswitch_offloads.c | 2 +-
.../net/ethernet/mellanox/mlx5/core/fs_core.c | 26 +++++++++++--------
.../net/ethernet/mellanox/mlx5/core/vport.c | 15 +++++++++++
include/linux/mlx5/driver.h | 9 ++++---
include/linux/mlx5/eswitch.h | 3 +++
include/linux/mlx5/vport.h | 3 ---
8 files changed, 43 insertions(+), 21 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/ib_rep.c b/drivers/infiniband/hw/mlx5/ib_rep.c
index 3065c5d0ee96..f2cb789d2331 100644
--- a/drivers/infiniband/hw/mlx5/ib_rep.c
+++ b/drivers/infiniband/hw/mlx5/ib_rep.c
@@ -29,7 +29,7 @@ mlx5_ib_set_vport_rep(struct mlx5_core_dev *dev, struct mlx5_eswitch_rep *rep)
static int
mlx5_ib_vport_rep_load(struct mlx5_core_dev *dev, struct mlx5_eswitch_rep *rep)
{
- int num_ports = MLX5_TOTAL_VPORTS(dev);
+ int num_ports = mlx5_eswitch_get_total_vports(dev);
const struct mlx5_ib_profile *profile;
struct mlx5_ib_dev *ibdev;
int vport_index;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
index 89f52370e770..9137a8390216 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
@@ -1868,14 +1868,16 @@ void mlx5_eswitch_disable(struct mlx5_eswitch *esw)
int mlx5_eswitch_init(struct mlx5_core_dev *dev)
{
- int total_vports = MLX5_TOTAL_VPORTS(dev);
struct mlx5_eswitch *esw;
struct mlx5_vport *vport;
+ int total_vports;
int err, i;
if (!MLX5_VPORT_MANAGER(dev))
return 0;
+ total_vports = mlx5_eswitch_get_total_vports(dev);
+
esw_info(dev,
"Total vports %d, per vport: max uc(%d) max mc(%d)\n",
total_vports,
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
index 50e5841c1698..5c8fb2597bfa 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
@@ -1394,7 +1394,7 @@ void esw_offloads_cleanup_reps(struct mlx5_eswitch *esw)
int esw_offloads_init_reps(struct mlx5_eswitch *esw)
{
- int total_vports = MLX5_TOTAL_VPORTS(esw->dev);
+ int total_vports = esw->total_vports;
struct mlx5_core_dev *dev = esw->dev;
struct mlx5_eswitch_rep *rep;
u8 hw_id[ETH_ALEN], rep_type;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
index 9f5544ac6b8a..8162252585ad 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
@@ -2090,7 +2090,7 @@ struct mlx5_flow_namespace *mlx5_get_flow_vport_acl_namespace(struct mlx5_core_d
{
struct mlx5_flow_steering *steering = dev->priv.steering;
- if (!steering || vport >= MLX5_TOTAL_VPORTS(dev))
+ if (!steering || vport >= mlx5_eswitch_get_total_vports(dev))
return NULL;
switch (type) {
@@ -2421,7 +2421,7 @@ static void cleanup_egress_acls_root_ns(struct mlx5_core_dev *dev)
if (!steering->esw_egress_root_ns)
return;
- for (i = 0; i < MLX5_TOTAL_VPORTS(dev); i++)
+ for (i = 0; i < mlx5_eswitch_get_total_vports(dev); i++)
cleanup_root_ns(steering->esw_egress_root_ns[i]);
kfree(steering->esw_egress_root_ns);
@@ -2435,7 +2435,7 @@ static void cleanup_ingress_acls_root_ns(struct mlx5_core_dev *dev)
if (!steering->esw_ingress_root_ns)
return;
- for (i = 0; i < MLX5_TOTAL_VPORTS(dev); i++)
+ for (i = 0; i < mlx5_eswitch_get_total_vports(dev); i++)
cleanup_root_ns(steering->esw_ingress_root_ns[i]);
kfree(steering->esw_ingress_root_ns);
@@ -2614,16 +2614,18 @@ static int init_ingress_acl_root_ns(struct mlx5_flow_steering *steering, int vpo
static int init_egress_acls_root_ns(struct mlx5_core_dev *dev)
{
struct mlx5_flow_steering *steering = dev->priv.steering;
+ int total_vports = mlx5_eswitch_get_total_vports(dev);
int err;
int i;
- steering->esw_egress_root_ns = kcalloc(MLX5_TOTAL_VPORTS(dev),
- sizeof(*steering->esw_egress_root_ns),
- GFP_KERNEL);
+ steering->esw_egress_root_ns =
+ kcalloc(total_vports,
+ sizeof(*steering->esw_egress_root_ns),
+ GFP_KERNEL);
if (!steering->esw_egress_root_ns)
return -ENOMEM;
- for (i = 0; i < MLX5_TOTAL_VPORTS(dev); i++) {
+ for (i = 0; i < total_vports; i++) {
err = init_egress_acl_root_ns(steering, i);
if (err)
goto cleanup_root_ns;
@@ -2641,16 +2643,18 @@ static int init_egress_acls_root_ns(struct mlx5_core_dev *dev)
static int init_ingress_acls_root_ns(struct mlx5_core_dev *dev)
{
struct mlx5_flow_steering *steering = dev->priv.steering;
+ int total_vports = mlx5_eswitch_get_total_vports(dev);
int err;
int i;
- steering->esw_ingress_root_ns = kcalloc(MLX5_TOTAL_VPORTS(dev),
- sizeof(*steering->esw_ingress_root_ns),
- GFP_KERNEL);
+ steering->esw_ingress_root_ns =
+ kcalloc(total_vports,
+ sizeof(*steering->esw_ingress_root_ns),
+ GFP_KERNEL);
if (!steering->esw_ingress_root_ns)
return -ENOMEM;
- for (i = 0; i < MLX5_TOTAL_VPORTS(dev); i++) {
+ for (i = 0; i < total_vports; i++) {
err = init_ingress_acl_root_ns(steering, i);
if (err)
goto cleanup_root_ns;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/vport.c b/drivers/net/ethernet/mellanox/mlx5/core/vport.c
index 670fa493c5f5..c912d82ca64b 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/vport.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/vport.c
@@ -34,6 +34,7 @@
#include <linux/etherdevice.h>
#include <linux/mlx5/driver.h>
#include <linux/mlx5/vport.h>
+#include <linux/mlx5/eswitch.h>
#include "mlx5_core.h"
/* Mutex to hold while enabling or disabling RoCE */
@@ -1165,3 +1166,17 @@ u64 mlx5_query_nic_system_image_guid(struct mlx5_core_dev *mdev)
return tmp;
}
EXPORT_SYMBOL_GPL(mlx5_query_nic_system_image_guid);
+
+/**
+ * mlx5_eswitch_get_total_vports - Get total vports of the eswitch
+ *
+ * @dev: Pointer to core device
+ *
+ * mlx5_eswitch_get_total_vports returns total number of vports for
+ * the eswitch.
+ */
+u16 mlx5_eswitch_get_total_vports(const struct mlx5_core_dev *dev)
+{
+ return MLX5_SPECIAL_VPORTS(dev) + mlx5_core_max_vfs(dev);
+}
+EXPORT_SYMBOL(mlx5_eswitch_get_total_vports);
diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h
index 7658a4908431..2c3e8d86e12d 100644
--- a/include/linux/mlx5/driver.h
+++ b/include/linux/mlx5/driver.h
@@ -1083,7 +1083,7 @@ enum {
MLX5_PCI_DEV_IS_VF = 1 << 0,
};
-static inline bool mlx5_core_is_pf(struct mlx5_core_dev *dev)
+static inline bool mlx5_core_is_pf(const struct mlx5_core_dev *dev)
{
return dev->coredev_type == MLX5_COREDEV_PF;
}
@@ -1093,17 +1093,18 @@ static inline bool mlx5_core_is_ecpf(struct mlx5_core_dev *dev)
return dev->caps.embedded_cpu;
}
-static inline bool mlx5_core_is_ecpf_esw_manager(struct mlx5_core_dev *dev)
+static inline bool
+mlx5_core_is_ecpf_esw_manager(const struct mlx5_core_dev *dev)
{
return dev->caps.embedded_cpu && MLX5_CAP_GEN(dev, eswitch_manager);
}
-static inline bool mlx5_ecpf_vport_exists(struct mlx5_core_dev *dev)
+static inline bool mlx5_ecpf_vport_exists(const struct mlx5_core_dev *dev)
{
return mlx5_core_is_pf(dev) && MLX5_CAP_ESW(dev, ecpf_vport_exists);
}
-static inline u16 mlx5_core_max_vfs(struct mlx5_core_dev *dev)
+static inline u16 mlx5_core_max_vfs(const struct mlx5_core_dev *dev)
{
return dev->priv.sriov.max_vfs;
}
diff --git a/include/linux/mlx5/eswitch.h b/include/linux/mlx5/eswitch.h
index d4731199edb4..61db37aa9642 100644
--- a/include/linux/mlx5/eswitch.h
+++ b/include/linux/mlx5/eswitch.h
@@ -66,6 +66,8 @@ struct mlx5_flow_handle *
mlx5_eswitch_add_send_to_vport_rule(struct mlx5_eswitch *esw,
int vport, u32 sqn);
+u16 mlx5_eswitch_get_total_vports(const struct mlx5_core_dev *dev);
+
#ifdef CONFIG_MLX5_ESWITCH
enum devlink_eswitch_encap_mode
mlx5_eswitch_get_encap_mode(const struct mlx5_core_dev *dev);
@@ -93,4 +95,5 @@ mlx5_eswitch_get_vport_metadata_for_match(const struct mlx5_eswitch *esw,
return 0;
};
#endif /* CONFIG_MLX5_ESWITCH */
+
#endif
diff --git a/include/linux/mlx5/vport.h b/include/linux/mlx5/vport.h
index 6cbf29229749..16060fb9b5e5 100644
--- a/include/linux/mlx5/vport.h
+++ b/include/linux/mlx5/vport.h
@@ -44,9 +44,6 @@
MLX5_VPORT_UPLINK_PLACEHOLDER + \
MLX5_VPORT_ECPF_PLACEHOLDER(mdev))
-#define MLX5_TOTAL_VPORTS(mdev) (MLX5_SPECIAL_VPORTS(mdev) + \
- mlx5_core_max_vfs(mdev))
-
#define MLX5_VPORT_MANAGER(mdev) \
(MLX5_CAP_GEN(mdev, vport_group_manager) && \
(MLX5_CAP_GEN(mdev, port_type) == MLX5_CAP_PORT_TYPE_ETH) && \
--
2.21.0
^ permalink raw reply related
* [PATCH mlx5-next 0/5] Mellanox, mlx5 low level updates 2019-07-02
From: Saeed Mahameed @ 2019-07-03 7:39 UTC (permalink / raw)
To: Saeed Mahameed, Leon Romanovsky
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org
Hi All,
This series includes some low level updates to mlx5 driver, required for
shared mlx5-next branch.
Tariq extends the WQE control fields names.
Eran adds the required HW definitions and structures for upcoming TLS
support.
Parav improves and refactors the E-Switch "function changed" handler.
In case of no objections these patches will be applied to mlx5-next and
will be sent later as pull request to both rdma-next and net-next trees.
Thanks,
Saeed.
---
Eran Ben Elisha (1):
net/mlx5: Introduce TLS TX offload hardware bits and structures
Parav Pandit (3):
net/mlx5: Introduce and use mlx5_eswitch_get_total_vports()
net/mlx5: E-Switch prepare functions change handler to be modular
net/mlx5: Refactor mlx5_esw_query_functions for modularity
Tariq Toukan (1):
net/mlx5: Properly name the generic WQE control field
drivers/infiniband/hw/mlx5/ib_rep.c | 2 +-
.../net/ethernet/mellanox/mlx5/core/eswitch.c | 42 +++++--
.../net/ethernet/mellanox/mlx5/core/eswitch.h | 7 +-
.../mellanox/mlx5/core/eswitch_offloads.c | 46 +++++---
.../net/ethernet/mellanox/mlx5/core/fs_core.c | 26 +++--
.../net/ethernet/mellanox/mlx5/core/sriov.c | 15 ++-
.../net/ethernet/mellanox/mlx5/core/vport.c | 15 +++
include/linux/mlx5/device.h | 14 +++
include/linux/mlx5/driver.h | 9 +-
include/linux/mlx5/eswitch.h | 3 +
include/linux/mlx5/mlx5_ifc.h | 104 +++++++++++++++++-
include/linux/mlx5/qp.h | 7 +-
include/linux/mlx5/vport.h | 3 -
13 files changed, 232 insertions(+), 61 deletions(-)
--
2.21.0
^ permalink raw reply
* Re: [PATCH v5 net-next 6/6] net: ethernet: ti: cpsw: add XDP support
From: Ivan Khoronzhuk @ 2019-07-03 7:38 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: grygorii.strashko, hawk, davem, ast, linux-kernel, linux-omap,
xdp-newbies, ilias.apalodimas, netdev, daniel, jakub.kicinski,
john.fastabend
In-Reply-To: <20190703092603.66f36914@carbon>
On Wed, Jul 03, 2019 at 09:26:03AM +0200, Jesper Dangaard Brouer wrote:
>
>On Sun, 30 Jun 2019 20:23:48 +0300 Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote:
>
>> Add XDP support based on rx page_pool allocator, one frame per page.
>> Page pool allocator is used with assumption that only one rx_handler
>> is running simultaneously. DMA map/unmap is reused from page pool
>> despite there is no need to map whole page.
>>
>> Due to specific of cpsw, the same TX/RX handler can be used by 2
>> network devices, so special fields in buffer are added to identify
>> an interface the frame is destined to. Thus XDP works for both
>> interfaces, that allows to test xdp redirect between two interfaces
>> easily. Aslo, each rx queue have own page pools, but common for both
>> netdevs.
>
>Looking at the details what happen when a single RX-queue can receive
>into multiple net_device'es. I realize that this driver will
>violate/kill some of the "hidden"/implicit RX-bulking that the
>XDP_REDIRECT code depend on for performance.
>
>Specifically, it violate this assumption:
> https://github.com/torvalds/linux/blob/v5.2-rc7/kernel/bpf/devmap.c#L324-L329
>
> /* Ingress dev_rx will be the same for all xdp_frame's in
> * bulk_queue, because bq stored per-CPU and must be flushed
> * from net_device drivers NAPI func end.
> */
> if (!bq->dev_rx)
> bq->dev_rx = dev_rx;
>
>This drivers "NAPI func end", can have received into multiple
>net_devices, before it's NAPI cycle ends. Thus, violating this code
>assumption.
). I said, I moved to be per device in rx_handler. It violates nothing.
>
>Knowing all xdp_frame's in the bulk queue is from the same net_device,
>can be used to further optimize XDP. E.g. the dev->netdev_ops->ndo_xdp_xmit()
>call don't take fully advantage of this, yet. If we merge this driver,
>it will block optimizations in this area.
>
>NACK
Jesper,
Seems I said that I moved it to flush, that does
dev->netdev_ops->ndo_xdp_xmit(), to rx_handler, so that it's done per device,
so device is knows per each flush.
In the code, I hope everyone can see ..., after each flush dev_rx is cleared
to 0. So no any impact on it.
As for me, it's very not clear and strange decision.
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* Re: [PATCH net-next v6 11/15] ethtool: provide link mode names as a string set
From: Michal Kubecek @ 2019-07-03 7:38 UTC (permalink / raw)
To: netdev
Cc: Jakub Kicinski, David Miller, Jiri Pirko, Andrew Lunn,
Florian Fainelli, John Linville, Stephen Hemminger, Johannes Berg,
linux-kernel
In-Reply-To: <20190702191124.259c6628@cakuba.netronome.com>
On Tue, Jul 02, 2019 at 07:11:24PM -0700, Jakub Kicinski wrote:
> On Tue, 2 Jul 2019 19:04:19 -0700, Jakub Kicinski wrote:
> > On Tue, 2 Jul 2019 13:50:34 +0200 (CEST), Michal Kubecek wrote:
> > > +const char *const link_mode_names[] = {
> > > + __DEFINE_LINK_MODE_NAME(10, T, Half),
> > > + __DEFINE_LINK_MODE_NAME(10, T, Full),
> > > + __DEFINE_LINK_MODE_NAME(100, T, Half),
> > > + __DEFINE_LINK_MODE_NAME(100, T, Full),
> > > + __DEFINE_LINK_MODE_NAME(1000, T, Half),
> > > + __DEFINE_LINK_MODE_NAME(1000, T, Full),
> > > + __DEFINE_SPECIAL_MODE_NAME(Autoneg, "Autoneg"),
> > > + __DEFINE_SPECIAL_MODE_NAME(TP, "TP"),
> > > + __DEFINE_SPECIAL_MODE_NAME(AUI, "AUI"),
> > > + __DEFINE_SPECIAL_MODE_NAME(MII, "MII"),
> > > + __DEFINE_SPECIAL_MODE_NAME(FIBRE, "FIBRE"),
> > > + __DEFINE_SPECIAL_MODE_NAME(BNC, "BNC"),
> >
> > > + __DEFINE_LINK_MODE_NAME(10000, T, Full),
> > > + __DEFINE_SPECIAL_MODE_NAME(Pause, "Pause"),
> > > + __DEFINE_SPECIAL_MODE_NAME(Asym_Pause, "Asym_Pause"),
> > > + __DEFINE_LINK_MODE_NAME(2500, X, Full),
> > > + __DEFINE_SPECIAL_MODE_NAME(Backplane, "Backplane"),
> > > + __DEFINE_LINK_MODE_NAME(1000, KX, Full),
> > ...
> > > + __DEFINE_LINK_MODE_NAME(5000, T, Full),
> > > + __DEFINE_SPECIAL_MODE_NAME(FEC_NONE, "None"),
> > > + __DEFINE_SPECIAL_MODE_NAME(FEC_RS, "RS"),
> > > + __DEFINE_SPECIAL_MODE_NAME(FEC_BASER, "BASER"),
> >
> > Why are port types and FEC params among link mode strings?
>
> Ah, FEC for autoneg, but port type?
The bits in supported bitmap are used to pass information which port
types the device supports (but the information which port is selected
is passed in a different way :-( ). It is used by ethtool to provide the
"Supported ports:" line in "ethtool <dev>" output.
I don't like this design where link modes are mixed with few different
and only loosely related bitmaps. Maybe it would be cleaner to split it
into multiple bitmaps and later change the backend (ethtool_ops) too and
only translate to/from this combined bitmap for legacy ioctl interface.
Michal
>
> > > + __DEFINE_LINK_MODE_NAME(50000, KR, Full),
> > ...
> > > + __DEFINE_LINK_MODE_NAME(1000, T1, Full),
> > > +};
>
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
From: Greg KH @ 2019-07-03 7:28 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Song Liu, Networking, bpf, Alexei Starovoitov, Daniel Borkmann,
Kernel Team, Lorenz Bauer, Jann Horn
In-Reply-To: <CAEf4Bzb4ASMSNR0h+xgQHKEPryCtQnqFxtLnPvKuT4ME0eoe1Q@mail.gmail.com>
On Tue, Jul 02, 2019 at 12:22:56PM -0700, Andrii Nakryiko wrote:
> On Thu, Jun 27, 2019 at 1:20 PM Song Liu <songliubraving@fb.com> wrote:
> >
> > This patch introduce unprivileged BPF access. The access control is
> > achieved via device /dev/bpf. Users with write access to /dev/bpf are able
> > to call sys_bpf().
> >
> > Two ioctl command are added to /dev/bpf:
> >
> > The two commands enable/disable permission to call sys_bpf() for current
> > task. This permission is noted by bpf_permitted in task_struct. This
> > permission is inherited during clone(CLONE_THREAD).
> >
> > Helper function bpf_capable() is added to check whether the task has got
> > permission via /dev/bpf.
> >
> > Signed-off-by: Song Liu <songliubraving@fb.com>
> > ---
> > Documentation/ioctl/ioctl-number.txt | 1 +
> > include/linux/bpf.h | 11 +++++
> > include/linux/sched.h | 3 ++
> > include/uapi/linux/bpf.h | 6 +++
> > kernel/bpf/arraymap.c | 2 +-
> > kernel/bpf/cgroup.c | 2 +-
> > kernel/bpf/core.c | 4 +-
> > kernel/bpf/cpumap.c | 2 +-
> > kernel/bpf/devmap.c | 2 +-
> > kernel/bpf/hashtab.c | 4 +-
> > kernel/bpf/lpm_trie.c | 2 +-
> > kernel/bpf/offload.c | 2 +-
> > kernel/bpf/queue_stack_maps.c | 2 +-
> > kernel/bpf/reuseport_array.c | 2 +-
> > kernel/bpf/stackmap.c | 2 +-
> > kernel/bpf/syscall.c | 71 +++++++++++++++++++++-------
> > kernel/bpf/verifier.c | 2 +-
> > kernel/bpf/xskmap.c | 2 +-
> > kernel/fork.c | 5 ++
> > net/core/filter.c | 6 +--
> > 20 files changed, 99 insertions(+), 34 deletions(-)
> >
> > diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
> > index c9558146ac58..19998b99d603 100644
> > --- a/Documentation/ioctl/ioctl-number.txt
> > +++ b/Documentation/ioctl/ioctl-number.txt
> > @@ -327,6 +327,7 @@ Code Seq#(hex) Include File Comments
> > 0xB4 00-0F linux/gpio.h <mailto:linux-gpio@vger.kernel.org>
> > 0xB5 00-0F uapi/linux/rpmsg.h <mailto:linux-remoteproc@vger.kernel.org>
> > 0xB6 all linux/fpga-dfl.h
> > +0xBP 01-02 uapi/linux/bpf.h <mailto:bpf@vger.kernel.org>
>
> should this be 0xBF?
Why? It can be whatever the developer wants :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v5 net-next 6/6] net: ethernet: ti: cpsw: add XDP support
From: Jesper Dangaard Brouer @ 2019-07-03 7:26 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: grygorii.strashko, hawk, davem, ast, linux-kernel, linux-omap,
xdp-newbies, ilias.apalodimas, netdev, daniel, jakub.kicinski,
john.fastabend, brouer
In-Reply-To: <20190630172348.5692-7-ivan.khoronzhuk@linaro.org>
On Sun, 30 Jun 2019 20:23:48 +0300 Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote:
> Add XDP support based on rx page_pool allocator, one frame per page.
> Page pool allocator is used with assumption that only one rx_handler
> is running simultaneously. DMA map/unmap is reused from page pool
> despite there is no need to map whole page.
>
> Due to specific of cpsw, the same TX/RX handler can be used by 2
> network devices, so special fields in buffer are added to identify
> an interface the frame is destined to. Thus XDP works for both
> interfaces, that allows to test xdp redirect between two interfaces
> easily. Aslo, each rx queue have own page pools, but common for both
> netdevs.
Looking at the details what happen when a single RX-queue can receive
into multiple net_device'es. I realize that this driver will
violate/kill some of the "hidden"/implicit RX-bulking that the
XDP_REDIRECT code depend on for performance.
Specifically, it violate this assumption:
https://github.com/torvalds/linux/blob/v5.2-rc7/kernel/bpf/devmap.c#L324-L329
/* Ingress dev_rx will be the same for all xdp_frame's in
* bulk_queue, because bq stored per-CPU and must be flushed
* from net_device drivers NAPI func end.
*/
if (!bq->dev_rx)
bq->dev_rx = dev_rx;
This drivers "NAPI func end", can have received into multiple
net_devices, before it's NAPI cycle ends. Thus, violating this code
assumption.
Knowing all xdp_frame's in the bulk queue is from the same net_device,
can be used to further optimize XDP. E.g. the dev->netdev_ops->ndo_xdp_xmit()
call don't take fully advantage of this, yet. If we merge this driver,
it will block optimizations in this area.
NACK
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net-next v6 05/15] ethtool: helper functions for netlink interface
From: Michal Kubecek @ 2019-07-03 7:23 UTC (permalink / raw)
To: netdev
Cc: Jakub Kicinski, David Miller, Jiri Pirko, Andrew Lunn,
Florian Fainelli, John Linville, Stephen Hemminger, Johannes Berg,
linux-kernel
In-Reply-To: <20190702183724.423e3b1e@cakuba.netronome.com>
On Tue, Jul 02, 2019 at 06:37:24PM -0700, Jakub Kicinski wrote:
> On Tue, 2 Jul 2019 13:50:04 +0200 (CEST), Michal Kubecek wrote:
> > Add common request/reply header definition and helpers to parse request
> > header and fill reply header. Provide ethnl_update_* helpers to update
> > structure members from request attributes (to be used for *_SET requests).
> >
> > Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
>
> > diff --git a/net/ethtool/netlink.c b/net/ethtool/netlink.c
> > index 3c98b41f04e5..e13f29bbd625 100644
> > --- a/net/ethtool/netlink.c
> > +++ b/net/ethtool/netlink.c
> > @@ -1,8 +1,181 @@
> > // SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
> >
> > +#include <net/sock.h>
> > #include <linux/ethtool_netlink.h>
> > #include "netlink.h"
> >
> > +static struct genl_family ethtool_genl_family;
> > +
> > +static const struct nla_policy dflt_header_policy[ETHTOOL_A_HEADER_MAX + 1] = {
> > + [ETHTOOL_A_HEADER_UNSPEC] = { .type = NLA_REJECT },
>
> I think we want strict checking on all new netlink interfaces, and
> unfortunately that feature is opt-in.. so you need to add:
>
> .strict_start_type = ETHTOOL_A_HEADER_UNSPEC + 1
>
> To the first attr.
Oops... I'll have to check again how this works. I thought using
nla_parse_nested() instead of nla_parse_nested_deprecated() is
sufficient to have everything strict checked.
Michal
^ permalink raw reply
* [PATCH net] r8152: move calling r8153b_rx_agg_chg_indicate()
From: Hayes Wang @ 2019-07-03 7:11 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
r8153b_rx_agg_chg_indicate() needs to be called after enabling TX/RX and
before calling rxdy_gated_en(tp, false). Otherwise, the change of the
settings of RX aggregation wouldn't work.
Besides, adjust rtl8152_set_coalesce() for the same reason. If
rx_coalesce_usecs is changed, restart TX/RX to let the setting work.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 36 ++++++++++++++++++++++++++----------
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 101d1325f3f1..e887ac86fbef 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2367,6 +2367,12 @@ static int rtl_stop_rx(struct r8152 *tp)
return 0;
}
+static inline void r8153b_rx_agg_chg_indicate(struct r8152 *tp)
+{
+ ocp_write_byte(tp, MCU_TYPE_USB, USB_UPT_RXDMA_OWN,
+ OWN_UPDATE | OWN_CLEAR);
+}
+
static int rtl_enable(struct r8152 *tp)
{
u32 ocp_data;
@@ -2377,6 +2383,15 @@ static int rtl_enable(struct r8152 *tp)
ocp_data |= CR_RE | CR_TE;
ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CR, ocp_data);
+ switch (tp->version) {
+ case RTL_VER_08:
+ case RTL_VER_09:
+ r8153b_rx_agg_chg_indicate(tp);
+ break;
+ default:
+ break;
+ }
+
rxdy_gated_en(tp, false);
return 0;
@@ -2393,12 +2408,6 @@ static int rtl8152_enable(struct r8152 *tp)
return rtl_enable(tp);
}
-static inline void r8153b_rx_agg_chg_indicate(struct r8152 *tp)
-{
- ocp_write_byte(tp, MCU_TYPE_USB, USB_UPT_RXDMA_OWN,
- OWN_UPDATE | OWN_CLEAR);
-}
-
static void r8153_set_rx_early_timeout(struct r8152 *tp)
{
u32 ocp_data = tp->coalesce / 8;
@@ -2421,7 +2430,6 @@ static void r8153_set_rx_early_timeout(struct r8152 *tp)
128 / 8);
ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EXTRA_AGGR_TMR,
ocp_data);
- r8153b_rx_agg_chg_indicate(tp);
break;
default:
@@ -2445,7 +2453,6 @@ static void r8153_set_rx_early_size(struct r8152 *tp)
case RTL_VER_09:
ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EARLY_SIZE,
ocp_data / 8);
- r8153b_rx_agg_chg_indicate(tp);
break;
default:
WARN_ON_ONCE(1);
@@ -4919,8 +4926,17 @@ static int rtl8152_set_coalesce(struct net_device *netdev,
if (tp->coalesce != coalesce->rx_coalesce_usecs) {
tp->coalesce = coalesce->rx_coalesce_usecs;
- if (netif_running(tp->netdev) && netif_carrier_ok(netdev))
- r8153_set_rx_early_timeout(tp);
+ if (netif_running(netdev) && netif_carrier_ok(netdev)) {
+ netif_stop_queue(netdev);
+ napi_disable(&tp->napi);
+ tp->rtl_ops.disable(tp);
+ tp->rtl_ops.enable(tp);
+ rtl_start_rx(tp);
+ clear_bit(RTL8152_SET_RX_MODE, &tp->flags);
+ _rtl8152_set_rx_mode(netdev);
+ napi_enable(&tp->napi);
+ netif_wake_queue(netdev);
+ }
}
mutex_unlock(&tp->control);
--
2.21.0
^ permalink raw reply related
* [PATCH] wireless: core: no need to check return value of debugfs_create functions
From: Greg Kroah-Hartman @ 2019-07-03 7:01 UTC (permalink / raw)
To: Johannes Berg, David S. Miller; +Cc: linux-wireless, netdev
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/wireless/core.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 037816163e70..339b0ccb3241 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -142,12 +142,10 @@ int cfg80211_dev_rename(struct cfg80211_registered_device *rdev,
if (result)
return result;
- if (rdev->wiphy.debugfsdir &&
- !debugfs_rename(rdev->wiphy.debugfsdir->d_parent,
- rdev->wiphy.debugfsdir,
- rdev->wiphy.debugfsdir->d_parent,
- newname))
- pr_err("failed to rename debugfs dir to %s!\n", newname);
+ if (rdev->wiphy.debugfsdir)
+ debugfs_rename(rdev->wiphy.debugfsdir->d_parent,
+ rdev->wiphy.debugfsdir,
+ rdev->wiphy.debugfsdir->d_parent, newname);
nl80211_notify_wiphy(rdev, NL80211_CMD_NEW_WIPHY);
@@ -886,11 +884,8 @@ int wiphy_register(struct wiphy *wiphy)
cfg80211_rdev_list_generation++;
/* add to debugfs */
- rdev->wiphy.debugfsdir =
- debugfs_create_dir(wiphy_name(&rdev->wiphy),
- ieee80211_debugfs_dir);
- if (IS_ERR(rdev->wiphy.debugfsdir))
- rdev->wiphy.debugfsdir = NULL;
+ rdev->wiphy.debugfsdir = debugfs_create_dir(wiphy_name(&rdev->wiphy),
+ ieee80211_debugfs_dir);
cfg80211_debugfs_rdev_add(rdev);
nl80211_notify_wiphy(rdev, NL80211_CMD_NEW_WIPHY);
--
2.22.0
^ permalink raw reply related
* [PATCH] rt2x00: no need to check return value of debugfs_create functions
From: Greg Kroah-Hartman @ 2019-07-03 6:56 UTC (permalink / raw)
To: Stanislaw Gruszka, Helmut Schaa, Kalle Valo
Cc: David S. Miller, linux-wireless, netdev
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Because we don't need to save the individual debugfs files and
directories, remove the local storage of them and just remove the entire
debugfs directory in a single call, making things a lot simpler.
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
.../net/wireless/ralink/rt2x00/rt2x00debug.c | 100 ++++--------------
1 file changed, 23 insertions(+), 77 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c b/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
index aac3aae7afaa..7103904de28a 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
@@ -64,25 +64,6 @@ struct rt2x00debug_intf {
* - crypto stats file
*/
struct dentry *driver_folder;
- struct dentry *driver_entry;
- struct dentry *chipset_entry;
- struct dentry *dev_flags;
- struct dentry *cap_flags;
- struct dentry *register_folder;
- struct dentry *csr_off_entry;
- struct dentry *csr_val_entry;
- struct dentry *eeprom_off_entry;
- struct dentry *eeprom_val_entry;
- struct dentry *bbp_off_entry;
- struct dentry *bbp_val_entry;
- struct dentry *rf_off_entry;
- struct dentry *rf_val_entry;
- struct dentry *rfcsr_off_entry;
- struct dentry *rfcsr_val_entry;
- struct dentry *queue_folder;
- struct dentry *queue_frame_dump_entry;
- struct dentry *queue_stats_entry;
- struct dentry *crypto_stats_entry;
/*
* The frame dump file only allows a single reader,
@@ -631,6 +612,8 @@ void rt2x00debug_register(struct rt2x00_dev *rt2x00dev)
{
const struct rt2x00debug *debug = rt2x00dev->ops->debugfs;
struct rt2x00debug_intf *intf;
+ struct dentry *queue_folder;
+ struct dentry *register_folder;
intf = kzalloc(sizeof(struct rt2x00debug_intf), GFP_KERNEL);
if (!intf) {
@@ -646,39 +629,28 @@ void rt2x00debug_register(struct rt2x00_dev *rt2x00dev)
debugfs_create_dir(intf->rt2x00dev->ops->name,
rt2x00dev->hw->wiphy->debugfsdir);
- intf->driver_entry =
- rt2x00debug_create_file_driver("driver", intf, &intf->driver_blob);
+ rt2x00debug_create_file_driver("driver", intf, &intf->driver_blob);
- intf->chipset_entry =
- rt2x00debug_create_file_chipset("chipset",
- intf, &intf->chipset_blob);
+ rt2x00debug_create_file_chipset("chipset", intf, &intf->chipset_blob);
- intf->dev_flags = debugfs_create_file("dev_flags", 0400,
- intf->driver_folder, intf,
- &rt2x00debug_fop_dev_flags);
+ debugfs_create_file("dev_flags", 0400, intf->driver_folder, intf,
+ &rt2x00debug_fop_dev_flags);
- intf->cap_flags = debugfs_create_file("cap_flags", 0400,
- intf->driver_folder, intf,
- &rt2x00debug_fop_cap_flags);
+ debugfs_create_file("cap_flags", 0400, intf->driver_folder, intf,
+ &rt2x00debug_fop_cap_flags);
- intf->register_folder =
- debugfs_create_dir("register", intf->driver_folder);
+ register_folder = debugfs_create_dir("register", intf->driver_folder);
#define RT2X00DEBUGFS_CREATE_REGISTER_ENTRY(__intf, __name) \
({ \
if (debug->__name.read) { \
- (__intf)->__name##_off_entry = \
- debugfs_create_u32(__stringify(__name) "_offset", \
- 0600, \
- (__intf)->register_folder, \
- &(__intf)->offset_##__name); \
+ debugfs_create_u32(__stringify(__name) "_offset", 0600, \
+ register_folder, \
+ &(__intf)->offset_##__name); \
\
- (__intf)->__name##_val_entry = \
- debugfs_create_file(__stringify(__name) "_value", \
- 0600, \
- (__intf)->register_folder, \
- (__intf), \
- &rt2x00debug_fop_##__name); \
+ debugfs_create_file(__stringify(__name) "_value", 0600, \
+ register_folder, (__intf), \
+ &rt2x00debug_fop_##__name); \
} \
})
@@ -690,26 +662,21 @@ void rt2x00debug_register(struct rt2x00_dev *rt2x00dev)
#undef RT2X00DEBUGFS_CREATE_REGISTER_ENTRY
- intf->queue_folder =
- debugfs_create_dir("queue", intf->driver_folder);
+ queue_folder = debugfs_create_dir("queue", intf->driver_folder);
- intf->queue_frame_dump_entry =
- debugfs_create_file("dump", 0400, intf->queue_folder,
- intf, &rt2x00debug_fop_queue_dump);
+ debugfs_create_file("dump", 0400, queue_folder, intf,
+ &rt2x00debug_fop_queue_dump);
skb_queue_head_init(&intf->frame_dump_skbqueue);
init_waitqueue_head(&intf->frame_dump_waitqueue);
- intf->queue_stats_entry =
- debugfs_create_file("queue", 0400, intf->queue_folder,
- intf, &rt2x00debug_fop_queue_stats);
+ debugfs_create_file("queue", 0400, queue_folder, intf,
+ &rt2x00debug_fop_queue_stats);
#ifdef CONFIG_RT2X00_LIB_CRYPTO
if (rt2x00_has_cap_hw_crypto(rt2x00dev))
- intf->crypto_stats_entry =
- debugfs_create_file("crypto", 0444, intf->queue_folder,
- intf,
- &rt2x00debug_fop_crypto_stats);
+ debugfs_create_file("crypto", 0444, queue_folder, intf,
+ &rt2x00debug_fop_crypto_stats);
#endif
return;
@@ -724,28 +691,7 @@ void rt2x00debug_deregister(struct rt2x00_dev *rt2x00dev)
skb_queue_purge(&intf->frame_dump_skbqueue);
-#ifdef CONFIG_RT2X00_LIB_CRYPTO
- debugfs_remove(intf->crypto_stats_entry);
-#endif
- debugfs_remove(intf->queue_stats_entry);
- debugfs_remove(intf->queue_frame_dump_entry);
- debugfs_remove(intf->queue_folder);
- debugfs_remove(intf->rfcsr_val_entry);
- debugfs_remove(intf->rfcsr_off_entry);
- debugfs_remove(intf->rf_val_entry);
- debugfs_remove(intf->rf_off_entry);
- debugfs_remove(intf->bbp_val_entry);
- debugfs_remove(intf->bbp_off_entry);
- debugfs_remove(intf->eeprom_val_entry);
- debugfs_remove(intf->eeprom_off_entry);
- debugfs_remove(intf->csr_val_entry);
- debugfs_remove(intf->csr_off_entry);
- debugfs_remove(intf->register_folder);
- debugfs_remove(intf->dev_flags);
- debugfs_remove(intf->cap_flags);
- debugfs_remove(intf->chipset_entry);
- debugfs_remove(intf->driver_entry);
- debugfs_remove(intf->driver_folder);
+ debugfs_remove_recursive(intf->driver_folder);
kfree(intf->chipset_blob.data);
kfree(intf->driver_blob.data);
kfree(intf);
--
2.22.0
^ permalink raw reply related
* Re: [PATCH net-next v6 04/15] ethtool: introduce ethtool netlink interface
From: Michal Kubecek @ 2019-07-03 6:35 UTC (permalink / raw)
To: netdev
Cc: Jakub Kicinski, David Miller, Jiri Pirko, Andrew Lunn,
Florian Fainelli, John Linville, Stephen Hemminger, Johannes Berg,
linux-kernel
In-Reply-To: <20190702182956.26435d63@cakuba.netronome.com>
On Tue, Jul 02, 2019 at 06:29:56PM -0700, Jakub Kicinski wrote:
> On Tue, 2 Jul 2019 13:49:59 +0200 (CEST), Michal Kubecek wrote:
> > diff --git a/Documentation/networking/ethtool-netlink.txt b/Documentation/networking/ethtool-netlink.txt
> > new file mode 100644
> > index 000000000000..97c369aa290b
> > --- /dev/null
> > +++ b/Documentation/networking/ethtool-netlink.txt
> > @@ -0,0 +1,208 @@
> > + Netlink interface for ethtool
> > + =============================
> > +
> > +
> > +Basic information
> > +-----------------
>
> Probably not a blocker for initial merging, but please note a TODO to
> convert the documentation to ReST.
Yes, I want to do that. What stopped me was that I wasn't sure what to
do with the message structure descriptions. I guess I'll leave them as
preformated text (literal paragraph) for now and leave finding something
more fancy for later.
Michal
^ permalink raw reply
* [PATCH next] loopback: fix lockdep splat
From: Mahesh Bandewar @ 2019-07-03 6:16 UTC (permalink / raw)
To: Netdev
Cc: Eric Dumazet, David Miller, Mahesh Bandewar, Mahesh Bandewar,
Geert Uytterhoeven
dev_init_scheduler() and dev_activate() expect the caller to
hold RTNL. Since we don't want blackhole device to be initialized
per ns, we are initializing at init.
[ 3.855027] Call Trace:
[ 3.855034] dump_stack+0x67/0x95
[ 3.855037] lockdep_rcu_suspicious+0xd5/0x110
[ 3.855044] dev_init_scheduler+0xe3/0x120
[ 3.855048] ? net_olddevs_init+0x60/0x60
[ 3.855050] blackhole_netdev_init+0x45/0x6e
[ 3.855052] do_one_initcall+0x6c/0x2fa
[ 3.855058] ? rcu_read_lock_sched_held+0x8c/0xa0
[ 3.855066] kernel_init_freeable+0x1e5/0x288
[ 3.855071] ? rest_init+0x260/0x260
[ 3.855074] kernel_init+0xf/0x180
[ 3.855076] ? rest_init+0x260/0x260
[ 3.855078] ret_from_fork+0x24/0x30
Fixes: 4de83b88c66 ("loopback: create blackhole net device similar to loopack.")
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
drivers/net/loopback.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
index 3b39def5471e..14545a8797a8 100644
--- a/drivers/net/loopback.c
+++ b/drivers/net/loopback.c
@@ -261,8 +261,10 @@ static int __init blackhole_netdev_init(void)
if (!blackhole_netdev)
return -ENOMEM;
+ rtnl_lock();
dev_init_scheduler(blackhole_netdev);
dev_activate(blackhole_netdev);
+ rtnl_unlock();
blackhole_netdev->flags |= IFF_UP | IFF_RUNNING;
dev_net_set(blackhole_netdev, &init_net);
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH net-next v2 1/1] qed: Add support for Timestamping the unicast PTP packets.
From: Sudarsana Reddy Kalluru @ 2019-07-03 6:01 UTC (permalink / raw)
To: davem; +Cc: netdev, mkalderon, aelior
This patch adds driver changes to detect/timestamp the unicast PTP packets.
Changes from previous version:
-------------------------------
v2: Defined a macro for unicast ptp param mask.
Please consider applying this to "net-next".
Signed-off-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: Ariel Elior <aelior@marvell.com>
---
drivers/net/ethernet/qlogic/qed/qed_ptp.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_ptp.c b/drivers/net/ethernet/qlogic/qed/qed_ptp.c
index f3ebdc5..0dacf2c 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_ptp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_ptp.c
@@ -44,6 +44,8 @@
/* Add/subtract the Adjustment_Value when making a Drift adjustment */
#define QED_DRIFT_CNTR_DIRECTION_SHIFT 31
#define QED_TIMESTAMP_MASK BIT(16)
+/* Param mask for Hardware to detect/timestamp the unicast PTP packets */
+#define QED_PTP_UCAST_PARAM_MASK 0xF
static enum qed_resc_lock qed_ptcdev_to_resc(struct qed_hwfn *p_hwfn)
{
@@ -243,7 +245,8 @@ static int qed_ptp_hw_cfg_filters(struct qed_dev *cdev,
return -EINVAL;
}
- qed_wr(p_hwfn, p_ptt, NIG_REG_LLH_PTP_PARAM_MASK, 0);
+ qed_wr(p_hwfn, p_ptt, NIG_REG_LLH_PTP_PARAM_MASK,
+ QED_PTP_UCAST_PARAM_MASK);
qed_wr(p_hwfn, p_ptt, NIG_REG_LLH_PTP_RULE_MASK, rule_mask);
qed_wr(p_hwfn, p_ptt, NIG_REG_RX_PTP_EN, enable_cfg);
@@ -253,7 +256,8 @@ static int qed_ptp_hw_cfg_filters(struct qed_dev *cdev,
qed_wr(p_hwfn, p_ptt, NIG_REG_TX_LLH_PTP_RULE_MASK, 0x3FFF);
} else {
qed_wr(p_hwfn, p_ptt, NIG_REG_TX_PTP_EN, enable_cfg);
- qed_wr(p_hwfn, p_ptt, NIG_REG_TX_LLH_PTP_PARAM_MASK, 0);
+ qed_wr(p_hwfn, p_ptt, NIG_REG_TX_LLH_PTP_PARAM_MASK,
+ QED_PTP_UCAST_PARAM_MASK);
qed_wr(p_hwfn, p_ptt, NIG_REG_TX_LLH_PTP_RULE_MASK, rule_mask);
}
--
1.8.3.1
^ permalink raw reply related
* Reminder: 36 open syzbot bugs in "net/bpf" subsystem
From: Eric Biggers @ 2019-07-03 6:01 UTC (permalink / raw)
To: netdev, bpf, David S. Miller, Alexei Starovoitov, Daniel Borkmann,
John Fastabend
Cc: Martin KaFai Lau, Song Liu, Yonghong Song, linux-kernel,
syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 36 of them as possibly being bugs in the "net/bpf" subsystem. I've
listed these reports below, sorted by an algorithm that tries to list first the
reports most likely to be still valid, important, and actionable.
Of these 36 bugs, 8 were seen in mainline in the last week.
Of these 36 bugs, 12 were bisected to commits from the following people:
John Fastabend <john.fastabend@gmail.com>
Daniel Borkmann <daniel@iogearbox.net>
Alexei Starovoitov <ast@fb.com>
If you believe a bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed a bug to the "net/bpf" subsystem, please let me
know, and if possible forward the report to the correct people or mailing list.
Here are the bugs:
--------------------------------------------------------------------------------
Title: WARNING in bpf_jit_free
Last occurred: 0 days ago
Reported: 351 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=d04f9c2ec11ab2678f7427795ff5170cb9eb2220
Original thread: https://lkml.kernel.org/lkml/000000000000e92d1805711f5552@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 5 replies; the last was 21 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+2ff1e7cb738fd3c41113@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000e92d1805711f5552@google.com
--------------------------------------------------------------------------------
Title: BUG: unable to handle kernel paging request in bpf_prog_kallsyms_add
Last occurred: 0 days ago
Reported: 295 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=97f89d84d528e4f5150dcfbdeb97347bc8471e96
Original thread: https://lkml.kernel.org/lkml/0000000000009417ef0575802d44@google.com/T/#u
This bug has a syzkaller reproducer only.
The original thread for this bug received 2 replies; the last was 120 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+c827a78260579449ad39@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000009417ef0575802d44@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in sk_psock_unlink
Last occurred: 1 day ago
Reported: 249 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=d691981726208716cc7aec231fb915e27763d662
Original thread: https://lkml.kernel.org/lkml/000000000000fd342e05791cc86f@google.com/T/#u
This bug has a syzkaller reproducer only.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 1 reply, 41 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+3acd9f67a6a15766686e@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000fd342e05791cc86f@google.com
--------------------------------------------------------------------------------
Title: kernel panic: corrupted stack end in corrupted
Last occurred: 1 day ago
Reported: 12 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=1ee6edc829856a31fccb0c66cab50d2de0863f96
Original thread: https://lkml.kernel.org/lkml/00000000000097ca41058bc129cc@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend <john.fastabend@gmail.com>
Date: Sat Jun 30 13:17:47 2018 +0000
bpf: sockhash fix omitted bucket lock in sock_close
The original thread for this bug has received 1 reply, 12 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+b764c7ca388222ddfb17@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread, which had activity only 12 days ago. For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at https://lkml.kernel.org/r/00000000000097ca41058bc129cc@google.com
--------------------------------------------------------------------------------
Title: WARNING in bpf_prog_kallsyms_find
Last occurred: 0 days ago
Reported: 56 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=40b0c218e639f1d882b86abff2549cfe11c5101e
Original thread: https://lkml.kernel.org/lkml/000000000000a8fa360588580820@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+89d1ce6e80218a6192d8@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000a8fa360588580820@google.com
--------------------------------------------------------------------------------
Title: kernel panic: corrupted stack end in dput
Last occurred: 2 days ago
Reported: 1 day ago
Branches: net
Dashboard link: https://syzkaller.appspot.com/bug?id=84982a1f2b31c5239596ed6f436db8696418e233
Original thread: https://lkml.kernel.org/lkml/000000000000a5d3cb058c9a64f0@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend <john.fastabend@gmail.com>
Date: Sat Jun 30 13:17:47 2018 +0000
bpf: sockhash fix omitted bucket lock in sock_close
The original thread for this bug has received 1 reply, 9 hours ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+d88a977731a9888db7ba@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread, which had activity only 9 hours ago. For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at https://lkml.kernel.org/r/000000000000a5d3cb058c9a64f0@google.com
--------------------------------------------------------------------------------
Title: kernel panic: stack is corrupted in validate_chain
Last occurred: 7 days ago
Reported: 7 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=947c912ab7a1a9e3500b2cc279ba12f9be813d25
Original thread: https://lkml.kernel.org/lkml/000000000000c7a272058c2cde21@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend <john.fastabend@gmail.com>
Date: Sat Jun 30 13:17:47 2018 +0000
bpf: sockhash fix omitted bucket lock in sock_close
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+6ba34346b252f2d497c7@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread. For the git send-email command to use, or tips on how to reply if the
thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000c7a272058c2cde21@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in corrupted (3)
Last occurred: 6 days ago
Reported: 6 days ago
Branches: net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=5a60c112b10202cbf01ef00c3e912c160ad17b87
Original thread: https://lkml.kernel.org/lkml/000000000000f4f847058c387616@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend <john.fastabend@gmail.com>
Date: Sat Jun 30 13:17:47 2018 +0000
bpf: sockhash fix omitted bucket lock in sock_close
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+8a821b383523654227bf@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread. For the git send-email command to use, or tips on how to reply if the
thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000f4f847058c387616@google.com
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Read in class_equal
Last occurred: 0 days ago
Reported: 38 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=d299ab18d8295ac16f481e28f727e3aa0e01a1cf
Original thread: https://lkml.kernel.org/lkml/00000000000016cb560589b9c7c4@google.com/T/#u
This bug has a syzkaller reproducer only.
The original thread for this bug has received 1 reply, 37 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+3d04999521633dceb439@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000016cb560589b9c7c4@google.com
--------------------------------------------------------------------------------
Title: memory leak in sock_hash_update_common
Last occurred: 1 day ago
Reported: 41 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=9992588b3bbe2617f62f41b1162af9fc8ea4829c
Original thread: https://lkml.kernel.org/lkml/000000000000fa662405897c0774@google.com/T/#u
This bug has a syzkaller reproducer only.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+30c7a1fc662026545124@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000fa662405897c0774@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Write in validate_chain
Last occurred: 1 day ago
Reported: 11 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=e73b1b9f0fb147bf4b79e9f6fe7a465abd9256c5
Original thread: https://lkml.kernel.org/lkml/0000000000000c4e3e058bd5008d@google.com/T/#u
This bug has a syzkaller reproducer only.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+55c548ad445cef6063ab@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread. For the git send-email command to use, or tips on how to reply if the
thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000000c4e3e058bd5008d@google.com
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Read in usage_accumulate
Last occurred: 7 days ago
Reported: 26 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=53d11b9bbe4e2149cb3cc4cbe56068aa8202f079
Original thread: https://lkml.kernel.org/lkml/000000000000454279058aa80535@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend <john.fastabend@gmail.com>
Date: Sat Jun 30 13:17:47 2018 +0000
bpf: sockhash fix omitted bucket lock in sock_close
The original thread for this bug has received 1 reply, 26 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+b0d730107e2ca6cb952f@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000454279058aa80535@google.com
--------------------------------------------------------------------------------
Title: BUG: unable to handle kernel NULL pointer dereference in corrupted (4)
Last occurred: 8 days ago
Reported: 7 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=6751daddb34d9d52970e2c252b87564bf6876fbd
Original thread: https://lkml.kernel.org/lkml/000000000000c3bb59058c2cdef2@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend <john.fastabend@gmail.com>
Date: Sat Jun 30 13:17:47 2018 +0000
bpf: sockhash fix omitted bucket lock in sock_close
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+4b5d77fdf765668f9eba@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread. For the git send-email command to use, or tips on how to reply if the
thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000c3bb59058c2cdef2@google.com
--------------------------------------------------------------------------------
Title: general protection fault in rb_next (3)
Last occurred: 17 days ago
Reported: 15 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=18230564bca6dbde79a399755fefaca3a974f0c0
Original thread: https://lkml.kernel.org/lkml/0000000000003f07fe058b803013@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend <john.fastabend@gmail.com>
Date: Sat Jun 30 13:17:47 2018 +0000
bpf: sockhash fix omitted bucket lock in sock_close
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+ab4c44191771d56c4eda@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000003f07fe058b803013@google.com
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Write in validate_chain
Last occurred: 1 day ago
Reported: 11 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=af95641bc8a50769fceae59ec58e8e35ea052914
Original thread: https://lkml.kernel.org/lkml/000000000000e672c6058bd7ee45@google.com/T/#u
This bug has a syzkaller reproducer only.
The original thread for this bug has received 2 replies; the last was 6 days
ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+8893700724999566d6a9@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread, which had activity only 6 days ago. For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at https://lkml.kernel.org/r/000000000000e672c6058bd7ee45@google.com
--------------------------------------------------------------------------------
Title: general protection fault in rb_erase (2)
Last occurred: 27 days ago
Reported: 180 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=562d6c89d913184d9ed9bef5eec82105d71d2dc5
Original thread: https://lkml.kernel.org/lkml/0000000000008ab3c0057e8b747f@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend <john.fastabend@gmail.com>
Date: Sat Jun 30 13:17:47 2018 +0000
bpf: sockhash fix omitted bucket lock in sock_close
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+e8c40862180d8949d624@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000008ab3c0057e8b747f@google.com
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Read in corrupted (2)
Last occurred: 26 days ago
Reported: 26 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=9360900ac995e4ff25dea7f3ac939652b1f716e1
Original thread: https://lkml.kernel.org/lkml/0000000000004945f1058aa80556@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit d40b0116c94bd8fc2b63aae35ce8e66bb53bba42
Author: Daniel Borkmann <daniel@iogearbox.net>
Date: Thu Aug 16 19:49:08 2018 +0000
bpf, sockmap: fix leakage of smap_psock_map_entry
The original thread for this bug has received 1 reply, 26 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+9a901acbc447313bfe3e@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000004945f1058aa80556@google.com
--------------------------------------------------------------------------------
Title: WARNING in is_bpf_text_address
Last occurred: 0 days ago
Reported: 11 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=2386340f7a641010bb1e17228d1e9319592c01ba
Original thread: https://lkml.kernel.org/lkml/00000000000000ac4f058bd50039@google.com/T/#u
This bug has a syzkaller reproducer only.
The original thread for this bug has received 2 replies; the last was 1 day ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+bd3bba6ff3fcea7a6ec6@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread, which had activity only 1 day ago. For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at https://lkml.kernel.org/r/00000000000000ac4f058bd50039@google.com
--------------------------------------------------------------------------------
Title: BUG: unable to handle kernel paging request in tls_prots
Last occurred: 6 days ago
Reported: 6 days ago
Branches: net
Dashboard link: https://syzkaller.appspot.com/bug?id=8de86ced049e882cd68c3ef51cc69c634d8aeb7c
Original thread: https://lkml.kernel.org/lkml/000000000000d7bcbb058c3758a1@google.com/T/#u
This bug has a syzkaller reproducer only.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+4207c7f3a443366d8aa2@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread. For the git send-email command to use, or tips on how to reply if the
thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000d7bcbb058c3758a1@google.com
--------------------------------------------------------------------------------
Title: BUG: unable to handle kernel paging request in cpuacct_account_field
Last occurred: 12 days ago
Reported: 11 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=8155f45b63050b3a24f5e9091005488492d48461
Original thread: https://lkml.kernel.org/lkml/00000000000008f38a058bd500b9@google.com/T/#u
This bug has a syzkaller reproducer only.
The original thread for this bug has received 1 reply, 10 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+a952f743523593b39174@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread, which had activity only 10 days ago. For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at https://lkml.kernel.org/r/00000000000008f38a058bd500b9@google.com
--------------------------------------------------------------------------------
Title: BUG: unable to handle kernel paging request in __do_softirq
Last occurred: 14 days ago
Reported: 13 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=a0772f3c173c018b078174c3108eb00078c5818b
Original thread: https://lkml.kernel.org/lkml/00000000000017c9e2058baf4825@google.com/T/#u
This bug has a syzkaller reproducer only.
The original thread for this bug has received 1 reply, 13 days ago.
I believe that syzbot originally sent this report to the wrong people.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+0b224895cb9454584de1@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread, which had activity only 13 days ago. For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at https://lkml.kernel.org/r/00000000000017c9e2058baf4825@google.com
--------------------------------------------------------------------------------
Title: BUG: unable to handle kernel paging request in hrtimer_interrupt
Last occurred: 14 days ago
Reported: 13 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=fe68b600c03d48b14a769e379d1cda8704ffe9cb
Original thread: https://lkml.kernel.org/lkml/0000000000001c03bf058baf488a@google.com/T/#u
This bug has a syzkaller reproducer only.
The original thread for this bug has received 1 reply, 13 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+037e18398ba8c655a652@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread, which had activity only 13 days ago. For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at https://lkml.kernel.org/r/0000000000001c03bf058baf488a@google.com
--------------------------------------------------------------------------------
Title: general protection fault in mm_update_next_owner
Last occurred: 24 days ago
Reported: 24 days ago
Branches: net
Dashboard link: https://syzkaller.appspot.com/bug?id=eaeca1c76639c47820399a4478080ebcf931c489
Original thread: https://lkml.kernel.org/lkml/000000000000a802e6058ad4bc53@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend <john.fastabend@gmail.com>
Date: Sat Jun 30 13:17:47 2018 +0000
bpf: sockhash fix omitted bucket lock in sock_close
The original thread for this bug has received 2 replies; the last was 21 days
ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+f625baafb9a1c4bfc3f6@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000a802e6058ad4bc53@google.com
--------------------------------------------------------------------------------
Title: WARNING: kernel stack frame pointer has bad value (2)
Last occurred: 14 days ago
Reported: 351 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=02a32f98a4e3b5a2ed6929aabdd28dd1618b9c03
Original thread: https://lkml.kernel.org/lkml/0000000000000956640571197f98@google.com/T/#u
This bug has a C reproducer.
The original thread for this bug received 1 reply, 351 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+903cdd6bce9a6eb832a4@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000000956640571197f98@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in bpf_prog_kallsyms_del
Last occurred: 182 days ago
Reported: 260 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=55d929463ecf8859c0c4836a4f8f004cfec28cf7
Original thread: https://lkml.kernel.org/lkml/0000000000001d985405783e8aee@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit f4d7e40a5b7157e1329c3c5b10f60d8289fc2941
Author: Alexei Starovoitov <ast@fb.com>
Date: Fri Dec 15 01:55:06 2017 +0000
bpf: introduce function calls (verification)
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+10cffda23c81a3ff1088@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000001d985405783e8aee@google.com
--------------------------------------------------------------------------------
Title: WARNING in mark_lock
Last occurred: 12 days ago
Reported: 8 days ago
Branches: linux-next
Dashboard link: https://syzkaller.appspot.com/bug?id=cff2f292a776c2e85f65789d6a62a8c3b640aa98
Original thread: https://lkml.kernel.org/lkml/0000000000005aedf1058c1bf7e8@google.com/T/#u
This bug has a syzkaller reproducer only.
The original thread for this bug has received 8 replies; the last was 1 day ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+a861f52659ae2596492b@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread, which had activity only 1 day ago. For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at https://lkml.kernel.org/r/0000000000005aedf1058c1bf7e8@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in bpf_prog_kallsyms_add
Last occurred: 61 days ago
Reported: 295 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=0d9e7892096514a76e429ff8353aca183dac6e73
Original thread: https://lkml.kernel.org/lkml/000000000000ebd44005758029c2@google.com/T/#u
This bug has a syzkaller reproducer only.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+ac0311cfc9e80cd2e0e8@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000ebd44005758029c2@google.com
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Read in sock_hash_ctx_update_elem
Last occurred: 337 days ago
Reported: 337 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=4387b587226bb5f873bcf7dc8febc50c2dd3c540
Original thread: https://lkml.kernel.org/lkml/000000000000cc883b05723824b2@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+4207b2e0c72d65cc775d@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000cc883b05723824b2@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in psock_map_pop
Last occurred: 252 days ago
Reported: 295 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=931ba7ed06ce22b5933fbc3992e6377a889d3ceb
Original thread: https://lkml.kernel.org/lkml/0000000000008cc5260575802d0d@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+5bbe234204453085d43e@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000008cc5260575802d0d@google.com
--------------------------------------------------------------------------------
Title: general protection fault in bpf_tcp_close (2)
Last occurred: 312 days ago
Reported: 356 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=50e6f582ccc13e995abdad2ecdefed35f91bebad
Original thread: https://lkml.kernel.org/lkml/00000000000054fd6b0570be9fa8@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+339037020e772651f1d8@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000054fd6b0570be9fa8@google.com
--------------------------------------------------------------------------------
Title: general protection fault in smap_list_hash_remove
Last occurred: 344 days ago
Reported: 363 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=293f48c6a63935b5872fac5eafff89a15518864e
Original thread: https://lkml.kernel.org/lkml/000000000000b0e80905702dcf6f@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+b912ba691bb508925d72@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000b0e80905702dcf6f@google.com
--------------------------------------------------------------------------------
Title: BUG: unable to handle kernel paging request in bpf_prog_kallsyms_find
Last occurred: 151 days ago
Reported: 226 days ago
Branches: bpf-next and linux-next
Dashboard link: https://syzkaller.appspot.com/bug?id=a1c27d97870876dcccbac41a965e46f672fc3855
Original thread: https://lkml.kernel.org/lkml/000000000000b99324057af4dabb@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit f4d7e40a5b7157e1329c3c5b10f60d8289fc2941
Author: Alexei Starovoitov <ast@fb.com>
Date: Fri Dec 15 01:55:06 2017 +0000
bpf: introduce function calls (verification)
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+66d6b1d3055f1d9ee4f3@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000b99324057af4dabb@google.com
--------------------------------------------------------------------------------
Title: WARNING in bpf_prog_kallsyms_add
Last occurred: 180 days ago
Reported: 179 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=b658eb696c8279d9951a4ceea79efba8a1d12467
Original thread: https://lkml.kernel.org/lkml/000000000000f302fc057ea3b499@google.com/T/#u
This bug has a syzkaller reproducer only.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 2 replies; the last was 98 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+987e48d84abddbe2506d@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000f302fc057ea3b499@google.com
--------------------------------------------------------------------------------
Title: WARNING: suspicious RCU usage in trace_call_bpf
Last occurred: 285 days ago
Reported: 302 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=b4ec822cd97ffa2800cd27429997e0c8ea82331d
Original thread: https://lkml.kernel.org/lkml/00000000000072d3ab0574f40f80@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+1c843dc17610ca4c764f@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000072d3ab0574f40f80@google.com
--------------------------------------------------------------------------------
Title: WARNING in bpf_base_func_proto
Last occurred: 34 days ago
Reported: 32 days ago
Branches: bpf
Dashboard link: https://syzkaller.appspot.com/bug?id=5157126acdd38b1aedd23aeea5a3cfc26e16ce79
Original thread: https://lkml.kernel.org/lkml/0000000000002ea227058a2b28a4@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+5b595d1c2cd4d7d0f521@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000002ea227058a2b28a4@google.com
--------------------------------------------------------------------------------
Title: INFO: rcu detected stall in sys_bpf
Last occurred: 65 days ago
Reported: 97 days ago
Branches: bpf and linux-next
Dashboard link: https://syzkaller.appspot.com/bug?id=8a99735caa3c5e2b342382d6731db9da1a18aefd
Original thread: https://lkml.kernel.org/lkml/00000000000012a28e058517a481@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+c70685d9eac9589eaffc@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000012a28e058517a481@google.com
^ permalink raw reply
* Re: [PATCH net-next] net: socionext: remove set but not used variable 'pkts'
From: Ilias Apalodimas @ 2019-07-03 5:12 UTC (permalink / raw)
To: YueHaibing
Cc: Jassi Brar, Alexei Starovoitov, David S . Miller, Daniel Borkmann,
Jakub Kicinski, Jesper Dangaard Brouer, netdev, xdp-newbies, bpf,
kernel-janitors
In-Reply-To: <20190703024213.191191-1-yuehaibing@huawei.com>
On Wed, Jul 03, 2019 at 02:42:13AM +0000, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/socionext/netsec.c: In function 'netsec_clean_tx_dring':
> drivers/net/ethernet/socionext/netsec.c:637:15: warning:
> variable 'pkts' set but not used [-Wunused-but-set-variable]
>
> It is not used since commit ba2b232108d3 ("net: netsec: add XDP support")
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/net/ethernet/socionext/netsec.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/socionext/netsec.c b/drivers/net/ethernet/socionext/netsec.c
> index 5544a722543f..015d1ec5436a 100644
> --- a/drivers/net/ethernet/socionext/netsec.c
> +++ b/drivers/net/ethernet/socionext/netsec.c
> @@ -634,7 +634,7 @@ static void netsec_set_rx_de(struct netsec_priv *priv,
> static bool netsec_clean_tx_dring(struct netsec_priv *priv)
> {
> struct netsec_desc_ring *dring = &priv->desc_ring[NETSEC_RING_TX];
> - unsigned int pkts, bytes;
> + unsigned int bytes;
> struct netsec_de *entry;
> int tail = dring->tail;
> int cnt = 0;
> @@ -642,7 +642,6 @@ static bool netsec_clean_tx_dring(struct netsec_priv *priv)
> if (dring->is_xdp)
> spin_lock(&dring->lock);
>
> - pkts = 0;
> bytes = 0;
> entry = dring->vaddr + DESC_SZ * tail;
>
>
>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
^ permalink raw reply
* RE: [PATCH net-next 1/3] devlink: Introduce PCI PF port flavour and port attribute
From: Parav Pandit @ 2019-07-03 4:46 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Jiri Pirko, netdev@vger.kernel.org, Saeed Mahameed
In-Reply-To: <20190702191536.4de1ac68@cakuba.netronome.com>
> -----Original Message-----
> From: Jakub Kicinski <jakub.kicinski@netronome.com>
> Sent: Wednesday, July 3, 2019 7:46 AM
> To: Parav Pandit <parav@mellanox.com>
> Cc: Jiri Pirko <jiri@mellanox.com>; netdev@vger.kernel.org; Saeed
> Mahameed <saeedm@mellanox.com>
> Subject: Re: [PATCH net-next 1/3] devlink: Introduce PCI PF port flavour and
> port attribute
>
> On Wed, 3 Jul 2019 02:08:39 +0000, Parav Pandit wrote:
> > > If you want to expose some device specific eswitch port ID please
> > > add a new attribute for that.
> > > The fact that that ID may match port_number for your device today is
> > > coincidental. port_number, and split attributes should not be
> > > exposed for PCI ports.
> >
> > So your concern is non mellanox hw has eswitch but there may not be a
> > unique handle to identify a eswitch port?
>
> That's not a concern, no. Like any debug attribute it should be optional.
>
> > Or that handle may be wider than 32-bit?
>
> 64 bit would probably be better, yes, although that wasn't my initial
> concern.
>
Why 32-bit is not enough?
> > And instead of treating port_number as handle, there should be
> > different attribute, is that the ask?
>
> Yes, the ask, as always, is to not abuse existing attributes to carry
> tangentially related information.
Why it is tangential?
Devlink_port has got a port_number. Depending on flavour this port_number represents a port.
If it is floavour=PHYSICAL, its physical port number.
If it is eswitch pf/vf ports, it represents eswitch port.
Why you see it only as physical_port_number?
Jiri,
Do you see it this way too?
^ permalink raw reply
* Re: suspicious RCU usage (was: Re: [PATCHv3 next 1/3] loopback: create blackhole net device similar to loopack.)
From: Mahesh Bandewar (महेश बंडेवार) @ 2019-07-03 4:45 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Netdev, Eric Dumazet, David Miller, Michael Chan, Daniel Axtens,
Mahesh Bandewar, Paul E. McKenney, linux-arm-kernel, linux-kernel
In-Reply-To: <alpine.DEB.2.21.1907021450320.5764@ramsan.of.borg>
On Tue, Jul 2, 2019 at 5:54 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Mahesh,
>
> On Mon, 1 Jul 2019, Mahesh Bandewar wrote:
> > Create a blackhole net device that can be used for "dead"
> > dst entries instead of loopback device. This blackhole device differs
> > from loopback in few aspects: (a) It's not per-ns. (b) MTU on this
> > device is ETH_MIN_MTU (c) The xmit function is essentially kfree_skb().
> > and (d) since it's not registered it won't have ifindex.
> >
> > Lower MTU effectively make the device not pass the MTU check during
> > the route check when a dst associated with the skb is dead.
> >
> > Signed-off-by: Mahesh Bandewar <maheshb@google.com>
>
> This is now commit 4de83b88c66a1e4d ("loopback: create blackhole net
> device similar to loopack.") in net-next, and causes the following
> warning on arm64:
>
> WARNING: suspicious RCU usage
> 5.2.0-rc6-arm64-renesas-01699-g4de83b88c66a1e4d #263 Not tainted
> -----------------------------
> include/linux/rtnetlink.h:85 suspicious rcu_dereference_protected() usage!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 2, debug_locks = 1
> no locks held by swapper/0/1.
>
thanks for the report. Let me take a look at this.
> stack backtrace:
> CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.2.0-rc6-arm64-renesas-01699-g4de83b88c66a1e4d #263
> Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ (DT)
> Call trace:
> dump_backtrace+0x0/0x148
> show_stack+0x14/0x20
> dump_stack+0xd4/0x11c
> lockdep_rcu_suspicious+0xcc/0x110
> dev_init_scheduler+0x114/0x150
> blackhole_netdev_init+0x40/0x80
> do_one_initcall+0x178/0x37c
> kernel_init_freeable+0x490/0x530
> kernel_init+0x10/0x100
> ret_from_fork+0x10/0x1c
>
>
> > ---
> > v1->v2->v3
> > no change
> >
> > drivers/net/loopback.c | 76 ++++++++++++++++++++++++++++++++++-----
> > include/linux/netdevice.h | 2 ++
> > 2 files changed, 69 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
> > index 87d361666cdd..3b39def5471e 100644
> > --- a/drivers/net/loopback.c
> > +++ b/drivers/net/loopback.c
> > @@ -55,6 +55,13 @@
> > #include <net/net_namespace.h>
> > #include <linux/u64_stats_sync.h>
> >
> > +/* blackhole_netdev - a device used for dsts that are marked expired!
> > + * This is global device (instead of per-net-ns) since it's not needed
> > + * to be per-ns and gets initialized at boot time.
> > + */
> > +struct net_device *blackhole_netdev;
> > +EXPORT_SYMBOL(blackhole_netdev);
> > +
> > /* The higher levels take care of making this non-reentrant (it's
> > * called with bh's disabled).
> > */
> > @@ -150,12 +157,14 @@ static const struct net_device_ops loopback_ops = {
> > .ndo_set_mac_address = eth_mac_addr,
> > };
> >
> > -/* The loopback device is special. There is only one instance
> > - * per network namespace.
> > - */
> > -static void loopback_setup(struct net_device *dev)
> > +static void gen_lo_setup(struct net_device *dev,
> > + unsigned int mtu,
> > + const struct ethtool_ops *eth_ops,
> > + const struct header_ops *hdr_ops,
> > + const struct net_device_ops *dev_ops,
> > + void (*dev_destructor)(struct net_device *dev))
> > {
> > - dev->mtu = 64 * 1024;
> > + dev->mtu = mtu;
> > dev->hard_header_len = ETH_HLEN; /* 14 */
> > dev->min_header_len = ETH_HLEN; /* 14 */
> > dev->addr_len = ETH_ALEN; /* 6 */
> > @@ -174,11 +183,20 @@ static void loopback_setup(struct net_device *dev)
> > | NETIF_F_NETNS_LOCAL
> > | NETIF_F_VLAN_CHALLENGED
> > | NETIF_F_LOOPBACK;
> > - dev->ethtool_ops = &loopback_ethtool_ops;
> > - dev->header_ops = ð_header_ops;
> > - dev->netdev_ops = &loopback_ops;
> > + dev->ethtool_ops = eth_ops;
> > + dev->header_ops = hdr_ops;
> > + dev->netdev_ops = dev_ops;
> > dev->needs_free_netdev = true;
> > - dev->priv_destructor = loopback_dev_free;
> > + dev->priv_destructor = dev_destructor;
> > +}
> > +
> > +/* The loopback device is special. There is only one instance
> > + * per network namespace.
> > + */
> > +static void loopback_setup(struct net_device *dev)
> > +{
> > + gen_lo_setup(dev, (64 * 1024), &loopback_ethtool_ops, ð_header_ops,
> > + &loopback_ops, loopback_dev_free);
> > }
> >
> > /* Setup and register the loopback device. */
> > @@ -213,3 +231,43 @@ static __net_init int loopback_net_init(struct net *net)
> > struct pernet_operations __net_initdata loopback_net_ops = {
> > .init = loopback_net_init,
> > };
> > +
> > +/* blackhole netdevice */
> > +static netdev_tx_t blackhole_netdev_xmit(struct sk_buff *skb,
> > + struct net_device *dev)
> > +{
> > + kfree_skb(skb);
> > + net_warn_ratelimited("%s(): Dropping skb.\n", __func__);
> > + return NETDEV_TX_OK;
> > +}
> > +
> > +static const struct net_device_ops blackhole_netdev_ops = {
> > + .ndo_start_xmit = blackhole_netdev_xmit,
> > +};
> > +
> > +/* This is a dst-dummy device used specifically for invalidated
> > + * DSTs and unlike loopback, this is not per-ns.
> > + */
> > +static void blackhole_netdev_setup(struct net_device *dev)
> > +{
> > + gen_lo_setup(dev, ETH_MIN_MTU, NULL, NULL, &blackhole_netdev_ops, NULL);
> > +}
> > +
> > +/* Setup and register the blackhole_netdev. */
> > +static int __init blackhole_netdev_init(void)
> > +{
> > + blackhole_netdev = alloc_netdev(0, "blackhole_dev", NET_NAME_UNKNOWN,
> > + blackhole_netdev_setup);
> > + if (!blackhole_netdev)
> > + return -ENOMEM;
> > +
> > + dev_init_scheduler(blackhole_netdev);
> > + dev_activate(blackhole_netdev);
> > +
> > + blackhole_netdev->flags |= IFF_UP | IFF_RUNNING;
> > + dev_net_set(blackhole_netdev, &init_net);
> > +
> > + return 0;
> > +}
> > +
> > +device_initcall(blackhole_netdev_init);
> > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > index eeacebd7debb..88292953aa6f 100644
> > --- a/include/linux/netdevice.h
> > +++ b/include/linux/netdevice.h
> > @@ -4870,4 +4870,6 @@ do { \
> > #define PTYPE_HASH_SIZE (16)
> > #define PTYPE_HASH_MASK (PTYPE_HASH_SIZE - 1)
> >
> > +extern struct net_device *blackhole_netdev;
> > +
> > #endif /* _LINUX_NETDEVICE_H */
> >
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
>
^ permalink raw reply
* Re: [PATCH net-next] skbuff: increase verbosity when dumping skb data
From: Yunsheng Lin @ 2019-07-03 3:28 UTC (permalink / raw)
To: Willem de Bruijn, netdev
Cc: davem, xiyou.wangcong, herbert, eric.dumazet, saeedm,
Willem de Bruijn
In-Reply-To: <20190702193927.116668-1-willemdebruijn.kernel@gmail.com>
On 2019/7/3 3:39, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> skb_warn_bad_offload and netdev_rx_csum_fault trigger on hard to debug
> issues. Dump more state and the header.
>
> Optionally dump the entire packet and linear segment. This is required
> to debug checksum bugs that may include bytes past skb_tail_pointer().
>
> Both call sites call this function inside a net_ratelimit() block.
> Limit full packet log further to a hard limit of can_dump_full (5).
>
> Based on an earlier patch by Cong Wang, see link below.
>
> Link: https://patchwork.ozlabs.org/patch/1000841/
> Signed-off-by: Willem de Bruijn <willemb@google.com>
> ---
> include/linux/skbuff.h | 1 +
> net/core/dev.c | 16 ++-----
> net/core/skbuff.c | 103 +++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 108 insertions(+), 12 deletions(-)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index b5d427b149c92..48b08549a8b78 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -1024,6 +1024,7 @@ static inline bool skb_unref(struct sk_buff *skb)
> void skb_release_head_state(struct sk_buff *skb);
> void kfree_skb(struct sk_buff *skb);
> void kfree_skb_list(struct sk_buff *segs);
> +void skb_dump(const char *level, const struct sk_buff *skb, bool full_pkt);
> void skb_tx_error(struct sk_buff *skb);
> void consume_skb(struct sk_buff *skb);
> void __consume_stateless_skb(struct sk_buff *skb);
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 58529318b3a94..fc676b2610e3c 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2900,12 +2900,10 @@ static void skb_warn_bad_offload(const struct sk_buff *skb)
> else
> name = netdev_name(dev);
> }
> - WARN(1, "%s: caps=(%pNF, %pNF) len=%d data_len=%d gso_size=%d "
> - "gso_type=%d ip_summed=%d\n",
> + skb_dump(KERN_WARNING, skb, false);
> + WARN(1, "%s: caps=(%pNF, %pNF)\n",
> name, dev ? &dev->features : &null_features,
> - skb->sk ? &skb->sk->sk_route_caps : &null_features,
> - skb->len, skb->data_len, skb_shinfo(skb)->gso_size,
> - skb_shinfo(skb)->gso_type, skb->ip_summed);
> + skb->sk ? &skb->sk->sk_route_caps : &null_features);
> }
>
> /*
> @@ -3124,13 +3122,7 @@ void netdev_rx_csum_fault(struct net_device *dev, struct sk_buff *skb)
> {
> if (net_ratelimit()) {
> pr_err("%s: hw csum failure\n", dev ? dev->name : "<unknown>");
> - if (dev)
> - pr_err("dev features: %pNF\n", &dev->features);
> - pr_err("skb len=%u data_len=%u pkt_type=%u gso_size=%u gso_type=%u nr_frags=%u ip_summed=%u csum=%x csum_complete_sw=%d csum_valid=%d csum_level=%u\n",
> - skb->len, skb->data_len, skb->pkt_type,
> - skb_shinfo(skb)->gso_size, skb_shinfo(skb)->gso_type,
> - skb_shinfo(skb)->nr_frags, skb->ip_summed, skb->csum,
> - skb->csum_complete_sw, skb->csum_valid, skb->csum_level);
> + skb_dump(KERN_ERR, skb, true);
> dump_stack();
> }
> }
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 5323441a12ccf..5d501066d00ca 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -707,6 +707,109 @@ void kfree_skb_list(struct sk_buff *segs)
> }
> EXPORT_SYMBOL(kfree_skb_list);
>
> +/* Dump skb information and contents.
> + *
> + * Must only be called from net_ratelimit()-ed paths.
> + *
> + * Dumps up to can_dump_full whole packets if full_pkt, headers otherwise.
> + */
> +void skb_dump(const char *level, const struct sk_buff *skb, bool full_pkt)
> +{
> + static atomic_t can_dump_full = ATOMIC_INIT(5);
> + struct skb_shared_info *sh = skb_shinfo(skb);
> + struct net_device *dev = skb->dev;
> + struct sock *sk = skb->sk;
> + struct sk_buff *list_skb;
> + bool has_mac, has_trans;
> + int headroom, tailroom;
> + int i, len, seg_len;
> +
> + if (full_pkt)
> + full_pkt = atomic_dec_if_positive(&can_dump_full) >= 0;
> +
> + if (full_pkt)
> + len = skb->len;
Minor question:
Here we set the len to skb->len if full_pkt is true when skb_dump is
called with frag_list skb and full_pkt being true below, which may
cause some problem?
Maybe change the definition to:
void skb_dump(const char *level, const struct sk_buff *skb, int len, bool full_pkt)
skb_dump(KERN_ERR, skb, skb->len, true);
> + else
> + len = min_t(int, skb->len, MAX_HEADER + 128);
> +
> + headroom = skb_headroom(skb);
> + tailroom = skb_tailroom(skb);
> +
> + has_mac = skb_mac_header_was_set(skb);
> + has_trans = skb_transport_header_was_set(skb);
> +
> + printk("%sskb len=%u headroom=%u headlen=%u tailroom=%u\n"
> + "mac=(%d,%d) net=(%d,%d) trans=%d\n"
> + "shinfo(txflags=%u nr_frags=%u gso(size=%hu type=%u segs=%hu))\n"
> + "csum(0x%x ip_summed=%u complete_sw=%u valid=%u level=%u)\n"
> + "hash(0x%x sw=%u l4=%u) proto=0x%04x pkttype=%u iif=%d\n",
> + level, skb->len, headroom, skb_headlen(skb), tailroom,
> + has_mac ? skb->mac_header : -1,
> + has_mac ? skb_mac_header_len(skb) : -1,
> + skb->network_header,
> + has_trans ? skb_network_header_len(skb) : -1,
> + has_trans ? skb->transport_header : -1,
> + sh->tx_flags, sh->nr_frags,
> + sh->gso_size, sh->gso_type, sh->gso_segs,
> + skb->csum, skb->ip_summed, skb->csum_complete_sw,
> + skb->csum_valid, skb->csum_level,
> + skb->hash, skb->sw_hash, skb->l4_hash,
> + ntohs(skb->protocol), skb->pkt_type, skb->skb_iif);
> +
> + if (dev)
> + printk("%sdev name=%s feat=0x%pNF\n",
> + level, dev->name, &dev->features);
> + if (sk)
> + printk("%ssk family=%hu type=%hu proto=%hu\n",
> + level, sk->sk_family, sk->sk_type, sk->sk_protocol);
> +
> + if (full_pkt && headroom)
> + print_hex_dump(level, "skb headroom: ", DUMP_PREFIX_OFFSET,
> + 16, 1, skb->head, headroom, false);
> +
> + seg_len = min_t(int, skb_headlen(skb), len);
> + if (seg_len)
> + print_hex_dump(level, "skb linear: ", DUMP_PREFIX_OFFSET,
> + 16, 1, skb->data, seg_len, false);
> + len -= seg_len;
> +
> + if (full_pkt && tailroom)
> + print_hex_dump(level, "skb tailroom: ", DUMP_PREFIX_OFFSET,
> + 16, 1, skb_tail_pointer(skb), tailroom, false);
> +
> + for (i = 0; len && i < skb_shinfo(skb)->nr_frags; i++) {
> + skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
> + u32 p_off, p_len, copied;
> + struct page *p;
> + u8 *vaddr;
> +
> + skb_frag_foreach_page(frag, frag->page_offset,
> + skb_frag_size(frag), p, p_off, p_len,
> + copied) {
> + seg_len = min_t(int, p_len, len);
> + vaddr = kmap_atomic(p);
> + print_hex_dump(level, "skb frag: ",
> + DUMP_PREFIX_OFFSET,
> + 16, 1, vaddr + p_off, seg_len, false);
> + kunmap_atomic(vaddr);
> + len -= seg_len;
> + if (!len)
> + break;
> + }
> + }
> +
> + if (len && skb_has_frag_list(skb)) {
> + printk("skb fraglist:\n");
> + skb_walk_frags(skb, list_skb) {
> + if (len <= 0)
> + break;
> + skb_dump(level, list_skb, len);
Here we call skb_dump passing len as full_pkt.
Maybe call it with skb_dump(level, list_skb, len, full_pkt);
> + len -= list_skb->len;
> + }
> + }
> +}
> +EXPORT_SYMBOL(skb_dump);
> +
> /**
> * skb_tx_error - report an sk_buff xmit error
> * @skb: buffer that triggered an error
>
^ 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