* Re: [PATCH 0/2] gpiolib: Fix issues introduced by fast bitmap processing path
From: Janusz Krzysztofik @ 2018-09-24 11:08 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Andrew Lunn, Ulf Hansson, linux-doc, Tony Lindgren, Linus Walleij,
Dominik Brodowski, Peter Rosin, netdev, linux-i2c,
Peter Meerwald-Stadler, devel, Florian Fainelli, Jonathan Corbet,
Krzysztof Kozlowski, Kishon Vijay Abraham I, linux-iio,
Peter Korsgaard, Geert Uytterhoeven, linux-serial, Jiri Slaby,
Michael Hennerich, Uwe Kleine-König, linux-gpio,
Russell King
In-Reply-To: <20180924094339eucas1p282f2f7cb627c183fe87da044edb90fa5~XTMgQ4GFs1339913399eucas1p2N@eucas1p2.samsung.com>
Hi Marek,
2018-09-24 11:43 GMT+02:00, Marek Szyprowski <m.szyprowski@samsung.com>:
> Hi Janusz,
>
> On 2018-09-24 01:53, Janusz Krzysztofik wrote:
>> While investigating possible reasons of GPIO fast bitmap processing
>> related boot hang on Samsung Snow Chromebook, reported by Marek
>> Szyprowski (thanks!), I've discovered one coding bug, addressed by
>> PATCH 1/2 of this series, and one potential regression introduced at
>> design level of the solution, hopefully fixed by PATCH 2/2. See
>> commit messages for details.
>>
>> Janusz Krzysztofik (2):
>> gpiolib: Fix missing updates of bitmap index
>> gpiolib: Fix array members of same chip processed separately
>>
>> The fixes should resolve the boot hang observed by Marek, however the
>> second change excludes that particular case from fast bitmap processing
>> and restores the old behaviour.
>
> I confirm, that the above 2 patches fixes boot issue on Samsung Snow
> Chromebook with next-20180920.
>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
>> Hence, it is possible still another
>> issue which have had an influence on that boot hang exists in the code.
>> In order to fully verify the fix, it would have to be tested on a
>> platform where an array of GPIO descriptors is used which starts from
>> at least two consecutive pins of one GPIO chip in hardware order,
>> starting ftom 0, followed by one or more pins belonging to other
>> chip(s).
>>
>> In order to verify if separate calls to .set() chip callback for each
>> pin instead of one call to .set_multiple() is actually the reason of
>> boot hang on Samsung Snow Chromebook, the affected driver -
>> drivers/mmc/core/pwrseq_simple.c - would have to be temporarily
>> modified for testing purposes so it calls gpiod_set_value() for each
>> pin instead of gpiod_set_array_value() for all of them. If that would
>> also result in boot hang, we could be sure the issue was really the
>> one addressed by the second fix. Marek, could you please try to
>> perform such test?
>
> Yes, I've just tested next-20180920 only with the first patch from this
> patchset and the mentioned change to drivers/mmc/core/pwrseq_simple.c.
> It boots fine, so indeed the issue is in handling of arrays of gpios.
>
> Just to be sure I did it right, this is my change to the mentioned file:
Yeah, that's what I had on mind. However, I'd be more lucky if it didn't work
for you. Setting the pins sequentially, not simultaneously as before, was
exactly what I hoped was the reason of the hang.
> diff --git a/drivers/mmc/core/pwrseq_simple.c
> b/drivers/mmc/core/pwrseq_simple.c
> index 7f882a2bb872..9397dc1f2e38 100644
> --- a/drivers/mmc/core/pwrseq_simple.c
> +++ b/drivers/mmc/core/pwrseq_simple.c
> @@ -38,16 +38,11 @@ static void mmc_pwrseq_simple_set_gpios_value(struct
> mmc_pwrseq_simple *pwrseq,
> int value)
> {
> struct gpio_descs *reset_gpios = pwrseq->reset_gpios;
> + int i;
>
> - if (!IS_ERR(reset_gpios)) {
> - DECLARE_BITMAP(values, BITS_PER_TYPE(value));
> - int nvalues = reset_gpios->ndescs;
> -
> - values[0] = value;
> -
> - gpiod_set_array_value_cansleep(nvalues, reset_gpios->desc,
> - reset_gpios->info, values);
> - }
> + if (!IS_ERR(reset_gpios))
> + for (i = 0; i < reset_gpios->ndescs; i++)
The only difference from the behaviour when the hang was occurring is now
the order the pins are manipulated. Maybe that matters?
Could you please retry the same with the order of pins reversed, either in
the .dts file or here inside this for loop?
Thanks,
Janusz
> + gpiod_set_value_cansleep(reset_gpios->desc[i], value);
> }
>
> static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host)
>
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>
>
^ permalink raw reply
* [PATCH v2 net-next 5/9] bnxt_en: return proper error when FW returns HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED
From: Vasundhara Volam @ 2018-09-24 5:16 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev
In-Reply-To: <1537766181-18994-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 58e3061..1b25e3a 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
@@ -77,8 +77,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 v2 net-next 4/9] bnxt_en: Use ignore_ari devlink parameter
From: Vasundhara Volam @ 2018-09-24 5:16 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev
In-Reply-To: <1537766181-18994-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 f3b9fbc..58e3061 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,
@@ -105,6 +107,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 v2 net-next 1/9] devlink: Add generic parameter ignore_ari
From: Vasundhara Volam @ 2018-09-24 5:16 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev
In-Reply-To: <1537766181-18994-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 65fc366..6b08ad6 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -2676,6 +2676,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 v2 net-next 0/9] bnxt_en: devlink param updates
From: Vasundhara Volam @ 2018-09-24 5:16 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev
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.
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_en.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 | 35 +++++++++
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, 194 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 v2 net-next 7/9] bnxt_en: Add a driver specific gre_ver_check devlink parameter.
From: Vasundhara Volam @ 2018-09-24 5:16 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev
In-Reply-To: <1537766181-18994-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 7dc754b..fdeb4e5 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,
@@ -109,9 +116,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,
@@ -121,6 +134,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);
}
@@ -161,6 +178,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 v2 net-next 3/9] devlink: Add generic parameter msix_vec_per_pf_min
From: Vasundhara Volam @ 2018-09-24 5:16 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev
In-Reply-To: <1537766181-18994-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 7e0ac2e..8faf889 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -2686,6 +2686,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 v2 net-next 8/9] devlink: Add Documentation/networking/devlink-params.txt
From: Vasundhara Volam @ 2018-09-24 5:16 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev
In-Reply-To: <1537766181-18994-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
* [PATCH v2 net-next 2/9] devlink: Add generic parameter msix_vec_per_pf_max
From: Vasundhara Volam @ 2018-09-24 5:16 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev
In-Reply-To: <1537766181-18994-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 6b08ad6..7e0ac2e 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -2681,6 +2681,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 v2 net-next 9/9] devlink: Add Documentation/networking/devlink-params-bnxt.txt
From: Vasundhara Volam @ 2018-09-24 5:16 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev
In-Reply-To: <1537766181-18994-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 | 35 ++++++++++++++++++++++++
1 file changed, 35 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..ca7c457
--- /dev/null
+++ b/Documentation/networking/devlink-params-bnxt.txt
@@ -0,0 +1,35 @@
+enable_sriov [DEVICE, GENERIC]
+ Enable Single Root I/O Virtualisation (SRIOV) in
+ the device.
+ Type: Boolean
+ Configuration mode: Permanent
+
+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
+ Configuration mode: Permanent
+
+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
+ Configuration mode: Permanent
+
+msix_vec_per_pf_min [DEVICE, GENERIC]
+ Provides the minimum number of MSIX interrupts required
+ or the device initialization. Value is same across all
+ physical functions (PFs) in the device.
+ 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 v2 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-24 5:16 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev
In-Reply-To: <1537766181-18994-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 1b25e3a..7dc754b 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,
@@ -54,8 +58,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);
@@ -106,6 +124,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),
@@ -115,6 +153,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
* Re: [PATCH v2 net] net: aquantia: memory corruption on jumbo frames
From: David Miller @ 2018-09-24 5:25 UTC (permalink / raw)
To: igor.russkikh; +Cc: nikita.danilov, netdev, f.gerold
In-Reply-To: <71ff3378-b20e-e0e9-d643-d4f7401d1864@aquantia.com>
From: Igor Russkikh <igor.russkikh@aquantia.com>
Date: Tue, 18 Sep 2018 11:28:55 +0300
>
>>> Fixes: 018423e90bee ("net: ethernet: aquantia: Add ring support code")
>>>
>>> Reported-by: Friedemann Gerold <f.gerold@b-c-s.de>
>>> Reported-by: Michael Rauch <michael@rauch.be>
>>> Signed-off-by: Friedemann Gerold <f.gerold@b-c-s.de>
>>> Tested-by: Nikita Danilov <nikita.danilov@aquantia.com>
>>> Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
>>
>> APplied and queued up for -stable.
>
> Hi David, I see this was applied to net-next tree only.
> Can we have it in net? We consider it as critical flaw.
Sorry about that, fixed.
^ permalink raw reply
* Re: [PATCH net-next] tcp: expose sk_state in tcp_retransmit_skb tracepoint
From: Yafang Shao @ 2018-09-24 12:39 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Eric Dumazet, David Miller, netdev, LKML
In-Reply-To: <375c389d-f391-5b72-bc52-9a82d61c6bd7@gmail.com>
On Mon, Sep 24, 2018 at 5:42 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
> On 09/23/2018 12:49 PM, Yafang Shao wrote:
>> With sk_state, we can know whether this connection is in SYN_SENT state
>> or ESTBLISHED state.
>> The reason to distinguish between these two scenario is that the
>> retransmission in ESTABLISHED state always mean network congestion while
>> in SYN_SENT state it always mean server issue, i.e. the syn packet is
>> dropped due to syn backlog queue full.
>
> You mean, a packet drop on the remote peer ?
>
Yes, I mean drop on the remote peer.
> It could also be a packet drop in the network.
>
Yes of course.
> Your patch is good, but changelog is quite misleading.
Will modify the changelog.
Thanks
Yafang
^ permalink raw reply
* Re: [PATCH net] VSOCK: check sk state before receive
From: Jorgen S. Hansen @ 2018-09-24 7:00 UTC (permalink / raw)
To: Hangbin Liu; +Cc: Stefan Hajnoczi, netdev@vger.kernel.org, David S. Miller
In-Reply-To: <20180922062744.GC24677@leo.usersys.redhat.com>
On Sep 22, 2018, at 8:27 AM, Hangbin Liu <liuhangbin@gmail.com> wrote:
>
> On Fri, Sep 21, 2018 at 07:48:25AM +0000, Jorgen S. Hansen wrote:
>> Hi Hangbin,
>>
>> I finaly got to the bottom of this - the issue was indeed in the VMCI driver. The patch is posted here:
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2018%2F9%2F21%2F326&data=02%7C01%7Cjhansen%40vmware.com%7C280a9c79e99248db3d1108d6205488de%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636731944784367201&sdata=BEExXdB%2BF0SSh83Epa5fAuyoG4qn%2FAeM2J0wG2gM6GQ%3D&reserved=0
>>
>> I used your reproduce.log to test the fix. Thanks for discovering this issue.
>
> Hi Jorgen,
>
> Thanks for your patch. I built a test kernel with your fix, run my
> reproducer and syzkaller socket vnet test for a while. There is no such
> error. So I think your patch fixed this issue.
Great. Thanks a lot for trying out the patch.
> BTW, with FAULT_INJECTION enabled. I got another call trace:
The vhost_* stuff is for Virtio. Stefan would know better what is going on there.
> [ 251.166377] FAULT_INJECTION: forcing a failure.
> [ 251.178736] CPU: 15 PID: 10448 Comm: syz-executor7 Not tainted 4.19.0
> -rc4.syz.vnet+ #3
> [ 251.187577] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.1.5 04/11/2016
> [ 251.187578] Call Trace:
> [ 251.187586] dump_stack+0x8c/0xce
> [ 251.187594] should_fail+0x5dd/0x6b0
> [ 251.199932] ? fault_create_debugfs_attr+0x1d0/0x1d0
> [ 251.199937] __should_failslab+0xe8/0x120
> [ 251.199945] should_failslab+0xa/0x20
> [ 251.228430] kmem_cache_alloc_trace+0x43/0x1f0
> [ 251.233392] ? vhost_dev_set_owner+0x366/0x790 [vhost]
> [ 251.239129] vhost_dev_set_owner+0x366/0x790 [vhost]
> [ 251.244672] ? vhost_poll_wakeup+0xa0/0xa0 [vhost]
> [ 251.250018] ? kasan_unpoison_shadow+0x30/0x40
> [ 251.254978] ? vhost_worker+0x370/0x370 [vhost]
> [ 251.260035] ? kasan_kmalloc_large+0x71/0xe0
> [ 251.264799] ? kmalloc_order+0x54/0x60
> [ 251.268985] vhost_net_ioctl+0xc2e/0x14c0 [vhost_net]
> [ 251.274635] ? avc_ss_reset+0x150/0x150
> [ 251.278915] ? kstrtouint_from_user+0xe5/0x140
> [ 251.283876] ? handle_tx_kick+0x40/0x40 [vhost_net]
> [ 251.289320] ? save_stack+0x89/0xb0
> [ 251.293213] ? __kasan_slab_free+0x12e/0x180
> [ 251.297979] ? kmem_cache_free+0x7a/0x210
> [ 251.302452] ? putname+0xe2/0x120
> [ 251.306151] ? get_pid_task+0x6e/0x90
> [ 251.310238] ? proc_fail_nth_write+0x91/0x1c0
> [ 251.315100] ? map_files_get_link+0x3c0/0x3c0
> [ 251.319963] ? exit_robust_list+0x1c0/0x1c0
> [ 251.324633] ? __vfs_write+0xf7/0x6a0
> [ 251.328711] ? handle_tx_kick+0x40/0x40 [vhost_net]
> [ 251.334154] do_vfs_ioctl+0x1a5/0xfb0
> [ 251.338241] ? ioctl_preallocate+0x1c0/0x1c0
> [ 251.343009] ? selinux_file_ioctl+0x382/0x560
> [ 251.347872] ? selinux_capable+0x40/0x40
> [ 251.352250] ? __fget+0x211/0x2e0
> [ 251.355949] ? iterate_fd+0x1c0/0x1c0
> [ 251.360038] ? syscall_trace_enter+0x285/0xaa0
> [ 251.365011] ? security_file_ioctl+0x5d/0xb0
> [ 251.369776] ? selinux_capable+0x40/0x40
> [ 251.374153] ksys_ioctl+0x89/0xa0
> [ 251.377853] __x64_sys_ioctl+0x74/0xb0
> [ 251.382036] do_syscall_64+0xc3/0x390
> [ 251.386123] ? syscall_return_slowpath+0x14c/0x230
> [ 251.391473] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 251.397111] RIP: 0033:0x451b89
> [ 251.400519] Code: fc ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 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 0b 67 fc ff c3 66 2e 0f 1f 84 00 00 00 00
> [ 251.421476] RSP: 002b:00007fc0d9673c48 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> [ 251.429927] RAX: ffffffffffffffda RBX: 00007fc0d96746b4 RCX: 0000000000451b89
> [ 251.437889] RDX: 0000000000000000 RSI: 000000000000af01 RDI: 0000000000000003
> [ 251.445852] RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
> [ 251.453815] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000004
> [ 251.461778] R13: 0000000000006450 R14: 00000000004d3090 R15: 00007fc0d9674700
>
> Thanks
> Hangbin
Thanks,
Jorgen
^ permalink raw reply
* Ping: [PATCH 0/3] xen-netback: hash mapping hanling adjustments
From: Jan Beulich @ 2018-09-24 7:43 UTC (permalink / raw)
To: davem; +Cc: Paul Durrant, Wei Liu, xen-devel, netdev
In-Reply-To: <20180911101623.3tuzvlyr7musocrg@zion.uk.xensource.com>
>>> On 11.09.18 at 12:16, <wei.liu2@citrix.com> wrote:
> On Tue, Sep 11, 2018 at 02:12:07AM -0600, Jan Beulich wrote:
>> >>> On 28.08.18 at 16:54, wrote:
>> > First and foremost the fix for XSA-270. On top of that further changes
>> > which looked desirable to me while investigating that XSA.
>> >
>> > 1: fix input validation in xenvif_set_hash_mapping()
>> > 2: validate queue numbers in xenvif_set_hash_mapping()
>> > 3: handle page straddling in xenvif_set_hash_mapping()
>> >
>> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> What is the way forward here? I've got R-b-s from Paul for all three
>> patches, and a minor change request on patch 2 from Wei. I'm not
>> really certain what to do in this case (hints appreciated), but could
>> at least the security fix (patch 1) be applied immediately?
>
> If you happen to resend, please make the adjustment; otherwise I'm fine
> with the patches as they are. I don't want to block useful things on
> cosmetic issues.
Dave? I notice none of the patches is in 4.19-rc5, not even the security
fix, the advisory for which had gone public over a month ago.
Jan
^ permalink raw reply
* Re: [PATCH net] xfrm: validate template mode
From: Steffen Klassert @ 2018-09-24 8:03 UTC (permalink / raw)
To: Sean Tranchetti; +Cc: netdev
In-Reply-To: <1537386896-5425-1-git-send-email-stranche@codeaurora.org>
On Wed, Sep 19, 2018 at 01:54:56PM -0600, Sean Tranchetti wrote:
> XFRM mode parameters passed as part of the user templates
> in the IP_XFRM_POLICY are never properly validated. Passing
> values other than valid XFRM modes can cause stack-out-of-bounds
> reads to occur later in the XFRM processing:
>
> [ 140.535608] ================================================================
> [ 140.543058] BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x17e4/0x1cc4
> [ 140.550306] Read of size 4 at addr ffffffc0238a7a58 by task repro/5148
> [ 140.557369]
> [ 140.558927] Call trace:
> [ 140.558936] dump_backtrace+0x0/0x388
> [ 140.558940] show_stack+0x24/0x30
> [ 140.558946] __dump_stack+0x24/0x2c
> [ 140.558949] dump_stack+0x8c/0xd0
> [ 140.558956] print_address_description+0x74/0x234
> [ 140.558960] kasan_report+0x240/0x264
> [ 140.558963] __asan_report_load4_noabort+0x2c/0x38
> [ 140.558967] xfrm_state_find+0x17e4/0x1cc4
> [ 140.558971] xfrm_resolve_and_create_bundle+0x40c/0x1fb8
> [ 140.558975] xfrm_lookup+0x238/0x1444
> [ 140.558977] xfrm_lookup_route+0x48/0x11c
> [ 140.558984] ip_route_output_flow+0x88/0xc4
> [ 140.558991] raw_sendmsg+0xa74/0x266c
> [ 140.558996] inet_sendmsg+0x258/0x3b0
> [ 140.559002] sock_sendmsg+0xbc/0xec
> [ 140.559005] SyS_sendto+0x3a8/0x5a8
> [ 140.559008] el0_svc_naked+0x34/0x38
> [ 140.559009]
> [ 140.592245] page dumped because: kasan: bad access detected
> [ 140.597981] page_owner info is not active (free page?)
> [ 140.603267]
> [ 140.653503] ================================================================
>
> Signed-off-by: Sean Tranchetti <stranche@codeaurora.org>
Applied to the ipsec tree, thanks a lot!
^ permalink raw reply
* Re: [PATCH 2/2] gpiolib: Fix array members of same chip processed separately
From: Linus Walleij @ 2018-09-24 8:13 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: Jonathan Corbet, Miguel Ojeda Sandonis, Peter Korsgaard,
Peter Rosin, Ulf Hansson, Andrew Lunn, Florian Fainelli,
David S. Miller, Dominik Brodowski, Greg KH, kishon,
Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
Hartmut Knaack, Peter Meerwald, Jiri Slaby, Willy Tarreau,
Geert Uytterhoeven, Sebastien Bourdelin
In-Reply-To: <20180923235336.22148-3-jmkrzyszt@gmail.com>
On Mon, Sep 24, 2018 at 1:52 AM Janusz Krzysztofik <jmkrzyszt@gmail.com> wrote:
> New code introduced by commit bf9346f5d47b ("gpiolib: Identify arrays
> matching GPIO hardware") forcibly tries to find an array member which
> has its array index number equal to its hardware pin number and set
> up an array info for possible fast bitmap processing of all arrray
> pins belonging to that chip which also satisfy that numbering rule.
>
> Depending on array content, it may happen that consecutive array
> members which belong to the same chip but don't have array indexes
> equal to their pin hardware numbers will be split into groups, some of
> them processed together via the fast bitmap path, and rest of them
> separetely. However, applications may expect all those pins being
> processed together with a single call to .set_multiple() chip callback,
> like that was done before the change.
>
> Limit applicability of fast bitmap processing path to cases where all
> pins of consecutive array members starting from 0 which belong to the
> same chip have their hardware numbers equal to their corresponding
> array indexes. That should still speed up processing of applications
> using whole GPIO banks as I/O ports, while not breaking simultaneous
> manipulation of consecutive pins of the same chip which don't follow
> the equal numbering rule.
>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Patch applied!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH bpf-next 2/2] xsk: fix bug when trying to use both copy and zero-copy on one queue id
From: Magnus Karlsson @ 2018-09-24 8:37 UTC (permalink / raw)
To: jakub.kicinski
Cc: Y Song, Karlsson, Magnus, Björn Töpel, ast,
Daniel Borkmann, Network Development
In-Reply-To: <20180920074143.0add8cc4@cakuba.netronome.com>
On Thu, Sep 20, 2018 at 4:41 PM Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
>
> On Thu, 20 Sep 2018 11:17:17 +0200, Magnus Karlsson wrote:
> > On Wed, Sep 19, 2018 at 9:18 AM Magnus Karlsson wrote:
> > > On Wed, Sep 19, 2018 at 3:58 AM Jakub Kicinski wrote:
> > > >
> > > > On Tue, 18 Sep 2018 10:22:11 -0700, Y Song wrote:
> > > > > > +/* The umem is stored both in the _rx struct and the _tx struct as we do
> > > > > > + * not know if the device has more tx queues than rx, or the opposite.
> > > > > > + * This might also change during run time.
> > > > > > + */
> > > > > > +static void xdp_reg_umem_at_qid(struct net_device *dev, struct xdp_umem *umem,
> > > > > > + u16 queue_id)
> > > > > > +{
> > > > > > + if (queue_id < dev->real_num_rx_queues)
> > > > > > + dev->_rx[queue_id].umem = umem;
> > > > > > + if (queue_id < dev->real_num_tx_queues)
> > > > > > + dev->_tx[queue_id].umem = umem;
> > > > > > +}
> > > > > > +
> > > > > > +static struct xdp_umem *xdp_get_umem_from_qid(struct net_device *dev,
> > > > > > + u16 queue_id)
> > > > > > +{
> > > > > > + if (queue_id < dev->real_num_rx_queues)
> > > > > > + return dev->_rx[queue_id].umem;
> > > > > > + if (queue_id < dev->real_num_tx_queues)
> > > > > > + return dev->_tx[queue_id].umem;
> > > > > > +
> > > > > > + return NULL;
> > > > > > +}
> > > > > > +
> > > > > > +static void xdp_clear_umem_at_qid(struct net_device *dev, u16 queue_id)
> > > > > > +{
> > > > > > + /* Zero out the entry independent on how many queues are configured
> > > > > > + * at this point in time, as it might be used in the future.
> > > > > > + */
> > > > > > + if (queue_id < dev->num_rx_queues)
> > > > > > + dev->_rx[queue_id].umem = NULL;
> > > > > > + if (queue_id < dev->num_tx_queues)
> > > > > > + dev->_tx[queue_id].umem = NULL;
> > > > > > +}
> > > > > > +
> > > > >
> > > > > I am sure whether the following scenario can happen or not.
> > > > > Could you clarify?
> > > > > 1. suppose initially we have num_rx_queues = num_tx_queues = 10
> > > > > xdp_reg_umem_at_qid() set umem1 to queue_id = 8
> > > > > 2. num_tx_queues is changed to 5
> > > > > 3. xdp_clear_umem_at_qid() is called for queue_id = 8,
> > > > > and dev->_rx[8].umum = 0.
> > > > > 4. xdp_reg_umem_at_qid() is called gain to set for queue_id = 8
> > > > > dev->_rx[8].umem = umem2
> > > > > 5. num_tx_queues is changed to 10
> > > > > Now dev->_rx[8].umem != dev->_tx[8].umem, is this possible and is it
> > > > > a problem?
> > > >
> > > > Plus IIRC the check of qid vs real_num_[rt]x_queues in xsk_bind() is
> > > > not under rtnl_lock so it doesn't count for much. Why not do all the
> > > > checks against num_[rt]x_queues here, instead of real_..?
> > >
> > > You are correct, two separate rtnl_lock regions is broken. Will spin a
> > > v2 tomorrow when I am back in the office.
> > >
> > > Thanks Jakub for catching this. I really appreciate you reviewing my code.
> >
> > Sorry, forgot to answer your question about why real_num_ instead of
> > num_. If we used num_ instead, we would get a behavior where we can
> > open a socket on a queue id, let us say 10, that will not be active if
> > real_num_ is below 10. So no traffic will flow on this socket until we
> > issue an ethtool command to state that we have 10 or more queues
> > configured. While this behavior is sane (and consistent), I believe it
> > will lead to a more complicated driver implementation, break the
> > current uapi (since we will return an error if you try to bind to a
> > queue id that is not active at the moment) and I like my suggestion
> > below better :-).
> >
> > What I would like to suggest is that the current model at bind() is
> > kept, that is it will fail if you try to bind to a non-active queue
> > id. But we add some code in ethool_set_channels in net/core/ethtool.c
> > to check if you have an active af_xdp socket on a queue id and try to
> > make it inactive, we return an error and disallow the change. This
> > would IMHO be like not allowing a load module to be unloaded if
> > someone is using it or not allowing unmounting a file system if files
> > are in use. What do you think? If you think this is the right way to
> > go, I can implement this in a follow up patch or in this patch set if
> > that makes more sense, let me know. This suggestion would actually
> > make it simpler to implement zero-copy support in the driver. Some of
> > the complications we are having today is due to the fact that ethtool
> > can come in from the side and change things for us when an AF_XDP
> > socket is active on a queue id. And implementing zero copy support in
> > the driver needs to get simpler IMO.
> >
> > Please let me know what you think.
>
> I think I'd like that:
> https://patchwork.ozlabs.org/project/netdev/list/?series=57843&state=*
> in particular:
> https://patchwork.ozlabs.org/patch/949891/
> ;)
Perfect :-). I will drop the code I wrote to fix this and use yours in
my patch set. Please let me know if that does not work for you.
> If we fix the resize indeed you could stick to real_* but to be honest,
> I'm not entirely clear on what the advantage would be? The arrays are
> sized to num..queues, do you envision a use case where having
> xdp_get_umem_from_qid() return a NULL when asked for qid > real_..
> would help? Is there one for xdp_reg_umem_at_qid()
I just think that testing against real_ combined with not allowing to
remove queues that have an active af_xdp socket makes it consistent.
You cannot start an af_xdp socket on a non-active queue_id. You have
to make the queue active (increase real_num_ so it encompasses the
queue in question) first, then you can start your socket, and in order
to decrease real_num, you first have to remove the socket. AF_XDP
sockets are only on active queue ids. Should make the state handling
simpler, IMHO.
/Magnus
> I have no strong preference here, just wondering.
^ permalink raw reply
* Re: [PATCH net-next] dt-bindings: net: ravb: Add support for r8a7744 SoC
From: Simon Horman @ 2018-09-24 8:45 UTC (permalink / raw)
To: Biju Das
Cc: Sergei Shtylyov, Rob Herring, Mark Rutland, David S. Miller,
Geert Uytterhoeven, Fabrizio Castro, Jacopo Mondi,
Yoshihiro Shimoda, netdev@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org,
Chris Paterson
In-Reply-To: <OSBPR01MB21036782B7F7938C35D0D859B8120@OSBPR01MB2103.jpnprd01.prod.outlook.com>
On Fri, Sep 21, 2018 at 03:57:33PM +0000, Biju Das wrote:
> Hi Sergei,
>
> Thanks for the feedback.
>
> > Subject: Re: [PATCH net-next] dt-bindings: net: ravb: Add support for
> > r8a7744 SoC
> >
> > Hello!
> >
> > On 09/21/2018 05:25 PM, Biju Das wrote:
> >
> > > Document RZ/G1N (R8A7744) SoC bindings.
> > >
> > > Signed-off-by: Biju Das <biju.das@bp.renesas.com>
> > > Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> >
> > Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> >
> > > ---
> > > Documentation/devicetree/bindings/net/renesas,ravb.txt | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt
> > b/Documentation/devicetree/bindings/net/renesas,ravb.txt
> > > index da249b7..3530256 100644
> > > --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt
> > > +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt
> > > @@ -6,6 +6,7 @@ interface contains.
> > > Required properties:
> > > - compatible: Must contain one or more of the following:
> > > - "renesas,etheravb-r8a7743" for the R8A7743 SoC.
> > > + - "renesas,etheravb-r8a7744" for the R8A7744 SoC.
> >
> > Mmm, I thought it was decided to go with the full model #s, like with
> > R8A77470 below?
>
> For RZ/G1C case, there are 2 variants 1 with HDMI(R8A77470) and the other without HDMI(R8A77471).
> Current support is for R8A77470.
r8a7744 is consistent with other bindings for this SoC and my understanding
is that it is a) sufficient to differentiate this SoC and b) in keeping
with most other RZ/G1 SoCs (RZ/G1C being the exception).
In short, this seems fine to me.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> > > - "renesas,etheravb-r8a7745" for the R8A7745 SoC.
> > > - "renesas,etheravb-r8a77470" for the R8A77470 SoC.
> > > - "renesas,etheravb-r8a7790" for the R8A7790 SoC.
^ permalink raw reply
* Re: [PATCH v2 net-next] ravb: remove tx buffer addr 4byte alilgnment restriction for R-Car Gen3
From: Simon Horman @ 2018-09-24 8:46 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: David Miller, Magnus Damm, netdev, linux-renesas-soc,
Kazuya Mizuguchi
In-Reply-To: <4b0144fc-d2f2-e687-eb15-4ad703f9c649@cogentembedded.com>
On Fri, Sep 21, 2018 at 07:14:02PM +0300, Sergei Shtylyov wrote:
> On 09/19/2018 11:06 AM, Simon Horman wrote:
>
> > From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
> >
> > This patch sets from two descriptor to one descriptor because R-Car Gen3
> > does not have the 4 bytes alignment restriction of the transmission buffer.
> >
> > Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > ---
> > v2 [Simon Horman]
> > * As per review by Sergi Shtylyov
>
> It's Sergei or (more correctly) Sergey. :-)
Sorry, that was completely unintentional.
>
> > - Use reverse xmas tree for variable declarations
> > - Use > rather than >= for conditions
> > - Dropped unnecessary parentheses
> > - Don't allocate memory for tx_align when it will not be used
> > - But, kept NUM_TX_DESC_GEN[23] as I see some value in
> > the self-documentation provided by these #defines
> [...]
>
> Better late than never (-:
>
> Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> MBR, Sergei
>
^ permalink raw reply
* [PATCH net] net: mvneta: fix the remaining Rx descriptor unmapping issues
From: Antoine Tenart @ 2018-09-24 14:56 UTC (permalink / raw)
To: davem, yelena
Cc: Antoine Tenart, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, gregory.clement, miquel.raynal, nadavh,
stefanc, ymarkman, mw
With CONFIG_DMA_API_DEBUG enabled we get DMA unmapping warning in
various places of the mvneta driver, for example when putting down an
interface while traffic is passing through.
The issue is when using s/w buffer management, the Rx buffers are mapped
using dma_map_page but unmapped with dma_unmap_single. This patch fixes
this by using the right unmapping function.
Fixes: 562e2f467e71 ("net: mvneta: Improve the buffer allocation method for SWBM")
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
drivers/net/ethernet/marvell/mvneta.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 2db9708f2e24..b4ed7d394d07 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -1890,8 +1890,8 @@ static void mvneta_rxq_drop_pkts(struct mvneta_port *pp,
if (!data || !(rx_desc->buf_phys_addr))
continue;
- dma_unmap_single(pp->dev->dev.parent, rx_desc->buf_phys_addr,
- MVNETA_RX_BUF_SIZE(pp->pkt_size), DMA_FROM_DEVICE);
+ dma_unmap_page(pp->dev->dev.parent, rx_desc->buf_phys_addr,
+ PAGE_SIZE, DMA_FROM_DEVICE);
__free_page(data);
}
}
@@ -2039,9 +2039,8 @@ static int mvneta_rx_swbm(struct napi_struct *napi,
frag_offset, frag_size,
PAGE_SIZE);
- dma_unmap_single(dev->dev.parent, phys_addr,
- PAGE_SIZE,
- DMA_FROM_DEVICE);
+ dma_unmap_page(dev->dev.parent, phys_addr,
+ PAGE_SIZE, DMA_FROM_DEVICE);
rxq->left_size -= frag_size;
}
--
2.17.1
^ permalink raw reply related
* [mainline][ppc][bnx2x] watchdog: CPU 80 self-detected hard LOCKUP @ opal_interrupt+0x28/0x70 when module load/unload
From: Abdul Haleem @ 2018-09-24 8:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel, netdev, maurosr, mpe, manvanth, sim
Greeting's
bnx2x module load/unload test results in continuous hard LOCKUP trace on
my powerpc bare-metal running mainline 4.19.0-rc4 kernel
the instruction address points to:
0xc00000000009d048 is in opal_interrupt
(arch/powerpc/platforms/powernv/opal-irqchip.c:133).
128
129 static irqreturn_t opal_interrupt(int irq, void *data)
130 {
131 __be64 events;
132
133 opal_handle_interrupt(virq_to_hw(irq), &events);
134 last_outstanding_events = be64_to_cpu(events);
135 if (opal_have_pending_events())
136 opal_wake_poller();
137
trace:
bnx2x 0008:01:00.3 enP8p1s0f3: renamed from eth0
bnx2x 0008:01:00.3 enP8p1s0f3: using MSI-X IRQs: sp 297 fp[0] 299 ... fp[7] 306
bnx2x 0008:01:00.2 enP8p1s0f2: NIC Link is Up, 1000 Mbps full duplex, Flow control: none
bnx2x 0008:01:00.3 enP8p1s0f3: NIC Link is Up, 1000 Mbps full duplex, Flow control: none
bnx2x: QLogic 5771x/578xx 10/20-Gigabit Ethernet Driver bnx2x 1.712.30-0 (2014/02/10)
bnx2x 0008:01:00.0: msix capability found
bnx2x 0008:01:00.0: Using 64-bit DMA iommu bypass
bnx2x 0008:01:00.0: part number 0-0-0-0
bnx2x 0008:01:00.0: 32.000 Gb/s available PCIe bandwidth (5 GT/s x8 link)
bnx2x 0008:01:00.0 enP8p1s0f0: renamed from eth0
bnx2x 0008:01:00.1: msix capability found
bnx2x 0008:01:00.1: Using 64-bit DMA iommu bypass
bnx2x 0008:01:00.1: part number 0-0-0-0
bnx2x 0008:01:00.0 enP8p1s0f0: using MSI-X IRQs: sp 267 fp[0] 269 ... fp[7] 276
bnx2x 0008:01:00.0 enP8p1s0f0: NIC Link is Up, 10000 Mbps full duplex, Flow control: ON - receive & transmit
bnx2x 0008:01:00.1: 32.000 Gb/s available PCIe bandwidth (5 GT/s x8 link)
bnx2x 0008:01:00.1 enP8p1s0f1: renamed from eth0
bnx2x 0008:01:00.2: msix capability found
bnx2x 0008:01:00.2: Using 64-bit DMA iommu bypass
bnx2x 0008:01:00.2: part number 0-0-0-0
bnx2x 0008:01:00.1 enP8p1s0f1: using MSI-X IRQs: sp 277 fp[0] 279 ... fp[7] 286
bnx2x 0008:01:00.1 enP8p1s0f1: NIC Link is Up, 10000 Mbps full duplex, Flow control: ON - receive & transmit
watchdog: CPU 80 self-detected hard LOCKUP @ opal_interrupt+0x28/0x70
watchdog: CPU 80 TB:980794111093, last heartbeat TB:973959617200 (13348ms ago)
Modules linked in: bnx2x(+) iptable_mangle ipt_MASQUERADE iptable_nat
nf_nat_ipv4 nf_nat xt_conntrack nf_conntrack nf_defrag_ipv4 ipt_REJECT
nf_reject_ipv4 xt_tcpudp tun bridge stp llc iptable_filter dm_mirror
dm_region_hash dm_log dm_service_time vmx_crypto powernv_rng rng_core
dm_multipath kvm_hv kvm binfmt_misc nfsd ip_tables x_tables autofs4 xfs
lpfc crc_t10dif crct10dif_generic nvme_fc nvme_fabrics mdio libcrc32c
nvme_core crct10dif_common [last unloaded: bnx2x]
CPU: 80 PID: 0 Comm: swapper/80 Not tainted 4.19.0-rc4-autotest-autotest #1
NIP: c00000000009d048 LR: c000000000092fd0 CTR: 0000000030032a00
REGS: c000003fff493d80 TRAP: 0900 Not tainted (4.19.0-rc4-autotest-autotest)
MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 48004042 XER: 00000000
CFAR: c000000000092fbc IRQMASK: 1
GPR00: 0000000030005128 c000003fff70f220 c0000000010ae500 0000000000000000
GPR04: 0000000048004042 c00000000009d048 9000000000009033 0000000000000090
GPR08: 0000000000000000 0000000000000000 c000000000092fe4 9000000000001003
GPR12: c000000000092fbc c000003fff7ff300 c000003c96c80c00 0000000000010000
GPR16: 0000000000000000 000000000000003c c000003c96c80800 c000003c96d00700
GPR20: 0000000000000001 0000000000000001 0000000000000002 0000000000000014
GPR24: c000001fe8741000 c000003fff70f330 0000000000000000 c000003ca947fb40
GPR28: 00000000092f47d0 0000000000000014 c000001fe8741000 c000001fe9860200
NIP [c00000000009d048] opal_interrupt+0x28/0x70
LR [c000000000092fd0] opal_return+0x14/0x48
Call Trace:
[c000003fff70f220] [c00000000009d048] opal_interrupt+0x28/0x70 (unreliable)
[c000003fff70f250] [c00000000016d890] __handle_irq_event_percpu+0x90/0x2d0
[c000003fff70f310] [c00000000016db00] handle_irq_event_percpu+0x30/0x90
[c000003fff70f350] [c00000000016dbc0] handle_irq_event+0x60/0xc0
[c000003fff70f380] [c000000000172d2c] handle_fasteoi_irq+0xbc/0x1f0
[c000003fff70f3b0] [c00000000016c084] generic_handle_irq+0x44/0x70
[c000003fff70f3d0] [c0000000000193cc] __do_irq+0x8c/0x200
[c000003fff70f440] [c000000000019640] do_IRQ+0x100/0x110
[c000003fff70f490] [c000000000008db8] hardware_interrupt_common+0x158/0x160
--- interrupt: 501 at fib_table_lookup+0xfc/0x600
LR = fib_validate_source+0x148/0x370
[c000003fff70f780] [0000000000000000] (null) (unreliable)
[c000003fff70f7e0] [c000000000959af8] fib_validate_source+0x148/0x370
[c000003fff70f8a0] [c0000000008fd664] ip_route_input_rcu+0x214/0x970
[c000003fff70f990] [c0000000008fdde0] ip_route_input_noref+0x20/0x30
[c000003fff70f9e0] [c000000000945e28] arp_process.constprop.14+0x3d8/0x8a0
[c000003fff70faf0] [c00000000089eb20] __netif_receive_skb_one_core+0x60/0x80
[c000003fff70fb30] [c0000000008a7d00] netif_receive_skb_internal+0x30/0x110
[c000003fff70fb70] [c0000000008a888c] napi_gro_receive+0x11c/0x1c0
[c000003fff70fbb0] [c000000000702afc] tg3_poll_work+0x5fc/0x1060
[c000003fff70fcb0] [c0000000007035b4] tg3_poll_msix+0x54/0x210
[c000003fff70fd00] [c0000000008a922c] net_rx_action+0x31c/0x470
[c000003fff70fe10] [c0000000009f5afc] __do_softirq+0x15c/0x3b4
[c000003fff70ff00] [c0000000000fddf0] irq_exit+0x100/0x120
[c000003fff70ff20] [c0000000000193d8] __do_irq+0x98/0x200
[c000003fff70ff90] [c00000000002af24] call_do_irq+0x14/0x24
[c000003ca947fa80] [c0000000000195d4] do_IRQ+0x94/0x110
[c000003ca947fad0] [c000000000008db8] hardware_interrupt_common+0x158/0x160
--- interrupt: 501 at replay_interrupt_return+0x0/0x4
LR = arch_local_irq_restore+0x84/0x90
[c000003ca947fdc0] [0000000000080000] 0x80000 (unreliable)
[c000003ca947fde0] [c000000000181f60] rcu_idle_exit+0xa0/0xd0
[c000003ca947fe30] [c000000000136d08] do_idle+0x1c8/0x3a0
[c000003ca947fec0] [c0000000001370b4] cpu_startup_entry+0x34/0x40
[c000003ca947fef0] [c0000000000467f4] start_secondary+0x4d4/0x520
[c000003ca947ff90] [c00000000000b270] start_secondary_prolog+0x10/0x14
Instruction dump:
60000000 60420000 3c4c0101 384214e0 7c0802a6 78630020 f8010010 f821ffd1
4bf7b901 60000000 38810020 4bff657d <60000000> 39010020 3d42ffed e94a5d28
watchdog: CPU 80 became unstuck TB:980802789270
CPU: 80 PID: 412 Comm: ksoftirqd/80 Not tainted 4.19.0-rc4-autotest-autotest #1
Call Trace:
[c000003ca96f7910] [c0000000009d4cec] dump_stack+0xb0/0xf4 (unreliable)
[c000003ca96f7950] [c00000000002f278] wd_smp_clear_cpu_pending+0x368/0x3f0
[c000003ca96f7a10] [c00000000002fa48] wd_timer_fn+0x78/0x3a0
[c000003ca96f7ad0] [c00000000018a3c0] call_timer_fn+0x50/0x1b0
[c000003ca96f7b50] [c00000000018a658] expire_timers+0x138/0x1e0
[c000003ca96f7bc0] [c00000000018a7c8] run_timer_softirq+0xc8/0x220
[c000003ca96f7c50] [c0000000009f5afc] __do_softirq+0x15c/0x3b4
[c000003ca96f7d40] [c0000000000fdab4] run_ksoftirqd+0x54/0x80
[c000003ca96f7d60] [c000000000126f10] smpboot_thread_fn+0x290/0x2a0
[c000003ca96f7dc0] [c0000000001215ac] kthread+0x15c/0x1a0
[c000003ca96f7e30] [c00000000000bdd4] ret_from_kernel_thread+0x5c/0x68
bnx2x 0008:01:00.2: 32.000 Gb/s available PCIe bandwidth (5 GT/s x8 link)
bnx2x 0008:01:00.2 enP8p1s0f2: renamed from eth0
bnx2x 0008:01:00.3: msix capability found
bnx2x 0008:01:00.3: Using 64-bit DMA iommu bypass
bnx2x 0008:01:00.3: part number 0-0-0-0
bnx2x 0008:01:00.3: 32.000 Gb/s available PCIe bandwidth (5 GT/s x8 link)
bnx2x 0008:01:00.3 enP8p1s0f3: renamed from eth0
--
Regard's
Abdul Haleem
IBM Linux Technology Centre
^ permalink raw reply
* Re: [PATCH net-next] dt-bindings: net: ravb: Add support for r8a7744 SoC
From: Geert Uytterhoeven @ 2018-09-24 9:26 UTC (permalink / raw)
To: Biju Das
Cc: Rob Herring, Mark Rutland, Sergei Shtylyov, David S. Miller,
Geert Uytterhoeven, Simon Horman, Fabrizio Castro, Jacopo Mondi,
Yoshihiro Shimoda, netdev, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Simon Horman, Chris Paterson
In-Reply-To: <1537539943-24712-1-git-send-email-biju.das@bp.renesas.com>
On Fri, Sep 21, 2018 at 4:32 PM Biju Das <biju.das@bp.renesas.com> wrote:
> Document RZ/G1N (R8A7744) SoC bindings.
>
> Signed-off-by: Biju Das <biju.das@bp.renesas.com>
> Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
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
* pull-request: bpf 2018-09-24
From: Daniel Borkmann @ 2018-09-24 9:31 UTC (permalink / raw)
To: davem; +Cc: daniel, ast, netdev
Hi David,
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) Several fixes for BPF sockmap to only allow sockets being attached in
ESTABLISHED state, from John.
2) Fix up the license to LGPL/BSD for the libc compat header which contains
fallback helpers that libbpf and bpftool is using, from Jakub.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit 69ba423d35c25ae06fa419ac1d4f6c4e2b74e412:
Merge branch 'ipv6-fix-issues-on-accessing-fib6_metrics' (2018-09-18 20:17:01 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
for you to fetch changes up to fad0c40fab14523ca381a30fef88b7c3266bef1c:
Merge branch 'bpf-sockmap-estab-fixes' (2018-09-22 02:46:43 +0200)
----------------------------------------------------------------
Daniel Borkmann (1):
Merge branch 'bpf-sockmap-estab-fixes'
Jakub Kicinski (1):
tools: bpf: fix license for a compat header file
John Fastabend (3):
bpf: sockmap only allow ESTABLISHED sock state
bpf: sockmap, fix transition through disconnect without close
bpf: test_maps, only support ESTABLISHED socks
kernel/bpf/sockmap.c | 91 +++++++++++++++++++++++++--------
tools/include/tools/libc_compat.h | 2 +-
tools/testing/selftests/bpf/test_maps.c | 10 ++--
3 files changed, 79 insertions(+), 24 deletions(-)
^ permalink raw reply
* Re: [PATCH net] net: mvneta: fix the remaining Rx descriptor unmapping issues
From: Gregory CLEMENT @ 2018-09-24 15:37 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, yelena, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw
In-Reply-To: <20180924145613.27307-1-antoine.tenart@bootlin.com>
Hi Antoine,
On lun., sept. 24 2018, Antoine Tenart <antoine.tenart@bootlin.com> wrote:
> With CONFIG_DMA_API_DEBUG enabled we get DMA unmapping warning in
> various places of the mvneta driver, for example when putting down an
> interface while traffic is passing through.
>
> The issue is when using s/w buffer management, the Rx buffers are mapped
> using dma_map_page but unmapped with dma_unmap_single. This patch fixes
> this by using the right unmapping function.
>
> Fixes: 562e2f467e71 ("net: mvneta: Improve the buffer allocation method for SWBM")
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Given the clarification provided by Yelen, this patch looks good:
Reviewed-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Thanks,
Gregory
> ---
> drivers/net/ethernet/marvell/mvneta.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index 2db9708f2e24..b4ed7d394d07 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -1890,8 +1890,8 @@ static void mvneta_rxq_drop_pkts(struct mvneta_port *pp,
> if (!data || !(rx_desc->buf_phys_addr))
> continue;
>
> - dma_unmap_single(pp->dev->dev.parent, rx_desc->buf_phys_addr,
> - MVNETA_RX_BUF_SIZE(pp->pkt_size), DMA_FROM_DEVICE);
> + dma_unmap_page(pp->dev->dev.parent, rx_desc->buf_phys_addr,
> + PAGE_SIZE, DMA_FROM_DEVICE);
> __free_page(data);
> }
> }
> @@ -2039,9 +2039,8 @@ static int mvneta_rx_swbm(struct napi_struct *napi,
> frag_offset, frag_size,
> PAGE_SIZE);
>
> - dma_unmap_single(dev->dev.parent, phys_addr,
> - PAGE_SIZE,
> - DMA_FROM_DEVICE);
> + dma_unmap_page(dev->dev.parent, phys_addr,
> + PAGE_SIZE, DMA_FROM_DEVICE);
>
> rxq->left_size -= frag_size;
> }
> --
> 2.17.1
>
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com
^ 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