* [PATCH 2/7] netfilter: nft_compat: make lists per netns
From: Pablo Neira Ayuso @ 2019-01-28 14:04 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20190128140405.15020-1-pablo@netfilter.org>
From: Florian Westphal <fw@strlen.de>
There are two problems with nft_compat since the netlink config
plane uses a per-netns mutex:
1. Concurrent add/del accesses to the same list
2. accesses to a list element after it has been free'd already.
This patch fixes the first problem.
Freeing occurs from a work queue, after transaction mutexes have been
released, i.e., it still possible for a new transaction (even from
same net ns) to find the to-be-deleted expression in the list.
The ->destroy functions are not allowed to have any such side effects,
i.e. the list_del() in the destroy function is not allowed.
This part of the problem is solved in the next patch.
I tried to make this work by serializing list access via mutex
and by moving list_del() to a deactivate callback, but
Taehee spotted following race on this approach:
NET #0 NET #1
>select_ops()
->init()
->select_ops()
->deactivate()
->destroy()
nft_xt_put()
kfree_rcu(xt, rcu_head);
->init() <-- use-after-free occurred.
Unfortunately, we can't increment reference count in
select_ops(), because we can't undo the refcount increase in
case a different expression fails in the same batch.
(The destroy hook will only be called in case the expression
was initialized successfully).
Fixes: f102d66b335a ("netfilter: nf_tables: use dedicated mutex to guard transactions")
Reported-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nft_compat.c | 129 +++++++++++++++++++++++++++++++--------------
1 file changed, 89 insertions(+), 40 deletions(-)
diff --git a/net/netfilter/nft_compat.c b/net/netfilter/nft_compat.c
index acc85acad31b..abed3490a8f8 100644
--- a/net/netfilter/nft_compat.c
+++ b/net/netfilter/nft_compat.c
@@ -22,6 +22,7 @@
#include <linux/netfilter_bridge/ebtables.h>
#include <linux/netfilter_arp/arp_tables.h>
#include <net/netfilter/nf_tables.h>
+#include <net/netns/generic.h>
struct nft_xt {
struct list_head head;
@@ -43,6 +44,20 @@ struct nft_xt_match_priv {
void *info;
};
+struct nft_compat_net {
+ struct list_head nft_target_list;
+ struct list_head nft_match_list;
+};
+
+static unsigned int nft_compat_net_id __read_mostly;
+static struct nft_expr_type nft_match_type;
+static struct nft_expr_type nft_target_type;
+
+static struct nft_compat_net *nft_compat_pernet(struct net *net)
+{
+ return net_generic(net, nft_compat_net_id);
+}
+
static bool nft_xt_put(struct nft_xt *xt)
{
if (refcount_dec_and_test(&xt->refcnt)) {
@@ -734,10 +749,6 @@ static const struct nfnetlink_subsystem nfnl_compat_subsys = {
.cb = nfnl_nft_compat_cb,
};
-static LIST_HEAD(nft_match_list);
-
-static struct nft_expr_type nft_match_type;
-
static bool nft_match_cmp(const struct xt_match *match,
const char *name, u32 rev, u32 family)
{
@@ -749,6 +760,7 @@ static const struct nft_expr_ops *
nft_match_select_ops(const struct nft_ctx *ctx,
const struct nlattr * const tb[])
{
+ struct nft_compat_net *cn;
struct nft_xt *nft_match;
struct xt_match *match;
unsigned int matchsize;
@@ -765,8 +777,10 @@ nft_match_select_ops(const struct nft_ctx *ctx,
rev = ntohl(nla_get_be32(tb[NFTA_MATCH_REV]));
family = ctx->family;
+ cn = nft_compat_pernet(ctx->net);
+
/* Re-use the existing match if it's already loaded. */
- list_for_each_entry(nft_match, &nft_match_list, head) {
+ list_for_each_entry(nft_match, &cn->nft_match_list, head) {
struct xt_match *match = nft_match->ops.data;
if (nft_match_cmp(match, mt_name, rev, family))
@@ -810,7 +824,7 @@ nft_match_select_ops(const struct nft_ctx *ctx,
nft_match->ops.size = matchsize;
- list_add(&nft_match->head, &nft_match_list);
+ list_add(&nft_match->head, &cn->nft_match_list);
return &nft_match->ops;
err:
@@ -826,10 +840,6 @@ static struct nft_expr_type nft_match_type __read_mostly = {
.owner = THIS_MODULE,
};
-static LIST_HEAD(nft_target_list);
-
-static struct nft_expr_type nft_target_type;
-
static bool nft_target_cmp(const struct xt_target *tg,
const char *name, u32 rev, u32 family)
{
@@ -841,6 +851,7 @@ static const struct nft_expr_ops *
nft_target_select_ops(const struct nft_ctx *ctx,
const struct nlattr * const tb[])
{
+ struct nft_compat_net *cn;
struct nft_xt *nft_target;
struct xt_target *target;
char *tg_name;
@@ -861,8 +872,9 @@ nft_target_select_ops(const struct nft_ctx *ctx,
strcmp(tg_name, "standard") == 0)
return ERR_PTR(-EINVAL);
+ cn = nft_compat_pernet(ctx->net);
/* Re-use the existing target if it's already loaded. */
- list_for_each_entry(nft_target, &nft_target_list, head) {
+ list_for_each_entry(nft_target, &cn->nft_target_list, head) {
struct xt_target *target = nft_target->ops.data;
if (!target->target)
@@ -907,7 +919,7 @@ nft_target_select_ops(const struct nft_ctx *ctx,
else
nft_target->ops.eval = nft_target_eval_xt;
- list_add(&nft_target->head, &nft_target_list);
+ list_add(&nft_target->head, &cn->nft_target_list);
return &nft_target->ops;
err:
@@ -923,13 +935,74 @@ static struct nft_expr_type nft_target_type __read_mostly = {
.owner = THIS_MODULE,
};
+static int __net_init nft_compat_init_net(struct net *net)
+{
+ struct nft_compat_net *cn = nft_compat_pernet(net);
+
+ INIT_LIST_HEAD(&cn->nft_target_list);
+ INIT_LIST_HEAD(&cn->nft_match_list);
+
+ return 0;
+}
+
+static void __net_exit nft_compat_exit_net(struct net *net)
+{
+ struct nft_compat_net *cn = nft_compat_pernet(net);
+ struct nft_xt *xt, *next;
+
+ if (list_empty(&cn->nft_match_list) &&
+ list_empty(&cn->nft_target_list))
+ return;
+
+ /* If there was an error that caused nft_xt expr to not be initialized
+ * fully and noone else requested the same expression later, the lists
+ * contain 0-refcount entries that still hold module reference.
+ *
+ * Clean them here.
+ */
+ mutex_lock(&net->nft.commit_mutex);
+ list_for_each_entry_safe(xt, next, &cn->nft_target_list, head) {
+ struct xt_target *target = xt->ops.data;
+
+ list_del_init(&xt->head);
+
+ if (refcount_read(&xt->refcnt))
+ continue;
+ module_put(target->me);
+ kfree(xt);
+ }
+
+ list_for_each_entry_safe(xt, next, &cn->nft_match_list, head) {
+ struct xt_match *match = xt->ops.data;
+
+ list_del_init(&xt->head);
+
+ if (refcount_read(&xt->refcnt))
+ continue;
+ module_put(match->me);
+ kfree(xt);
+ }
+ mutex_unlock(&net->nft.commit_mutex);
+}
+
+static struct pernet_operations nft_compat_net_ops = {
+ .init = nft_compat_init_net,
+ .exit = nft_compat_exit_net,
+ .id = &nft_compat_net_id,
+ .size = sizeof(struct nft_compat_net),
+};
+
static int __init nft_compat_module_init(void)
{
int ret;
+ ret = register_pernet_subsys(&nft_compat_net_ops);
+ if (ret < 0)
+ goto err_target;
+
ret = nft_register_expr(&nft_match_type);
if (ret < 0)
- return ret;
+ goto err_pernet;
ret = nft_register_expr(&nft_target_type);
if (ret < 0)
@@ -942,45 +1015,21 @@ static int __init nft_compat_module_init(void)
}
return ret;
-
err_target:
nft_unregister_expr(&nft_target_type);
err_match:
nft_unregister_expr(&nft_match_type);
+err_pernet:
+ unregister_pernet_subsys(&nft_compat_net_ops);
return ret;
}
static void __exit nft_compat_module_exit(void)
{
- struct nft_xt *xt, *next;
-
- /* list should be empty here, it can be non-empty only in case there
- * was an error that caused nft_xt expr to not be initialized fully
- * and noone else requested the same expression later.
- *
- * In this case, the lists contain 0-refcount entries that still
- * hold module reference.
- */
- list_for_each_entry_safe(xt, next, &nft_target_list, head) {
- struct xt_target *target = xt->ops.data;
-
- if (WARN_ON_ONCE(refcount_read(&xt->refcnt)))
- continue;
- module_put(target->me);
- kfree(xt);
- }
-
- list_for_each_entry_safe(xt, next, &nft_match_list, head) {
- struct xt_match *match = xt->ops.data;
-
- if (WARN_ON_ONCE(refcount_read(&xt->refcnt)))
- continue;
- module_put(match->me);
- kfree(xt);
- }
nfnetlink_subsys_unregister(&nfnl_compat_subsys);
nft_unregister_expr(&nft_target_type);
nft_unregister_expr(&nft_match_type);
+ unregister_pernet_subsys(&nft_compat_net_ops);
}
MODULE_ALIAS_NFNL_SUBSYS(NFNL_SUBSYS_NFT_COMPAT);
--
2.11.0
^ permalink raw reply related
* [PATCH 1/7] netfilter: nft_compat: use refcnt_t type for nft_xt reference count
From: Pablo Neira Ayuso @ 2019-01-28 14:03 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20190128140405.15020-1-pablo@netfilter.org>
From: Florian Westphal <fw@strlen.de>
Using standard integer type was fine while all operations on it were
guarded by the nftnl subsys mutex.
This isn't true anymore:
1. transactions are guarded only by a pernet mutex, so concurrent
rule manipulation in different netns is racy
2. the ->destroy hook runs from a work queue after the transaction
mutex has been released already.
cpu0 cpu1 (net 1) cpu2 (net 2)
kworker
nft_compat->destroy nft_compat->init nft_compat->init
if (--nft_xt->ref == 0) nft_xt->ref++ nft_xt->ref++
Switch to refcount_t. Doing this however only fixes a minor aspect,
nft_compat also performs linked-list operations in an unsafe way.
This is addressed in the next two patches.
Fixes: f102d66b335a ("netfilter: nf_tables: use dedicated mutex to guard transactions")
Fixes: 0935d5588400 ("netfilter: nf_tables: asynchronous release")
Reported-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nft_compat.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/net/netfilter/nft_compat.c b/net/netfilter/nft_compat.c
index 7334e0b80a5e..acc85acad31b 100644
--- a/net/netfilter/nft_compat.c
+++ b/net/netfilter/nft_compat.c
@@ -26,7 +26,7 @@
struct nft_xt {
struct list_head head;
struct nft_expr_ops ops;
- unsigned int refcnt;
+ refcount_t refcnt;
/* Unlike other expressions, ops doesn't have static storage duration.
* nft core assumes they do. We use kfree_rcu so that nft core can
@@ -45,7 +45,7 @@ struct nft_xt_match_priv {
static bool nft_xt_put(struct nft_xt *xt)
{
- if (--xt->refcnt == 0) {
+ if (refcount_dec_and_test(&xt->refcnt)) {
list_del(&xt->head);
kfree_rcu(xt, rcu_head);
return true;
@@ -273,7 +273,7 @@ nft_target_init(const struct nft_ctx *ctx, const struct nft_expr *expr,
return -EINVAL;
nft_xt = container_of(expr->ops, struct nft_xt, ops);
- nft_xt->refcnt++;
+ refcount_inc(&nft_xt->refcnt);
return 0;
}
@@ -486,7 +486,7 @@ __nft_match_init(const struct nft_ctx *ctx, const struct nft_expr *expr,
return ret;
nft_xt = container_of(expr->ops, struct nft_xt, ops);
- nft_xt->refcnt++;
+ refcount_inc(&nft_xt->refcnt);
return 0;
}
@@ -789,7 +789,7 @@ nft_match_select_ops(const struct nft_ctx *ctx,
goto err;
}
- nft_match->refcnt = 0;
+ refcount_set(&nft_match->refcnt, 0);
nft_match->ops.type = &nft_match_type;
nft_match->ops.eval = nft_match_eval;
nft_match->ops.init = nft_match_init;
@@ -893,7 +893,7 @@ nft_target_select_ops(const struct nft_ctx *ctx,
goto err;
}
- nft_target->refcnt = 0;
+ refcount_set(&nft_target->refcnt, 0);
nft_target->ops.type = &nft_target_type;
nft_target->ops.size = NFT_EXPR_SIZE(XT_ALIGN(target->targetsize));
nft_target->ops.init = nft_target_init;
@@ -964,7 +964,7 @@ static void __exit nft_compat_module_exit(void)
list_for_each_entry_safe(xt, next, &nft_target_list, head) {
struct xt_target *target = xt->ops.data;
- if (WARN_ON_ONCE(xt->refcnt))
+ if (WARN_ON_ONCE(refcount_read(&xt->refcnt)))
continue;
module_put(target->me);
kfree(xt);
@@ -973,7 +973,7 @@ static void __exit nft_compat_module_exit(void)
list_for_each_entry_safe(xt, next, &nft_match_list, head) {
struct xt_match *match = xt->ops.data;
- if (WARN_ON_ONCE(xt->refcnt))
+ if (WARN_ON_ONCE(refcount_read(&xt->refcnt)))
continue;
module_put(match->me);
kfree(xt);
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next v8 4/8] devlink: Add support for driverinit get value for devlink_port
From: Jiri Pirko @ 2019-01-28 14:02 UTC (permalink / raw)
To: Vasundhara Volam
Cc: davem, michael.chan, jiri, jakub.kicinski, mkubecek, netdev
In-Reply-To: <1548678627-21938-5-git-send-email-vasundhara-v.volam@broadcom.com>
Mon, Jan 28, 2019 at 01:30:23PM CET, vasundhara-v.volam@broadcom.com wrote:
>Add support for "driverinit" configuration mode value for devlink_port
>configuration parameters. Add devlink_port_param_driverinit_value_get()
>function to help the driver get the value from devlink_port.
>
>Also, move the common code to __devlink_param_driverinit_value_get()
>to be used by both device and port params.
>
>v7->v8:
>-Add the missing devlink_port_param_driverinit_value_get() declaration.
>-Also, order devlink_port_param_driverinit_value_get() after
>devlink_param_driverinit_value_get/set() calls
>
>Cc: Jiri Pirko <jiri@mellanox.com>
>Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next v8 5/8] devlink: Add support for driverinit set value for devlink_port
From: Jiri Pirko @ 2019-01-28 14:11 UTC (permalink / raw)
To: Vasundhara Volam
Cc: davem, michael.chan, jiri, jakub.kicinski, mkubecek, netdev
In-Reply-To: <1548678627-21938-6-git-send-email-vasundhara-v.volam@broadcom.com>
Mon, Jan 28, 2019 at 01:30:24PM CET, vasundhara-v.volam@broadcom.com wrote:
>Add support for "driverinit" configuration mode value for devlink_port
>configuration parameters. Add devlink_port_param_driverinit_value_set()
>function to help the driver set the value to devlink_port.
>
>Also, move the common code to __devlink_param_driverinit_value_set()
>to be used by both device and port params.
>
>v7->v8:
>Re-order the definitions as follows:
>__devlink_param_driverinit_value_get
>__devlink_param_driverinit_value_set
>devlink_param_driverinit_value_get
>devlink_param_driverinit_value_set
>devlink_port_param_driverinit_value_get
>devlink_port_param_driverinit_value_set
>
>Cc: Jiri Pirko <jiri@mellanox.com>
>Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 5/7] net: phy: marvell10g: Force reading of 2.5/5G PMA extended abilities
From: Maxime Chevallier @ 2019-01-28 14:26 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, davem, netdev, linux-kernel, Florian Fainelli,
Heiner Kallweit, linux-arm-kernel, Antoine Tenart,
thomas.petazzoni, gregory.clement, miquel.raynal, nadavh, stefanc,
mw
In-Reply-To: <20190121130030.i5kkjb55gwttobvq@e5254000004ec.dyn.armlinux.org.uk>
Hello Russell,
On Mon, 21 Jan 2019 13:00:30 +0000
Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
>On Mon, Jan 21, 2019 at 01:29:45PM +0100, Maxime Chevallier wrote:
>> Hello Russell,
>>
>> On Mon, 21 Jan 2019 10:52:06 +0000
>> Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
>> >It's entirely possible that the 3310 switches to different hardware
>> >blocks for 2.5G and 5G speeds, and reading _just_ the 1.4 register
>> >is not sufficient.
>>
>> I agree with you but in that particular case, I think we are reading
>> from the correct device. The datasheet itself says that we should be
>> reading 1.4 and 1.11 as we expect, with 2.5G/5G support being set (these
>> registers are read-only, and the datasheet's values aren't what we
>> actually read).
>
>No, you missed what I was saying.
>
>The 88x3310 is a hybrid device. It contains multiple instances of
>each individual device at different offsets in each MMD address space.
Ah I see, I indeed thought you refered to the MMDs.
[...]
>The exception seems to be the PMA/PMD MMD which I've only discovered
>a single instance.
Yes there only seems to be one. There are some other registers in the
1.0xCxxx range, but those who are documented don't help a lot with
determing wether or not these modes are supported.
I wonder if these values are correctly reported in newer PHY firmware
revisions.
I've checked other PCS instances, but it seems the one at 3.0x0xxx is
the one used in 2.5/5GBASET.
I've tested with other PHYs from this family, it looks like they are
derivatives of the 33x0 design, with the addition/removal of internal
IPs. Since the 2110 returns the correct values and has a similar
design, with the PMA returning the correct abilities, I think we are
reading from the correct instance.
Thanks,
Maxime
--
Maxime Chevallier, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net-next v8 6/8] devlink: Add devlink notifications support for port params
From: Jiri Pirko @ 2019-01-28 14:23 UTC (permalink / raw)
To: Vasundhara Volam
Cc: davem, michael.chan, jiri, jakub.kicinski, mkubecek, netdev
In-Reply-To: <1548678627-21938-7-git-send-email-vasundhara-v.volam@broadcom.com>
Mon, Jan 28, 2019 at 01:30:25PM CET, vasundhara-v.volam@broadcom.com wrote:
>Add notification call for devlink port param set, register and unregister
>functions.
>Add devlink_port_param_value_changed() function to enable the driver notify
>devlink on value change. Driver should use this function after value was
>changed on any configuration mode part to driverinit.
>
>v7->v8:
>Order devlink_port_param_value_changed() definitions followed by
>devlink_param_value_changed()
>
>Cc: Jiri Pirko <jiri@mellanox.com>
>Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH] ucc_geth: Reset BQL queue when stopping device
From: Mathias Thore @ 2019-01-28 14:36 UTC (permalink / raw)
To: Christophe Leroy, leoyang.li@nxp.com, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, David Gounaris, Joakim Tjernlund
In-Reply-To: <6bc7e64a-b91a-cb6e-ed65-5e412cef3a76@c-s.fr>
Hi,
This is what we observed: there was a storm on the medium so that our controller could not do its TX, resulting in timeout. When timeout occurs, the driver clears all descriptors from the TX queue. The function called in this patch is used to reflect this clearing also in the BQL layer. Without it, the controller would get stuck, unable to perform TX, even several minutes after the storm had ended. Bringing the device down and then up again would solve the problem, but this patch also solves it automatically.
Some other drivers do the same, for example e1000e driver calls netdev_reset_queue in its e1000_clean_tx_ring function. It is possible that other drivers should do the same; I have no way of verifying this.
Regards,
Mathias
--
From: Christophe Leroy <christophe.leroy@c-s.fr>
Sent: Monday, January 28, 2019 10:48 AM
To: Mathias Thore; leoyang.li@nxp.com; netdev@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; David Gounaris; Joakim Tjernlund
Subject: Re: [PATCH] ucc_geth: Reset BQL queue when stopping device
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi,
Le 28/01/2019 à 10:07, Mathias Thore a écrit :
> After a timeout event caused by for example a broadcast storm, when
> the MAC and PHY are reset, the BQL TX queue needs to be reset as
> well. Otherwise, the device will exhibit severe performance issues
> even after the storm has ended.
What are the symptomns ?
Is this reset needed on any network driver in that case, or is it
something particular for the ucc_geth ?
For instance, the freescale fs_enet doesn't have that reset. Should it
have it too ?
Christophe
>
> Co-authored-by: David Gounaris <david.gounaris@infinera.com>
> Signed-off-by: Mathias Thore <mathias.thore@infinera.com>
> ---
> drivers/net/ethernet/freescale/ucc_geth.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
> index c3d539e209ed..eb3e65e8868f 100644
> --- a/drivers/net/ethernet/freescale/ucc_geth.c
> +++ b/drivers/net/ethernet/freescale/ucc_geth.c
> @@ -1879,6 +1879,8 @@ static void ucc_geth_free_tx(struct ucc_geth_private *ugeth)
> u16 i, j;
> u8 __iomem *bd;
>
> + netdev_reset_queue(ugeth->ndev);
> +
> ug_info = ugeth->ug_info;
> uf_info = &ug_info->uf_info;
>
>
^ permalink raw reply
* Re: [PATCH net-next] mdio_bus: Fix PTR_ERR() usage after initialization to constant
From: Andrew Lunn @ 2019-01-28 14:36 UTC (permalink / raw)
To: YueHaibing; +Cc: davem, f.fainelli, hkallweit1, linux-kernel, netdev
In-Reply-To: <20190128132409.17736-1-yuehaibing@huawei.com>
On Mon, Jan 28, 2019 at 09:24:09PM +0800, YueHaibing wrote:
> Fix coccinelle warning:
>
> ./drivers/net/phy/mdio_bus.c:51:5-12: ERROR: PTR_ERR applied after initialization to constant on line 44
> ./drivers/net/phy/mdio_bus.c:52:5-12: ERROR: PTR_ERR applied after initialization to constant on line 44
>
> fix this by using IS_ERR before PTR_ERR
>
> Fixes: bafbdd527d56 ("phylib: Add device reset GPIO support")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/net/phy/mdio_bus.c | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index 3d31358..802716a 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -42,17 +42,20 @@
> static int mdiobus_register_gpiod(struct mdio_device *mdiodev)
> {
> struct gpio_desc *gpiod = NULL;
> + int ret;
>
Hi YueHaibing
I think i prefer the simpler fix:
static int mdiobus_register_gpiod(struct mdio_device *mdiodev)
{
- struct gpio_desc *gpiod = NULL;
+ struct gpio_desc *gpiod = ERR_PTR(-ENOENT);
Totally untested...
Andrew
> /* Deassert the optional reset signal */
> if (mdiodev->dev.of_node)
> gpiod = fwnode_get_named_gpiod(&mdiodev->dev.of_node->fwnode,
> "reset-gpios", 0, GPIOD_OUT_LOW,
> "PHY reset");
> - if (PTR_ERR(gpiod) == -ENOENT ||
> - PTR_ERR(gpiod) == -ENOSYS)
> - gpiod = NULL;
> - else if (IS_ERR(gpiod))
> - return PTR_ERR(gpiod);
> + if (IS_ERR(gpiod)) {
> + ret = PTR_ERR(gpiod);
> + if (ret == -ENOENT || ret == -ENOSYS)
> + gpiod = NULL;
> + else
> + return ret;
> + }
>
> mdiodev->reset = gpiod;
>
> --
> 2.7.4
>
>
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] net: dsa: mv88e6xxx: Save switch rules
From: Miquel Raynal @ 2019-01-28 14:24 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, Vivien Didelot, David S. Miller, netdev,
linux-kernel, Thomas Petazzoni, Gregory Clement, Antoine Tenart,
Maxime Chevallier, Nadav Haklai
In-Reply-To: <c1421a5d-5f92-bb86-b5cc-9fa19a1c8d9f@gmail.com>
Hi Florian,
Florian Fainelli <f.fainelli@gmail.com> wrote on Fri, 25 Jan 2019
10:37:38 -0800:
> Hi Miquel,
>
> On 1/25/19 1:55 AM, Miquel Raynal wrote:
> > The user might apply a specific switch configuration, with specific
> > forwarding rules, VLAN, bridges, etc.
> >
> > During suspend to RAM the switch power will be turned off and the
> > switch will lost its configuration. In an attempt to bring S2RAM
> > support to the mv88e6xxx DSA, let's first save these rules in a
> > per-chip list thanks to the mv88e6xxx_add/del_xxx_rule()
> > helpers. These helpers are then called from various callbacks:
> > * mv88e6xxx_port_fdb_add/del()
> > * mv88e6xxx_port_mdb_add/del()
> > * mv88e6xxx_port_vlan_add/del()
> > * mv88e6xxx_port_bridge_join/leave()
> > * mv88e6xxx_crosschip_bridge_join/leave()
> >
> > To avoid recursion problems when replaying the rules, the content of
> > the above *_add()/*_join() callbacks has been moved in separate
> > helpers with a '_' prefix. Hence, each callback just calls the
> > corresponding helper and the corresponding *_add_xxx_rule().
>
> None of this should be done in the driver IMHO, because this is
> presumably applicable to all switch devices that lose their state during
> suspend/resume, so at best, this should be moved to the core DSA layer,
> but doing this means that we should also have a well established
> contract between the DSA layer and individual switch drivers as far as
> quiescing/saving/restoring state goes.
>
> By moving things to the core we can also more tightly control what data
> structures get used to represent e.g.: VLANs, FDBs, MDBs etc and
> possibly push/utilize caching into the original subsystem. For instance
> VLAN/bridge already do maintain caches of VLANs, so if we could somehow
> expose those, we would not bloat the kernel's memory footprint by having
> an additional layer to maintain with identical information.
So you suggest to move the intelligence of FDBs/MDBs in net/dsa/port.c,
is this right?
I don't see where VLAN and bridge information are cached, can you point
me to the relevant locations?
What about cross-chip bridges? There is nothing about them in
net/dsa/port.c. The implementation I see in the mv88e6xxx driver
only touches the PVT but I don't get whether we should handle this
calls like regular bridge-join/leave events or not (maybe they are
cached with regular bridge events?).
Thanks,
Miquèl
^ permalink raw reply
* [PATCH net V2] net: i825xx: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
From: Yang Wei @ 2019-01-28 14:42 UTC (permalink / raw)
To: netdev, davem; +Cc: andrew, Yang Wei
dev_consume_skb_irq() should be called in i596_interrupt() when skb
xmit done. It makes drop profiles(dropwatch, perf) more friendly.
Signed-off-by: Yang Wei <albin_yang@163.com>
---
drivers/net/ethernet/i825xx/82596.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/i825xx/82596.c b/drivers/net/ethernet/i825xx/82596.c
index d719668..855900a 100644
--- a/drivers/net/ethernet/i825xx/82596.c
+++ b/drivers/net/ethernet/i825xx/82596.c
@@ -1310,7 +1310,7 @@ static irqreturn_t i596_interrupt(int irq, void *dev_id)
dev->stats.tx_aborted_errors++;
}
- dev_kfree_skb_irq(skb);
+ dev_consume_skb_irq(skb);
tx_cmd->cmd.command = 0; /* Mark free */
break;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next v2 1/2] net: dsa: mv88e6xxx: Save switch rules
From: Andrew Lunn @ 2019-01-28 14:44 UTC (permalink / raw)
To: Miquel Raynal
Cc: Florian Fainelli, Vivien Didelot, David S. Miller, netdev,
linux-kernel, Thomas Petazzoni, Gregory Clement, Antoine Tenart,
Maxime Chevallier, Nadav Haklai
In-Reply-To: <20190128152456.212ae5ac@xps13>
> I don't see where VLAN and bridge information are cached, can you point
> me to the relevant locations?
Miquèl
The bridge should have all that information. You need to ask it to
enumerate the current configuration and replay it to the switch.
There might be something in the Mellanox driver you can copy? But i've
not looked, i'm just guessing.
We also need to think about how we are going to test this. There is a
lot of state information in a switch. So we are going to need some
pretty good tests to show we have recreated all of it.
Andrew
^ permalink raw reply
* RE: [PATCH 2/3] arm64: dts: renesas: r8a774a1: Add clkp2 clock to CAN nodes
From: Fabrizio Castro @ 2019-01-28 14:49 UTC (permalink / raw)
To: Simon Horman
Cc: Geert Uytterhoeven, Wolfgang Grandegger, Marc Kleine-Budde,
Rob Herring, Mark Rutland, Michael Turquette, Stephen Boyd,
David S. Miller, Magnus Damm, Geert Uytterhoeven, Chris Paterson,
Biju Das, linux-can@vger.kernel.org, netdev@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <20190128130111.t54jbcyx35fiymq6@verge.net.au>
> From: Simon Horman <horms@verge.net.au>
> Sent: 28 January 2019 13:01
> Subject: Re: [PATCH 2/3] arm64: dts: renesas: r8a774a1: Add clkp2 clock to CAN nodes
>
> On Fri, Jan 25, 2019 at 11:33:41AM +0000, Fabrizio Castro wrote:
> > Hello Simon,
> >
> > Thank you for your feedback!
> >
> > > From: Simon Horman <horms@verge.net.au>
> > > Sent: 24 January 2019 10:01
> > > Subject: Re: [PATCH 2/3] arm64: dts: renesas: r8a774a1: Add clkp2 clock to CAN nodes
> > >
> > > On Wed, Jan 23, 2019 at 12:18:45PM +0000, Fabrizio Castro wrote:
> > > > Hello Geert,
> > > >
> > > > Thank you for your feedback!
> > > >
> > > > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > > > Sent: 23 January 2019 12:08
> > > > > Subject: Re: [PATCH 2/3] arm64: dts: renesas: r8a774a1: Add clkp2 clock to CAN nodes
> > > > >
> > > > > Hi Fabrizio,
> > > > >
> > > > > On Wed, Jan 23, 2019 at 1:01 PM Fabrizio Castro
> > > > > <fabrizio.castro@bp.renesas.com> wrote:
> > > > > > > From: Simon Horman <horms@verge.net.au>
> > > > > > > Sent: 23 January 2019 11:38
> > > > > > > Subject: Re: [PATCH 2/3] arm64: dts: renesas: r8a774a1: Add clkp2 clock to CAN nodes
> > > > > > >
> > > > > > > On Wed, Jan 23, 2019 at 10:51:23AM +0100, Simon Horman wrote:
> > > > > > > > On Fri, Jan 18, 2019 at 01:13:53PM +0100, Simon Horman wrote:
> > > > > > > > > On Thu, Jan 17, 2019 at 02:54:15PM +0000, Fabrizio Castro wrote:
> > > > > > > > > > According to the latest information, clkp2 is available on RZ/G2.
> > > > > > > > > > Modify CAN0 and CAN1 nodes accordingly.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > > > > > > > > Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com>
> > > > >
> > > > > > > > Thanks again, applied for v5.1.
> > > > > > >
> > > > > > > Sorry, I was a little hasty there.
> > > > > > >
> > > > > > > This patch depends on the presence of R8A774A1_CLK_CANFD which
> > > > > > > (rightly) is added in a different patch in this series which is to
> > > > > > > go upstream via a different tree.
> > > > > > >
> > > > > > > I have dropped this patch for now. I think there are two solution to this
> > > > > > > problem.
> > > > > > >
> > > > > > > 1. Provide a version of this patch which uses a numeric index instead of
> > > > > > > R8A774A1_CLK_CANFD. And then, once R8A774A1_CLK_CANFD is present in an
> > > > > > > RC release provide a patch to switch to using R8A774A1_CLK_CANFD.
> > > > > > >
> > > > > > > 2. Defer this patch until R8A774A1_CLK_CANFD is present in an RC release.
> > > > > >
> > > > > > Yeah, my personal preference is solution 2.
> > > > >
> > > > > Note that solution 2 will probably defer the DT patch to v5.2.
> > > >
> > > > Yeah, my understanding is that even if we chose solution 1 we would still
> > > > need to be waiting for v5.2 for the patch to switch to using
> > > > R8A774A1_CLK_CANFD to appear in a rc, therefore I think solution 2 is
> > > > fine.
> > >
> > > Your understanding is the same as mine.
> > >
> > > I do seem some slight value in option 1 in terms of getting the change,
> > > less the minor issue of using an index rather than a symbol, upstream
> > > earlier. But I do not feel strongly about this.
> > >
> > > I am marking this patch as deferred. Please repost or otherwise ping me
> > > when you would like to revisit this topic.
> >
> > Thank you. Will do.
>
> Thanks.
>
> I believe "[10/11] arm64: dts: renesas: r8a774c0: Add clkp2 clock to CAN nodes"
> falls into the same category. I have marked it as deferred accordingly.
Ok, thank you Simon
Fab
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* Re: [PATCH 3/7] sh_eth: offload RX checksum on R7S72100
From: Sergei Shtylyov @ 2019-01-28 15:21 UTC (permalink / raw)
To: Simon Horman; +Cc: netdev, David S. Miller, linux-renesas-soc, linux-sh
In-Reply-To: <20190128122053.vb5ifhf34zbnuclp@verge.net.au>
On 01/28/2019 03:20 PM, Simon Horman wrote:
>> The RZ/A1H (R7S721000) SoC manual describes the Ether MAC's RX checksum
>> offload the same way as it's implemented in the EtherAVB MACs...
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> Regarding this and the remaining patches in this series,
> which add rx-csum offload support in the sh_eth driver for
> various SoCs: has this been tested?
As I said, I've only tested it on R8A77980.
MBR, Sergei
^ permalink raw reply
* Re: [PATCH RFC v2 1/3] UDP: enable GRO by default.
From: Paolo Abeni @ 2019-01-28 15:30 UTC (permalink / raw)
To: Steffen Klassert, netdev; +Cc: Willem de Bruijn, Jason A. Donenfeld
In-Reply-To: <20190128085025.14532-2-steffen.klassert@secunet.com>
Hi,
On Mon, 2019-01-28 at 09:50 +0100, Steffen Klassert wrote:
> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> index 64f9715173ac..584635db9231 100644
> --- a/net/ipv4/udp_offload.c
> +++ b/net/ipv4/udp_offload.c
> @@ -392,35 +392,24 @@ static struct sk_buff *udp_gro_receive_segment(struct list_head *head,
> return NULL;
> }
>
> -INDIRECT_CALLABLE_DECLARE(struct sock *udp6_lib_lookup_skb(struct sk_buff *skb,
> - __be16 sport, __be16 dport));
> struct sk_buff *udp_gro_receive(struct list_head *head, struct sk_buff *skb,
> - struct udphdr *uh, udp_lookup_t lookup)
> + struct udphdr *uh, struct sock *sk)
> {
> struct sk_buff *pp = NULL;
> struct sk_buff *p;
> struct udphdr *uh2;
> unsigned int off = skb_gro_offset(skb);
> int flush = 1;
> - struct sock *sk;
> -
> - rcu_read_lock();
> - sk = INDIRECT_CALL_INET(lookup, udp6_lib_lookup_skb,
> - udp4_lib_lookup_skb, skb, uh->source, uh->dest);
> - if (!sk)
> - goto out_unlock;
>
> - if (udp_sk(sk)->gro_enabled) {
> + if (!sk || !udp_sk(sk)->gro_receive) {
> pp = call_gro_receive(udp_gro_receive_segment, head, skb);
> - rcu_read_unlock();
> return pp;
> }
>
> if (NAPI_GRO_CB(skb)->encap_mark ||
> (skb->ip_summed != CHECKSUM_PARTIAL &&
> NAPI_GRO_CB(skb)->csum_cnt == 0 &&
> - !NAPI_GRO_CB(skb)->csum_valid) ||
> - !udp_sk(sk)->gro_receive)
> + !NAPI_GRO_CB(skb)->csum_valid))
> goto out_unlock;
Here I think an additional chunk is missing: the caller is holding the
rcu lock, we should drop the rcu_read_unlock() from this function (and
likely rename the associated label).
> /* mark that this skb passed once through the tunnel gro layer */
> @@ -459,8 +448,10 @@ INDIRECT_CALLABLE_SCOPE
> struct sk_buff *udp4_gro_receive(struct list_head *head, struct sk_buff *skb)
> {
> struct udphdr *uh = udp_gro_udphdr(skb);
> + struct sk_buff *pp;
> + struct sock *sk;
>
> - if (unlikely(!uh) || !static_branch_unlikely(&udp_encap_needed_key))
> + if (unlikely(!uh))
> goto flush;
>
> /* Don't bother verifying checksum if we're going to flush anyway. */
> @@ -475,7 +466,11 @@ struct sk_buff *udp4_gro_receive(struct list_head *head, struct sk_buff *skb)
> inet_gro_compute_pseudo);
> skip:
> NAPI_GRO_CB(skb)->is_ipv6 = 0;
> - return udp_gro_receive(head, skb, uh, udp4_lib_lookup_skb);
> + rcu_read_lock();
> + sk = static_branch_unlikely(&udp_encap_needed_key) ? udp4_lib_lookup_skb(skb, uh->source, uh->dest) : NULL;
> + pp = udp_gro_receive(head, skb, uh, sk);
> + rcu_read_unlock();
> + return pp;
>
> flush:
> NAPI_GRO_CB(skb)->flush = 1;
_Unrelated_ to this patch, but IIRC the RCU lock is already help by
dev_gro_receive(), so IMHO a follow-up patch could possibly remove the
lock here and make the code smaller.
Apart from first point above, I like this patch a lot!
Paolo
^ permalink raw reply
* Re: [PATCH net v4 2/2] net/mlx5e: Don't overwrite pedit action when multiple pedit used
From: Or Gerlitz @ 2019-01-28 15:34 UTC (permalink / raw)
To: Tonghao Zhang; +Cc: Saeed Mahameed, Linux Netdev List, Or Gerlitz
In-Reply-To: <CAMDZJNWxQN5f=msq5Pp7dYPrSuakjZ3b88cGdkve0B6JodjOKQ@mail.gmail.com>
On Mon, Jan 28, 2019 at 2:10 PM Tonghao Zhang <xiangxia.m.yue@gmail.com> wrote:
> On Mon, Jan 28, 2019 at 12:40 AM Or Gerlitz <gerlitz.or@gmail.com> wrote:
> >
> > On Sun, Jan 27, 2019 at 1:06 PM <xiangxia.m.yue@gmail.com> wrote:
> > > From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> > >
> > > In some case, we may use multiple pedit actions to modify packets.
> > > The command shown as below: the last pedit action is effective.
> >
> > > @@ -2073,7 +2076,8 @@ static int alloc_mod_hdr_actions(struct mlx5e_priv *priv,
> > > if (!parse_attr->mod_hdr_actions)
> > > return -ENOMEM;
> > >
> > > - parse_attr->num_mod_hdr_actions = max_actions;
> > > + parse_attr->max_mod_hdr_actions = max_actions;
> > > + parse_attr->num_mod_hdr_actions = 0;
> >
> > why would we want to do this zeroing? what purpose does it serve?
> Because we use the num_mod_hdr_actions to store the number of actions
> we have parsed,
> and when we alloc it, we init it 0 as default.
>
> > On a probably related note, I suspect that the patch broke the caching
> > we do for modify header contexts, see mlx5e_attach_mod_hdr where we
> > look if a given set of modify header operations already has hw modify header
> > context and we use it.
> >
> > To test that, put two tc rules with different matching but same set of
> > modify header
> > (pedit) actions and see that only one modify header context is used.
> The patch does't break the cache, I think that different matching may
> share the same set of pedit actions.
I suspect it does break it.. at [1] we have this code for the cache lookup:
num_actions = parse_attr->num_mod_hdr_actions;
[..]
key.actions = parse_attr->mod_hdr_actions;
key.num_actions = num_actions;
hash_key = hash_mod_hdr_info(&key);
so we are doing the cached insertion and lookup with
parse_attr->num_mod_hdr_actions
which was zeroed along the way and not accounting for the full set of
pedit actions, agree?
[1] https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c#L179
^ permalink raw reply
* [PATCH] mwifiex: don't print error message on coex event
From: Stefan Agner @ 2019-01-28 15:43 UTC (permalink / raw)
To: amitkarwar, nishants, gbhat, huxinming820
Cc: kvalo, davem, linux-wireless, netdev, linux-kernel, Stefan Agner
The BT coex event is not an error condition. Don't print an error
message in this case. The same even in sta_event.c prints a
message using the debug level already.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
drivers/net/wireless/marvell/mwifiex/uap_event.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/uap_event.c b/drivers/net/wireless/marvell/mwifiex/uap_event.c
index e86217a6b9ca..ca759d9c0253 100644
--- a/drivers/net/wireless/marvell/mwifiex/uap_event.c
+++ b/drivers/net/wireless/marvell/mwifiex/uap_event.c
@@ -300,7 +300,7 @@ int mwifiex_process_uap_event(struct mwifiex_private *priv)
mwifiex_11h_handle_radar_detected(priv, adapter->event_skb);
break;
case EVENT_BT_COEX_WLAN_PARA_CHANGE:
- dev_err(adapter->dev, "EVENT: BT coex wlan param update\n");
+ mwifiex_dbg(adapter, EVENT, "event: BT coex wlan param update\n");
mwifiex_bt_coex_wlan_param_update_event(priv,
adapter->event_skb);
break;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 017/304] ath10k: assign 'n_cipher_suites' for WCN3990
From: Sasha Levin @ 2019-01-28 15:38 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Brian Norris, Rakesh Pillai, Govind Singh, Kalle Valo,
Sasha Levin, ath10k, linux-wireless, netdev
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Brian Norris <briannorris@chromium.org>
[ Upstream commit 2bd345cd2bfc0bd44528896313c0b45f087bdf67 ]
Commit 2ea9f12cefe4 ("ath10k: add new cipher suite support") added a new
n_cipher_suites HW param with a fallback value and a warning log. Commit
03a72288c546 ("ath10k: wmi: add hw params entry for wcn3990") later
added WCN3990 HW entries, but it missed the n_cipher_suites.
Rather than seeing this warning every boot
ath10k_snoc 18800000.wifi: invalid hw_params.n_cipher_suites 0
let's provide the appropriate value.
Cc: Rakesh Pillai <pillair@qti.qualcomm.com>
Cc: Govind Singh <govinds@qti.qualcomm.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/ath10k/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index d210b0ed59be..59fdda67f89f 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -561,6 +561,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.hw_ops = &wcn3990_ops,
.decap_align_bytes = 1,
.num_peers = TARGET_HL_10_TLV_NUM_PEERS,
+ .n_cipher_suites = 8,
.ast_skid_limit = TARGET_HL_10_TLV_AST_SKID_LIMIT,
.num_wds_entries = TARGET_HL_10_TLV_NUM_WDS_ENTRIES,
.target_64bit = true,
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 018/304] ath9k: dynack: use authentication messages for 'late' ack
From: Sasha Levin @ 2019-01-28 15:38 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Lorenzo Bianconi, Kalle Valo, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
[ Upstream commit 3831a2a0010c72e3956020cbf1057a1701a2e469 ]
In order to properly support dynack in ad-hoc mode running
wpa_supplicant, take into account authentication frames for
'late ack' detection. This patch has been tested on devices
mounted on offshore high-voltage stations connected through
~24Km link
Reported-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/ath9k/dynack.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/dynack.c b/drivers/net/wireless/ath/ath9k/dynack.c
index 7334c9b09e82..cc0dc966c512 100644
--- a/drivers/net/wireless/ath/ath9k/dynack.c
+++ b/drivers/net/wireless/ath/ath9k/dynack.c
@@ -187,7 +187,8 @@ void ath_dynack_sample_tx_ts(struct ath_hw *ah, struct sk_buff *skb,
/* late ACK */
if (ts->ts_status & ATH9K_TXERR_XRETRY) {
if (ieee80211_is_assoc_req(hdr->frame_control) ||
- ieee80211_is_assoc_resp(hdr->frame_control)) {
+ ieee80211_is_assoc_resp(hdr->frame_control) ||
+ ieee80211_is_auth(hdr->frame_control)) {
ath_dbg(common, DYNACK, "late ack\n");
ath9k_hw_setslottime(ah, (LATEACK_TO - 3) / 2);
ath9k_hw_set_ack_timeout(ah, LATEACK_TO);
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 039/304] sctp: Fix SKB list traversal in sctp_intl_store_ordered().
From: Sasha Levin @ 2019-01-28 15:39 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: David S. Miller, Sasha Levin, linux-sctp, netdev
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: "David S. Miller" <davem@davemloft.net>
[ Upstream commit e15e067d0656625c77c52b4e5f0cfbf0c0c3583f ]
Same change as made to sctp_intl_store_reasm().
To be fully correct, an iterator has an undefined value when something
like skb_queue_walk() naturally terminates.
This will actually matter when SKB queues are converted over to
list_head.
Formalize what this code ends up doing with the current
implementation.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/sctp/stream_interleave.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/net/sctp/stream_interleave.c b/net/sctp/stream_interleave.c
index 0a78cdf86463..500449b72eca 100644
--- a/net/sctp/stream_interleave.c
+++ b/net/sctp/stream_interleave.c
@@ -383,7 +383,7 @@ static void sctp_intl_store_ordered(struct sctp_ulpq *ulpq,
struct sctp_ulpevent *event)
{
struct sctp_ulpevent *cevent;
- struct sk_buff *pos;
+ struct sk_buff *pos, *loc;
pos = skb_peek_tail(&ulpq->lobby);
if (!pos) {
@@ -403,18 +403,25 @@ static void sctp_intl_store_ordered(struct sctp_ulpq *ulpq,
return;
}
+ loc = NULL;
skb_queue_walk(&ulpq->lobby, pos) {
cevent = (struct sctp_ulpevent *)pos->cb;
- if (cevent->stream > event->stream)
+ if (cevent->stream > event->stream) {
+ loc = pos;
break;
-
+ }
if (cevent->stream == event->stream &&
- MID_lt(event->mid, cevent->mid))
+ MID_lt(event->mid, cevent->mid)) {
+ loc = pos;
break;
+ }
}
- __skb_queue_before(&ulpq->lobby, pos, sctp_event2skb(event));
+ if (!loc)
+ __skb_queue_tail(&ulpq->lobby, sctp_event2skb(event));
+ else
+ __skb_queue_before(&ulpq->lobby, loc, sctp_event2skb(event));
}
static void sctp_intl_retrieve_ordered(struct sctp_ulpq *ulpq,
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 048/304] i40e: suppress bogus error message
From: Sasha Levin @ 2019-01-28 15:39 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Mitch Williams, Jeff Kirsher, Sasha Levin, netdev
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Mitch Williams <mitch.a.williams@intel.com>
[ Upstream commit 7cd8eb0861981ad212ce4242a1870c4b5831ceff ]
The i40e driver complains about unprivileged VFs trying to configure
promiscuous mode each time a VF reset occurs. This isn't the fault of
the poor VF driver - the PF driver itself is making the request.
To fix this, skip the privilege check if the request is to disable all
promiscuous activity. This gets rid of the bogus message, but doesn't
affect privilege checks, since we really only care if the unprivileged
VF is trying to enable promiscuous mode.
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index ac5698ed0b11..c41e8ada23d1 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -1112,7 +1112,8 @@ static i40e_status i40e_config_vf_promiscuous_mode(struct i40e_vf *vf,
if (!i40e_vc_isvalid_vsi_id(vf, vsi_id) || !vsi)
return I40E_ERR_PARAM;
- if (!test_bit(I40E_VIRTCHNL_VF_CAP_PRIVILEGE, &vf->vf_caps)) {
+ if (!test_bit(I40E_VIRTCHNL_VF_CAP_PRIVILEGE, &vf->vf_caps) &&
+ (allmulti || alluni)) {
dev_err(&pf->pdev->dev,
"Unprivileged VF %d is attempting to configure promiscuous mode\n",
vf->vf_id);
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 049/304] i40e: prevent overlapping tx_timeout recover
From: Sasha Levin @ 2019-01-28 15:39 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Alan Brady, Jeff Kirsher, Sasha Levin, netdev
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Alan Brady <alan.brady@intel.com>
[ Upstream commit d5585b7b6846a6d0f9517afe57be3843150719da ]
If a TX hang occurs, we attempt to recover by incrementally resetting.
If we're starved for CPU time, it's possible the reset doesn't actually
complete (or even fire) before another tx_timeout fires causing us to
fly through the different resets without actually doing them.
This adds a bit to set and check if a timeout recovery is already
pending and, if so, bail out of tx_timeout. The bit will get cleared at
the end of i40e_rebuild when reset is complete.
Signed-off-by: Alan Brady <alan.brady@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/i40e/i40e.h | 1 +
drivers/net/ethernet/intel/i40e/i40e_main.c | 5 +++++
2 files changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e.h b/drivers/net/ethernet/intel/i40e/i40e.h
index 876cac317e79..8245ff12fd64 100644
--- a/drivers/net/ethernet/intel/i40e/i40e.h
+++ b/drivers/net/ethernet/intel/i40e/i40e.h
@@ -122,6 +122,7 @@ enum i40e_state_t {
__I40E_MDD_EVENT_PENDING,
__I40E_VFLR_EVENT_PENDING,
__I40E_RESET_RECOVERY_PENDING,
+ __I40E_TIMEOUT_RECOVERY_PENDING,
__I40E_MISC_IRQ_REQUESTED,
__I40E_RESET_INTR_RECEIVED,
__I40E_REINIT_REQUESTED,
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 0e5dc74b4ef2..419cf3faada6 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -338,6 +338,10 @@ static void i40e_tx_timeout(struct net_device *netdev)
(pf->tx_timeout_last_recovery + netdev->watchdog_timeo)))
return; /* don't do any new action before the next timeout */
+ /* don't kick off another recovery if one is already pending */
+ if (test_and_set_bit(__I40E_TIMEOUT_RECOVERY_PENDING, pf->state))
+ return;
+
if (tx_ring) {
head = i40e_get_head(tx_ring);
/* Read interrupt register */
@@ -9632,6 +9636,7 @@ end_core_reset:
clear_bit(__I40E_RESET_FAILED, pf->state);
clear_recovery:
clear_bit(__I40E_RESET_RECOVERY_PENDING, pf->state);
+ clear_bit(__I40E_TIMEOUT_RECOVERY_PENDING, pf->state);
}
/**
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 058/304] net/mlx5: EQ, Use the right place to store/read IRQ affinity hint
From: Sasha Levin @ 2019-01-28 15:39 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Saeed Mahameed, Leon Romanovsky, Sasha Levin, netdev, linux-rdma
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Saeed Mahameed <saeedm@mellanox.com>
[ Upstream commit 1e86ace4c140fd5a693e266c9b23409358f25381 ]
Currently the cpu affinity hint mask for completion EQs is stored and
read from the wrong place, since reading and storing is done from the
same index, there is no actual issue with that, but internal irq_info
for completion EQs stars at MLX5_EQ_VEC_COMP_BASE offset in irq_info
array, this patch changes the code to use the correct offset to store
and read the IRQ affinity hint.
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/main.c | 14 ++++++++------
include/linux/mlx5/driver.h | 2 +-
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index b70cb6fd164c..9577d0657839 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -1771,7 +1771,7 @@ static void mlx5e_close_cq(struct mlx5e_cq *cq)
static int mlx5e_get_cpu(struct mlx5e_priv *priv, int ix)
{
- return cpumask_first(priv->mdev->priv.irq_info[ix].mask);
+ return cpumask_first(priv->mdev->priv.irq_info[ix + MLX5_EQ_VEC_COMP_BASE].mask);
}
static int mlx5e_open_tx_cqs(struct mlx5e_channel *c,
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index 28132c7dc05f..d5cea0a36e6a 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -640,18 +640,19 @@ u64 mlx5_read_internal_timer(struct mlx5_core_dev *dev)
static int mlx5_irq_set_affinity_hint(struct mlx5_core_dev *mdev, int i)
{
struct mlx5_priv *priv = &mdev->priv;
- int irq = pci_irq_vector(mdev->pdev, MLX5_EQ_VEC_COMP_BASE + i);
+ int vecidx = MLX5_EQ_VEC_COMP_BASE + i;
+ int irq = pci_irq_vector(mdev->pdev, vecidx);
- if (!zalloc_cpumask_var(&priv->irq_info[i].mask, GFP_KERNEL)) {
+ if (!zalloc_cpumask_var(&priv->irq_info[vecidx].mask, GFP_KERNEL)) {
mlx5_core_warn(mdev, "zalloc_cpumask_var failed");
return -ENOMEM;
}
cpumask_set_cpu(cpumask_local_spread(i, priv->numa_node),
- priv->irq_info[i].mask);
+ priv->irq_info[vecidx].mask);
if (IS_ENABLED(CONFIG_SMP) &&
- irq_set_affinity_hint(irq, priv->irq_info[i].mask))
+ irq_set_affinity_hint(irq, priv->irq_info[vecidx].mask))
mlx5_core_warn(mdev, "irq_set_affinity_hint failed, irq 0x%.4x", irq);
return 0;
@@ -659,11 +660,12 @@ static int mlx5_irq_set_affinity_hint(struct mlx5_core_dev *mdev, int i)
static void mlx5_irq_clear_affinity_hint(struct mlx5_core_dev *mdev, int i)
{
+ int vecidx = MLX5_EQ_VEC_COMP_BASE + i;
struct mlx5_priv *priv = &mdev->priv;
- int irq = pci_irq_vector(mdev->pdev, MLX5_EQ_VEC_COMP_BASE + i);
+ int irq = pci_irq_vector(mdev->pdev, vecidx);
irq_set_affinity_hint(irq, NULL);
- free_cpumask_var(priv->irq_info[i].mask);
+ free_cpumask_var(priv->irq_info[vecidx].mask);
}
static int mlx5_irq_set_affinity_hints(struct mlx5_core_dev *mdev)
diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h
index aa5963b5d38e..7d4ed995b4ce 100644
--- a/include/linux/mlx5/driver.h
+++ b/include/linux/mlx5/driver.h
@@ -1309,7 +1309,7 @@ enum {
static inline const struct cpumask *
mlx5_get_vector_affinity_hint(struct mlx5_core_dev *dev, int vector)
{
- return dev->priv.irq_info[vector].mask;
+ return dev->priv.irq_info[vector + MLX5_EQ_VEC_COMP_BASE].mask;
}
#endif /* MLX5_DRIVER_H */
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 104/304] mt76x0: dfs: fix IBI_R11 configuration on non-radar channels
From: Sasha Levin @ 2019-01-28 15:40 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Lorenzo Bianconi, Felix Fietkau, Sasha Levin, linux-wireless,
netdev
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
[ Upstream commit 6bf4a8e902aad7df55d7f2b10b850cfa3f880996 ]
Fix IBI_R11 configuration on non-radar channels for mt76x0e
driver. This patch improve system stability under heavy load.
Moreover use IBI_R11 name and remove magic numbers for
0x212c register
Fixes: 0c3b3abc9251 ("mt76x0: pci: add DFS support")
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt76x2/pci_dfs.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_dfs.c b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_dfs.c
index b56febae8945..764528c9f48a 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_dfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_dfs.c
@@ -800,7 +800,7 @@ static void mt76x2_dfs_set_bbp_params(struct mt76x02_dev *dev)
/* enable detection*/
mt76_wr(dev, MT_BBP(DFS, 0), MT_DFS_CH_EN << 16);
- mt76_wr(dev, 0x212c, 0x0c350001);
+ mt76_wr(dev, MT_BBP(IBI, 11), 0x0c350001);
}
void mt76x2_dfs_adjust_agc(struct mt76x02_dev *dev)
@@ -843,7 +843,11 @@ void mt76x2_dfs_init_params(struct mt76x02_dev *dev)
mt76_wr(dev, MT_BBP(DFS, 0), 0);
/* clear detector status */
mt76_wr(dev, MT_BBP(DFS, 1), 0xf);
- mt76_wr(dev, 0x212c, 0);
+ if (mt76_chip(&dev->mt76) == 0x7610 ||
+ mt76_chip(&dev->mt76) == 0x7630)
+ mt76_wr(dev, MT_BBP(IBI, 11), 0xfde8081);
+ else
+ mt76_wr(dev, MT_BBP(IBI, 11), 0);
mt76x02_irq_disable(dev, MT_INT_GPTIMER);
mt76_rmw_field(dev, MT_INT_TIMER_EN,
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 105/304] mt76x0: use band parameter for LC calibration
From: Sasha Levin @ 2019-01-28 15:40 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Stanislaw Gruszka, Felix Fietkau, Sasha Levin, linux-wireless,
netdev
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Stanislaw Gruszka <sgruszka@redhat.com>
[ Upstream commit ad3f993a0857ad3b792e7463828eb0d90cdd6f4d ]
We use always 1 as band parameter for MCU_CAL_LC, this break 2GHz,
we should use 0 for this band instead.
Patch fixes problems happened sometimes when try to associate with 2GHz
AP and manifest by errors like below:
[14680.920823] wlan0: authenticate with 18:31:bf:c0:51:b0
[14681.109506] wlan0: send auth to 18:31:bf:c0:51:b0 (try 1/3)
[14681.310454] wlan0: send auth to 18:31:bf:c0:51:b0 (try 2/3)
[14681.518469] wlan0: send auth to 18:31:bf:c0:51:b0 (try 3/3)
[14681.726499] wlan0: authentication with 18:31:bf:c0:51:b0 timed out
Fixes: 9aec146d0f6b ("mt76x0: pci: introduce mt76x0_phy_calirate routine")
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
index cf024950e0ed..9c0a042c28b0 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
@@ -585,6 +585,7 @@ void mt76x0_phy_set_txpower(struct mt76x02_dev *dev)
void mt76x0_phy_calibrate(struct mt76x02_dev *dev, bool power_on)
{
struct ieee80211_channel *chan = dev->mt76.chandef.chan;
+ int is_5ghz = (chan->band == NL80211_BAND_5GHZ) ? 1 : 0;
u32 val, tx_alc, reg_val;
if (power_on) {
@@ -602,7 +603,7 @@ void mt76x0_phy_calibrate(struct mt76x02_dev *dev, bool power_on)
reg_val = mt76_rr(dev, MT_BBP(IBI, 9));
mt76_wr(dev, MT_BBP(IBI, 9), 0xffffff7e);
- if (chan->band == NL80211_BAND_5GHZ) {
+ if (is_5ghz) {
if (chan->hw_value < 100)
val = 0x701;
else if (chan->hw_value < 140)
@@ -615,7 +616,7 @@ void mt76x0_phy_calibrate(struct mt76x02_dev *dev, bool power_on)
mt76x02_mcu_calibrate(dev, MCU_CAL_FULL, val, false);
msleep(350);
- mt76x02_mcu_calibrate(dev, MCU_CAL_LC, 1, false);
+ mt76x02_mcu_calibrate(dev, MCU_CAL_LC, is_5ghz, false);
usleep_range(15000, 20000);
mt76_wr(dev, MT_BBP(IBI, 9), reg_val);
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 109/304] nfp: add locking around representor changes
From: Sasha Levin @ 2019-01-28 15:40 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jakub Kicinski, David S . Miller, Sasha Levin, oss-drivers,
netdev
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
[ Upstream commit 71844fac1ed459024dd2a448d63d5b28b8c87daa ]
Up until now we never needed to keep a networking locks around
representors accesses, we only accessed them when device was
reconfigured (under nfp pf->lock) or on fast path (under RCU).
Now we want to be able to iterate over all representors during
notifications, so make sure representor assignment is done
under RTNL lock.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: John Hurley <john.hurley@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/netronome/nfp/abm/main.c | 4 ++++
drivers/net/ethernet/netronome/nfp/nfp_app.c | 2 ++
drivers/net/ethernet/netronome/nfp/nfp_net_repr.c | 2 ++
3 files changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/netronome/nfp/abm/main.c b/drivers/net/ethernet/netronome/nfp/abm/main.c
index c0830c0c2c3f..376df412ea55 100644
--- a/drivers/net/ethernet/netronome/nfp/abm/main.c
+++ b/drivers/net/ethernet/netronome/nfp/abm/main.c
@@ -384,7 +384,9 @@ nfp_abm_spawn_repr(struct nfp_app *app, struct nfp_abm_link *alink,
reprs = nfp_reprs_get_locked(app, rtype);
WARN(nfp_repr_get_locked(app, reprs, alink->id), "duplicate repr");
+ rtnl_lock();
rcu_assign_pointer(reprs->reprs[alink->id], netdev);
+ rtnl_unlock();
nfp_info(app->cpp, "%s Port %d Representor(%s) created\n",
ptype == NFP_PORT_PF_PORT ? "PCIe" : "Phys",
@@ -410,7 +412,9 @@ nfp_abm_kill_repr(struct nfp_app *app, struct nfp_abm_link *alink,
netdev = nfp_repr_get_locked(app, reprs, alink->id);
if (!netdev)
return;
+ rtnl_lock();
rcu_assign_pointer(reprs->reprs[alink->id], NULL);
+ rtnl_unlock();
synchronize_rcu();
/* Cast to make sure nfp_repr_clean_and_free() takes a nfp_repr */
nfp_repr_clean_and_free((struct nfp_repr *)netdev_priv(netdev));
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_app.c b/drivers/net/ethernet/netronome/nfp/nfp_app.c
index 68a0991aac22..3bd1386162b9 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_app.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_app.c
@@ -131,7 +131,9 @@ nfp_app_reprs_set(struct nfp_app *app, enum nfp_repr_type type,
struct nfp_reprs *old;
old = nfp_reprs_get_locked(app, type);
+ rtnl_lock();
rcu_assign_pointer(app->reprs[type], reprs);
+ rtnl_unlock();
return old;
}
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c b/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c
index c09b893c30dd..0cf3f40eb8cf 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c
@@ -442,7 +442,9 @@ int nfp_reprs_resync_phys_ports(struct nfp_app *app)
continue;
nfp_app_repr_preclean(app, netdev);
+ rtnl_lock();
rcu_assign_pointer(reprs->reprs[i], NULL);
+ rtnl_unlock();
synchronize_rcu();
nfp_repr_clean(repr);
}
--
2.19.1
^ permalink raw reply related
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