* [PATCH net-next 08/10] bpf: nfp: Report bpf_prog ID during XDP_QUERY_PROG
From: Martin KaFai Lau @ 2017-06-13 1:00 UTC (permalink / raw)
To: netdev; +Cc: Alexei Starovoitov, Daniel Borkmann, kernel-team, Jakub Kicinski
In-Reply-To: <20170613010025.2983342-1-kafai@fb.com>
Add support to nfp to report bpf_prog ID during XDP_QUERY_PROG.
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
Acked-by: Alexei Starovoitov <ast@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
---
drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
index 49d1756d6a8e..e4d175853dc7 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -3254,9 +3254,16 @@ static int nfp_net_xdp(struct net_device *netdev, struct netdev_xdp *xdp)
switch (xdp->command) {
case XDP_SETUP_PROG:
return nfp_net_xdp_setup(nn, xdp);
- case XDP_QUERY_PROG:
- xdp->prog_attached = !!nn->dp.xdp_prog;
+ case XDP_QUERY_PROG: {
+ const struct bpf_prog *xdp_prog;
+
+ xdp_prog = READ_ONCE(nn->dp.xdp_prog);
+ if (xdp_prog)
+ xdp->prog_id = xdp_prog->aux->id;
+ else
+ xdp->prog_id = 0;
return 0;
+ }
default:
return -EINVAL;
}
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 09/10] bpf: qede: Report bpf_prog ID during XDP_QUERY_PROG
From: Martin KaFai Lau @ 2017-06-13 1:00 UTC (permalink / raw)
To: netdev; +Cc: Alexei Starovoitov, Daniel Borkmann, kernel-team, Mintz, Yuval
In-Reply-To: <20170613010025.2983342-1-kafai@fb.com>
Add support to qede to report bpf_prog ID during XDP_QUERY_PROG.
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Cc: Mintz, Yuval <Yuval.Mintz@cavium.com>
Acked-by: Alexei Starovoitov <ast@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
---
drivers/net/ethernet/qlogic/qede/qede_filter.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_filter.c b/drivers/net/ethernet/qlogic/qede/qede_filter.c
index 13955a3bd3b3..26b652ae5ec1 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_filter.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_filter.c
@@ -1035,9 +1035,16 @@ int qede_xdp(struct net_device *dev, struct netdev_xdp *xdp)
switch (xdp->command) {
case XDP_SETUP_PROG:
return qede_xdp_set(edev, xdp->prog);
- case XDP_QUERY_PROG:
- xdp->prog_attached = !!edev->xdp_prog;
+ case XDP_QUERY_PROG: {
+ const struct bpf_prog *xdp_prog;
+
+ xdp_prog = READ_ONCE(edev->xdp_prog);
+ if (xdp_prog)
+ xdp->prog_id = xdp_prog->aux->id;
+ else
+ xdp->prog_id = 0;
return 0;
+ }
default:
return -EINVAL;
}
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 10/10] net: Remove prog_attached from struct netdev_xdp
From: Martin KaFai Lau @ 2017-06-13 1:00 UTC (permalink / raw)
To: netdev; +Cc: Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20170613010025.2983342-1-kafai@fb.com>
prog_attached can be implied by prog_id (!!prog_id) and
all drivers supporting xdp has been stopped setting prog_attached.
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Alexei Starovoitov <ast@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
---
include/linux/netdevice.h | 5 ++---
net/core/dev.c | 14 ++++----------
net/core/rtnetlink.c | 7 +++++--
3 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index dec4a2f25c2e..a4ac0821b903 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -824,9 +824,8 @@ struct netdev_xdp {
struct netlink_ext_ack *extack;
};
/* XDP_QUERY_PROG */
- bool prog_attached;
+ u32 prog_id;
};
- u32 prog_id;
};
#ifdef CONFIG_XFRM_OFFLOAD
@@ -3303,7 +3302,7 @@ struct sk_buff *dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
typedef int (*xdp_op_t)(struct net_device *dev, struct netdev_xdp *xdp);
int dev_change_xdp_fd(struct net_device *dev, struct netlink_ext_ack *extack,
int fd, u32 flags);
-bool __dev_xdp_attached(struct net_device *dev, xdp_op_t xdp_op, u32 *prog_id);
+u32 __dev_xdp_attached(struct net_device *dev, xdp_op_t xdp_op);
int __dev_forward_skb(struct net_device *dev, struct sk_buff *skb);
int dev_forward_skb(struct net_device *dev, struct sk_buff *skb);
diff --git a/net/core/dev.c b/net/core/dev.c
index aa7c6eba5af6..a484f946267c 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6931,8 +6931,7 @@ int dev_change_proto_down(struct net_device *dev, bool proto_down)
}
EXPORT_SYMBOL(dev_change_proto_down);
-bool __dev_xdp_attached(struct net_device *dev, xdp_op_t xdp_op,
- u32 *prog_id)
+u32 __dev_xdp_attached(struct net_device *dev, xdp_op_t xdp_op)
{
struct netdev_xdp xdp;
@@ -6941,12 +6940,7 @@ bool __dev_xdp_attached(struct net_device *dev, xdp_op_t xdp_op,
/* Query must always succeed. */
WARN_ON(xdp_op(dev, &xdp) < 0);
- if (xdp.prog_id)
- xdp.prog_attached = true;
- if (prog_id)
- *prog_id = xdp.prog_id;
-
- return xdp.prog_attached;
+ return xdp.prog_id;
}
static int dev_xdp_install(struct net_device *dev, xdp_op_t xdp_op,
@@ -6991,10 +6985,10 @@ int dev_change_xdp_fd(struct net_device *dev, struct netlink_ext_ack *extack,
xdp_chk = generic_xdp_install;
if (fd >= 0) {
- if (xdp_chk && __dev_xdp_attached(dev, xdp_chk, NULL))
+ if (xdp_chk && __dev_xdp_attached(dev, xdp_chk))
return -EEXIST;
if ((flags & XDP_FLAGS_UPDATE_IF_NOEXIST) &&
- __dev_xdp_attached(dev, xdp_op, NULL))
+ __dev_xdp_attached(dev, xdp_op))
return -EBUSY;
prog = bpf_prog_get_type(fd, BPF_PROG_TYPE_XDP);
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index f25a53b1fb92..feba0ec757c4 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1262,8 +1262,11 @@ static u8 rtnl_xdp_attached_mode(struct net_device *dev, u32 *prog_id)
*prog_id = generic_xdp_prog->aux->id;
return XDP_ATTACHED_SKB;
}
- if (ops->ndo_xdp && __dev_xdp_attached(dev, ops->ndo_xdp, prog_id))
- return XDP_ATTACHED_DRV;
+ if (ops->ndo_xdp) {
+ *prog_id = __dev_xdp_attached(dev, ops->ndo_xdp);
+ if (*prog_id)
+ return XDP_ATTACHED_DRV;
+ }
return XDP_ATTACHED_NONE;
}
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 07/10] bpf: ixgbe: Report bpf_prog ID during XDP_QUERY_PROG
From: Martin KaFai Lau @ 2017-06-13 1:00 UTC (permalink / raw)
To: netdev
Cc: Alexei Starovoitov, Daniel Borkmann, kernel-team, Alexander Duyck,
John Fastabend
In-Reply-To: <20170613010025.2983342-1-kafai@fb.com>
Add support to ixgbe to report bpf_prog ID during XDP_QUERY_PROG.
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Cc: Alexander Duyck <alexander.h.duyck@intel.com>
Cc: John Fastabend <john.fastabend@gmail.com>
Acked-by: Alexei Starovoitov <ast@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 812319ab77db..62fb564d62a2 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -9799,9 +9799,16 @@ static int ixgbe_xdp(struct net_device *dev, struct netdev_xdp *xdp)
switch (xdp->command) {
case XDP_SETUP_PROG:
return ixgbe_xdp_setup(dev, xdp->prog);
- case XDP_QUERY_PROG:
- xdp->prog_attached = !!(adapter->xdp_prog);
+ case XDP_QUERY_PROG: {
+ const struct bpf_prog *xdp_prog;
+
+ xdp_prog = READ_ONCE(adapter->xdp_prog);
+ if (xdp_prog)
+ xdp->prog_id = xdp_prog->aux->id;
+ else
+ xdp->prog_id = 0;
return 0;
+ }
default:
return -EINVAL;
}
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 03/10] bpf: mlx5e: Report bpf_prog ID during XDP_QUERY_PROG
From: Martin KaFai Lau @ 2017-06-13 1:00 UTC (permalink / raw)
To: netdev
Cc: Alexei Starovoitov, Daniel Borkmann, kernel-team, Tariq Toukan,
Saeed Mahameed
In-Reply-To: <20170613010025.2983342-1-kafai@fb.com>
Add support to mlx5e to report bpf_prog ID during XDP_QUERY_PROG.
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Cc: Tariq Toukan <tariqt@mellanox.com>
Cc: Saeed Mahameed <saeedm@mellanox.com>
Acked-by: Alexei Starovoitov <ast@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 5afec0f4a658..c3ed2e122e12 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -3599,11 +3599,19 @@ static int mlx5e_xdp_set(struct net_device *netdev, struct bpf_prog *prog)
return err;
}
-static bool mlx5e_xdp_attached(struct net_device *dev)
+static u32 mlx5e_xdp_query(struct net_device *dev)
{
+ const struct bpf_prog *xdp_prog;
struct mlx5e_priv *priv = netdev_priv(dev);
+ u32 prog_id = 0;
- return !!priv->channels.params.xdp_prog;
+ mutex_lock(&priv->state_lock);
+ xdp_prog = READ_ONCE(priv->channels.params.xdp_prog);
+ if (xdp_prog)
+ prog_id = xdp_prog->aux->id;
+ mutex_unlock(&priv->state_lock);
+
+ return prog_id;
}
static int mlx5e_xdp(struct net_device *dev, struct netdev_xdp *xdp)
@@ -3612,7 +3620,7 @@ static int mlx5e_xdp(struct net_device *dev, struct netdev_xdp *xdp)
case XDP_SETUP_PROG:
return mlx5e_xdp_set(dev, xdp->prog);
case XDP_QUERY_PROG:
- xdp->prog_attached = mlx5e_xdp_attached(dev);
+ xdp->prog_id = mlx5e_xdp_query(dev);
return 0;
default:
return -EINVAL;
--
2.9.3
^ permalink raw reply related
* Re: [PATCH net-next 00/10] bpf: xdp: Report bpf_prog ID in IFLA_XDP
From: Jakub Kicinski @ 2017-06-13 1:26 UTC (permalink / raw)
To: Martin KaFai Lau; +Cc: netdev, Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20170613010025.2983342-1-kafai@fb.com>
On Mon, 12 Jun 2017 18:00:15 -0700, Martin KaFai Lau wrote:
> This is the first usage of the new bpf_prog ID. It is for
> reporting the ID of a xdp_prog through netlink.
>
> It rides on the existing IFLA_XDP. This patch adds IFLA_XDP_PROG_ID
> for the bpf_prog ID reporting.
>
> It starts with changing the generic_xdp first. After that,
> the hardware driver is changed one by one. The final patch
> removes the prog_attached from 'struct netdev_xdp' because
> prog_id > 0 implies the presence of xdp_prog.
Daniel made the XDP_ATTACHED an enum to be able to extend it with other
modes. I would appreciate if you didn't remove the member since I have
this waiting in my tree:
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Mon, 5 Jun 2017 22:52:01 -0700
Subject: [PATCH net-next] xdp: add reporting of offload mode
Extend the XDP_ATTACHED_* values to include offloaded mode.
Let drivers report whether program is installed in the driver
or the HW by changing the prog_attached field from bool to
u8 (type of the netlink attribute).
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
include/linux/netdevice.h | 7 ++++---
include/uapi/linux/if_link.h | 1 +
net/core/dev.c | 2 +-
net/core/rtnetlink.c | 6 +++---
4 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 524c7776ce96..76165dfd2a1e 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -808,7 +808,8 @@ enum xdp_netdev_command {
*/
XDP_SETUP_PROG,
/* Check if a bpf program is set on the device. The callee should
- * return true if a program is currently attached and running.
+ * set @prog_attached to one of XDP_ATTACHED_* values, note that "true"
+ * is equivalent to XDP_ATTACHED_DRV.
*/
XDP_QUERY_PROG,
};
@@ -824,7 +825,7 @@ struct netdev_xdp {
struct netlink_ext_ack *extack;
};
/* XDP_QUERY_PROG */
- bool prog_attached;
+ u8 prog_attached;
};
};
@@ -3302,7 +3303,7 @@ struct sk_buff *dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
typedef int (*xdp_op_t)(struct net_device *dev, struct netdev_xdp *xdp);
int dev_change_xdp_fd(struct net_device *dev, struct netlink_ext_ack *extack,
int fd, u32 flags);
-bool __dev_xdp_attached(struct net_device *dev, xdp_op_t xdp_op);
+u8 __dev_xdp_attached(struct net_device *dev, xdp_op_t xdp_op);
int __dev_forward_skb(struct net_device *dev, struct sk_buff *skb);
int dev_forward_skb(struct net_device *dev, struct sk_buff *skb);
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index 8ed679fe603f..4dd59b7463a9 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -900,6 +900,7 @@ enum {
XDP_ATTACHED_NONE = 0,
XDP_ATTACHED_DRV,
XDP_ATTACHED_SKB,
+ XDP_ATTACHED_HW,
};
enum {
diff --git a/net/core/dev.c b/net/core/dev.c
index 8f72f4a9c6ac..8f29b6ba99ac 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6930,7 +6930,7 @@ int dev_change_proto_down(struct net_device *dev, bool proto_down)
}
EXPORT_SYMBOL(dev_change_proto_down);
-bool __dev_xdp_attached(struct net_device *dev, xdp_op_t xdp_op)
+u8 __dev_xdp_attached(struct net_device *dev, xdp_op_t xdp_op)
{
struct netdev_xdp xdp;
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 7084f1db2446..5b16e479ea68 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1255,10 +1255,10 @@ static u8 rtnl_xdp_attached_mode(struct net_device *dev)
if (rcu_access_pointer(dev->xdp_prog))
return XDP_ATTACHED_SKB;
- if (ops->ndo_xdp && __dev_xdp_attached(dev, ops->ndo_xdp))
- return XDP_ATTACHED_DRV;
+ if (!ops->ndo_xdp)
+ return XDP_ATTACHED_NONE;
- return XDP_ATTACHED_NONE;
+ return __dev_xdp_attached(dev, ops->ndo_xdp);
}
static int rtnl_xdp_fill(struct sk_buff *skb, struct net_device *dev)
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next 08/10] bpf: nfp: Report bpf_prog ID during XDP_QUERY_PROG
From: Jakub Kicinski @ 2017-06-13 1:28 UTC (permalink / raw)
To: Martin KaFai Lau; +Cc: netdev, Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20170613010025.2983342-9-kafai@fb.com>
On Mon, 12 Jun 2017 18:00:23 -0700, Martin KaFai Lau wrote:
> + case XDP_QUERY_PROG: {
> + const struct bpf_prog *xdp_prog;
> +
> + xdp_prog = READ_ONCE(nn->dp.xdp_prog);
> + if (xdp_prog)
> + xdp->prog_id = xdp_prog->aux->id;
> + else
> + xdp->prog_id = 0;
> return 0;
> + }
> default:
> return -EINVAL;
> }
Why READ_ONCE? I thought .ndo_xdp is always called under RTNL.
^ permalink raw reply
* Re: linux-next: build failure after merge of the wireless-drivers-next tree
From: Stephen Rothwell @ 2017-06-13 2:00 UTC (permalink / raw)
To: David Miller, Networking
Cc: Kalle Valo, Wireless, Linux-Next Mailing List,
Linux Kernel Mailing List, Igor Mitsyanko, Dmitrii Lebed,
Sergei Maksimenko, Sergey Matyukevich, Bindu Therthala,
Huizhao Wang, Kamlesh Rath, Avinash Patil
In-Reply-To: <20170608122759.7ffda0c3@canb.auug.org.au>
Hi Dave,
On Thu, 8 Jun 2017 12:27:59 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the wireless-drivers-next tree, today's linux-next build
> (x86_64 allmodconfig) failed like this:
>
> drivers/net/wireless/quantenna/qtnfmac/core.c: In function 'qtnf_core_net_attach':
> drivers/net/wireless/quantenna/qtnfmac/core.c:319:5: error: 'struct net_device' has no member named 'destructor'
> dev->destructor = free_netdev;
> ^
>
> Caused by commit
>
> 98f44cb0655c ("qtnfmac: introduce new FullMAC driver for Quantenna chipsets")
This commit is now in the net-next tree ...
> interacting with commit
>
> cf124db566e6 ("net: Fix inconsistent teardown and release of private netdev state.")
>
> from the net tree.
>
> I applied this merge fix patch for today.
So this merge fix patch is needed when the net and net-next trees are merged.
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 8 Jun 2017 12:24:08 +1000
> Subject: [PATCH] qtnfmac: fix up for "net: Fix inconsistent teardown and
> release of private netdev state."
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/net/wireless/quantenna/qtnfmac/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/quantenna/qtnfmac/core.c b/drivers/net/wireless/quantenna/qtnfmac/core.c
> index c5ac252464f4..f053532c0e87 100644
> --- a/drivers/net/wireless/quantenna/qtnfmac/core.c
> +++ b/drivers/net/wireless/quantenna/qtnfmac/core.c
> @@ -316,7 +316,7 @@ int qtnf_core_net_attach(struct qtnf_wmac *mac, struct qtnf_vif *vif,
> vif->netdev = dev;
>
> dev->netdev_ops = &qtnf_netdev_ops;
> - dev->destructor = free_netdev;
> + dev->needs_free_netdev = true;
> dev_net_set(dev, wiphy_net(wiphy));
> dev->ieee80211_ptr = &vif->wdev;
> dev->ieee80211_ptr->iftype = iftype;
> --
> 2.11.0
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* RE: [PATCH net-next 1/2] r8152: split rtl8152_resume function
From: Hayes Wang @ 2017-06-13 2:27 UTC (permalink / raw)
To: Oliver Neukum, netdev@vger.kernel.org
Cc: nic_swsd, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
In-Reply-To: <1497270806.15677.18.camel@suse.com>
Oliver Neukum [mailto:oneukum@suse.com]
> Sent: Monday, June 12, 2017 8:33 PM
[...]
> > + usb_submit_urb(tp->intr_urb, GFP_KERNEL);
>
> If you ever built a device with included storage, this can deadlock,
> as you may want to wake up a device for memory that is needed to wake
> up a device. Use GFP_NOIO in resume() and reset_resume(), always.
I would change it. Thanks.
Best Regards,
Hayes
^ permalink raw reply
* Re: [PATCH net-next 08/10] bpf: nfp: Report bpf_prog ID during XDP_QUERY_PROG
From: Martin KaFai Lau @ 2017-06-13 4:54 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20170612182842.3150789d@cakuba.netronome.com>
On Mon, Jun 12, 2017 at 06:28:42PM -0700, Jakub Kicinski wrote:
> On Mon, 12 Jun 2017 18:00:23 -0700, Martin KaFai Lau wrote:
> > + case XDP_QUERY_PROG: {
> > + const struct bpf_prog *xdp_prog;
> > +
> > + xdp_prog = READ_ONCE(nn->dp.xdp_prog);
> > + if (xdp_prog)
> > + xdp->prog_id = xdp_prog->aux->id;
> > + else
> > + xdp->prog_id = 0;
> > return 0;
> > + }
> > default:
> > return -EINVAL;
> > }
>
> Why READ_ONCE? I thought .ndo_xdp is always called under RTNL.
will remove in the next spin.
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-binding: ptp: add bindings document for dte based ptp clock
From: Richard Cochran @ 2017-06-13 5:09 UTC (permalink / raw)
To: Arun Parameswaran
Cc: Rob Herring, Mark Rutland, devicetree, linux-kernel, netdev,
bcm-kernel-feedback-list
In-Reply-To: <1497299161-6458-2-git-send-email-arun.parameswaran@broadcom.com>
On Mon, Jun 12, 2017 at 01:26:00PM -0700, Arun Parameswaran wrote:
> +Example:
> +
> +ptp_dte: ptp_dte@180af650 {
> + compatible = "brcm,ptp-dte";
> + reg = <0x180af650 0x10>;
> + status = "okay";
> +};
This patch set looks okay, as far as it goes, but how does one
actually use the clock?
How does one connect this node to an Ethernet MAC, for example?
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH net-next v10 1/4] net netlink: Add new type NLA_FLAG_BITS
From: Jiri Pirko @ 2017-06-13 5:32 UTC (permalink / raw)
To: David Ahern
Cc: Jamal Hadi Salim, davem, netdev, xiyou.wangcong, eric.dumazet,
simon.horman, mrv
In-Reply-To: <4d150766-dd1e-26f5-43ea-a3c93cdf291b@gmail.com>
Mon, Jun 12, 2017 at 09:58:33PM CEST, dsahern@gmail.com wrote:
>On 6/12/17 1:22 PM, Jiri Pirko wrote:
>>
>>> 3. IMO since these are nla prefixes and new NLA type they should be in
>>> uapi/linux/netlink.h
>> Including NLA_* type enum? I think it is reasonable.
>
>well, maybe not the NLA_BITFIELD. That enum is for policy validation
>kernel side so not really part of the API.
Yeah, now I see it. Agreed.
^ permalink raw reply
* Re: [PATCH net-next 00/10] bpf: xdp: Report bpf_prog ID in IFLA_XDP
From: Martin KaFai Lau @ 2017-06-13 5:35 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20170612182452.61b8a0a3@cakuba.netronome.com>
On Mon, Jun 12, 2017 at 06:26:02PM -0700, Jakub Kicinski wrote:
> On Mon, 12 Jun 2017 18:00:15 -0700, Martin KaFai Lau wrote:
> > This is the first usage of the new bpf_prog ID. It is for
> > reporting the ID of a xdp_prog through netlink.
> >
> > It rides on the existing IFLA_XDP. This patch adds IFLA_XDP_PROG_ID
> > for the bpf_prog ID reporting.
> >
> > It starts with changing the generic_xdp first. After that,
> > the hardware driver is changed one by one. The final patch
> > removes the prog_attached from 'struct netdev_xdp' because
> > prog_id > 0 implies the presence of xdp_prog.
>
> Daniel made the XDP_ATTACHED an enum to be able to extend it with other
> modes. I would appreciate if you didn't remove the member since I have
> this waiting in my tree:
I see. I will keep prog_attached then.
>
> From: Jakub Kicinski <jakub.kicinski@netronome.com>
> Date: Mon, 5 Jun 2017 22:52:01 -0700
> Subject: [PATCH net-next] xdp: add reporting of offload mode
>
> Extend the XDP_ATTACHED_* values to include offloaded mode.
> Let drivers report whether program is installed in the driver
> or the HW by changing the prog_attached field from bool to
> u8 (type of the netlink attribute).
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> ---
> include/linux/netdevice.h | 7 ++++---
j
> include/uapi/linux/if_link.h | 1 +
> net/core/dev.c | 2 +-
> net/core/rtnetlink.c | 6 +++---
> 4 files changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 524c7776ce96..76165dfd2a1e 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -808,7 +808,8 @@ enum xdp_netdev_command {
> */
> XDP_SETUP_PROG,
> /* Check if a bpf program is set on the device. The callee should
> - * return true if a program is currently attached and running.
> + * set @prog_attached to one of XDP_ATTACHED_* values, note that "true"
> + * is equivalent to XDP_ATTACHED_DRV.
> */
> XDP_QUERY_PROG,
> };
> @@ -824,7 +825,7 @@ struct netdev_xdp {
> struct netlink_ext_ack *extack;
> };
> /* XDP_QUERY_PROG */
> - bool prog_attached;
> + u8 prog_attached;
> };
> };
>
> @@ -3302,7 +3303,7 @@ struct sk_buff *dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
> typedef int (*xdp_op_t)(struct net_device *dev, struct netdev_xdp *xdp);
> int dev_change_xdp_fd(struct net_device *dev, struct netlink_ext_ack *extack,
> int fd, u32 flags);
> -bool __dev_xdp_attached(struct net_device *dev, xdp_op_t xdp_op);
> +u8 __dev_xdp_attached(struct net_device *dev, xdp_op_t xdp_op);
>
> int __dev_forward_skb(struct net_device *dev, struct sk_buff *skb);
> int dev_forward_skb(struct net_device *dev, struct sk_buff *skb);
> diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
> index 8ed679fe603f..4dd59b7463a9 100644
> --- a/include/uapi/linux/if_link.h
> +++ b/include/uapi/linux/if_link.h
> @@ -900,6 +900,7 @@ enum {
> XDP_ATTACHED_NONE = 0,
> XDP_ATTACHED_DRV,
> XDP_ATTACHED_SKB,
> + XDP_ATTACHED_HW,
> };
>
> enum {
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 8f72f4a9c6ac..8f29b6ba99ac 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -6930,7 +6930,7 @@ int dev_change_proto_down(struct net_device *dev, bool proto_down)
> }
> EXPORT_SYMBOL(dev_change_proto_down);
>
> -bool __dev_xdp_attached(struct net_device *dev, xdp_op_t xdp_op)
> +u8 __dev_xdp_attached(struct net_device *dev, xdp_op_t xdp_op)
> {
> struct netdev_xdp xdp;
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index 7084f1db2446..5b16e479ea68 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -1255,10 +1255,10 @@ static u8 rtnl_xdp_attached_mode(struct net_device *dev)
>
> if (rcu_access_pointer(dev->xdp_prog))
> return XDP_ATTACHED_SKB;
> - if (ops->ndo_xdp && __dev_xdp_attached(dev, ops->ndo_xdp))
> - return XDP_ATTACHED_DRV;
> + if (!ops->ndo_xdp)
> + return XDP_ATTACHED_NONE;
>
> - return XDP_ATTACHED_NONE;
> + return __dev_xdp_attached(dev, ops->ndo_xdp);
> }
>
> static int rtnl_xdp_fill(struct sk_buff *skb, struct net_device *dev)
> --
> 2.11.0
>
^ permalink raw reply
* Re: brcmfmac: Fix kernel oops on resume when request firmware fails.
From: Kalle Valo @ 2017-06-13 5:54 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Arend van Spriel, linux-wireless, brcm80211-dev-list.pdl, netdev,
linux-kernel, Hante Meuleman, Christian Daudt
In-Reply-To: <20170523180733.26276-1-enric.balletbo@collabora.com>
Enric Balletbo i Serra <enric.balletbo@collabora.com> wrote:
> When request firmware fails, brcmf_ops_sdio_remove is being called and
> brcmf_bus freed. In such circumstancies if you do a suspend/resume cycle
> the kernel hangs on resume due a NULL pointer dereference in resume
> function.
>
> Steps to reproduce the problem:
> - modprobe brcmfmac without the firmware
> brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac4354-sdio.bin
> failed with error -2
> - do a suspend/resume cycle (echo mem > /sys/power/state)
>
> Protect against the NULL pointer derefence by checking if dev_get_drvdata
> returned a valid pointer.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
My understanding is that there's a new version of this patch which fixes
the issue. If not, let me know.
Patch set to Superseded.
--
https://patchwork.kernel.org/patch/9743159/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* patch "net: caif: convert to use DRIVER_ATTR_RO" added to driver-core-next
From: gregkh @ 2017-06-13 5:58 UTC (permalink / raw)
To: gregkh, davem, dmitry.tarnyagin, netdev
This is a note to let you know that I've just added the patch titled
net: caif: convert to use DRIVER_ATTR_RO
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From f85205c42eb0423e05c91d0276bfc86b136d42f6 Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri, 9 Jun 2017 11:03:08 +0200
Subject: net: caif: convert to use DRIVER_ATTR_RO
We are trying to get rid of DRIVER_ATTR(), and the caif driver's
attributes can be trivially changed to use DRIVER_ATTR_RO().
Cc: Dmitry Tarnyagin <dmitry.tarnyagin@lockless.no>
Cc: <netdev@vger.kernel.org>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/caif/caif_spi.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/caif/caif_spi.c b/drivers/net/caif/caif_spi.c
index 3a529fbe539f..3281a3e0c144 100644
--- a/drivers/net/caif/caif_spi.c
+++ b/drivers/net/caif/caif_spi.c
@@ -289,44 +289,44 @@ static LIST_HEAD(cfspi_list);
static spinlock_t cfspi_list_lock;
/* SPI uplink head alignment. */
-static ssize_t show_up_head_align(struct device_driver *driver, char *buf)
+static ssize_t up_head_align_show(struct device_driver *driver, char *buf)
{
return sprintf(buf, "%d\n", spi_up_head_align);
}
-static DRIVER_ATTR(up_head_align, S_IRUSR, show_up_head_align, NULL);
+static DRIVER_ATTR_RO(up_head_align);
/* SPI uplink tail alignment. */
-static ssize_t show_up_tail_align(struct device_driver *driver, char *buf)
+static ssize_t up_tail_align_show(struct device_driver *driver, char *buf)
{
return sprintf(buf, "%d\n", spi_up_tail_align);
}
-static DRIVER_ATTR(up_tail_align, S_IRUSR, show_up_tail_align, NULL);
+static DRIVER_ATTR_RO(up_tail_align);
/* SPI downlink head alignment. */
-static ssize_t show_down_head_align(struct device_driver *driver, char *buf)
+static ssize_t down_head_align_show(struct device_driver *driver, char *buf)
{
return sprintf(buf, "%d\n", spi_down_head_align);
}
-static DRIVER_ATTR(down_head_align, S_IRUSR, show_down_head_align, NULL);
+static DRIVER_ATTR_RO(down_head_align);
/* SPI downlink tail alignment. */
-static ssize_t show_down_tail_align(struct device_driver *driver, char *buf)
+static ssize_t down_tail_align_show(struct device_driver *driver, char *buf)
{
return sprintf(buf, "%d\n", spi_down_tail_align);
}
-static DRIVER_ATTR(down_tail_align, S_IRUSR, show_down_tail_align, NULL);
+static DRIVER_ATTR_RO(down_tail_align);
/* SPI frame alignment. */
-static ssize_t show_frame_align(struct device_driver *driver, char *buf)
+static ssize_t frame_align_show(struct device_driver *driver, char *buf)
{
return sprintf(buf, "%d\n", spi_frm_align);
}
-static DRIVER_ATTR(frame_align, S_IRUSR, show_frame_align, NULL);
+static DRIVER_ATTR_RO(frame_align);
int cfspi_xmitfrm(struct cfspi *cfspi, u8 *buf, size_t len)
{
--
2.13.1
^ permalink raw reply related
* patch "net: ehea: convert to use DRIVER_ATTR_RO" added to driver-core-next
From: gregkh @ 2017-06-13 5:58 UTC (permalink / raw)
To: gregkh, davem, dougmill, netdev
This is a note to let you know that I've just added the patch titled
net: ehea: convert to use DRIVER_ATTR_RO
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From ce8e0cd892c66be110613876dded547acc66da13 Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri, 9 Jun 2017 11:03:09 +0200
Subject: net: ehea: convert to use DRIVER_ATTR_RO
We are trying to get rid of DRIVER_ATTR(), and the ehea driver's
attribute can be trivially changed to use DRIVER_ATTR_RO().
Cc: Douglas Miller <dougmill@linux.vnet.ibm.com>
Cc: <netdev@vger.kernel.org>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/ibm/ehea/ehea_main.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ehea/ehea_main.c b/drivers/net/ethernet/ibm/ehea/ehea_main.c
index 1e53d7a82675..b9d310f20bcc 100644
--- a/drivers/net/ethernet/ibm/ehea/ehea_main.c
+++ b/drivers/net/ethernet/ibm/ehea/ehea_main.c
@@ -3553,14 +3553,12 @@ static int check_module_parm(void)
return ret;
}
-static ssize_t ehea_show_capabilities(struct device_driver *drv,
- char *buf)
+static ssize_t capabilities_show(struct device_driver *drv, char *buf)
{
return sprintf(buf, "%d", EHEA_CAPABILITIES);
}
-static DRIVER_ATTR(capabilities, S_IRUSR | S_IRGRP | S_IROTH,
- ehea_show_capabilities, NULL);
+static DRIVER_ATTR_RO(capabilities);
static int __init ehea_module_init(void)
{
--
2.13.1
^ permalink raw reply related
* patch "wireless: ipw2x00: convert to use DRIVER_ATTR_RW" added to driver-core-next
From: gregkh @ 2017-06-13 5:58 UTC (permalink / raw)
To: gregkh, kvalo, linux-wireless, netdev, stas.yakovlev
This is a note to let you know that I've just added the patch titled
wireless: ipw2x00: convert to use DRIVER_ATTR_RW
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From 0457e1ae0f4b88676b0cea30ef6acff24febbbc0 Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri, 9 Jun 2017 11:03:10 +0200
Subject: wireless: ipw2x00: convert to use DRIVER_ATTR_RW
We are trying to get rid of DRIVER_ATTR(), and the ipw2x00 driver's
attributes can be trivially changed to use DRIVER_ATTR_RW().
Cc: Stanislav Yakovlev <stas.yakovlev@gmail.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: <linux-wireless@vger.kernel.org>
Cc: <netdev@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/intel/ipw2x00/ipw2100.c | 8 +++-----
drivers/net/wireless/intel/ipw2x00/ipw2200.c | 8 +++-----
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2100.c b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
index f922859acf40..aaaca4d08e2b 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
@@ -4160,12 +4160,12 @@ static ssize_t show_bssinfo(struct device *d, struct device_attribute *attr,
static DEVICE_ATTR(bssinfo, S_IRUGO, show_bssinfo, NULL);
#ifdef CONFIG_IPW2100_DEBUG
-static ssize_t show_debug_level(struct device_driver *d, char *buf)
+static ssize_t debug_level_show(struct device_driver *d, char *buf)
{
return sprintf(buf, "0x%08X\n", ipw2100_debug_level);
}
-static ssize_t store_debug_level(struct device_driver *d,
+static ssize_t debug_level_store(struct device_driver *d,
const char *buf, size_t count)
{
u32 val;
@@ -4179,9 +4179,7 @@ static ssize_t store_debug_level(struct device_driver *d,
return strnlen(buf, count);
}
-
-static DRIVER_ATTR(debug_level, S_IWUSR | S_IRUGO, show_debug_level,
- store_debug_level);
+static DRIVER_ATTR_RW(debug_level);
#endif /* CONFIG_IPW2100_DEBUG */
static ssize_t show_fatal_error(struct device *d,
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.c b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
index bbc579b647b6..5b79e2ec3a16 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
@@ -1195,12 +1195,12 @@ static void ipw_led_shutdown(struct ipw_priv *priv)
*
* See the level definitions in ipw for details.
*/
-static ssize_t show_debug_level(struct device_driver *d, char *buf)
+static ssize_t debug_level_show(struct device_driver *d, char *buf)
{
return sprintf(buf, "0x%08X\n", ipw_debug_level);
}
-static ssize_t store_debug_level(struct device_driver *d, const char *buf,
+static ssize_t debug_level_store(struct device_driver *d, const char *buf,
size_t count)
{
char *p = (char *)buf;
@@ -1221,9 +1221,7 @@ static ssize_t store_debug_level(struct device_driver *d, const char *buf,
return strnlen(buf, count);
}
-
-static DRIVER_ATTR(debug_level, S_IWUSR | S_IRUGO,
- show_debug_level, store_debug_level);
+static DRIVER_ATTR_RW(debug_level);
static inline u32 ipw_get_event_log_len(struct ipw_priv *priv)
{
--
2.13.1
^ permalink raw reply related
* Re: [PATCH net-next 00/10] bpf: xdp: Report bpf_prog ID in IFLA_XDP
From: Jakub Kicinski @ 2017-06-13 6:07 UTC (permalink / raw)
To: Martin KaFai Lau; +Cc: netdev, Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20170613053534.2afamabn6wkwka44@dhcp-172-26-110-210.dhcp.thefacebook.com>
On Mon, 12 Jun 2017 22:35:34 -0700, Martin KaFai Lau wrote:
> On Mon, Jun 12, 2017 at 06:26:02PM -0700, Jakub Kicinski wrote:
> > On Mon, 12 Jun 2017 18:00:15 -0700, Martin KaFai Lau wrote:
> > > This is the first usage of the new bpf_prog ID. It is for
> > > reporting the ID of a xdp_prog through netlink.
> > >
> > > It rides on the existing IFLA_XDP. This patch adds IFLA_XDP_PROG_ID
> > > for the bpf_prog ID reporting.
> > >
> > > It starts with changing the generic_xdp first. After that,
> > > the hardware driver is changed one by one. The final patch
> > > removes the prog_attached from 'struct netdev_xdp' because
> > > prog_id > 0 implies the presence of xdp_prog.
> >
> > Daniel made the XDP_ATTACHED an enum to be able to extend it with other
> > modes. I would appreciate if you didn't remove the member since I have
> > this waiting in my tree:
> I see. I will keep prog_attached then.
Thanks!
^ permalink raw reply
* Re: [PATCH nf-next] netns: add and use net_ns_barrier
From: Florian Westphal @ 2017-06-13 6:16 UTC (permalink / raw)
To: Cong Wang
Cc: Florian Westphal, Eric W. Biederman, netfilter-devel,
Linux Kernel Network Developers
In-Reply-To: <CAM_iQpXgrQcbrQsMVoomcsHtk4JffRjJ27FLRoignndAzFVkug@mail.gmail.com>
Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Thu, Jun 1, 2017 at 1:52 AM, Florian Westphal <fw@strlen.de> wrote:
> > Joe described it nicely, problem is that after unload we may have
> > conntracks that still have a nf_conn_help extension attached that
> > has a pointer to a structure that resided in the (unloaded) module.
>
> Why not hold a refcnt for its module?
That would work as well.
I'm not sure its nice to disallow rmmod of helper modules if they are
used by a connection however.
Right now you can "rmmod nf_conntrack_foo" at any time and this should
work just fine without first having to flush affected conntracks
manually.
^ permalink raw reply
* Re: [PATCH] mwifiex: fixes the trivial print
From: Kalle Valo @ 2017-06-13 6:28 UTC (permalink / raw)
To: Caesar Wang
Cc: amitkarwar, huxm, nishants, gbhat, linux-wireless, netdev,
linux-kernel, briannorris, jeffy.chen
In-Reply-To: <1497008411-15223-1-git-send-email-wxt@rock-chips.com>
Caesar Wang <wxt@rock-chips.com> writes:
> We have always met the unused log be printed as following.
>
> ...
> [23193.523182] mwifiex_pcie 0000:01:00.0: mwifiex_get_cfp:
> cannot find cfp by band 2 & channel=13 freq=0
> [23378.633684] mwifiex_pcie 0000:01:00.0: mwifiex_get_cfp:
> cannot find cfp by band 2 & channel=13 freq=0
>
> Maybe that's related to wifi regdom, since wifi default area
> was US and didn't support 12~14 channels.
>
> As Frequencies:
> * 2412 MHz [1] (30.0 dBm)
> * 2417 MHz [2] (30.0 dBm)
> * 2422 MHz [3] (30.0 dBm)
> * 2427 MHz [4] (30.0 dBm)
> * 2432 MHz [5] (30.0 dBm)
> * 2437 MHz [6] (30.0 dBm)
> * 2442 MHz [7] (30.0 dBm)
> * 2447 MHz [8] (30.0 dBm)
> * 2452 MHz [9] (30.0 dBm)
> * 2457 MHz [10] (30.0 dBm)
> * 2462 MHz [11] (30.0 dBm)
> * 2467 MHz [12] (disabled)
> * 2472 MHz [13] (disabled)
> * 2484 MHz [14] (disabled)
>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> ---
>
> drivers/net/wireless/marvell/mwifiex/cfp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/cfp.c b/drivers/net/wireless/marvell/mwifiex/cfp.c
> index 1ff2205..6e29943 100644
> --- a/drivers/net/wireless/marvell/mwifiex/cfp.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cfp.c
> @@ -350,7 +350,7 @@ mwifiex_get_cfp(struct mwifiex_private *priv, u8 band, u16 channel, u32 freq)
> }
> }
> if (i == sband->n_channels) {
> - mwifiex_dbg(priv->adapter, ERROR,
> + mwifiex_dbg(priv->adapter, WARN,
> "%s: cannot find cfp by band %d\t"
> "& channel=%d freq=%d\n",
> __func__, band, channel, freq);
I don't see how this fixes anything, care to explain? And the title is
quite vague.
And I would rather fix the root cause, mwifiex folks please comment.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] mwifiex: fixes the trivial print
From: Caesar Wang @ 2017-06-13 6:54 UTC (permalink / raw)
To: Kalle Valo
Cc: amitkarwar, huxm, nishants, gbhat, linux-wireless, netdev,
linux-kernel, briannorris, jeffy.chen
In-Reply-To: <87poe8pfjs.fsf@purkki.adurom.net>
Kalle,
在 2017年06月13日 14:28, Kalle Valo 写道:
> Caesar Wang <wxt@rock-chips.com> writes:
>
>> We have always met the unused log be printed as following.
>>
>> ...
>> [23193.523182] mwifiex_pcie 0000:01:00.0: mwifiex_get_cfp:
>> cannot find cfp by band 2 & channel=13 freq=0
>> [23378.633684] mwifiex_pcie 0000:01:00.0: mwifiex_get_cfp:
>> cannot find cfp by band 2 & channel=13 freq=0
>>
>> Maybe that's related to wifi regdom, since wifi default area
>> was US and didn't support 12~14 channels.
>>
>> As Frequencies:
>> * 2412 MHz [1] (30.0 dBm)
>> * 2417 MHz [2] (30.0 dBm)
>> * 2422 MHz [3] (30.0 dBm)
>> * 2427 MHz [4] (30.0 dBm)
>> * 2432 MHz [5] (30.0 dBm)
>> * 2437 MHz [6] (30.0 dBm)
>> * 2442 MHz [7] (30.0 dBm)
>> * 2447 MHz [8] (30.0 dBm)
>> * 2452 MHz [9] (30.0 dBm)
>> * 2457 MHz [10] (30.0 dBm)
>> * 2462 MHz [11] (30.0 dBm)
>> * 2467 MHz [12] (disabled)
>> * 2472 MHz [13] (disabled)
>> * 2484 MHz [14] (disabled)
>>
>> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
>> ---
>>
>> drivers/net/wireless/marvell/mwifiex/cfp.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/marvell/mwifiex/cfp.c b/drivers/net/wireless/marvell/mwifiex/cfp.c
>> index 1ff2205..6e29943 100644
>> --- a/drivers/net/wireless/marvell/mwifiex/cfp.c
>> +++ b/drivers/net/wireless/marvell/mwifiex/cfp.c
>> @@ -350,7 +350,7 @@ mwifiex_get_cfp(struct mwifiex_private *priv, u8 band, u16 channel, u32 freq)
>> }
>> }
>> if (i == sband->n_channels) {
>> - mwifiex_dbg(priv->adapter, ERROR,
>> + mwifiex_dbg(priv->adapter, WARN,
>> "%s: cannot find cfp by band %d\t"
>> "& channel=%d freq=%d\n",
>> __func__, band, channel, freq);
> I don't see how this fixes anything, care to explain? And the title is
> quite vague.
Sorry for the description maybe unclear.
I'm assuming the print log is expected for marvel wifi driver. Do we
should use 'WARN' to instead of the 'ERROR' here.
>
> And I would rather fix the root cause, mwifiex folks please comment.
Indeed, that's my expected.
-Caesar
>
^ permalink raw reply
* Re: [PATCH v2] arm: eBPF JIT compiler
From: Shubham Bansal @ 2017-06-13 6:56 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Kees Cook, Network Development, David S. Miller,
Alexei Starovoitov, Russell King,
linux-arm-kernel@lists.infradead.org, LKML, Andrew Lunn
In-Reply-To: <CAHgaXd+DW2bggto=2S9hOdMrtPTvhD2QN4rPf2V8iHewQpg-YA@mail.gmail.com>
Hi Daniel, Kees, David, Russel,
>> Any plans to implement above especially BPF_JMP | BPF_CALL in near future?
>> Reason why I'm asking is that i) currently the arm32 cBPF JIT implements
>> all of the cBPF extensions (except SKF_AD_RANDOM and SKF_AD_VLAN_TPID).
>> Some of the programs that were JITed before e.g. using SKF_AD_CPU would now
>> fall back to the eBPF interpreter due to lack of translation in JIT, but
>> also ii) that probably most (if not all) of eBPF programs use BPF helper
>> calls heavily, which will still redirect them to the interpreter right now
>> due to lack of BPF_JMP | BPF_CALL support, so it's really quite essential
>> to have it implemented.
>
> I can try for BPF_JMP | BPF_CALL. I didn't do it last time because I
> thought, it would make the code look messy and become pain to get it
> through the review.
> For this, I have to map eBPF arguments with arm ABI arguments and move
> ebpf arguments to corresponding arm ABI arguments, as eBPF arguments
> doesn't match with arm ABI arguments.
> Let me try that if its possible.
Okay. I looked at it, tried few different solutions also. There is a
problem with implementing BPF_JMP | BPF_CALL.
Problem is transition between 4 byte and 8 byte arguments. Lets take a
look a the following example to get a more clear look at the problem.
Lets consider this function :
CASE 1: foo(int a, int b, long long c, int d)
For calling this function in arm 32 arch, I have to pass the arguments
as following:
a -> r0
b -> r1
c -> r2, r3
d -> stack_top
Now consider an another example function :
CASE 2: bar(int a, int b, int c, int d)
For calling this function in arm32 arch, I have to pass the arguments
as following:
a -> r0
b -> r1
c -> r2
d -> r3
So, you can clearly see the problem with it. There is no way of
knowing which of the above way to pass the arguments. There are
solutions possible:
1. One thing I can do is look at the address of the function to call
and pass the argument accordingly but thats not really a robust
solution as we have to change the arm32 JIT each time we add any new
BPF helper function.
2. Another solution is, if any of you guys can assure/confirm me that
there will be only 4 byte argument passed to BPF helper functions in
arm32 as of now and in future including the pointer as well, then I
can just assume that each argument is passed as 4 byte value and my
trimming the 8byte arguments to 4 bytes arguments wouldn't be a
problem. In that case, arguments for CASE 1 and CASE 2 will be passed
in the same way, i.e.
a -> r0
b -> r1
c -> r2
d -> r3
Let me know what you think. I don't think I can find the solution to
this problem other than those mentioned above. Would love to here any
ideas from you guys.
>> Did you also manage to get the BPF selftest suite running in the meantime
>> (tools/testing/selftests/bpf/)? There are a couple of programs that clang
>> will compile (test_pkt_access.o, test_xdp.o, test_l4lb.o, test_tcp_estats.o)
>> and then test run.
I will run these tests tonight. Hopefully I will be able to run them.
Any comments are welcome. Would love to here what you think about my
solutions above.
Thanks.
Shubham
^ permalink raw reply
* [net-next,v2] openvswitch: add macro MODULE_ALIAS_VPORT_TYPE for vport type alias
From: Zhang Shengju @ 2017-06-13 7:00 UTC (permalink / raw)
To: pshelar, netdev, davem
Add a new macro MODULE_ALIAS_VPORT_TYPE to unify and simplify the
declaration of vport type alias.
Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
---
net/openvswitch/vport-geneve.c | 2 +-
net/openvswitch/vport-gre.c | 2 +-
net/openvswitch/vport-vxlan.c | 2 +-
net/openvswitch/vport.h | 3 +++
4 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/openvswitch/vport-geneve.c b/net/openvswitch/vport-geneve.c
index 5aaf3ba..0ebf023 100644
--- a/net/openvswitch/vport-geneve.c
+++ b/net/openvswitch/vport-geneve.c
@@ -141,4 +141,4 @@ static void __exit ovs_geneve_tnl_exit(void)
MODULE_DESCRIPTION("OVS: Geneve switching port");
MODULE_LICENSE("GPL");
-MODULE_ALIAS("vport-type-5");
+MODULE_ALIAS_VPORT_TYPE(5);
diff --git a/net/openvswitch/vport-gre.c b/net/openvswitch/vport-gre.c
index 0e72d95..97fc4d5 100644
--- a/net/openvswitch/vport-gre.c
+++ b/net/openvswitch/vport-gre.c
@@ -113,4 +113,4 @@ static void __exit ovs_gre_tnl_exit(void)
MODULE_DESCRIPTION("OVS: GRE switching port");
MODULE_LICENSE("GPL");
-MODULE_ALIAS("vport-type-3");
+MODULE_ALIAS_VPORT_TYPE(3);
diff --git a/net/openvswitch/vport-vxlan.c b/net/openvswitch/vport-vxlan.c
index 869acb3..0375b6a 100644
--- a/net/openvswitch/vport-vxlan.c
+++ b/net/openvswitch/vport-vxlan.c
@@ -179,4 +179,4 @@ static void __exit ovs_vxlan_tnl_exit(void)
MODULE_DESCRIPTION("OVS: VXLAN switching port");
MODULE_LICENSE("GPL");
-MODULE_ALIAS("vport-type-4");
+MODULE_ALIAS_VPORT_TYPE(4);
diff --git a/net/openvswitch/vport.h b/net/openvswitch/vport.h
index cda66c2..1d1584f 100644
--- a/net/openvswitch/vport.h
+++ b/net/openvswitch/vport.h
@@ -199,4 +199,7 @@ static inline const char *ovs_vport_name(struct vport *vport)
void ovs_vport_ops_unregister(struct vport_ops *ops);
void ovs_vport_send(struct vport *vport, struct sk_buff *skb, u8 mac_proto);
+#define MODULE_ALIAS_VPORT_TYPE(type) \
+ MODULE_ALIAS("vport-type-" __stringify(type))
+
#endif /* vport.h */
--
1.8.3.1
^ permalink raw reply related
* Re: [-next] mwifiex: make function mwifiex_ret_pkt_aggr_ctrl static
From: Kalle Valo @ 2017-06-13 7:01 UTC (permalink / raw)
To: Colin Ian King
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
linux-wireless, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20170602085639.29338-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> function mwifiex_ret_pkt_aggr_ctrl can be made static as it does not
> need to be in global scope.
>
> Cleans up sparse warning: "symbol 'mwifiex_ret_pkt_aggr_ctrl' was not
> declared. Should it be static?"
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied to wireless-drivers-next.git, thanks.
292c333300ec mwifiex: make function mwifiex_ret_pkt_aggr_ctrl static
--
https://patchwork.kernel.org/patch/9761985/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [wireless-next] qtnfmac: check band before allocating cmd_skb to avoid resource leak
From: Kalle Valo @ 2017-06-13 7:02 UTC (permalink / raw)
To: Colin Ian King
Cc: Igor Mitsyanko, Avinash Patil, Sergey Matyukevich, Dmitrii Lebed,
Huizhao Wang, linux-wireless, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20170602154045.28948-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The current code allocates cmd_skb and then will leak this if band->band
> is an illegal value. It is simpler to sanity check the band first before
> allocating cmd_skb so that we don't have to free cmd_skb if an invalid
> band occurs.
>
> Detected by CoverityScan, CID#1437561 ("Resource Leak")
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Reviewed-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
Patch applied to wireless-drivers-next.git, thanks.
bc0384eedb66 qtnfmac: check band before allocating cmd_skb to avoid resource leak
--
https://patchwork.kernel.org/patch/9762863/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ 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