* [PATCH v3 net-next 0/9] bnxt_en: devlink param updates
From: Vasundhara Volam @ 2018-09-28 6:28 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev, jiri, jakub.kicinski
This patchset adds support for 3 generic and 1 driver-specific devlink
parameters. Add documentation for these configuration parameters.
Also, this patchset adds support to return proper error code if
HWRM_NVM_GET/SET_VARIABLE commands return error code
HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED.
v2->v3:
-Remove description of generic parameters from devlink-params-bnxt.txt.
v1->v2:
-Remove hw_tc_offload parameter.
-Update all patches with Cc of MAINTAINERS.
-Add more description in commit message for device specific parameter.
-Add a new Documentation/networking/devlink-params.txt with some
generic devlink parameters information.
-Add a new Documentation/networking/devlink-params-bnxt.txt with devlink
parameters information that are supported by bnxt_en driver.
Vasundhara Volam (9):
devlink: Add generic parameter ignore_ari
devlink: Add generic parameter msix_vec_per_pf_max
devlink: Add generic parameter msix_vec_per_pf_min
bnxt_en: Use ignore_ari devlink parameter
bnxt_en: return proper error when FW returns
HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED
bnxt_en: Use msix_vec_per_pf_max and msix_vec_per_pf_min devlink
params.
bnxt_en: Add a driver specific gre_ver_check devlink parameter.
devlink: Add Documentation/networking/devlink-params.txt
devlink: Add Documentation/networking/devlink-params-bnxt.txt
Documentation/networking/devlink-params-bnxt.txt | 22 ++++++
Documentation/networking/devlink-params.txt | 42 +++++++++++
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 86 +++++++++++++++++++++--
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h | 8 +++
include/net/devlink.h | 12 ++++
net/core/devlink.c | 15 ++++
6 files changed, 181 insertions(+), 4 deletions(-)
create mode 100644 Documentation/networking/devlink-params-bnxt.txt
create mode 100644 Documentation/networking/devlink-params.txt
--
1.8.3.1
^ permalink raw reply
* [PATCH v3 net-next 1/9] devlink: Add generic parameter ignore_ari
From: Vasundhara Volam @ 2018-09-28 6:28 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev, jiri, jakub.kicinski
In-Reply-To: <1538116103-12356-1-git-send-email-vasundhara-v.volam@broadcom.com>
ignore_ari - Device ignores ARI(Alternate Routing ID) capability,
even when platforms has the support and creates same number of
partitions when platform does not support ARI capability.
Cc: Jiri Pirko <jiri@mellanox.com>
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
include/net/devlink.h | 4 ++++
net/core/devlink.c | 5 +++++
2 files changed, 9 insertions(+)
diff --git a/include/net/devlink.h b/include/net/devlink.h
index b9b89d6..90d8343 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -362,6 +362,7 @@ enum devlink_param_generic_id {
DEVLINK_PARAM_GENERIC_ID_MAX_MACS,
DEVLINK_PARAM_GENERIC_ID_ENABLE_SRIOV,
DEVLINK_PARAM_GENERIC_ID_REGION_SNAPSHOT,
+ DEVLINK_PARAM_GENERIC_ID_IGNORE_ARI,
/* add new param generic ids above here*/
__DEVLINK_PARAM_GENERIC_ID_MAX,
@@ -380,6 +381,9 @@ enum devlink_param_generic_id {
#define DEVLINK_PARAM_GENERIC_REGION_SNAPSHOT_NAME "region_snapshot_enable"
#define DEVLINK_PARAM_GENERIC_REGION_SNAPSHOT_TYPE DEVLINK_PARAM_TYPE_BOOL
+#define DEVLINK_PARAM_GENERIC_IGNORE_ARI_NAME "ignore_ari"
+#define DEVLINK_PARAM_GENERIC_IGNORE_ARI_TYPE DEVLINK_PARAM_TYPE_BOOL
+
#define DEVLINK_PARAM_GENERIC(_id, _cmodes, _get, _set, _validate) \
{ \
.id = DEVLINK_PARAM_GENERIC_ID_##_id, \
diff --git a/net/core/devlink.c b/net/core/devlink.c
index 8c0ed22..3349a4d 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -2675,6 +2675,11 @@ static int devlink_nl_cmd_reload(struct sk_buff *skb, struct genl_info *info)
.name = DEVLINK_PARAM_GENERIC_REGION_SNAPSHOT_NAME,
.type = DEVLINK_PARAM_GENERIC_REGION_SNAPSHOT_TYPE,
},
+ {
+ .id = DEVLINK_PARAM_GENERIC_ID_IGNORE_ARI,
+ .name = DEVLINK_PARAM_GENERIC_IGNORE_ARI_NAME,
+ .type = DEVLINK_PARAM_GENERIC_IGNORE_ARI_TYPE,
+ },
};
static int devlink_param_generic_verify(const struct devlink_param *param)
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 net-next 3/9] devlink: Add generic parameter msix_vec_per_pf_min
From: Vasundhara Volam @ 2018-09-28 6:28 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev, jiri, jakub.kicinski
In-Reply-To: <1538116103-12356-1-git-send-email-vasundhara-v.volam@broadcom.com>
msix_vec_per_pf_min - This param sets the number of minimal MSIX
vectors required for the device initialization. This value is set
in the device which limits MSIX vectors per PF.
Cc: Jiri Pirko <jiri@mellanox.com>
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
include/net/devlink.h | 4 ++++
net/core/devlink.c | 5 +++++
2 files changed, 9 insertions(+)
diff --git a/include/net/devlink.h b/include/net/devlink.h
index 59be17b..361f525 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -364,6 +364,7 @@ enum devlink_param_generic_id {
DEVLINK_PARAM_GENERIC_ID_REGION_SNAPSHOT,
DEVLINK_PARAM_GENERIC_ID_IGNORE_ARI,
DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MAX,
+ DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MIN,
/* add new param generic ids above here*/
__DEVLINK_PARAM_GENERIC_ID_MAX,
@@ -388,6 +389,9 @@ enum devlink_param_generic_id {
#define DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_NAME "msix_vec_per_pf_max"
#define DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_TYPE DEVLINK_PARAM_TYPE_U32
+#define DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MIN_NAME "msix_vec_per_pf_min"
+#define DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MIN_TYPE DEVLINK_PARAM_TYPE_U32
+
#define DEVLINK_PARAM_GENERIC(_id, _cmodes, _get, _set, _validate) \
{ \
.id = DEVLINK_PARAM_GENERIC_ID_##_id, \
diff --git a/net/core/devlink.c b/net/core/devlink.c
index ce9fe63..25d3bfa 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -2685,6 +2685,11 @@ static int devlink_nl_cmd_reload(struct sk_buff *skb, struct genl_info *info)
.name = DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_NAME,
.type = DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_TYPE,
},
+ {
+ .id = DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MIN,
+ .name = DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MIN_NAME,
+ .type = DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MIN_TYPE,
+ },
};
static int devlink_param_generic_verify(const struct devlink_param *param)
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 net-next 4/9] bnxt_en: Use ignore_ari devlink parameter
From: Vasundhara Volam @ 2018-09-28 6:28 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev, jiri, jakub.kicinski
In-Reply-To: <1538116103-12356-1-git-send-email-vasundhara-v.volam@broadcom.com>
This patch adds support for ignore_ari generic permanent mode
devlink parameter. This parameter is disabled by default. It can be
enabled using devlink param commands.
ignore_ari - If enabled, device ignores ARI(Alternate Routing ID)
capability, even when platforms has the support and creates same number
of partitions when platform does not support ARI capability.
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 6 ++++++
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
index 790c684..5173881 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
@@ -24,6 +24,8 @@
static const struct bnxt_dl_nvm_param nvm_params[] = {
{DEVLINK_PARAM_GENERIC_ID_ENABLE_SRIOV, NVM_OFF_ENABLE_SRIOV,
BNXT_NVM_SHARED_CFG, 1},
+ {DEVLINK_PARAM_GENERIC_ID_IGNORE_ARI, NVM_OFF_IGNORE_ARI,
+ BNXT_NVM_SHARED_CFG, 1},
};
static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
@@ -108,6 +110,10 @@ static int bnxt_dl_nvm_param_set(struct devlink *dl, u32 id,
BIT(DEVLINK_PARAM_CMODE_PERMANENT),
bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
NULL),
+ DEVLINK_PARAM_GENERIC(IGNORE_ARI,
+ BIT(DEVLINK_PARAM_CMODE_PERMANENT),
+ bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
+ NULL),
};
int bnxt_dl_register(struct bnxt *bp)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
index 2f68dc0..da146492 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
@@ -33,6 +33,8 @@ static inline void bnxt_link_bp_to_dl(struct bnxt *bp, struct devlink *dl)
}
}
+#define NVM_OFF_IGNORE_ARI 164
+#define NVM_OFF_HW_TC_OFFLOAD 170
#define NVM_OFF_ENABLE_SRIOV 401
enum bnxt_nvm_dir_type {
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 net-next 2/9] devlink: Add generic parameter msix_vec_per_pf_max
From: Vasundhara Volam @ 2018-09-28 6:28 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev, jiri, jakub.kicinski
In-Reply-To: <1538116103-12356-1-git-send-email-vasundhara-v.volam@broadcom.com>
msix_vec_per_pf_max - This param sets the number of MSIX vectors
that the device requests from the host on driver initialization.
This value is set in the device which is applicable per PF.
Cc: Jiri Pirko <jiri@mellanox.com>
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
include/net/devlink.h | 4 ++++
net/core/devlink.c | 5 +++++
2 files changed, 9 insertions(+)
diff --git a/include/net/devlink.h b/include/net/devlink.h
index 90d8343..59be17b 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -363,6 +363,7 @@ enum devlink_param_generic_id {
DEVLINK_PARAM_GENERIC_ID_ENABLE_SRIOV,
DEVLINK_PARAM_GENERIC_ID_REGION_SNAPSHOT,
DEVLINK_PARAM_GENERIC_ID_IGNORE_ARI,
+ DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MAX,
/* add new param generic ids above here*/
__DEVLINK_PARAM_GENERIC_ID_MAX,
@@ -384,6 +385,9 @@ enum devlink_param_generic_id {
#define DEVLINK_PARAM_GENERIC_IGNORE_ARI_NAME "ignore_ari"
#define DEVLINK_PARAM_GENERIC_IGNORE_ARI_TYPE DEVLINK_PARAM_TYPE_BOOL
+#define DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_NAME "msix_vec_per_pf_max"
+#define DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_TYPE DEVLINK_PARAM_TYPE_U32
+
#define DEVLINK_PARAM_GENERIC(_id, _cmodes, _get, _set, _validate) \
{ \
.id = DEVLINK_PARAM_GENERIC_ID_##_id, \
diff --git a/net/core/devlink.c b/net/core/devlink.c
index 3349a4d..ce9fe63 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -2680,6 +2680,11 @@ static int devlink_nl_cmd_reload(struct sk_buff *skb, struct genl_info *info)
.name = DEVLINK_PARAM_GENERIC_IGNORE_ARI_NAME,
.type = DEVLINK_PARAM_GENERIC_IGNORE_ARI_TYPE,
},
+ {
+ .id = DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MAX,
+ .name = DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_NAME,
+ .type = DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_TYPE,
+ },
};
static int devlink_param_generic_verify(const struct devlink_param *param)
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 net-next 5/9] bnxt_en: return proper error when FW returns HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED
From: Vasundhara Volam @ 2018-09-28 6:28 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev, jiri, jakub.kicinski
In-Reply-To: <1538116103-12356-1-git-send-email-vasundhara-v.volam@broadcom.com>
Return proper error code when Firmware returns
HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED for HWRM_NVM_GET/SET_VARIABLE
commands.
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
index 5173881..dc566fd 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
@@ -80,8 +80,12 @@ static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
memcpy(buf, data_addr, bytesize);
dma_free_coherent(&bp->pdev->dev, bytesize, data_addr, data_dma_addr);
- if (rc)
+ if (rc == HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED) {
+ netdev_err(bp->dev, "PF does not have admin privileges to modify NVM config\n");
+ return -EACCES;
+ } else if (rc) {
return -EIO;
+ }
return 0;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 net-next 6/9] bnxt_en: Use msix_vec_per_pf_max and msix_vec_per_pf_min devlink params.
From: Vasundhara Volam @ 2018-09-28 6:28 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev, jiri, jakub.kicinski
In-Reply-To: <1538116103-12356-1-git-send-email-vasundhara-v.volam@broadcom.com>
This patch adds support for following generic permanent mode
devlink parameters. They can be modified using devlink param
commands.
msix_vec_per_pf_max - This param sets the number of MSIX vectors
that the device requests from the host on driver initialization.
This value is set in the device which limits MSIX vectors per PF.
msix_vec_per_pf_min - This param sets the number of minimal MSIX
vectors required for the device initialization. Value 0 indicates
a default value is selected. This value is set in the device which
limits MSIX vectors per PF.
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 50 ++++++++++++++++++++++-
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h | 5 +++
2 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
index dc566fd..de7e74a 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
@@ -26,6 +26,10 @@
BNXT_NVM_SHARED_CFG, 1},
{DEVLINK_PARAM_GENERIC_ID_IGNORE_ARI, NVM_OFF_IGNORE_ARI,
BNXT_NVM_SHARED_CFG, 1},
+ {DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MAX,
+ NVM_OFF_MSIX_VEC_PER_PF_MAX, BNXT_NVM_SHARED_CFG, 10},
+ {DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MIN,
+ NVM_OFF_MSIX_VEC_PER_PF_MIN, BNXT_NVM_SHARED_CFG, 7},
};
static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
@@ -57,8 +61,22 @@ static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
idx = bp->pf.fw_fid - BNXT_FIRST_PF_FID;
bytesize = roundup(nvm_param.num_bits, BITS_PER_BYTE) / BITS_PER_BYTE;
- if (nvm_param.num_bits == 1)
- buf = &val->vbool;
+ switch (bytesize) {
+ case 1:
+ if (nvm_param.num_bits == 1)
+ buf = &val->vbool;
+ else
+ buf = &val->vu8;
+ break;
+ case 2:
+ buf = &val->vu16;
+ break;
+ case 4:
+ buf = &val->vu32;
+ break;
+ default:
+ return -EFAULT;
+ }
data_addr = dma_zalloc_coherent(&bp->pdev->dev, bytesize,
&data_dma_addr, GFP_KERNEL);
@@ -109,6 +127,26 @@ static int bnxt_dl_nvm_param_set(struct devlink *dl, u32 id,
return bnxt_hwrm_nvm_req(bp, id, &req, sizeof(req), &ctx->val);
}
+static int bnxt_dl_msix_validate(struct devlink *dl, u32 id,
+ union devlink_param_value val,
+ struct netlink_ext_ack *extack)
+{
+ int max_val;
+
+ if (id == DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MAX)
+ max_val = BNXT_MSIX_VEC_MAX;
+
+ if (id == DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MIN)
+ max_val = BNXT_MSIX_VEC_MIN_MAX;
+
+ if (val.vu32 < 0 || val.vu32 > max_val) {
+ NL_SET_ERR_MSG_MOD(extack, "MSIX value is exceeding the range");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static const struct devlink_param bnxt_dl_params[] = {
DEVLINK_PARAM_GENERIC(ENABLE_SRIOV,
BIT(DEVLINK_PARAM_CMODE_PERMANENT),
@@ -118,6 +156,14 @@ static int bnxt_dl_nvm_param_set(struct devlink *dl, u32 id,
BIT(DEVLINK_PARAM_CMODE_PERMANENT),
bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
NULL),
+ DEVLINK_PARAM_GENERIC(MSIX_VEC_PER_PF_MAX,
+ BIT(DEVLINK_PARAM_CMODE_PERMANENT),
+ bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
+ bnxt_dl_msix_validate),
+ DEVLINK_PARAM_GENERIC(MSIX_VEC_PER_PF_MIN,
+ BIT(DEVLINK_PARAM_CMODE_PERMANENT),
+ bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
+ bnxt_dl_msix_validate),
};
int bnxt_dl_register(struct bnxt *bp)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
index da146492..0e67c05 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
@@ -33,10 +33,15 @@ static inline void bnxt_link_bp_to_dl(struct bnxt *bp, struct devlink *dl)
}
}
+#define NVM_OFF_MSIX_VEC_PER_PF_MAX 108
+#define NVM_OFF_MSIX_VEC_PER_PF_MIN 114
#define NVM_OFF_IGNORE_ARI 164
#define NVM_OFF_HW_TC_OFFLOAD 170
#define NVM_OFF_ENABLE_SRIOV 401
+#define BNXT_MSIX_VEC_MAX 1280
+#define BNXT_MSIX_VEC_MIN_MAX 128
+
enum bnxt_nvm_dir_type {
BNXT_NVM_SHARED_CFG = 40,
BNXT_NVM_PORT_CFG,
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 net-next 7/9] bnxt_en: Add a driver specific gre_ver_check devlink parameter.
From: Vasundhara Volam @ 2018-09-28 6:28 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev, jiri, jakub.kicinski
In-Reply-To: <1538116103-12356-1-git-send-email-vasundhara-v.volam@broadcom.com>
This patch adds following driver-specific permanent mode boolean
parameter.
gre_ver_check - Generic Routing Encapsulation(GRE) version check
will be enabled in the device. If disabled, device skips version
checking for GRE packets.
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 24 ++++++++++++++++++++++-
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h | 1 +
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
index de7e74a..8a10e01 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
@@ -21,6 +21,11 @@
#endif /* CONFIG_BNXT_SRIOV */
};
+enum bnxt_dl_param_id {
+ BNXT_DEVLINK_PARAM_ID_BASE = DEVLINK_PARAM_GENERIC_ID_MAX,
+ BNXT_DEVLINK_PARAM_ID_GRE_VER_CHECK,
+};
+
static const struct bnxt_dl_nvm_param nvm_params[] = {
{DEVLINK_PARAM_GENERIC_ID_ENABLE_SRIOV, NVM_OFF_ENABLE_SRIOV,
BNXT_NVM_SHARED_CFG, 1},
@@ -30,6 +35,8 @@
NVM_OFF_MSIX_VEC_PER_PF_MAX, BNXT_NVM_SHARED_CFG, 10},
{DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MIN,
NVM_OFF_MSIX_VEC_PER_PF_MIN, BNXT_NVM_SHARED_CFG, 7},
+ {BNXT_DEVLINK_PARAM_ID_GRE_VER_CHECK, NVM_OFF_DIS_GRE_VER_CHECK,
+ BNXT_NVM_SHARED_CFG, 1},
};
static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
@@ -112,9 +119,15 @@ static int bnxt_dl_nvm_param_get(struct devlink *dl, u32 id,
{
struct hwrm_nvm_get_variable_input req = {0};
struct bnxt *bp = bnxt_get_bp_from_dl(dl);
+ int rc;
bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_NVM_GET_VARIABLE, -1, -1);
- return bnxt_hwrm_nvm_req(bp, id, &req, sizeof(req), &ctx->val);
+ rc = bnxt_hwrm_nvm_req(bp, id, &req, sizeof(req), &ctx->val);
+ if (!rc)
+ if (id == BNXT_DEVLINK_PARAM_ID_GRE_VER_CHECK)
+ ctx->val.vbool = !ctx->val.vbool;
+
+ return rc;
}
static int bnxt_dl_nvm_param_set(struct devlink *dl, u32 id,
@@ -124,6 +137,10 @@ static int bnxt_dl_nvm_param_set(struct devlink *dl, u32 id,
struct bnxt *bp = bnxt_get_bp_from_dl(dl);
bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_NVM_SET_VARIABLE, -1, -1);
+
+ if (id == BNXT_DEVLINK_PARAM_ID_GRE_VER_CHECK)
+ ctx->val.vbool = !ctx->val.vbool;
+
return bnxt_hwrm_nvm_req(bp, id, &req, sizeof(req), &ctx->val);
}
@@ -164,6 +181,11 @@ static int bnxt_dl_msix_validate(struct devlink *dl, u32 id,
BIT(DEVLINK_PARAM_CMODE_PERMANENT),
bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
bnxt_dl_msix_validate),
+ DEVLINK_PARAM_DRIVER(BNXT_DEVLINK_PARAM_ID_GRE_VER_CHECK,
+ "gre_ver_check", DEVLINK_PARAM_TYPE_BOOL,
+ BIT(DEVLINK_PARAM_CMODE_PERMANENT),
+ bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
+ NULL),
};
int bnxt_dl_register(struct bnxt *bp)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
index 0e67c05..e36e41a 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
@@ -37,6 +37,7 @@ static inline void bnxt_link_bp_to_dl(struct bnxt *bp, struct devlink *dl)
#define NVM_OFF_MSIX_VEC_PER_PF_MIN 114
#define NVM_OFF_IGNORE_ARI 164
#define NVM_OFF_HW_TC_OFFLOAD 170
+#define NVM_OFF_DIS_GRE_VER_CHECK 171
#define NVM_OFF_ENABLE_SRIOV 401
#define BNXT_MSIX_VEC_MAX 1280
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 net-next 9/9] devlink: Add Documentation/networking/devlink-params-bnxt.txt
From: Vasundhara Volam @ 2018-09-28 6:28 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev, jiri, jakub.kicinski
In-Reply-To: <1538116103-12356-1-git-send-email-vasundhara-v.volam@broadcom.com>
This patch adds a new file to add information about configuration
parameters that are supported by bnxt_en driver via devlink.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
Cc: Jiri Pirko <jiri@mellanox.com>
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
Documentation/networking/devlink-params-bnxt.txt | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/networking/devlink-params-bnxt.txt
diff --git a/Documentation/networking/devlink-params-bnxt.txt b/Documentation/networking/devlink-params-bnxt.txt
new file mode 100644
index 0000000..c7bc9d8
--- /dev/null
+++ b/Documentation/networking/devlink-params-bnxt.txt
@@ -0,0 +1,22 @@
+enable_sriov [DEVICE, GENERIC]
+ Type: Boolean
+ Configuration mode: Permanent
+
+ignore_ari [DEVICE, GENERIC]
+ Type: Boolean
+ Configuration mode: Permanent
+
+msix_vec_per_pf_max [DEVICE, GENERIC]
+ Type: u32
+ Configuration mode: Permanent
+
+msix_vec_per_pf_min [DEVICE, GENERIC]
+ Type: u32
+ Configuration mode: Permanent
+
+gre_ver_check [DEVICE, DRIVER-SPECIFIC]
+ Generic Routing Encapsulation (GRE) version check will
+ be enabled in the device. If disabled, device skips
+ version checking for incoming packets.
+ Type: Boolean
+ Configuration mode: Permanent
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 net-next 8/9] devlink: Add Documentation/networking/devlink-params.txt
From: Vasundhara Volam @ 2018-09-28 6:28 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev, jiri, jakub.kicinski
In-Reply-To: <1538116103-12356-1-git-send-email-vasundhara-v.volam@broadcom.com>
This patch adds a new file to add information about some of the
generic configuration parameters set via devlink.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
Cc: Jiri Pirko <jiri@mellanox.com>
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
Documentation/networking/devlink-params.txt | 42 +++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
create mode 100644 Documentation/networking/devlink-params.txt
diff --git a/Documentation/networking/devlink-params.txt b/Documentation/networking/devlink-params.txt
new file mode 100644
index 0000000..ae444ff
--- /dev/null
+++ b/Documentation/networking/devlink-params.txt
@@ -0,0 +1,42 @@
+Devlink configuration parameters
+================================
+Following is the list of configuration parameters via devlink interface.
+Each parameter can be generic or driver specific and are device level
+parameters.
+
+Note that the driver-specific files should contain the generic params
+they support to, with supported config modes.
+
+Each parameter can be set in different configuration modes:
+ runtime - set while driver is running, no reset required.
+ driverinit - applied while driver initializes, requires restart
+ driver by devlink reload command.
+ permanent - written to device's non-volatile memory, hard reset
+ required.
+
+Following is the list of parameters:
+====================================
+enable_sriov [DEVICE, GENERIC]
+ Enable Single Root I/O Virtualisation (SRIOV) in
+ the device.
+ Type: Boolean
+
+ignore_ari [DEVICE, GENERIC]
+ Ignore Alternative Routing-ID Interpretation (ARI)
+ capability. If enabled, adapter will ignore ARI
+ capability even when platforms has the support
+ enabled and creates same number of partitions when
+ platform does not support ARI.
+ Type: Boolean
+
+msix_vec_per_pf_max [DEVICE, GENERIC]
+ Provides the maximum number of MSIX interrupts that
+ a device can create. Value is same across all
+ physical functions (PFs) in the device.
+ Type: u32
+
+msix_vec_per_pf_min [DEVICE, GENERIC]
+ Provides the minimum number of MSIX interrupts required
+ for the device initialization. Value is same across all
+ physical functions (PFs) in the device.
+ Type: u32
--
1.8.3.1
^ permalink raw reply related
* KASAN: use-after-free Read in tls_tx_records
From: syzbot @ 2018-09-28 13:09 UTC (permalink / raw)
To: aviadye, borisp, davejwatson, davem, linux-kernel, netdev,
syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 1042caa79e93 net-ipv4: remove 2 always zero parameters fro..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13fff711400000
kernel config: https://syzkaller.appspot.com/x/.config?x=6da69433212d7e87
dashboard link: https://syzkaller.appspot.com/bug?extid=c45f79b4e5e940da28a9
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+c45f79b4e5e940da28a9@syzkaller.appspotmail.com
EXT4-fs (sda1): resizing filesystem from 524032 to 6 blocks
EXT4-fs warning (device sda1): ext4_resize_fs:1930: can't shrink FS -
resize aborted
EXT4-fs (sda1): resizing filesystem from 524032 to 6 blocks
EXT4-fs warning (device sda1): ext4_resize_fs:1930: can't shrink FS -
resize aborted
==================================================================
BUG: KASAN: use-after-free in tls_tx_records+0x8b0/0x980
net/tls/tls_sw.c:365
Read of size 8 at addr ffff8801ce46e040 by task syz-executor3/28575
CPU: 0 PID: 28575 Comm: syz-executor3 Not tainted 4.19.0-rc5+ #235
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
tls_tx_records+0x8b0/0x980 net/tls/tls_sw.c:365
tls_sw_free_resources_tx+0x1ec/0xd20 net/tls/tls_sw.c:1552
tls_sk_proto_close+0x605/0x750 net/tls/tls_main.c:278
inet_release+0x104/0x1f0 net/ipv4/af_inet.c:428
inet6_release+0x50/0x70 net/ipv6/af_inet6.c:458
__sock_release+0xd7/0x250 net/socket.c:579
sock_close+0x19/0x20 net/socket.c:1141
__fput+0x385/0xa30 fs/file_table.c:278
____fput+0x15/0x20 fs/file_table.c:309
task_work_run+0x1e8/0x2a0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:193 [inline]
exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457579
Code: 1d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 eb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f2ccaa3bc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000457579
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 000000000072bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f2ccaa3c6d4
R13: 00000000004ef912 R14: 00000000004cc460 R15: 00000000ffffffff
Allocated by task 28575:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
__do_kmalloc mm/slab.c:3718 [inline]
__kmalloc+0x14e/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:518 [inline]
kzalloc include/linux/slab.h:707 [inline]
get_rec+0x147/0x630 net/tls/tls_sw.c:653
tls_sw_sendmsg+0x47e/0x17a0 net/tls/tls_sw.c:727
inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:631
__sys_sendto+0x3d7/0x670 net/socket.c:1788
__do_sys_sendto net/socket.c:1800 [inline]
__se_sys_sendto net/socket.c:1796 [inline]
__x64_sys_sendto+0xe1/0x1a0 net/socket.c:1796
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 23411:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xcf/0x230 mm/slab.c:3813
tls_encrypt_done+0x221/0x610 net/tls/tls_sw.c:417
aead_request_complete include/crypto/internal/aead.h:75 [inline]
pcrypt_aead_serial+0x7b/0xb0 crypto/pcrypt.c:123
padata_serial_worker+0x4c6/0x760 kernel/padata.c:349
process_one_work+0xc90/0x1b90 kernel/workqueue.c:2153
worker_thread+0x17f/0x1390 kernel/workqueue.c:2296
kthread+0x35a/0x420 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:413
The buggy address belongs to the object at ffff8801ce46e040
which belongs to the cache kmalloc-2048 of size 2048
The buggy address is located 0 bytes inside of
2048-byte region [ffff8801ce46e040, ffff8801ce46e840)
The buggy address belongs to the page:
page:ffffea0007391b80 count:1 mapcount:0 mapping:ffff8801da800c40 index:0x0
compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffffea00071b4f88 ffffea0007344f88 ffff8801da800c40
raw: 0000000000000000 ffff8801ce46e040 0000000100000003 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801ce46df00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8801ce46df80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801ce46e000: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
ffff8801ce46e080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801ce46e100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* [PATCH v2 net-next] net: phy: improve handling delayed work
From: Heiner Kallweit @ 2018-09-28 6:51 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn, David Miller; +Cc: netdev@vger.kernel.org
Using mod_delayed_work() allows to simplify handling delayed work and
removes the need for the sync parameter in phy_trigger_machine().
Also introduce a helper phy_queue_state_machine() to encapsulate the
low-level delayed work calls. No functional change intended.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
v2:
- removed inline annotation from phy_queue_state_machine()
---
drivers/net/phy/phy.c | 29 +++++++++++++++--------------
include/linux/phy.h | 2 +-
2 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index a1f8e4816..14509a890 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -537,7 +537,7 @@ static int phy_start_aneg_priv(struct phy_device *phydev, bool sync)
mutex_unlock(&phydev->lock);
if (trigger)
- phy_trigger_machine(phydev, sync);
+ phy_trigger_machine(phydev);
return err;
}
@@ -635,6 +635,13 @@ int phy_speed_up(struct phy_device *phydev)
}
EXPORT_SYMBOL_GPL(phy_speed_up);
+static void phy_queue_state_machine(struct phy_device *phydev,
+ unsigned int secs)
+{
+ mod_delayed_work(system_power_efficient_wq, &phydev->state_queue,
+ secs * HZ);
+}
+
/**
* phy_start_machine - start PHY state machine tracking
* @phydev: the phy_device struct
@@ -647,7 +654,7 @@ EXPORT_SYMBOL_GPL(phy_speed_up);
*/
void phy_start_machine(struct phy_device *phydev)
{
- queue_delayed_work(system_power_efficient_wq, &phydev->state_queue, HZ);
+ phy_queue_state_machine(phydev, 1);
}
EXPORT_SYMBOL_GPL(phy_start_machine);
@@ -655,19 +662,14 @@ EXPORT_SYMBOL_GPL(phy_start_machine);
* phy_trigger_machine - trigger the state machine to run
*
* @phydev: the phy_device struct
- * @sync: indicate whether we should wait for the workqueue cancelation
*
* Description: There has been a change in state which requires that the
* state machine runs.
*/
-void phy_trigger_machine(struct phy_device *phydev, bool sync)
+void phy_trigger_machine(struct phy_device *phydev)
{
- if (sync)
- cancel_delayed_work_sync(&phydev->state_queue);
- else
- cancel_delayed_work(&phydev->state_queue);
- queue_delayed_work(system_power_efficient_wq, &phydev->state_queue, 0);
+ phy_queue_state_machine(phydev, 0);
}
/**
@@ -703,7 +705,7 @@ static void phy_error(struct phy_device *phydev)
phydev->state = PHY_HALTED;
mutex_unlock(&phydev->lock);
- phy_trigger_machine(phydev, false);
+ phy_trigger_machine(phydev);
}
/**
@@ -745,7 +747,7 @@ static irqreturn_t phy_change(struct phy_device *phydev)
mutex_unlock(&phydev->lock);
/* reschedule state queue work to run as soon as possible */
- phy_trigger_machine(phydev, true);
+ phy_trigger_machine(phydev);
if (phy_interrupt_is_valid(phydev) && phy_clear_interrupt(phydev))
goto phy_err;
@@ -911,7 +913,7 @@ void phy_start(struct phy_device *phydev)
}
mutex_unlock(&phydev->lock);
- phy_trigger_machine(phydev, true);
+ phy_trigger_machine(phydev);
}
EXPORT_SYMBOL(phy_start);
@@ -1130,8 +1132,7 @@ void phy_state_machine(struct work_struct *work)
* called from phy_disconnect() synchronously.
*/
if (phy_polling_mode(phydev) && old_state != PHY_HALTED)
- queue_delayed_work(system_power_efficient_wq, &phydev->state_queue,
- PHY_STATE_TIME * HZ);
+ phy_queue_state_machine(phydev, PHY_STATE_TIME);
}
/**
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 192a1fa0c..15bd074ef 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1039,7 +1039,7 @@ void phy_change_work(struct work_struct *work);
void phy_mac_interrupt(struct phy_device *phydev);
void phy_start_machine(struct phy_device *phydev);
void phy_stop_machine(struct phy_device *phydev);
-void phy_trigger_machine(struct phy_device *phydev, bool sync);
+void phy_trigger_machine(struct phy_device *phydev);
int phy_ethtool_sset(struct phy_device *phydev, struct ethtool_cmd *cmd);
void phy_ethtool_ksettings_get(struct phy_device *phydev,
struct ethtool_link_ksettings *cmd);
--
2.19.0
^ permalink raw reply related
* Re: KASAN: global-out-of-bounds Read in __aa_lookupn_ns
From: John Johansen @ 2018-09-28 13:19 UTC (permalink / raw)
To: Dmitry Vyukov, syzbot, James Morris, Serge E. Hallyn,
linux-security-module
Cc: David Miller, LKML, netdev, syzkaller-bugs
In-Reply-To: <CACT4Y+ZP3bFBZ7Omjn7e78ibfCNAFriMpmPut5P38Ex_aGcJHQ@mail.gmail.com>
On 09/28/2018 01:39 AM, Dmitry Vyukov wrote:
> On Wed, Sep 26, 2018 at 12:06 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
>> On Wed, Sep 26, 2018 at 9:54 AM, syzbot
>> <syzbot+71b6643475f707f93fdc@syzkaller.appspotmail.com> wrote:
>>> Hello,
>>>
>>> syzbot found the following crash on:
>>>
>>> HEAD commit: 02214bfc89c7 Merge tag 'media/v4.19-2' of git://git.kernel..
>>> git tree: upstream
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=1456f8a1400000
>>> kernel config: https://syzkaller.appspot.com/x/.config?x=22a62640793a83c9
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=71b6643475f707f93fdc
>>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>>>
>>> Unfortunately, I don't have any reproducer for this crash yet.
>>
>> Again misattributed to net. This misattribution should now be fixed by:
>> https://github.com/google/syzkaller/commit/db716d6653d073b0abfb51186cd4ac2d5418c9c6
>> Adding security/apparmor/policy_ns.c maintainers explicitly.
>
> This is the same as "KASAN: stack-out-of-bounds Read in __aa_lookupn_ns":
> https://syzkaller.appspot.com/bug?id=f0d603856d8b3cc9b8e09228f2f548c18ef907ac
> right?
>
yes it looks like it is
>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>> Reported-by: syzbot+71b6643475f707f93fdc@syzkaller.appspotmail.com
>>>
>>> sock_common_setsockopt+0x9a/0xe0 net/core/sock.c:3038
>>> __sys_setsockopt+0x1ba/0x3c0 net/socket.c:1902
>>> __do_sys_setsockopt net/socket.c:1913 [inline]
>>> __se_sys_setsockopt net/socket.c:1910 [inline]
>>> __x64_sys_setsockopt+0xbe/0x150 net/socket.c:1910
>>> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>>> ==================================================================
>>> BUG: KASAN: global-out-of-bounds in memcmp+0xe3/0x160 lib/string.c:861
>>> Read of size 1 at addr ffffffff88000008 by task syz-executor0/10914
>>>
>>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>>> RIP: 0033:0x457579
>>> Code: 1d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
>>> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff
>>> 0f 83 eb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
>>> RSP: 002b:00007f4c14533c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
>>> RAX: ffffffffffffffda RBX: 00007f4c14533c90 RCX: 0000000000457579
>>> RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003
>>> RBP: 000000000072bf00 R08: 0000000000000004 R09: 0000000000000000
>>> R10: 0000000020000080 R11: 0000000000000246 R12: 00007f4c145346d4
>>> R13: 00000000004c3ed9 R14: 00000000004d6260 R15: 0000000000000004
>>> CPU: 0 PID: 10914 Comm: syz-executor0 Not tainted 4.19.0-rc5+ #252
>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>>> Google 01/01/2011
>>> Call Trace:
>>> __dump_stack lib/dump_stack.c:77 [inline]
>>> dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
>>> print_address_description.cold.8+0x58/0x1ff mm/kasan/report.c:256
>>> kasan_report_error mm/kasan/report.c:354 [inline]
>>> kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
>>> __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430
>>> memcmp+0xe3/0x160 lib/string.c:861
>>> strnstr+0x4b/0x70 lib/string.c:934
>>> __aa_lookupn_ns+0xc1/0x570 security/apparmor/policy_ns.c:209
>>> aa_lookupn_ns+0x88/0x1e0 security/apparmor/policy_ns.c:240
>>> aa_fqlookupn_profile+0x1b9/0x1010 security/apparmor/policy.c:468
>>> fqlookupn_profile+0x80/0xc0 security/apparmor/label.c:1844
>>> aa_label_strn_parse+0xa3a/0x1230 security/apparmor/label.c:1908
>>> aa_label_parse+0x42/0x50 security/apparmor/label.c:1943
>>> aa_change_profile+0x513/0x3510 security/apparmor/domain.c:1362
>>> apparmor_setprocattr+0xa8b/0x1150 security/apparmor/lsm.c:656
>>> security_setprocattr+0x66/0xc0 security/security.c:1298
>>> proc_pid_attr_write+0x301/0x540 fs/proc/base.c:2555
>>> __vfs_write+0x119/0x9f0 fs/read_write.c:485
>>> vfs_write+0x1fc/0x560 fs/read_write.c:549
>>> ksys_write+0x101/0x260 fs/read_write.c:598
>>> __do_sys_write fs/read_write.c:610 [inline]
>>> __se_sys_write fs/read_write.c:607 [inline]
>>> __x64_sys_write+0x73/0xb0 fs/read_write.c:607
>>> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>>> RIP: 0033:0x457579
>>> Code: 1d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
>>> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff
>>> 0f 83 eb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
>>> RSP: 002b:00007f5a92ec2c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
>>> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457579
>>> RDX: 000000000000002c RSI: 00000000200000c0 RDI: 0000000000000004
>>> RBP: 000000000072bf00 R08: 0000000000000000 R09: 0000000000000000
>>> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f5a92ec36d4
>>> R13: 00000000004c5454 R14: 00000000004d8c78 R15: 00000000ffffffff
>>>
>>> CPU: 1 PID: 10921 Comm: syz-executor3 Not tainted 4.19.0-rc5+ #252
>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>>> Google 01/01/2011
>>> The buggy address belongs to the variable:
>>> __start_rodata+0x8/0x1000
>>> Call Trace:
>>> __dump_stack lib/dump_stack.c:77 [inline]
>>> dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
>>>
>>> Memory state around the buggy address:
>>> ffffffff87ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> ffffffff87ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> fail_dump lib/fault-inject.c:51 [inline]
>>> should_fail.cold.4+0xa/0x17 lib/fault-inject.c:149
>>>>
>>>> ffffffff88000000: 00 fa fa fa fa fa fa fa 00 01 fa fa fa fa fa fa
>>>
>>> ^
>>> ffffffff88000080: 00 00 00 07 fa fa fa fa 00 04 fa fa fa fa fa fa
>>> ffffffff88000100: 05 fa fa fa fa fa fa fa 00 00 00 00 05 fa fa fa
>>> ==================================================================
>>>
>>>
>>> ---
>>> This bug is generated by a bot. It may contain errors.
>>> See https://goo.gl/tpsmEJ for more information about syzbot.
>>> syzbot engineers can be reached at syzkaller@googlegroups.com.
>>>
>>> syzbot will keep track of this bug report. See:
>>> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
>>> syzbot.
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: fix flags check in bpf_percpu_cgroup_storage_update()
From: Roman Gushchin @ 2018-09-28 13:29 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, linux-kernel, kernel-team, Alexei Starovoitov
In-Reply-To: <c093c1ec-2da4-59ef-4617-f494b48952f0@iogearbox.net>
On Fri, Sep 28, 2018 at 02:11:48PM +0200, Daniel Borkmann wrote:
> On 09/28/2018 01:06 PM, Roman Gushchin wrote:
> > Fix an issue in bpf_percpu_cgroup_storage_update(): it should return
> > -EINVAL on an attempt to pass BPF_NOEXIST rather than BPF_EXIST.
> >
> > Cgroup local storage is automatically created on attaching of a bpf
> > program to a cgroup, and it can't be done from the userspace.
> >
> > Fixes: 0daef9b42374 ("bpf: introduce per-cpu cgroup local storage")
> > Signed-off-by: Roman Gushchin <guro@fb.com>
> > Cc: Daniel Borkmann <daniel@iogearbox.net>
> > Cc: Alexei Starovoitov <ast@kernel.org>
> > ---
> > kernel/bpf/local_storage.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/bpf/local_storage.c b/kernel/bpf/local_storage.c
> > index c739f6dcc3c2..190535f6d5e2 100644
> > --- a/kernel/bpf/local_storage.c
> > +++ b/kernel/bpf/local_storage.c
> > @@ -191,7 +191,7 @@ int bpf_percpu_cgroup_storage_update(struct bpf_map *_map, void *_key,
> > int cpu, off = 0;
> > u32 size;
> >
> > - if (unlikely(map_flags & BPF_EXIST))
> > + if (map_flags & BPF_NOEXIST)
> > return -EINVAL;
>
> Hmm, this is also incorrect as any future reserved flag would be accepted here and
> couldn't be extended anymore. :/ And it looks like cgroup_storage_update_elem() is
> doing the same today, given the cgroups local storage is still early, we should route
> a patch to stable for fixing this.
Fair enough, will post soon.
>
> Wrt this series, given the series is top of tree right now, I would prefer a fresh
> respin so we have the fix integrated properly w/o follow-up. Perhaps this could also
> incorporate Alexei's previous cleanup suggestions as well from today if you have a
> chance.
I'm not sure about merging copy() and update() functions, as large #define
blocks are really bad. So I'd think a bit more here. Will do the rest.
Thanks!
^ permalink raw reply
* [PATCH bpf] bpf: harden flags check in cgroup_storage_update_elem()
From: Roman Gushchin @ 2018-09-28 13:33 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel-team, Roman Gushchin, Alexei Starovoitov,
Daniel Borkmann
cgroup_storage_update_elem() shouldn't accept any flags
argument values except BPF_ANY and BPF_EXIST to guarantee
the backward compatibility, had a new flag value been added.
Fixes: de9cbbaadba5 ("bpf: introduce cgroup storage maps")
Signed-off-by: Roman Gushchin <guro@fb.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
---
kernel/bpf/local_storage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/local_storage.c b/kernel/bpf/local_storage.c
index f8746e6a9a35..2a7680106320 100644
--- a/kernel/bpf/local_storage.c
+++ b/kernel/bpf/local_storage.c
@@ -130,7 +130,7 @@ static int cgroup_storage_update_elem(struct bpf_map *map, void *_key,
struct bpf_cgroup_storage *storage;
struct bpf_storage_buffer *new;
- if (flags & BPF_NOEXIST)
+ if (flags != BPF_ANY && flags != BPF_EXIST)
return -EINVAL;
storage = cgroup_storage_lookup((struct bpf_cgroup_storage_map *)map,
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel
From: Jason A. Donenfeld @ 2018-09-28 13:40 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Eric Biggers, LKML, Netdev, Linux Crypto Mailing List,
David Miller, Greg Kroah-Hartman
In-Reply-To: <CAKv+Gu-ZMR7zEAKv6_2tyD3OqnjVugOzKHzBEXW3pQs5W-SvLw@mail.gmail.com>
On Fri, Sep 28, 2018 at 9:52 AM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> As I understood from someone who was at your Kernel Recipes talk, you
> mentioned that it actually stands for 'zinc is not crypto/' (note the
> slash)
I mentioned this was in v1 but it wasn't taken as lightly as planned
and was removed, so if it needs a recursive acronym it can be "zinc is
nice crypto", "zinc is neat crypto", or as the commit message
mentions, "zinc as in crypto." Alternatively, it can just not stand
for anything at all. Zinc -> Zinc. That's what the thing is called.
^ permalink raw reply
* Re: [PATCH net-next v6 01/23] asm: simd context helper API
From: Jason A. Donenfeld @ 2018-09-28 13:45 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman, Samuel Neves, Andrew Lutomirski,
Thomas Gleixner, linux-arch
In-Reply-To: <CAKv+Gu9e35+AyktmSq9qeNE0LR83_yrEEB3DiQv0bmyArivqRQ@mail.gmail.com>
On Fri, Sep 28, 2018 at 10:28 AM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> Given that this patch applies to all architectures at once, it is
> probably better to drop the unrelated reordering hunks to avoid
> conflicts.
Ack. Will retain order for v7.
> > +static __must_check inline bool may_use_simd(void)
> > +{
> > + return !in_interrupt();
> > +}
> > +
>
> Remember this guy?
>
> https://marc.info/?l=linux-arch&m=149631094625176&w=2
>
> That was never merged, so let's get it right this time.
Wow, nice memory. I had forgotten all about that. Queued for v7.
> > +static inline void simd_relax(simd_context_t *ctx)
> > +{
> > +#ifdef CONFIG_PREEMPT
> > + if ((*ctx & HAVE_SIMD_IN_USE) && need_resched()) {
> > + simd_put(ctx);
> > + simd_get(ctx);
> > + }
> > +#endif
>
> Could we return a bool here indicating whether we rescheduled or not?
> In some cases, we could pass that into the asm code as a 'reload'
> param, allowing repeated loads of key schedules, round constant tables
> or S-boxes to be elided.
Sure, sounds easy enough.
^ permalink raw reply
* Re: [PATCH net-next v6 01/23] asm: simd context helper API
From: Jason A. Donenfeld @ 2018-09-28 13:47 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Joe Perches, LKML, Netdev, Linux Crypto Mailing List,
David Miller, Greg Kroah-Hartman, Samuel Neves, Andrew Lutomirski,
Thomas Gleixner, linux-arch
In-Reply-To: <CAKv+Gu9kbLPZH4W0zKAfuv-b11mcDaZ05HUauvh9gMZVGVR0AQ@mail.gmail.com>
On Fri, Sep 28, 2018 at 10:49 AM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> >> +typedef enum {
> >> + HAVE_NO_SIMD = 1 << 0,
> >> + HAVE_FULL_SIMD = 1 << 1,
> >> + HAVE_SIMD_IN_USE = 1 << 31
> >> +} simd_context_t;
> >> +
>
> Oh, and another thing (and I'm surprised checkpatch.pl didn't complain
> about it): the use of typedef in new code is strongly discouraged.
> This policy predates my involvement, so perhaps Joe can elaborate on
> the rationale?
In case it matters, the motivation for making this a typedef is I
could imagine this at some point turning into a more complicated
struct on certain platforms and that would make refactoring easier. I
could just make it `struct simd_context` now with 1 member though...
^ permalink raw reply
* Re: [PATCH net-next v6 01/23] asm: simd context helper API
From: Ard Biesheuvel @ 2018-09-28 13:52 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Joe Perches, LKML, Netdev, Linux Crypto Mailing List,
David Miller, Greg Kroah-Hartman, Samuel Neves, Andrew Lutomirski,
Thomas Gleixner, linux-arch
In-Reply-To: <CAHmME9pfs0_MsD9QAGfSm31_w-=6BCF_gZO04XkfhD=mEoZmtQ@mail.gmail.com>
On 28 September 2018 at 15:47, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> On Fri, Sep 28, 2018 at 10:49 AM Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> >> +typedef enum {
>> >> + HAVE_NO_SIMD = 1 << 0,
>> >> + HAVE_FULL_SIMD = 1 << 1,
>> >> + HAVE_SIMD_IN_USE = 1 << 31
>> >> +} simd_context_t;
>> >> +
>>
>> Oh, and another thing (and I'm surprised checkpatch.pl didn't complain
>> about it): the use of typedef in new code is strongly discouraged.
>> This policy predates my involvement, so perhaps Joe can elaborate on
>> the rationale?
>
> In case it matters, the motivation for making this a typedef is I
> could imagine this at some point turning into a more complicated
> struct on certain platforms and that would make refactoring easier. I
> could just make it `struct simd_context` now with 1 member though...
Yes that makes sense
^ permalink raw reply
* Re: [PATCH v6] selftests: add headers_install to lib.mk
From: Shuah Khan @ 2018-09-28 13:52 UTC (permalink / raw)
To: Michael Ellerman, Anders Roxell, yamada.masahiro, michal.lkml,
bamv2005, brgl, pbonzini, akpm, rppt, aarcange
Cc: linux-kbuild, linux-kernel, linux-kselftest, netdev, linuxppc-dev,
Shuah Khan
In-Reply-To: <87y3bmte9l.fsf@concordia.ellerman.id.au>
On 09/27/2018 10:52 PM, Michael Ellerman wrote:
> [ + linuxppc-dev ]
>
> Anders Roxell <anders.roxell@linaro.org> writes:
>> If the kernel headers aren't installed we can't build all the tests.
>> Add a new make target rule 'khdr' in the file lib.mk to generate the
>> kernel headers and that gets include for every test-dir Makefile that
>> includes lib.mk If the testdir in turn have its own sub-dirs the
>> top_srcdir needs to be set to the linux-rootdir to be able to generate
>> the kernel headers.
>>
>> Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
>> Reviewed-by: Fathi Boudra <fathi.boudra@linaro.org>
>> ---
>>
>> I sent this (v5) a month ago and wondered if it got lost. Resending
>> unchanged.
>>
>> Cheers,
>> Anders
>>
>> Makefile | 14 +-------------
>> scripts/subarch.include | 13 +++++++++++++
>> tools/testing/selftests/android/Makefile | 2 +-
>> tools/testing/selftests/android/ion/Makefile | 2 ++
>> tools/testing/selftests/futex/functional/Makefile | 1 +
>> tools/testing/selftests/gpio/Makefile | 7 ++-----
>> tools/testing/selftests/kvm/Makefile | 7 ++-----
>> tools/testing/selftests/lib.mk | 12 ++++++++++++
>> tools/testing/selftests/net/Makefile | 1 +
>> .../selftests/networking/timestamping/Makefile | 1 +
>> tools/testing/selftests/vm/Makefile | 4 ----
>> 11 files changed, 36 insertions(+), 28 deletions(-)
>> create mode 100644 scripts/subarch.include
>
> This broke all the powerpc selftests :(
Sorry for thr breakage.
>
> Why did it go in at rc5?
>
This patch has been in linux-next for a sometime before I decided to send this.
My original intent was to send this for rc2, and my schedule was messed up with
traveling. Since I didn't hear any issues from linux-next soaking, I made a call
on sending this in for rc5.
On second thought I should have waited until 4.20. Sorry about that.
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH net 09/11] sfc: remove ndo_poll_controller
From: Bert Kenward @ 2018-09-28 7:30 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller
Cc: netdev, Michael Chan, Aviad Krawczyk, Song Liu, Douglas Miller,
Yisen Zhuang, Michael S . Tsirkin, Jason Wang, Harish Patil,
Manish Chopra, Netanel Belgazal, Solarflare linux maintainers,
Thomas Falcon, Edward Cree
In-Reply-To: <20180927163201.56609-10-edumazet@google.com>
On 27/09/18 17:31, Eric Dumazet wrote:
> As diagnosed by Song Liu, ndo_poll_controller() can
> be very dangerous on loaded hosts, since the cpu
> calling ndo_poll_controller() might steal all NAPI
> contexts (for all RX/TX queues of the NIC). This capture
> can last for unlimited amount of time, since one
> cpu is generally not able to drain all the queues under load.
>
> sfc uses NAPI for TX completions, so we better let core
> networking stack call the napi->poll() to avoid the capture.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Edward Cree <ecree@solarflare.com>
> Cc: Bert Kenward <bkenward@solarflare.com>
> Cc: Solarflare linux maintainers <linux-net-drivers@solarflare.com>
Acked-By: Bert Kenward <bkenward@solarflare.com>
> ---
> drivers/net/ethernet/sfc/efx.c | 26 --------------------------
> 1 file changed, 26 deletions(-)
>
> diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
> index 330233286e785254f5f29c87f9557a305974f606..3d0dd39c289e05b8a7a6778363461ef5698dc62b 100644
> --- a/drivers/net/ethernet/sfc/efx.c
> +++ b/drivers/net/ethernet/sfc/efx.c
> @@ -2206,29 +2206,6 @@ static void efx_fini_napi(struct efx_nic *efx)
> efx_fini_napi_channel(channel);
> }
>
> -/**************************************************************************
> - *
> - * Kernel netpoll interface
> - *
> - *************************************************************************/
> -
> -#ifdef CONFIG_NET_POLL_CONTROLLER
> -
> -/* Although in the common case interrupts will be disabled, this is not
> - * guaranteed. However, all our work happens inside the NAPI callback,
> - * so no locking is required.
> - */
> -static void efx_netpoll(struct net_device *net_dev)
> -{
> - struct efx_nic *efx = netdev_priv(net_dev);
> - struct efx_channel *channel;
> -
> - efx_for_each_channel(channel, efx)
> - efx_schedule_channel(channel);
> -}
> -
> -#endif
> -
> /**************************************************************************
> *
> * Kernel net device interface
> @@ -2509,9 +2486,6 @@ static const struct net_device_ops efx_netdev_ops = {
> #endif
> .ndo_get_phys_port_id = efx_get_phys_port_id,
> .ndo_get_phys_port_name = efx_get_phys_port_name,
> -#ifdef CONFIG_NET_POLL_CONTROLLER
> - .ndo_poll_controller = efx_netpoll,
> -#endif
> .ndo_setup_tc = efx_setup_tc,
> #ifdef CONFIG_RFS_ACCEL
> .ndo_rx_flow_steer = efx_filter_rfs,
>
^ permalink raw reply
* Re: [PATCH net 10/11] sfc-falcon: remove ndo_poll_controller
From: Bert Kenward @ 2018-09-28 7:30 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller
Cc: netdev, Michael Chan, Aviad Krawczyk, Song Liu, Douglas Miller,
Yisen Zhuang, Michael S . Tsirkin, Jason Wang, Harish Patil,
Manish Chopra, Netanel Belgazal, Solarflare linux maintainers,
Thomas Falcon, Edward Cree
In-Reply-To: <20180927163201.56609-11-edumazet@google.com>
On 27/09/18 17:32, Eric Dumazet wrote:
> As diagnosed by Song Liu, ndo_poll_controller() can
> be very dangerous on loaded hosts, since the cpu
> calling ndo_poll_controller() might steal all NAPI
> contexts (for all RX/TX queues of the NIC). This capture
> can last for unlimited amount of time, since one
> cpu is generally not able to drain all the queues under load.
>
> sfc-falcon uses NAPI for TX completions, so we better let core
> networking stack call the napi->poll() to avoid the capture.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Solarflare linux maintainers <linux-net-drivers@solarflare.com>
> Cc: Edward Cree <ecree@solarflare.com>
> Cc: Bert Kenward <bkenward@solarflare.com>
Acked-By: Bert Kenward <bkenward@solarflare.com>
> ---
> drivers/net/ethernet/sfc/falcon/efx.c | 26 --------------------------
> 1 file changed, 26 deletions(-)
>
> diff --git a/drivers/net/ethernet/sfc/falcon/efx.c b/drivers/net/ethernet/sfc/falcon/efx.c
> index dd5530a4f8c8936868aed7171bd9481f93730d76..03e2455c502eacd9a4fd5c7fd320a9edcf265f77 100644
> --- a/drivers/net/ethernet/sfc/falcon/efx.c
> +++ b/drivers/net/ethernet/sfc/falcon/efx.c
> @@ -2052,29 +2052,6 @@ static void ef4_fini_napi(struct ef4_nic *efx)
> ef4_fini_napi_channel(channel);
> }
>
> -/**************************************************************************
> - *
> - * Kernel netpoll interface
> - *
> - *************************************************************************/
> -
> -#ifdef CONFIG_NET_POLL_CONTROLLER
> -
> -/* Although in the common case interrupts will be disabled, this is not
> - * guaranteed. However, all our work happens inside the NAPI callback,
> - * so no locking is required.
> - */
> -static void ef4_netpoll(struct net_device *net_dev)
> -{
> - struct ef4_nic *efx = netdev_priv(net_dev);
> - struct ef4_channel *channel;
> -
> - ef4_for_each_channel(channel, efx)
> - ef4_schedule_channel(channel);
> -}
> -
> -#endif
> -
> /**************************************************************************
> *
> * Kernel net device interface
> @@ -2250,9 +2227,6 @@ static const struct net_device_ops ef4_netdev_ops = {
> .ndo_set_mac_address = ef4_set_mac_address,
> .ndo_set_rx_mode = ef4_set_rx_mode,
> .ndo_set_features = ef4_set_features,
> -#ifdef CONFIG_NET_POLL_CONTROLLER
> - .ndo_poll_controller = ef4_netpoll,
> -#endif
> .ndo_setup_tc = ef4_setup_tc,
> #ifdef CONFIG_RFS_ACCEL
> .ndo_rx_flow_steer = ef4_filter_rfs,
>
^ permalink raw reply
* Re: [PATCH bpf] bpf: harden flags check in cgroup_storage_update_elem()
From: Daniel Borkmann @ 2018-09-28 13:53 UTC (permalink / raw)
To: Roman Gushchin, netdev; +Cc: linux-kernel, kernel-team, Alexei Starovoitov
In-Reply-To: <20180928133321.31121-1-guro@fb.com>
On 09/28/2018 03:33 PM, Roman Gushchin wrote:
> cgroup_storage_update_elem() shouldn't accept any flags
> argument values except BPF_ANY and BPF_EXIST to guarantee
> the backward compatibility, had a new flag value been added.
>
> Fixes: de9cbbaadba5 ("bpf: introduce cgroup storage maps")
> Signed-off-by: Roman Gushchin <guro@fb.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> ---
> kernel/bpf/local_storage.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/local_storage.c b/kernel/bpf/local_storage.c
> index f8746e6a9a35..2a7680106320 100644
> --- a/kernel/bpf/local_storage.c
> +++ b/kernel/bpf/local_storage.c
> @@ -130,7 +130,7 @@ static int cgroup_storage_update_elem(struct bpf_map *map, void *_key,
> struct bpf_cgroup_storage *storage;
> struct bpf_storage_buffer *new;
>
> - if (flags & BPF_NOEXIST)
> + if (flags != BPF_ANY && flags != BPF_EXIST)
> return -EINVAL;
>
> storage = cgroup_storage_lookup((struct bpf_cgroup_storage_map *)map,
>
Applied to bpf, thanks!
^ permalink raw reply
* Re: [PATCH net-next v6 01/23] asm: simd context helper API
From: Jason A. Donenfeld @ 2018-09-28 13:59 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Joe Perches, LKML, Netdev, Linux Crypto Mailing List,
David Miller, Greg Kroah-Hartman, Samuel Neves, Andrew Lutomirski,
Thomas Gleixner, linux-arch
In-Reply-To: <CAKv+Gu__7mZFFq6qC=8yh0OuaV+TCCLFt6nm8yJfaANHUPrJ=A@mail.gmail.com>
On Fri, Sep 28, 2018 at 3:58 PM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
>
> On 28 September 2018 at 15:47, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> > On Fri, Sep 28, 2018 at 10:49 AM Ard Biesheuvel
> > <ard.biesheuvel@linaro.org> wrote:
> >> >> +typedef enum {
> >> >> + HAVE_NO_SIMD = 1 << 0,
> >> >> + HAVE_FULL_SIMD = 1 << 1,
> >> >> + HAVE_SIMD_IN_USE = 1 << 31
> >> >> +} simd_context_t;
> >> >> +
> >>
> >> Oh, and another thing (and I'm surprised checkpatch.pl didn't complain
> >> about it): the use of typedef in new code is strongly discouraged.
> >> This policy predates my involvement, so perhaps Joe can elaborate on
> >> the rationale?
> >
> > In case it matters, the motivation for making this a typedef is I
> > could imagine this at some point turning into a more complicated
> > struct on certain platforms and that would make refactoring easier. I
> > could just make it `struct simd_context` now with 1 member though...
>
> Yes that makes sense
The rationale for it being a typedef or moving to a struct now?
^ permalink raw reply
* Re: [PATCH net-next v6 01/23] asm: simd context helper API
From: Ard Biesheuvel @ 2018-09-28 14:00 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Joe Perches, LKML, Netdev, Linux Crypto Mailing List,
David Miller, Greg Kroah-Hartman, Samuel Neves, Andrew Lutomirski,
Thomas Gleixner, linux-arch
In-Reply-To: <CAHmME9owF+3aQaZUkK4KkfnJna+DK=GoWV8yf-Wb+gH4w3y9eg@mail.gmail.com>
On 28 September 2018 at 15:59, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> On Fri, Sep 28, 2018 at 3:58 PM Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>>
>> On 28 September 2018 at 15:47, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>> > On Fri, Sep 28, 2018 at 10:49 AM Ard Biesheuvel
>> > <ard.biesheuvel@linaro.org> wrote:
>> >> >> +typedef enum {
>> >> >> + HAVE_NO_SIMD = 1 << 0,
>> >> >> + HAVE_FULL_SIMD = 1 << 1,
>> >> >> + HAVE_SIMD_IN_USE = 1 << 31
>> >> >> +} simd_context_t;
>> >> >> +
>> >>
>> >> Oh, and another thing (and I'm surprised checkpatch.pl didn't complain
>> >> about it): the use of typedef in new code is strongly discouraged.
>> >> This policy predates my involvement, so perhaps Joe can elaborate on
>> >> the rationale?
>> >
>> > In case it matters, the motivation for making this a typedef is I
>> > could imagine this at some point turning into a more complicated
>> > struct on certain platforms and that would make refactoring easier. I
>> > could just make it `struct simd_context` now with 1 member though...
>>
>> Yes that makes sense
>
> The rationale for it being a typedef or moving to a struct now?
Yes just switch to a struct.
^ 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