* [PATCH 3/3] net: rsi: netlink: constify genl_ops
From: Arvind Yadav @ 2017-08-23 9:59 UTC (permalink / raw)
To: davem, Larry.Finger, chaoming_li, kvalo, jon.maloy, ying.xue
Cc: linux-kernel, linux-wireless, netdev
In-Reply-To: <1503482375-19983-1-git-send-email-arvind.yadav.cs@gmail.com>
genl_ops are not supposed to change at runtime. All functions
working with genl_ops provided by <net/genetlink.h> work with
const genl_ops. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
net/tipc/netlink_compat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/tipc/netlink_compat.c b/net/tipc/netlink_compat.c
index 750949d..e48f0b2 100644
--- a/net/tipc/netlink_compat.c
+++ b/net/tipc/netlink_compat.c
@@ -1217,7 +1217,7 @@ static int tipc_nl_compat_recv(struct sk_buff *skb, struct genl_info *info)
return err;
}
-static struct genl_ops tipc_genl_compat_ops[] = {
+static const struct genl_ops tipc_genl_compat_ops[] = {
{
.cmd = TIPC_GENL_CMD,
.doit = tipc_nl_compat_recv,
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 3/3] net: rsi: netlink: constify genl_ops
From: Kalle Valo @ 2017-08-23 10:02 UTC (permalink / raw)
To: Arvind Yadav
Cc: davem, Larry.Finger, chaoming_li, jon.maloy, ying.xue,
linux-kernel, linux-wireless, netdev
In-Reply-To: <1503482375-19983-4-git-send-email-arvind.yadav.cs@gmail.com>
Arvind Yadav <arvind.yadav.cs@gmail.com> writes:
> genl_ops are not supposed to change at runtime. All functions
> working with genl_ops provided by <net/genetlink.h> work with
> const genl_ops. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> ---
> net/tipc/netlink_compat.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Using the prefix "rsi:" looks wrong for this patch.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 3/3] net: rsi: netlink: constify genl_ops
From: Arvind Yadav @ 2017-08-23 10:05 UTC (permalink / raw)
To: Kalle Valo
Cc: davem, Larry.Finger, chaoming_li, jon.maloy, ying.xue,
linux-kernel, linux-wireless, netdev
In-Reply-To: <87378iy52u.fsf@kamboji.qca.qualcomm.com>
Hi,
On Wednesday 23 August 2017 03:32 PM, Kalle Valo wrote:
> Arvind Yadav <arvind.yadav.cs@gmail.com> writes:
>
>> genl_ops are not supposed to change at runtime. All functions
>> working with genl_ops provided by <net/genetlink.h> work with
>> const genl_ops. So mark the non-const structs as const.
>>
>> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
>> ---
>> net/tipc/netlink_compat.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
> Using the prefix "rsi:" looks wrong for this patch.
Thanks for pointing. I will update.
>
~arvind
^ permalink raw reply
* [PATCH 3/3 v2] net: netlink: constify genl_ops
From: Arvind Yadav @ 2017-08-23 10:08 UTC (permalink / raw)
To: davem, Larry.Finger, chaoming_li, kvalo, jon.maloy, ying.xue
Cc: linux-kernel, linux-wireless, netdev
genl_ops are not supposed to change at runtime. All functions
working with genl_ops provided by <net/genetlink.h> work with
const genl_ops. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
Changes in v2:
Patch Subject was wrong.
net/tipc/netlink_compat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/tipc/netlink_compat.c b/net/tipc/netlink_compat.c
index 750949d..e48f0b2 100644
--- a/net/tipc/netlink_compat.c
+++ b/net/tipc/netlink_compat.c
@@ -1217,7 +1217,7 @@ static int tipc_nl_compat_recv(struct sk_buff *skb, struct genl_info *info)
return err;
}
-static struct genl_ops tipc_genl_compat_ops[] = {
+static const struct genl_ops tipc_genl_compat_ops[] = {
{
.cmd = TIPC_GENL_CMD,
.doit = tipc_nl_compat_recv,
--
1.9.1
^ permalink raw reply related
* RE: [PATCH][net-next] net: hinic: make functions set_ctrl0 and set_ctrl1 static
From: Aviad Krawczyk (A) @ 2017-08-23 10:08 UTC (permalink / raw)
To: Colin King, netdev@vger.kernel.org
Cc: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20170823095940.27225-1-colin.king@canonical.com>
Thanks
-----Original Message-----
From: Colin King [mailto:colin.king@canonical.com]
Sent: Wednesday, August 23, 2017 1:00 PM
To: Aviad Krawczyk (A); netdev@vger.kernel.org
Cc: kernel-janitors@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: [PATCH][net-next] net: hinic: make functions set_ctrl0 and set_ctrl1 static
From: Colin Ian King <colin.king@canonical.com>
The functions set_ctrl0 and set_ctrl1 are local to the source and do not need to be in global scope, so make them static.
Cleans up sparse warnings:
symbol 'set_ctrl0' was not declared. Should it be static?
symbol 'set_ctrl1' was not declared. Should it be static?
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/huawei/hinic/hinic_hw_eqs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_eqs.c b/drivers/net/ethernet/huawei/hinic/hinic_hw_eqs.c
index cd09e6ef3aea..7cb8b9b94726 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_eqs.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_eqs.c
@@ -423,7 +423,7 @@ static irqreturn_t ceq_interrupt(int irq, void *data)
return IRQ_HANDLED;
}
-void set_ctrl0(struct hinic_eq *eq)
+static void set_ctrl0(struct hinic_eq *eq)
{
struct msix_entry *msix_entry = &eq->msix_entry;
enum hinic_eq_type type = eq->type;
@@ -474,7 +474,7 @@ void set_ctrl0(struct hinic_eq *eq)
}
}
-void set_ctrl1(struct hinic_eq *eq)
+static void set_ctrl1(struct hinic_eq *eq)
{
enum hinic_eq_type type = eq->type;
u32 page_size_val, elem_size;
^ permalink raw reply related
* [V2 PATCH net-next 0/5] xdp: more work on xdp tracepoints
From: Jesper Dangaard Brouer @ 2017-08-23 10:15 UTC (permalink / raw)
To: netdev; +Cc: Daniel Borkmann, John Fastabend, Jesper Dangaard Brouer
In-Reply-To: <599D42B8.6040200@iogearbox.net>
More work on streamlining the tracepoints for XDP.
I've created a simple xdp_monitor application that uses this
tracepoint, and prints statistics. Available at github:
https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/samples/bpf/xdp_monitor_kern.c
https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/samples/bpf/xdp_monitor_user.c
V2: Change trace_xdp_redirect() to align with args of trace_xdp_exception()
---
Jesper Dangaard Brouer (5):
xdp: remove bpf_warn_invalid_xdp_redirect
xdp: make generic xdp redirect use tracepoint trace_xdp_redirect
ixgbe: use return codes from ndo_xdp_xmit that are distinguishable
xdp: remove net_device names from xdp_redirect tracepoint
xdp: get tracepoints xdp_exception and xdp_redirect in sync
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 +-
include/linux/filter.h | 3 +-
include/trace/events/xdp.h | 36 +++++++++----------
net/core/dev.c | 4 +-
net/core/filter.c | 48 +++++++++++++------------
5 files changed, 48 insertions(+), 47 deletions(-)
^ permalink raw reply
* [V2 PATCH net-next 1/5] xdp: remove bpf_warn_invalid_xdp_redirect
From: Jesper Dangaard Brouer @ 2017-08-23 10:15 UTC (permalink / raw)
To: netdev; +Cc: Daniel Borkmann, John Fastabend, Jesper Dangaard Brouer
In-Reply-To: <150348327373.23476.14851572406177222309.stgit@firesoul>
Given there is a tracepoint that can track the error code
of xdp_do_redirect calls, the WARN_ONCE in bpf_warn_invalid_xdp_redirect
doesn't seem relevant any longer. Simply remove the function.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
---
net/core/filter.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index fa2115695037..31c579749679 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -2499,7 +2499,6 @@ static int __bpf_tx_xdp(struct net_device *dev,
int err;
if (!dev->netdev_ops->ndo_xdp_xmit) {
- bpf_warn_invalid_xdp_redirect(dev->ifindex);
return -EOPNOTSUPP;
}
@@ -2572,7 +2571,6 @@ int xdp_do_redirect(struct net_device *dev, struct xdp_buff *xdp,
fwd = dev_get_by_index_rcu(dev_net(dev), index);
ri->ifindex = 0;
if (unlikely(!fwd)) {
- bpf_warn_invalid_xdp_redirect(index);
err = -EINVAL;
goto out;
}
@@ -2593,7 +2591,6 @@ int xdp_do_generic_redirect(struct net_device *dev, struct sk_buff *skb)
dev = dev_get_by_index_rcu(dev_net(dev), index);
ri->ifindex = 0;
if (unlikely(!dev)) {
- bpf_warn_invalid_xdp_redirect(index);
goto err;
}
@@ -3573,11 +3570,6 @@ void bpf_warn_invalid_xdp_action(u32 act)
}
EXPORT_SYMBOL_GPL(bpf_warn_invalid_xdp_action);
-void bpf_warn_invalid_xdp_redirect(u32 ifindex)
-{
- WARN_ONCE(1, "Illegal XDP redirect to unsupported device ifindex(%i)\n", ifindex);
-}
-
static bool __is_valid_sock_ops_access(int off, int size)
{
if (off < 0 || off >= sizeof(struct bpf_sock_ops))
^ permalink raw reply related
* [V2 PATCH net-next 2/5] xdp: make generic xdp redirect use tracepoint trace_xdp_redirect
From: Jesper Dangaard Brouer @ 2017-08-23 10:15 UTC (permalink / raw)
To: netdev; +Cc: Daniel Borkmann, John Fastabend, Jesper Dangaard Brouer
In-Reply-To: <150348327373.23476.14851572406177222309.stgit@firesoul>
If the xdp_do_generic_redirect() call fails, it trigger the
trace_xdp_exception tracepoint. It seems better to use the same
tracepoint trace_xdp_redirect, as the native xdp_do_redirect{,_map} does.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
---
include/linux/filter.h | 3 ++-
net/core/dev.c | 4 ++--
net/core/filter.c | 36 ++++++++++++++++++++++--------------
3 files changed, 26 insertions(+), 17 deletions(-)
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 7015116331af..d29e58fde364 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -718,7 +718,8 @@ struct bpf_prog *bpf_patch_insn_single(struct bpf_prog *prog, u32 off,
* because we only track one map and force a flush when the map changes.
* This does not appear to be a real limitation for existing software.
*/
-int xdp_do_generic_redirect(struct net_device *dev, struct sk_buff *skb);
+int xdp_do_generic_redirect(struct net_device *dev, struct sk_buff *skb,
+ struct bpf_prog *prog);
int xdp_do_redirect(struct net_device *dev,
struct xdp_buff *xdp,
struct bpf_prog *prog);
diff --git a/net/core/dev.c b/net/core/dev.c
index 40b28e417072..270b54754821 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3953,7 +3953,8 @@ int do_xdp_generic(struct bpf_prog *xdp_prog, struct sk_buff *skb)
if (act != XDP_PASS) {
switch (act) {
case XDP_REDIRECT:
- err = xdp_do_generic_redirect(skb->dev, skb);
+ err = xdp_do_generic_redirect(skb->dev, skb,
+ xdp_prog);
if (err)
goto out_redir;
/* fallthru to submit skb */
@@ -3966,7 +3967,6 @@ int do_xdp_generic(struct bpf_prog *xdp_prog, struct sk_buff *skb)
}
return XDP_PASS;
out_redir:
- trace_xdp_exception(skb->dev, xdp_prog, XDP_REDIRECT);
kfree_skb(skb);
return XDP_DROP;
}
diff --git a/net/core/filter.c b/net/core/filter.c
index 31c579749679..2d7cdb2c5c66 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -2582,29 +2582,37 @@ int xdp_do_redirect(struct net_device *dev, struct xdp_buff *xdp,
}
EXPORT_SYMBOL_GPL(xdp_do_redirect);
-int xdp_do_generic_redirect(struct net_device *dev, struct sk_buff *skb)
+int xdp_do_generic_redirect(struct net_device *dev, struct sk_buff *skb,
+ struct bpf_prog *xdp_prog)
{
struct redirect_info *ri = this_cpu_ptr(&redirect_info);
- unsigned int len;
u32 index = ri->ifindex;
+ struct net_device *fwd;
+ unsigned int len;
+ int err = 0;
- dev = dev_get_by_index_rcu(dev_net(dev), index);
+ fwd = dev_get_by_index_rcu(dev_net(dev), index);
ri->ifindex = 0;
- if (unlikely(!dev)) {
- goto err;
+ if (unlikely(!fwd)) {
+ err = -EINVAL;
+ goto out;
}
- if (unlikely(!(dev->flags & IFF_UP)))
- goto err;
+ if (unlikely(!(fwd->flags & IFF_UP))) {
+ err = -ENOLINK;
+ goto out;
+ }
- len = dev->mtu + dev->hard_header_len + VLAN_HLEN;
- if (skb->len > len)
- goto err;
+ len = fwd->mtu + fwd->hard_header_len + VLAN_HLEN;
+ if (skb->len > len) {
+ err = -EMSGSIZE;
+ goto out;
+ }
- skb->dev = dev;
- return 0;
-err:
- return -EINVAL;
+ skb->dev = fwd;
+out:
+ trace_xdp_redirect(dev, fwd, xdp_prog, XDP_REDIRECT, err);
+ return err;
}
EXPORT_SYMBOL_GPL(xdp_do_generic_redirect);
^ permalink raw reply related
* [V2 PATCH net-next 3/5] ixgbe: use return codes from ndo_xdp_xmit that are distinguishable
From: Jesper Dangaard Brouer @ 2017-08-23 10:15 UTC (permalink / raw)
To: netdev; +Cc: Daniel Borkmann, John Fastabend, Jesper Dangaard Brouer
In-Reply-To: <150348327373.23476.14851572406177222309.stgit@firesoul>
For XDP_REDIRECT the use of return code -EINVAL is confusing, as it is
used in three different cases. (1) When the index or ifindex lookup
fails, and in the ixgbe driver (2) when link is down and (3) when XDP
have not been enabled.
The return code can be picked up by the tracepoint xdp:xdp_redirect
for diagnosing why XDP_REDIRECT isn't working. Thus, there is a need
different return codes to tell the issues apart.
I'm considering using a specific err-code scheme for XDP_REDIRECT
instead of using these errno codes.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 8d3224ad6434..3afb8c4b9d48 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -9849,14 +9849,14 @@ static int ixgbe_xdp_xmit(struct net_device *dev, struct xdp_buff *xdp)
int err;
if (unlikely(test_bit(__IXGBE_DOWN, &adapter->state)))
- return -EINVAL;
+ return -ENOLINK;
/* During program transitions its possible adapter->xdp_prog is assigned
* but ring has not been configured yet. In this case simply abort xmit.
*/
ring = adapter->xdp_prog ? adapter->xdp_ring[smp_processor_id()] : NULL;
if (unlikely(!ring))
- return -EINVAL;
+ return -ENXIO;
err = ixgbe_xmit_xdp_ring(adapter, xdp);
if (err != IXGBE_XDP_TX)
^ permalink raw reply related
* [V2 PATCH net-next 4/5] xdp: remove net_device names from xdp_redirect tracepoint
From: Jesper Dangaard Brouer @ 2017-08-23 10:15 UTC (permalink / raw)
To: netdev; +Cc: Daniel Borkmann, John Fastabend, Jesper Dangaard Brouer
In-Reply-To: <150348327373.23476.14851572406177222309.stgit@firesoul>
There is too much overhead in the current trace_xdp_redirect
tracepoint as it does strcpy and strlen on the net_device names.
Besides, exposing the ifindex/index is actually the information that
is needed in the tracepoint to diagnose issues. When a lookup fails
(either ifindex or devmap index) then there is a need for saying which
to_index that have issues.
V2: Adjust args to be aligned with trace_xdp_exception.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
include/trace/events/xdp.h | 24 ++++++++++++------------
net/core/filter.c | 6 +++---
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/include/trace/events/xdp.h b/include/trace/events/xdp.h
index 0e42e69f773b..cd37706c6f55 100644
--- a/include/trace/events/xdp.h
+++ b/include/trace/events/xdp.h
@@ -51,33 +51,33 @@ TRACE_EVENT(xdp_exception,
TRACE_EVENT(xdp_redirect,
- TP_PROTO(const struct net_device *from,
- const struct net_device *to,
- const struct bpf_prog *xdp, u32 act, int err),
+ TP_PROTO(const struct net_device *dev,
+ const struct bpf_prog *xdp, u32 act,
+ int to_index, int err),
- TP_ARGS(from, to, xdp, act, err),
+ TP_ARGS(dev, xdp, act, to_index, err),
TP_STRUCT__entry(
- __string(name_from, from->name)
- __string(name_to, to->name)
__array(u8, prog_tag, 8)
__field(u32, act)
+ __field(int, ifindex)
+ __field(int, to_index)
__field(int, err)
),
TP_fast_assign(
BUILD_BUG_ON(sizeof(__entry->prog_tag) != sizeof(xdp->tag));
memcpy(__entry->prog_tag, xdp->tag, sizeof(xdp->tag));
- __assign_str(name_from, from->name);
- __assign_str(name_to, to->name);
- __entry->act = act;
- __entry->err = err;
+ __entry->act = act;
+ __entry->ifindex = dev->ifindex;
+ __entry->to_index = to_index;
+ __entry->err = err;
),
- TP_printk("prog=%s from=%s to=%s action=%s err=%d",
+ TP_printk("prog=%s action=%s ifindex=%d to_index=%d err=%d",
__print_hex_str(__entry->prog_tag, 8),
- __get_str(name_from), __get_str(name_to),
__print_symbolic(__entry->act, __XDP_ACT_SYM_TAB),
+ __entry->ifindex, __entry->to_index,
__entry->err)
);
#endif /* _TRACE_XDP_H */
diff --git a/net/core/filter.c b/net/core/filter.c
index 2d7cdb2c5c66..2dbe985aecbb 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -2553,7 +2553,7 @@ int xdp_do_redirect_map(struct net_device *dev, struct xdp_buff *xdp,
ri->map_to_flush = map;
out:
- trace_xdp_redirect(dev, fwd, xdp_prog, XDP_REDIRECT, err);
+ trace_xdp_redirect(dev, xdp_prog, XDP_REDIRECT, index, err);
return err;
}
@@ -2577,7 +2577,7 @@ int xdp_do_redirect(struct net_device *dev, struct xdp_buff *xdp,
err = __bpf_tx_xdp(fwd, NULL, xdp, 0);
out:
- trace_xdp_redirect(dev, fwd, xdp_prog, XDP_REDIRECT, err);
+ trace_xdp_redirect(dev, xdp_prog, XDP_REDIRECT, index, err);
return err;
}
EXPORT_SYMBOL_GPL(xdp_do_redirect);
@@ -2611,7 +2611,7 @@ int xdp_do_generic_redirect(struct net_device *dev, struct sk_buff *skb,
skb->dev = fwd;
out:
- trace_xdp_redirect(dev, fwd, xdp_prog, XDP_REDIRECT, err);
+ trace_xdp_redirect(dev, xdp_prog, XDP_REDIRECT, index, err);
return err;
}
EXPORT_SYMBOL_GPL(xdp_do_generic_redirect);
^ permalink raw reply related
* [V2 PATCH net-next 5/5] xdp: get tracepoints xdp_exception and xdp_redirect in sync
From: Jesper Dangaard Brouer @ 2017-08-23 10:15 UTC (permalink / raw)
To: netdev; +Cc: Daniel Borkmann, John Fastabend, Jesper Dangaard Brouer
In-Reply-To: <150348327373.23476.14851572406177222309.stgit@firesoul>
Remove the net_device string name from the xdp_exception tracepoint,
like the xdp_redirect tracepoint.
Align the TP_STRUCT to have common entries between these two
tracepoint.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
include/trace/events/xdp.h | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/trace/events/xdp.h b/include/trace/events/xdp.h
index cd37706c6f55..27cf2ef35f5f 100644
--- a/include/trace/events/xdp.h
+++ b/include/trace/events/xdp.h
@@ -31,22 +31,22 @@ TRACE_EVENT(xdp_exception,
TP_ARGS(dev, xdp, act),
TP_STRUCT__entry(
- __string(name, dev->name)
__array(u8, prog_tag, 8)
__field(u32, act)
+ __field(int, ifindex)
),
TP_fast_assign(
BUILD_BUG_ON(sizeof(__entry->prog_tag) != sizeof(xdp->tag));
memcpy(__entry->prog_tag, xdp->tag, sizeof(xdp->tag));
- __assign_str(name, dev->name);
- __entry->act = act;
+ __entry->act = act;
+ __entry->ifindex = dev->ifindex;
),
- TP_printk("prog=%s device=%s action=%s",
+ TP_printk("prog=%s action=%s ifindex=%d",
__print_hex_str(__entry->prog_tag, 8),
- __get_str(name),
- __print_symbolic(__entry->act, __XDP_ACT_SYM_TAB))
+ __print_symbolic(__entry->act, __XDP_ACT_SYM_TAB),
+ __entry->ifindex)
);
TRACE_EVENT(xdp_redirect,
^ permalink raw reply related
* [PATCH 0/3] constify dsa_switch_ops
From: Arvind Yadav @ 2017-08-23 10:16 UTC (permalink / raw)
To: andrew, vivien.didelot, f.fainelli; +Cc: linux-kernel, netdev
dsa_switch_ops are not supposed to change at runtime. All functions
working with dsa_switch_ops provided by <net/dsa.h> work with
const dsa_switch_ops. So mark the non-const structs as const.
Arvind Yadav (3):
[PATCH 1/3] net: dsa: loop: constify dsa_switch_ops
[PATCH 2/3] net: dsa: lan9303: constify dsa_switch_ops
[PATCH 3/3] net: dsa: mt7530: constify dsa_switch_ops
drivers/net/dsa/dsa_loop.c | 2 +-
drivers/net/dsa/lan9303-core.c | 2 +-
drivers/net/dsa/mt7530.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/3] net: dsa: loop: constify dsa_switch_ops
From: Arvind Yadav @ 2017-08-23 10:16 UTC (permalink / raw)
To: andrew, vivien.didelot, f.fainelli; +Cc: linux-kernel, netdev
In-Reply-To: <1503483419-21780-1-git-send-email-arvind.yadav.cs@gmail.com>
dsa_switch_ops are not supposed to change at runtime. All functions
working with dsa_switch_ops provided by <net/dsa.h> work with
const dsa_switch_ops. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
drivers/net/dsa/dsa_loop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/dsa_loop.c b/drivers/net/dsa/dsa_loop.c
index fdd8f38..2418172 100644
--- a/drivers/net/dsa/dsa_loop.c
+++ b/drivers/net/dsa/dsa_loop.c
@@ -294,7 +294,7 @@ static int dsa_loop_port_vlan_dump(struct dsa_switch *ds, int port,
return err;
}
-static struct dsa_switch_ops dsa_loop_driver = {
+static const struct dsa_switch_ops dsa_loop_driver = {
.get_tag_protocol = dsa_loop_get_protocol,
.setup = dsa_loop_setup,
.get_strings = dsa_loop_get_strings,
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] net: dsa: lan9303: constify dsa_switch_ops
From: Arvind Yadav @ 2017-08-23 10:16 UTC (permalink / raw)
To: andrew, vivien.didelot, f.fainelli; +Cc: linux-kernel, netdev
In-Reply-To: <1503483419-21780-1-git-send-email-arvind.yadav.cs@gmail.com>
dsa_switch_ops are not supposed to change at runtime. All functions
working with dsa_switch_ops provided by <net/dsa.h> work with
const dsa_switch_ops. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
drivers/net/dsa/lan9303-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index cd76e61..d4820d2 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -780,7 +780,7 @@ static void lan9303_port_disable(struct dsa_switch *ds, int port,
}
}
-static struct dsa_switch_ops lan9303_switch_ops = {
+static const struct dsa_switch_ops lan9303_switch_ops = {
.get_tag_protocol = lan9303_get_tag_protocol,
.setup = lan9303_setup,
.get_strings = lan9303_get_strings,
--
1.9.1
^ permalink raw reply related
* [PATCH 3/3] net: dsa: mt7530: constify dsa_switch_ops
From: Arvind Yadav @ 2017-08-23 10:16 UTC (permalink / raw)
To: andrew, vivien.didelot, f.fainelli; +Cc: linux-kernel, netdev
In-Reply-To: <1503483419-21780-1-git-send-email-arvind.yadav.cs@gmail.com>
dsa_switch_ops are not supposed to change at runtime. All functions
working with dsa_switch_ops provided by <net/dsa.h> work with
const dsa_switch_ops. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
drivers/net/dsa/mt7530.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 264b281..77ae576 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -1039,7 +1039,7 @@ static void mt7530_adjust_link(struct dsa_switch *ds, int port,
return 0;
}
-static struct dsa_switch_ops mt7530_switch_ops = {
+static const struct dsa_switch_ops mt7530_switch_ops = {
.get_tag_protocol = mtk_get_tag_protocol,
.setup = mt7530_setup,
.get_strings = mt7530_get_strings,
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 3/3 v2] net: netlink: constify genl_ops
From: Kalle Valo @ 2017-08-23 10:20 UTC (permalink / raw)
To: Arvind Yadav
Cc: davem, Larry.Finger, chaoming_li, jon.maloy, ying.xue,
linux-kernel, linux-wireless, netdev
In-Reply-To: <1503482923-21640-1-git-send-email-arvind.yadav.cs@gmail.com>
Arvind Yadav <arvind.yadav.cs@gmail.com> writes:
> genl_ops are not supposed to change at runtime. All functions
> working with genl_ops provided by <net/genetlink.h> work with
> const genl_ops. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> ---
> Changes in v2:
> Patch Subject was wrong.
>
> net/tipc/netlink_compat.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
I don't think the title is still misleading. Other patches have used
"tipc:", I think you should use the same:
$ git log --oneline --no-merges -20 net/tipc
41c6d650f653 net: convert sock.sk_refcnt from atomic_t to refcount_t
343eba69c696 net: tipc: Fix a sleep-in-atomic bug in tipc_msg_reverse
844cf763fba6 tipc: make macro tipc_wait_for_cond() smp safe
ec8a09fbbeff tipc: refactor function tipc_sk_recv_stream()
e9f8b10101c6 tipc: refactor function tipc_sk_recvmsg()
c1be7756284b tipc: close the connection if protocol messages contain errors
4e0df4951e9e tipc: improve error validations for sockets in CONNECTING state
42b531de17d2 tipc: Fix missing connection request handling
05ff8378975a tipc: fix socket flow control accounting error at tipc_recv_stream
3364d61c92ec tipc: fix socket flow control accounting error at tipc_send_stream
78302fd40576 tipc: check return value of nlmsg_new
fe52145f91fe netlink: pass extended ACK struct where available
fceb6435e852 netlink: pass extended ACK struct to parsing functions
66bc1e8d5d1d tipc: allow rdm/dgram socketpairs
70b03759e9ec tipc: add support for stream/seqpacket socketpairs
7efea60dcffc tipc: adjust the policy of holding subscription kref
139bb36f754a tipc: advance the time of deleting subscription from subscriber->subscrp_list
557d054c01da tipc: fix nametbl deadlock at tipc_nametbl_unsubscribe
cdfbabfb2f0c net: Work around lockdep limitation in sockets that use sockets
174cd4b1e5fb sched/headers: Prepare to move signal wakeup & sigpending methods from <linux/sched.h> into <linux/sched/signal.h>
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v4] net: sunrpc: svcsock: fix NULL-pointer exception
From: Vadim Lomovtsev @ 2017-08-23 10:24 UTC (permalink / raw)
To: trond.myklebust, anna.schumaker, bfields, jlayton, davem,
linux-nfs, netdev, linux-kernel, pabeni
Cc: vlomovts
In-Reply-To: <1503314587-15420-1-git-send-email-vlomovts@redhat.com>
Hi all,
Any comments on this ?
WBR,
Vadim
On Mon, Aug 21, 2017 at 07:23:07AM -0400, Vadim Lomovtsev wrote:
> While running nfs/connectathon tests kernel NULL-pointer exception
> has been observed due to races in svcsock.c.
>
> Race is appear when kernel accepts connection by kernel_accept
> (which creates new socket) and start queuing ingress packets
> to new socket. This happens in ksoftirq context which could run
> concurrently on a different core while new socket setup is not done yet.
>
> The fix is to re-order socket user data init sequence and add
> write/read barrier calls to be sure that we got proper values
> for callback pointers before actually calling them.
>
> Test results: nfs/connectathon reports '0' failed tests for about 200+ iterations.
>
> Crash log:
> ---<-snip->---
> [ 6708.638984] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> [ 6708.647093] pgd = ffff0000094e0000
> [ 6708.650497] [00000000] *pgd=0000010ffff90003, *pud=0000010ffff90003, *pmd=0000010ffff80003, *pte=0000000000000000
> [ 6708.660761] Internal error: Oops: 86000005 [#1] SMP
> [ 6708.665630] Modules linked in: nfsv3 nfnetlink_queue nfnetlink_log nfnetlink rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache overlay xt_CONNSECMARK xt_SECMARK xt_conntrack iptable_security ip_tables ah4 xfrm4_mode_transport sctp tun binfmt_misc ext4 jbd2 mbcache loop tcp_diag udp_diag inet_diag rpcrdma ib_isert iscsi_target_mod ib_iser rdma_cm iw_cm libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib ib_ucm ib_uverbs ib_umad ib_cm ib_core nls_koi8_u nls_cp932 ts_kmp nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack vfat fat ghash_ce sha2_ce sha1_ce cavium_rng_vf i2c_thunderx sg thunderx_edac i2c_smbus edac_core cavium_rng nfsd auth_rpcgss nfs_acl lockd grace sunrpc xfs libcrc32c nicvf nicpf ast i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgb
lt fb_sys_fops
> [ 6708.736446] ttm drm i2c_core thunder_bgx thunder_xcv mdio_thunder mdio_cavium dm_mirror dm_region_hash dm_log dm_mod [last unloaded: stap_3c300909c5b3f46dcacd49aab3334af_87021]
> [ 6708.752275] CPU: 84 PID: 0 Comm: swapper/84 Tainted: G W OE 4.11.0-4.el7.aarch64 #1
> [ 6708.760787] Hardware name: www.cavium.com CRB-2S/CRB-2S, BIOS 0.3 Mar 13 2017
> [ 6708.767910] task: ffff810006842e80 task.stack: ffff81000689c000
> [ 6708.773822] PC is at 0x0
> [ 6708.776739] LR is at svc_data_ready+0x38/0x88 [sunrpc]
> [ 6708.781866] pc : [<0000000000000000>] lr : [<ffff0000029d7378>] pstate: 60000145
> [ 6708.789248] sp : ffff810ffbad3900
> [ 6708.792551] x29: ffff810ffbad3900 x28: ffff000008c73d58
> [ 6708.797853] x27: 0000000000000000 x26: ffff81000bbe1e00
> [ 6708.803156] x25: 0000000000000020 x24: ffff800f7410bf28
> [ 6708.808458] x23: ffff000008c63000 x22: ffff000008c63000
> [ 6708.813760] x21: ffff800f7410bf28 x20: ffff81000bbe1e00
> [ 6708.819063] x19: ffff810012412400 x18: 00000000d82a9df2
> [ 6708.824365] x17: 0000000000000000 x16: 0000000000000000
> [ 6708.829667] x15: 0000000000000000 x14: 0000000000000001
> [ 6708.834969] x13: 0000000000000000 x12: 722e736f622e676e
> [ 6708.840271] x11: 00000000f814dd99 x10: 0000000000000000
> [ 6708.845573] x9 : 7374687225000000 x8 : 0000000000000000
> [ 6708.850875] x7 : 0000000000000000 x6 : 0000000000000000
> [ 6708.856177] x5 : 0000000000000028 x4 : 0000000000000000
> [ 6708.861479] x3 : 0000000000000000 x2 : 00000000e5000000
> [ 6708.866781] x1 : 0000000000000000 x0 : ffff81000bbe1e00
> [ 6708.872084]
> [ 6708.873565] Process swapper/84 (pid: 0, stack limit = 0xffff81000689c000)
> [ 6708.880341] Stack: (0xffff810ffbad3900 to 0xffff8100068a0000)
> [ 6708.886075] Call trace:
> [ 6708.888513] Exception stack(0xffff810ffbad3710 to 0xffff810ffbad3840)
> [ 6708.894942] 3700: ffff810012412400 0001000000000000
> [ 6708.902759] 3720: ffff810ffbad3900 0000000000000000 0000000060000145 ffff800f79300000
> [ 6708.910577] 3740: ffff000009274d00 00000000000003ea 0000000000000015 ffff000008c63000
> [ 6708.918395] 3760: ffff810ffbad3830 ffff800f79300000 000000000000004d 0000000000000000
> [ 6708.926212] 3780: ffff810ffbad3890 ffff0000080f88dc ffff800f79300000 000000000000004d
> [ 6708.934030] 37a0: ffff800f7930093c ffff000008c63000 0000000000000000 0000000000000140
> [ 6708.941848] 37c0: ffff000008c2c000 0000000000040b00 ffff81000bbe1e00 0000000000000000
> [ 6708.949665] 37e0: 00000000e5000000 0000000000000000 0000000000000000 0000000000000028
> [ 6708.957483] 3800: 0000000000000000 0000000000000000 0000000000000000 7374687225000000
> [ 6708.965300] 3820: 0000000000000000 00000000f814dd99 722e736f622e676e 0000000000000000
> [ 6708.973117] [< (null)>] (null)
> [ 6708.977824] [<ffff0000086f9fa4>] tcp_data_queue+0x754/0xc5c
> [ 6708.983386] [<ffff0000086fa64c>] tcp_rcv_established+0x1a0/0x67c
> [ 6708.989384] [<ffff000008704120>] tcp_v4_do_rcv+0x15c/0x22c
> [ 6708.994858] [<ffff000008707418>] tcp_v4_rcv+0xaf0/0xb58
> [ 6709.000077] [<ffff0000086df784>] ip_local_deliver_finish+0x10c/0x254
> [ 6709.006419] [<ffff0000086dfea4>] ip_local_deliver+0xf0/0xfc
> [ 6709.011980] [<ffff0000086dfad4>] ip_rcv_finish+0x208/0x3a4
> [ 6709.017454] [<ffff0000086e018c>] ip_rcv+0x2dc/0x3c8
> [ 6709.022328] [<ffff000008692fc8>] __netif_receive_skb_core+0x2f8/0xa0c
> [ 6709.028758] [<ffff000008696068>] __netif_receive_skb+0x38/0x84
> [ 6709.034580] [<ffff00000869611c>] netif_receive_skb_internal+0x68/0xdc
> [ 6709.041010] [<ffff000008696bc0>] napi_gro_receive+0xcc/0x1a8
> [ 6709.046690] [<ffff0000014b0fc4>] nicvf_cq_intr_handler+0x59c/0x730 [nicvf]
> [ 6709.053559] [<ffff0000014b1380>] nicvf_poll+0x38/0xb8 [nicvf]
> [ 6709.059295] [<ffff000008697a6c>] net_rx_action+0x2f8/0x464
> [ 6709.064771] [<ffff000008081824>] __do_softirq+0x11c/0x308
> [ 6709.070164] [<ffff0000080d14e4>] irq_exit+0x12c/0x174
> [ 6709.075206] [<ffff00000813101c>] __handle_domain_irq+0x78/0xc4
> [ 6709.081027] [<ffff000008081608>] gic_handle_irq+0x94/0x190
> [ 6709.086501] Exception stack(0xffff81000689fdf0 to 0xffff81000689ff20)
> [ 6709.092929] fde0: 0000810ff2ec0000 ffff000008c10000
> [ 6709.100747] fe00: ffff000008c70ef4 0000000000000001 0000000000000000 ffff810ffbad9b18
> [ 6709.108565] fe20: ffff810ffbad9c70 ffff8100169d3800 ffff810006843ab0 ffff81000689fe80
> [ 6709.116382] fe40: 0000000000000bd0 0000ffffdf979cd0 183f5913da192500 0000ffff8a254ce4
> [ 6709.124200] fe60: 0000ffff8a254b78 0000aaab10339808 0000000000000000 0000ffff8a0c2a50
> [ 6709.132018] fe80: 0000ffffdf979b10 ffff000008d6d450 ffff000008c10000 ffff000008d6d000
> [ 6709.139836] fea0: 0000000000000054 ffff000008cd3dbc 0000000000000000 0000000000000000
> [ 6709.147653] fec0: 0000000000000000 0000000000000000 0000000000000000 ffff81000689ff20
> [ 6709.155471] fee0: ffff000008085240 ffff81000689ff20 ffff000008085244 0000000060000145
> [ 6709.163289] ff00: ffff81000689ff10 ffff00000813f1e4 ffffffffffffffff ffff00000813f238
> [ 6709.171107] [<ffff000008082eb4>] el1_irq+0xb4/0x140
> [ 6709.175976] [<ffff000008085244>] arch_cpu_idle+0x44/0x11c
> [ 6709.181368] [<ffff0000087bf3b8>] default_idle_call+0x20/0x30
> [ 6709.187020] [<ffff000008116d50>] do_idle+0x158/0x1e4
> [ 6709.191973] [<ffff000008116ff4>] cpu_startup_entry+0x2c/0x30
> [ 6709.197624] [<ffff00000808e7cc>] secondary_start_kernel+0x13c/0x160
> [ 6709.203878] [<0000000001bc71c4>] 0x1bc71c4
> [ 6709.207967] Code: bad PC value
> [ 6709.211061] SMP: stopping secondary CPUs
> [ 6709.218830] Starting crashdump kernel...
> [ 6709.222749] Bye!
> ---<-snip>---
>
> Signed-off-by: Vadim Lomovtsev <vlomovts@redhat.com>
> Reviewed-by: Jeff Layton <jlayton@redhat.com>
> ---
> net/sunrpc/svcsock.c | 22 ++++++++++++++++++++--
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
> index 2b720fa..e185001 100644
> --- a/net/sunrpc/svcsock.c
> +++ b/net/sunrpc/svcsock.c
> @@ -421,6 +421,9 @@ static void svc_data_ready(struct sock *sk)
> dprintk("svc: socket %p(inet %p), busy=%d\n",
> svsk, sk,
> test_bit(XPT_BUSY, &svsk->sk_xprt.xpt_flags));
> +
> + /* Refer to svc_setup_socket() for details. */
> + rmb();
> svsk->sk_odata(sk);
> if (!test_and_set_bit(XPT_DATA, &svsk->sk_xprt.xpt_flags))
> svc_xprt_enqueue(&svsk->sk_xprt);
> @@ -437,6 +440,9 @@ static void svc_write_space(struct sock *sk)
> if (svsk) {
> dprintk("svc: socket %p(inet %p), write_space busy=%d\n",
> svsk, sk, test_bit(XPT_BUSY, &svsk->sk_xprt.xpt_flags));
> +
> + /* Refer to svc_setup_socket() for details. */
> + rmb();
> svsk->sk_owspace(sk);
> svc_xprt_enqueue(&svsk->sk_xprt);
> }
> @@ -760,8 +766,12 @@ static void svc_tcp_listen_data_ready(struct sock *sk)
> dprintk("svc: socket %p TCP (listen) state change %d\n",
> sk, sk->sk_state);
>
> - if (svsk)
> + if (svsk) {
> + /* Refer to svc_setup_socket() for details. */
> + rmb();
> svsk->sk_odata(sk);
> + }
> +
> /*
> * This callback may called twice when a new connection
> * is established as a child socket inherits everything
> @@ -794,6 +804,8 @@ static void svc_tcp_state_change(struct sock *sk)
> if (!svsk)
> printk("svc: socket %p: no user data\n", sk);
> else {
> + /* Refer to svc_setup_socket() for details. */
> + rmb();
> svsk->sk_ostate(sk);
> if (sk->sk_state != TCP_ESTABLISHED) {
> set_bit(XPT_CLOSE, &svsk->sk_xprt.xpt_flags);
> @@ -1381,12 +1393,18 @@ static struct svc_sock *svc_setup_socket(struct svc_serv *serv,
> return ERR_PTR(err);
> }
>
> - inet->sk_user_data = svsk;
> svsk->sk_sock = sock;
> svsk->sk_sk = inet;
> svsk->sk_ostate = inet->sk_state_change;
> svsk->sk_odata = inet->sk_data_ready;
> svsk->sk_owspace = inet->sk_write_space;
> + /*
> + * This barrier is necessary in order to prevent race condition
> + * with svc_data_ready(), svc_listen_data_ready() and others
> + * when calling callbacks above.
> + */
> + wmb();
> + inet->sk_user_data = svsk;
>
> /* Initialize the socket */
> if (sock->type == SOCK_DGRAM)
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH 3/3 v2] net: netlink: constify genl_ops
From: Arvind Yadav @ 2017-08-23 10:24 UTC (permalink / raw)
To: Kalle Valo
Cc: davem, Larry.Finger, chaoming_li, jon.maloy, ying.xue,
linux-kernel, linux-wireless, netdev
In-Reply-To: <87y3qawpp1.fsf@kamboji.qca.qualcomm.com>
Hi Kalle,
On Wednesday 23 August 2017 03:50 PM, Kalle Valo wrote:
> Arvind Yadav <arvind.yadav.cs@gmail.com> writes:
>
>> genl_ops are not supposed to change at runtime. All functions
>> working with genl_ops provided by <net/genetlink.h> work with
>> const genl_ops. So mark the non-const structs as const.
>>
>> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
>> ---
>> Changes in v2:
>> Patch Subject was wrong.
>>
>> net/tipc/netlink_compat.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
> I don't think the title is still misleading. Other patches have used
> "tipc:", I think you should use the same:
Ok, I will update as per your suggestion.
>
> $ git log --oneline --no-merges -20 net/tipc
> 41c6d650f653 net: convert sock.sk_refcnt from atomic_t to refcount_t
> 343eba69c696 net: tipc: Fix a sleep-in-atomic bug in tipc_msg_reverse
> 844cf763fba6 tipc: make macro tipc_wait_for_cond() smp safe
> ec8a09fbbeff tipc: refactor function tipc_sk_recv_stream()
> e9f8b10101c6 tipc: refactor function tipc_sk_recvmsg()
> c1be7756284b tipc: close the connection if protocol messages contain errors
> 4e0df4951e9e tipc: improve error validations for sockets in CONNECTING state
> 42b531de17d2 tipc: Fix missing connection request handling
> 05ff8378975a tipc: fix socket flow control accounting error at tipc_recv_stream
> 3364d61c92ec tipc: fix socket flow control accounting error at tipc_send_stream
> 78302fd40576 tipc: check return value of nlmsg_new
> fe52145f91fe netlink: pass extended ACK struct where available
> fceb6435e852 netlink: pass extended ACK struct to parsing functions
> 66bc1e8d5d1d tipc: allow rdm/dgram socketpairs
> 70b03759e9ec tipc: add support for stream/seqpacket socketpairs
> 7efea60dcffc tipc: adjust the policy of holding subscription kref
> 139bb36f754a tipc: advance the time of deleting subscription from subscriber->subscrp_list
> 557d054c01da tipc: fix nametbl deadlock at tipc_nametbl_unsubscribe
> cdfbabfb2f0c net: Work around lockdep limitation in sockets that use sockets
> 174cd4b1e5fb sched/headers: Prepare to move signal wakeup & sigpending methods from <linux/sched.h> into <linux/sched/signal.h>
>
~arvind
^ permalink raw reply
* Re: [PATCH v4] net: sunrpc: svcsock: fix NULL-pointer exception
From: Jeff Layton @ 2017-08-23 10:33 UTC (permalink / raw)
To: Vadim Lomovtsev, trond.myklebust, anna.schumaker, bfields, davem,
linux-nfs, netdev, linux-kernel, pabeni
In-Reply-To: <20170823102403.GF1443@dhcp187-32.khw.lab.eng.bos.redhat.com>
On Wed, 2017-08-23 at 06:24 -0400, Vadim Lomovtsev wrote:
> Hi all,
>
> Any comments on this ?
>
> WBR,
> Vadim
>
> On Mon, Aug 21, 2017 at 07:23:07AM -0400, Vadim Lomovtsev wrote:
> > While running nfs/connectathon tests kernel NULL-pointer exception
> > has been observed due to races in svcsock.c.
> >
> > Race is appear when kernel accepts connection by kernel_accept
> > (which creates new socket) and start queuing ingress packets
> > to new socket. This happens in ksoftirq context which could run
> > concurrently on a different core while new socket setup is not done yet.
> >
> > The fix is to re-order socket user data init sequence and add
> > write/read barrier calls to be sure that we got proper values
> > for callback pointers before actually calling them.
> >
> > Test results: nfs/connectathon reports '0' failed tests for about 200+ iterations.
> >
> > Crash log:
> > ---<-snip->---
> > [ 6708.638984] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> > [ 6708.647093] pgd = ffff0000094e0000
> > [ 6708.650497] [00000000] *pgd=0000010ffff90003, *pud=0000010ffff90003, *pmd=0000010ffff80003, *pte=0000000000000000
> > [ 6708.660761] Internal error: Oops: 86000005 [#1] SMP
> > [ 6708.665630] Modules linked in: nfsv3 nfnetlink_queue nfnetlink_log nfnetlink rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache overlay xt_CONNSECMARK xt_SECMARK xt_conntrack iptable_security ip_tables ah4 xfrm4_mode_transport sctp tun binfmt_misc ext4 jbd2 mbcache loop tcp_diag udp_diag inet_diag rpcrdma ib_isert iscsi_target_mod ib_iser rdma_cm iw_cm libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib ib_ucm ib_uverbs ib_umad ib_cm ib_core nls_koi8_u nls_cp932 ts_kmp nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack vfat fat ghash_ce sha2_ce sha1_ce cavium_rng_vf i2c_thunderx sg thunderx_edac i2c_smbus edac_core cavium_rng nfsd auth_rpcgss nfs_acl lockd grace sunrpc xfs libcrc32c nicvf nicpf ast i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysim
gblt fb_sys_fops
> > [ 6708.736446] ttm drm i2c_core thunder_bgx thunder_xcv mdio_thunder mdio_cavium dm_mirror dm_region_hash dm_log dm_mod [last unloaded: stap_3c300909c5b3f46dcacd49aab3334af_87021]
> > [ 6708.752275] CPU: 84 PID: 0 Comm: swapper/84 Tainted: G W OE 4.11.0-4.el7.aarch64 #1
> > [ 6708.760787] Hardware name: www.cavium.com CRB-2S/CRB-2S, BIOS 0.3 Mar 13 2017
> > [ 6708.767910] task: ffff810006842e80 task.stack: ffff81000689c000
> > [ 6708.773822] PC is at 0x0
> > [ 6708.776739] LR is at svc_data_ready+0x38/0x88 [sunrpc]
> > [ 6708.781866] pc : [<0000000000000000>] lr : [<ffff0000029d7378>] pstate: 60000145
> > [ 6708.789248] sp : ffff810ffbad3900
> > [ 6708.792551] x29: ffff810ffbad3900 x28: ffff000008c73d58
> > [ 6708.797853] x27: 0000000000000000 x26: ffff81000bbe1e00
> > [ 6708.803156] x25: 0000000000000020 x24: ffff800f7410bf28
> > [ 6708.808458] x23: ffff000008c63000 x22: ffff000008c63000
> > [ 6708.813760] x21: ffff800f7410bf28 x20: ffff81000bbe1e00
> > [ 6708.819063] x19: ffff810012412400 x18: 00000000d82a9df2
> > [ 6708.824365] x17: 0000000000000000 x16: 0000000000000000
> > [ 6708.829667] x15: 0000000000000000 x14: 0000000000000001
> > [ 6708.834969] x13: 0000000000000000 x12: 722e736f622e676e
> > [ 6708.840271] x11: 00000000f814dd99 x10: 0000000000000000
> > [ 6708.845573] x9 : 7374687225000000 x8 : 0000000000000000
> > [ 6708.850875] x7 : 0000000000000000 x6 : 0000000000000000
> > [ 6708.856177] x5 : 0000000000000028 x4 : 0000000000000000
> > [ 6708.861479] x3 : 0000000000000000 x2 : 00000000e5000000
> > [ 6708.866781] x1 : 0000000000000000 x0 : ffff81000bbe1e00
> > [ 6708.872084]
> > [ 6708.873565] Process swapper/84 (pid: 0, stack limit = 0xffff81000689c000)
> > [ 6708.880341] Stack: (0xffff810ffbad3900 to 0xffff8100068a0000)
> > [ 6708.886075] Call trace:
> > [ 6708.888513] Exception stack(0xffff810ffbad3710 to 0xffff810ffbad3840)
> > [ 6708.894942] 3700: ffff810012412400 0001000000000000
> > [ 6708.902759] 3720: ffff810ffbad3900 0000000000000000 0000000060000145 ffff800f79300000
> > [ 6708.910577] 3740: ffff000009274d00 00000000000003ea 0000000000000015 ffff000008c63000
> > [ 6708.918395] 3760: ffff810ffbad3830 ffff800f79300000 000000000000004d 0000000000000000
> > [ 6708.926212] 3780: ffff810ffbad3890 ffff0000080f88dc ffff800f79300000 000000000000004d
> > [ 6708.934030] 37a0: ffff800f7930093c ffff000008c63000 0000000000000000 0000000000000140
> > [ 6708.941848] 37c0: ffff000008c2c000 0000000000040b00 ffff81000bbe1e00 0000000000000000
> > [ 6708.949665] 37e0: 00000000e5000000 0000000000000000 0000000000000000 0000000000000028
> > [ 6708.957483] 3800: 0000000000000000 0000000000000000 0000000000000000 7374687225000000
> > [ 6708.965300] 3820: 0000000000000000 00000000f814dd99 722e736f622e676e 0000000000000000
> > [ 6708.973117] [< (null)>] (null)
> > [ 6708.977824] [<ffff0000086f9fa4>] tcp_data_queue+0x754/0xc5c
> > [ 6708.983386] [<ffff0000086fa64c>] tcp_rcv_established+0x1a0/0x67c
> > [ 6708.989384] [<ffff000008704120>] tcp_v4_do_rcv+0x15c/0x22c
> > [ 6708.994858] [<ffff000008707418>] tcp_v4_rcv+0xaf0/0xb58
> > [ 6709.000077] [<ffff0000086df784>] ip_local_deliver_finish+0x10c/0x254
> > [ 6709.006419] [<ffff0000086dfea4>] ip_local_deliver+0xf0/0xfc
> > [ 6709.011980] [<ffff0000086dfad4>] ip_rcv_finish+0x208/0x3a4
> > [ 6709.017454] [<ffff0000086e018c>] ip_rcv+0x2dc/0x3c8
> > [ 6709.022328] [<ffff000008692fc8>] __netif_receive_skb_core+0x2f8/0xa0c
> > [ 6709.028758] [<ffff000008696068>] __netif_receive_skb+0x38/0x84
> > [ 6709.034580] [<ffff00000869611c>] netif_receive_skb_internal+0x68/0xdc
> > [ 6709.041010] [<ffff000008696bc0>] napi_gro_receive+0xcc/0x1a8
> > [ 6709.046690] [<ffff0000014b0fc4>] nicvf_cq_intr_handler+0x59c/0x730 [nicvf]
> > [ 6709.053559] [<ffff0000014b1380>] nicvf_poll+0x38/0xb8 [nicvf]
> > [ 6709.059295] [<ffff000008697a6c>] net_rx_action+0x2f8/0x464
> > [ 6709.064771] [<ffff000008081824>] __do_softirq+0x11c/0x308
> > [ 6709.070164] [<ffff0000080d14e4>] irq_exit+0x12c/0x174
> > [ 6709.075206] [<ffff00000813101c>] __handle_domain_irq+0x78/0xc4
> > [ 6709.081027] [<ffff000008081608>] gic_handle_irq+0x94/0x190
> > [ 6709.086501] Exception stack(0xffff81000689fdf0 to 0xffff81000689ff20)
> > [ 6709.092929] fde0: 0000810ff2ec0000 ffff000008c10000
> > [ 6709.100747] fe00: ffff000008c70ef4 0000000000000001 0000000000000000 ffff810ffbad9b18
> > [ 6709.108565] fe20: ffff810ffbad9c70 ffff8100169d3800 ffff810006843ab0 ffff81000689fe80
> > [ 6709.116382] fe40: 0000000000000bd0 0000ffffdf979cd0 183f5913da192500 0000ffff8a254ce4
> > [ 6709.124200] fe60: 0000ffff8a254b78 0000aaab10339808 0000000000000000 0000ffff8a0c2a50
> > [ 6709.132018] fe80: 0000ffffdf979b10 ffff000008d6d450 ffff000008c10000 ffff000008d6d000
> > [ 6709.139836] fea0: 0000000000000054 ffff000008cd3dbc 0000000000000000 0000000000000000
> > [ 6709.147653] fec0: 0000000000000000 0000000000000000 0000000000000000 ffff81000689ff20
> > [ 6709.155471] fee0: ffff000008085240 ffff81000689ff20 ffff000008085244 0000000060000145
> > [ 6709.163289] ff00: ffff81000689ff10 ffff00000813f1e4 ffffffffffffffff ffff00000813f238
> > [ 6709.171107] [<ffff000008082eb4>] el1_irq+0xb4/0x140
> > [ 6709.175976] [<ffff000008085244>] arch_cpu_idle+0x44/0x11c
> > [ 6709.181368] [<ffff0000087bf3b8>] default_idle_call+0x20/0x30
> > [ 6709.187020] [<ffff000008116d50>] do_idle+0x158/0x1e4
> > [ 6709.191973] [<ffff000008116ff4>] cpu_startup_entry+0x2c/0x30
> > [ 6709.197624] [<ffff00000808e7cc>] secondary_start_kernel+0x13c/0x160
> > [ 6709.203878] [<0000000001bc71c4>] 0x1bc71c4
> > [ 6709.207967] Code: bad PC value
> > [ 6709.211061] SMP: stopping secondary CPUs
> > [ 6709.218830] Starting crashdump kernel...
> > [ 6709.222749] Bye!
> > ---<-snip>---
> >
> > Signed-off-by: Vadim Lomovtsev <vlomovts@redhat.com>
> > Reviewed-by: Jeff Layton <jlayton@redhat.com>
> > ---
> > net/sunrpc/svcsock.c | 22 ++++++++++++++++++++--
> > 1 file changed, 20 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
> > index 2b720fa..e185001 100644
> > --- a/net/sunrpc/svcsock.c
> > +++ b/net/sunrpc/svcsock.c
> > @@ -421,6 +421,9 @@ static void svc_data_ready(struct sock *sk)
> > dprintk("svc: socket %p(inet %p), busy=%d\n",
> > svsk, sk,
> > test_bit(XPT_BUSY, &svsk->sk_xprt.xpt_flags));
> > +
> > + /* Refer to svc_setup_socket() for details. */
> > + rmb();
> > svsk->sk_odata(sk);
> > if (!test_and_set_bit(XPT_DATA, &svsk->sk_xprt.xpt_flags))
> > svc_xprt_enqueue(&svsk->sk_xprt);
> > @@ -437,6 +440,9 @@ static void svc_write_space(struct sock *sk)
> > if (svsk) {
> > dprintk("svc: socket %p(inet %p), write_space busy=%d\n",
> > svsk, sk, test_bit(XPT_BUSY, &svsk->sk_xprt.xpt_flags));
> > +
> > + /* Refer to svc_setup_socket() for details. */
> > + rmb();
> > svsk->sk_owspace(sk);
> > svc_xprt_enqueue(&svsk->sk_xprt);
> > }
> > @@ -760,8 +766,12 @@ static void svc_tcp_listen_data_ready(struct sock *sk)
> > dprintk("svc: socket %p TCP (listen) state change %d\n",
> > sk, sk->sk_state);
> >
> > - if (svsk)
> > + if (svsk) {
> > + /* Refer to svc_setup_socket() for details. */
> > + rmb();
> > svsk->sk_odata(sk);
> > + }
> > +
> > /*
> > * This callback may called twice when a new connection
> > * is established as a child socket inherits everything
> > @@ -794,6 +804,8 @@ static void svc_tcp_state_change(struct sock *sk)
> > if (!svsk)
> > printk("svc: socket %p: no user data\n", sk);
> > else {
> > + /* Refer to svc_setup_socket() for details. */
> > + rmb();
> > svsk->sk_ostate(sk);
> > if (sk->sk_state != TCP_ESTABLISHED) {
> > set_bit(XPT_CLOSE, &svsk->sk_xprt.xpt_flags);
> > @@ -1381,12 +1393,18 @@ static struct svc_sock *svc_setup_socket(struct svc_serv *serv,
> > return ERR_PTR(err);
> > }
> >
> > - inet->sk_user_data = svsk;
> > svsk->sk_sock = sock;
> > svsk->sk_sk = inet;
> > svsk->sk_ostate = inet->sk_state_change;
> > svsk->sk_odata = inet->sk_data_ready;
> > svsk->sk_owspace = inet->sk_write_space;
> > + /*
> > + * This barrier is necessary in order to prevent race condition
> > + * with svc_data_ready(), svc_listen_data_ready() and others
> > + * when calling callbacks above.
> > + */
> > + wmb();
> > + inet->sk_user_data = svsk;
> >
> > /* Initialize the socket */
> > if (sock->type == SOCK_DGRAM)
> > --
> > 1.8.3.1
> >
I think this one looks fine. Bruce, do you mind picking this one up? It
might also be reasonable for stable...
--
Jeff Layton <jlayton@redhat.com>
^ permalink raw reply
* Re: [PATCH V8 net-next 00/22] Huawei HiNIC Ethernet Driver
From: Arnd Bergmann @ 2017-08-23 10:37 UTC (permalink / raw)
To: Aviad Krawczyk
Cc: David Miller, Linux Kernel Mailing List, Networking, bc.y,
victor.gissin, zhaochen6, tony.qu
In-Reply-To: <e8db1165-06da-324a-37e5-13d670fb0499@huawei.com>
On Wed, Aug 23, 2017 at 11:31 AM, Aviad Krawczyk
<aviad.krawczyk@huawei.com> wrote:
> Hi Arnd,
>
> This is Huawei's PCIE HiNIC card.
>
> I am not familiar with the HiSilicon product and I don't see how
> Huawei's PCIE HiNIC card is connected to the HiSilicon drivers on Linux Tree.
>
> I don't see how it can be shared: different product and different code.
Sharing code was just a wild thought of mine, as I said I had not looked at
whether there is anything that can be shared.
However, simply moving drivers/net/ethernet/huawei/hinic to
drivers/net/ethernet/hisilicon/hinic/ still seems to be the right thing and
is a trivial patch.
It's clear that hinic is made by HiSilicon and that hns/hns3 are used
exclusively in Huawei, and maintained by Huawei developers, so it's
probably just a matter of time before the IP block from the SoC makes
it into a future PCI device or vice versa. Merging the two directories
now makes this easier to handle in the future and (slightly) reduces
the clutter in the top-level drivers/net/ethernet/Kconfig file.
Arnd
^ permalink raw reply
* RE: [EXT] Re: [PATCH net-next 03/18] net: mvpp2: set the SMI PHY address when connecting to the PHY
From: Stefan Chulski @ 2017-08-23 10:40 UTC (permalink / raw)
To: Andrew Lunn, Antoine Tenart
Cc: davem@davemloft.net, jason@lakedaemon.net,
gregory.clement@free-electrons.com,
sebastian.hesselbarth@gmail.com,
thomas.petazzoni@free-electrons.com, Nadav Haklai,
linux@armlinux.org.uk, mw@semihalf.com, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170728042153.GH18666@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Friday, July 28, 2017 7:22 AM
> To: Antoine Tenart <antoine.tenart@free-electrons.com>
> Cc: davem@davemloft.net; jason@lakedaemon.net; gregory.clement@free-
> electrons.com; sebastian.hesselbarth@gmail.com; thomas.petazzoni@free-
> electrons.com; Nadav Haklai <nadavh@marvell.com>; linux@armlinux.org.uk;
> mw@semihalf.com; Stefan Chulski <stefanc@marvell.com>;
> netdev@vger.kernel.org; linux-arm-kernel@lists.infradead.org
> Subject: [EXT] Re: [PATCH net-next 03/18] net: mvpp2: set the SMI PHY address
> when connecting to the PHY
>
> External Email
>
> ----------------------------------------------------------------------
> On Thu, Jul 27, 2017 at 06:49:05PM -0700, Antoine Tenart wrote:
> > Hi Andrew,
> >
> > On Wed, Jul 26, 2017 at 06:08:06PM +0200, Andrew Lunn wrote:
> > > On Mon, Jul 24, 2017 at 03:48:33PM +0200, Antoine Tenart wrote:
> > > >
> > > > + if (priv->hw_version != MVPP22)
> > > > + return 0;
> > > > +
> > > > + /* Set the SMI PHY address */
> > > > + if (of_property_read_u32(port->phy_node, "reg", &phy_addr)) {
> > > > + netdev_err(port->dev, "cannot find the PHY address\n");
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + writel(phy_addr, priv->iface_base +
> > > > +MVPP22_SMI_PHY_ADDR(port->gop_id));
> > > > return 0;
> > > > }
> > >
> > > You could use phy_dev->mdiodev->addr, rather than parse the DT.
> >
> > OK.
> >
> > > Why does the MAC need to know this address? The phylib and PHY
> > > driver should be the only thing accessing the PHY, otherwise you are
> > > asking for trouble.
> >
> > This is part of the SMI/xSMI interface. I added into the mvpp2 driver
> > and not in the mvmdio one because the GoP port number must be known to
> > set this register (so that would be even less clean to do it).
>
> Hi Antoine
>
> It is still not clear to my why you need to program the address into the
> hardware. Is the hardware talking to the PHY?
>
> Andrew
Hi Andrew,
This register configures SMI(Serial Management Interface) hardware unit, not PPv2(Packet Processor) hardware unit.
The SB incorporates the following SMI management interfaces:
MDC - Serial Management Interface Clock , MDIO - Serial Management Interface Data and complies with IEEE 802.3 Clause 22.
SMI interface used for:
1. PHY register read/write.
The device provides a mechanism for PHY registers read and write access.
2. Auto-Negotiation with PHY devices connected to the GMAC ports.
The device uses a standard master Serial Management Interface for reading from/writing to the PHY
registers. In addition, the PHY polling unit performs Auto-Negotiation status update with PHY devices attached
to the Network ports via the Master SMI Interface.
The device polls the Status register of each PHY in a round-robin manner.
If the device detects a change in the link from down to up on 1 of the ports, it performs a series of
register reads from the PHY and updates the Auto-Negotiation results in the device's registers. The
Port MAC Status register is updated with these results only if Auto-Negotiation is enabled.
So SMI interface should know GoP(MAC) id.
Regards,
Stefan.
^ permalink raw reply
* Re: [RFC PATCH v2 3/6] [net-next]net: i40e: Extend set switch config command to accept cloud filter mode
From: Jeff Kirsher @ 2017-08-23 10:43 UTC (permalink / raw)
To: Amritha Nambiar, intel-wired-lan
Cc: alexander.h.duyck, kiran.patil, netdev, mitch.a.williams,
alexander.duyck, neerav.parikh, sridhar.samudrala,
carolyn.wyborny
In-Reply-To: <150296562149.16910.5659916522674039966.stgit@anamdev.jf.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]
On Thu, 2017-08-17 at 03:27 -0700, Amritha Nambiar wrote:
> Add definitions for L4 filters and switch modes based on cloud
> filters
> modes and extend the set switch config command to include the
> additional cloud filter mode.
>
> Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com>
> Signed-off-by: Kiran Patil <kiran.patil@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h | 31
> ++++++++++++++++++++-
> drivers/net/ethernet/intel/i40e/i40e_common.c | 4 ++-
> drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 2 +
> drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +
> drivers/net/ethernet/intel/i40e/i40e_prototype.h | 2 +
> drivers/net/ethernet/intel/i40e/i40e_type.h | 9 ++++++
> 6 files changed, 45 insertions(+), 5 deletions(-)
Unfortunately, this does not apply (not even close). Since you are
needing to make changes to the first set of 6 patches, please rebase
your entire set of patches to my latest tree and that should fix the
issue.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH V8 net-next 00/22] Huawei HiNIC Ethernet Driver
From: Aviad Krawczyk @ 2017-08-23 10:46 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David Miller, Linux Kernel Mailing List, Networking, bc.y,
victor.gissin, zhaochen6, tony.qu
In-Reply-To: <CAK8P3a0St2mZ7q33zccHZ1uPyv0FKf2A+q+cMk+LN_L_qjxfkg@mail.gmail.com>
Hi,
> It's clear that ...
Sorry, but there are wrong assumptions here.
Thanks,
Aviad
On 8/23/2017 1:37 PM, Arnd Bergmann wrote:
> On Wed, Aug 23, 2017 at 11:31 AM, Aviad Krawczyk
> <aviad.krawczyk@huawei.com> wrote:
>> Hi Arnd,
>>
>> This is Huawei's PCIE HiNIC card.
>>
>> I am not familiar with the HiSilicon product and I don't see how
>> Huawei's PCIE HiNIC card is connected to the HiSilicon drivers on Linux Tree.
>>
>> I don't see how it can be shared: different product and different code.
>
> Sharing code was just a wild thought of mine, as I said I had not looked at
> whether there is anything that can be shared.
>
> However, simply moving drivers/net/ethernet/huawei/hinic to
> drivers/net/ethernet/hisilicon/hinic/ still seems to be the right thing and
> is a trivial patch.
>
> It's clear that hinic is made by HiSilicon and that hns/hns3 are used
> exclusively in Huawei, and maintained by Huawei developers, so it's
> probably just a matter of time before the IP block from the SoC makes
> it into a future PCI device or vice versa. Merging the two directories
> now makes this easier to handle in the future and (slightly) reduces
> the clutter in the top-level drivers/net/ethernet/Kconfig file.
>
> Arnd
>
> .
>
^ permalink raw reply
* [PATCH 3/3 v3] net: tipc: constify genl_ops
From: Arvind Yadav @ 2017-08-23 10:52 UTC (permalink / raw)
To: davem, Larry.Finger, chaoming_li, kvalo, jon.maloy, ying.xue
Cc: linux-kernel, linux-wireless, netdev
genl_ops are not supposed to change at runtime. All functions
working with genl_ops provided by <net/genetlink.h> work with
const genl_ops. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
Changes in v2:
Patch Subject was wrong.
changes in v3 :
Updated patch subject as per comment.
net/tipc/netlink_compat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/tipc/netlink_compat.c b/net/tipc/netlink_compat.c
index 750949d..e48f0b2 100644
--- a/net/tipc/netlink_compat.c
+++ b/net/tipc/netlink_compat.c
@@ -1217,7 +1217,7 @@ static int tipc_nl_compat_recv(struct sk_buff *skb, struct genl_info *info)
return err;
}
-static struct genl_ops tipc_genl_compat_ops[] = {
+static const struct genl_ops tipc_genl_compat_ops[] = {
{
.cmd = TIPC_GENL_CMD,
.doit = tipc_nl_compat_recv,
--
1.9.1
^ permalink raw reply related
* Re: [V2 PATCH net-next 4/5] xdp: remove net_device names from xdp_redirect tracepoint
From: Daniel Borkmann @ 2017-08-23 10:58 UTC (permalink / raw)
To: Jesper Dangaard Brouer, netdev; +Cc: Daniel Borkmann, John Fastabend
In-Reply-To: <150348333529.23476.10681237706586293307.stgit@firesoul>
On 08/23/2017 12:15 PM, Jesper Dangaard Brouer wrote:
> There is too much overhead in the current trace_xdp_redirect
> tracepoint as it does strcpy and strlen on the net_device names.
>
> Besides, exposing the ifindex/index is actually the information that
> is needed in the tracepoint to diagnose issues. When a lookup fails
> (either ifindex or devmap index) then there is a need for saying which
> to_index that have issues.
>
> V2: Adjust args to be aligned with trace_xdp_exception.
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ 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