* SIOCSIWFREQ while in NL80211_IFTYPE_STATION
From: Jorge Ramirez @ 2017-01-05 11:02 UTC (permalink / raw)
To: netdev, Daniel Lezcano
Hello all,
I am running a single wlan0 interface in managed mode (no aliases, no
other wireless interfaces).
The association with the AP still hasn't happened.
I noticed that if trying to change the frequency to one of the valid
values, the driver returns EBUSY.
The call stack is
cfg80211_wext_siwfreq
-->cfg80211_mgd_wext_siwfreq
--->cfg80211_set_monitor_channel (notice call to set 'monitor' channel
in managed mode)
----> fails with EBUSY
Is therefore the expected behavior to fail under the above circumstances
(managed mode && single wlan0 interface && no association)?
And if it is, please could you clarify when would it be valid to change
the frequency in managed mode?
many thanks in advance for the help,
Jorge
^ permalink raw reply
* [PATCH 2/6] netfilter: nft_queue: use raw_smp_processor_id()
From: Pablo Neira Ayuso @ 2017-01-05 11:19 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1483615193-2931-1-git-send-email-pablo@netfilter.org>
Using smp_processor_id() causes splats with PREEMPT_RCU:
[19379.552780] BUG: using smp_processor_id() in preemptible [00000000] code: ping/32389
[19379.552793] caller is debug_smp_processor_id+0x17/0x19
[...]
[19379.552823] Call Trace:
[19379.552832] [<ffffffff81274e9e>] dump_stack+0x67/0x90
[19379.552837] [<ffffffff8129a4d4>] check_preemption_disabled+0xe5/0xf5
[19379.552842] [<ffffffff8129a4fb>] debug_smp_processor_id+0x17/0x19
[19379.552849] [<ffffffffa07c42dd>] nft_queue_eval+0x35/0x20c [nft_queue]
No need to disable preemption since we only fetch the numeric value, so
let's use raw_smp_processor_id() instead.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nft_queue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/nft_queue.c b/net/netfilter/nft_queue.c
index 3e19fa1230dc..dbb6aaff67ec 100644
--- a/net/netfilter/nft_queue.c
+++ b/net/netfilter/nft_queue.c
@@ -38,7 +38,7 @@ static void nft_queue_eval(const struct nft_expr *expr,
if (priv->queues_total > 1) {
if (priv->flags & NFT_QUEUE_FLAG_CPU_FANOUT) {
- int cpu = smp_processor_id();
+ int cpu = raw_smp_processor_id();
queue = priv->queuenum + cpu % priv->queues_total;
} else {
--
2.1.4
^ permalink raw reply related
* [PATCH 6/6] bridge: netfilter: Fix dropping packets that moving through bridge interface
From: Pablo Neira Ayuso @ 2017-01-05 11:19 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1483615193-2931-1-git-send-email-pablo@netfilter.org>
From: Artur Molchanov <arturmolchanov@gmail.com>
Problem:
br_nf_pre_routing_finish() calls itself instead of
br_nf_pre_routing_finish_bridge(). Due to this bug reverse path filter drops
packets that go through bridge interface.
User impact:
Local docker containers with bridge network can not communicate with each
other.
Fixes: c5136b15ea36 ("netfilter: bridge: add and use br_nf_hook_thresh")
Signed-off-by: Artur Molchanov <artur.molchanov@synesis.ru>
Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/bridge/br_netfilter_hooks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bridge/br_netfilter_hooks.c b/net/bridge/br_netfilter_hooks.c
index b12501a77f18..135cc8ab813c 100644
--- a/net/bridge/br_netfilter_hooks.c
+++ b/net/bridge/br_netfilter_hooks.c
@@ -399,7 +399,7 @@ static int br_nf_pre_routing_finish(struct net *net, struct sock *sk, struct sk_
br_nf_hook_thresh(NF_BR_PRE_ROUTING,
net, sk, skb, skb->dev,
NULL,
- br_nf_pre_routing_finish);
+ br_nf_pre_routing_finish_bridge);
return 0;
}
ether_addr_copy(eth_hdr(skb)->h_dest, dev->dev_addr);
--
2.1.4
^ permalink raw reply related
* [PATCH 1/6] netfilter: nft_quota: reset quota after dump
From: Pablo Neira Ayuso @ 2017-01-05 11:19 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1483615193-2931-1-git-send-email-pablo@netfilter.org>
Dumping of netlink attributes may fail due to insufficient room in the
skbuff, so let's reset consumed quota if we succeed to put netlink
attributes into the skbuff.
Fixes: 43da04a593d8 ("netfilter: nf_tables: atomic dump and reset for stateful objects")
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nft_quota.c | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/net/netfilter/nft_quota.c b/net/netfilter/nft_quota.c
index bd6efc53f26d..2d6fe3559912 100644
--- a/net/netfilter/nft_quota.c
+++ b/net/netfilter/nft_quota.c
@@ -110,30 +110,32 @@ static int nft_quota_obj_init(const struct nlattr * const tb[],
static int nft_quota_do_dump(struct sk_buff *skb, struct nft_quota *priv,
bool reset)
{
+ u64 consumed, consumed_cap;
u32 flags = priv->flags;
- u64 consumed;
-
- if (reset) {
- consumed = atomic64_xchg(&priv->consumed, 0);
- if (test_and_clear_bit(NFT_QUOTA_DEPLETED_BIT, &priv->flags))
- flags |= NFT_QUOTA_F_DEPLETED;
- } else {
- consumed = atomic64_read(&priv->consumed);
- }
/* Since we inconditionally increment consumed quota for each packet
* that we see, don't go over the quota boundary in what we send to
* userspace.
*/
- if (consumed > priv->quota)
- consumed = priv->quota;
+ consumed = atomic64_read(&priv->consumed);
+ if (consumed >= priv->quota) {
+ consumed_cap = priv->quota;
+ flags |= NFT_QUOTA_F_DEPLETED;
+ } else {
+ consumed_cap = consumed;
+ }
if (nla_put_be64(skb, NFTA_QUOTA_BYTES, cpu_to_be64(priv->quota),
NFTA_QUOTA_PAD) ||
- nla_put_be64(skb, NFTA_QUOTA_CONSUMED, cpu_to_be64(consumed),
+ nla_put_be64(skb, NFTA_QUOTA_CONSUMED, cpu_to_be64(consumed_cap),
NFTA_QUOTA_PAD) ||
nla_put_be32(skb, NFTA_QUOTA_FLAGS, htonl(flags)))
goto nla_put_failure;
+
+ if (reset) {
+ atomic64_sub(consumed, &priv->consumed);
+ clear_bit(NFT_QUOTA_DEPLETED_BIT, &priv->flags);
+ }
return 0;
nla_put_failure:
--
2.1.4
^ permalink raw reply related
* [PATCH 0/6] Netfilter fixes for net
From: Pablo Neira Ayuso @ 2017-01-05 11:19 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
Hi David,
The following patchset contains accumulated Netfilter fixes for your
net tree:
1) Ensure quota dump and reset happens iff we can deliver numbers to
userspace.
2) Silence splat on incorrect use of smp_processor_id() from nft_queue.
3) Fix an out-of-bound access reported by KASAN in
nf_tables_rule_destroy(), patch from Florian Westphal.
4) Fix layer 4 checksum mangling in the nf_tables payload expression
with IPv6.
5) Fix a race in the CLUSTERIP target from control plane path when two
threads run to add a new configuration object. Serialize invocations
of clusterip_config_init() using spin_lock. From Xin Long.
6) Call br_nf_pre_routing_finish_bridge_finish() once we are done with
the br_nf_pre_routing_finish() hook. From Artur Molchanov.
You can pull these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
Wish you a nice new year btw, thanks!
----------------------------------------------------------------
The following changes since commit a220871be66f99d8957c693cf22ec67ecbd9c23a:
virtio-net: correctly enable multiqueue (2016-12-13 10:37:38 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git HEAD
for you to fetch changes up to 14221cc45caad2fcab3a8543234bb7eda9b540d5:
bridge: netfilter: Fix dropping packets that moving through bridge interface (2016-12-30 18:22:50 +0100)
----------------------------------------------------------------
Artur Molchanov (1):
bridge: netfilter: Fix dropping packets that moving through bridge interface
Florian Westphal (1):
netfilter: nf_tables: fix oob access
Pablo Neira Ayuso (3):
netfilter: nft_quota: reset quota after dump
netfilter: nft_queue: use raw_smp_processor_id()
netfilter: nft_payload: mangle ckecksum if NFT_PAYLOAD_L4CSUM_PSEUDOHDR is set
Xin Long (1):
netfilter: ipt_CLUSTERIP: check duplicate config when initializing
net/bridge/br_netfilter_hooks.c | 2 +-
net/ipv4/netfilter/ipt_CLUSTERIP.c | 34 +++++++++++++++++++++++-----------
net/netfilter/nf_tables_api.c | 2 +-
net/netfilter/nft_payload.c | 27 +++++++++++++++++++--------
net/netfilter/nft_queue.c | 2 +-
net/netfilter/nft_quota.c | 26 ++++++++++++++------------
6 files changed, 59 insertions(+), 34 deletions(-)
^ permalink raw reply
* [PATCH 4/6] netfilter: nft_payload: mangle ckecksum if NFT_PAYLOAD_L4CSUM_PSEUDOHDR is set
From: Pablo Neira Ayuso @ 2017-01-05 11:19 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1483615193-2931-1-git-send-email-pablo@netfilter.org>
If the NFT_PAYLOAD_L4CSUM_PSEUDOHDR flag is set, then mangle layer 4
checksum. This should not depend on csum_type NFT_PAYLOAD_CSUM_INET
since IPv6 header has no checksum field, but still an update of any of
the pseudoheader fields may trigger a layer 4 checksum update.
Fixes: 1814096980bb ("netfilter: nft_payload: layer 4 checksum adjustment for pseudoheader fields")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nft_payload.c | 27 +++++++++++++++++++--------
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/net/netfilter/nft_payload.c b/net/netfilter/nft_payload.c
index 36d2b1096546..7d699bbd45b0 100644
--- a/net/netfilter/nft_payload.c
+++ b/net/netfilter/nft_payload.c
@@ -250,6 +250,22 @@ static int nft_payload_l4csum_update(const struct nft_pktinfo *pkt,
return 0;
}
+static int nft_payload_csum_inet(struct sk_buff *skb, const u32 *src,
+ __wsum fsum, __wsum tsum, int csum_offset)
+{
+ __sum16 sum;
+
+ if (skb_copy_bits(skb, csum_offset, &sum, sizeof(sum)) < 0)
+ return -1;
+
+ nft_csum_replace(&sum, fsum, tsum);
+ if (!skb_make_writable(skb, csum_offset + sizeof(sum)) ||
+ skb_store_bits(skb, csum_offset, &sum, sizeof(sum)) < 0)
+ return -1;
+
+ return 0;
+}
+
static void nft_payload_set_eval(const struct nft_expr *expr,
struct nft_regs *regs,
const struct nft_pktinfo *pkt)
@@ -259,7 +275,6 @@ static void nft_payload_set_eval(const struct nft_expr *expr,
const u32 *src = ®s->data[priv->sreg];
int offset, csum_offset;
__wsum fsum, tsum;
- __sum16 sum;
switch (priv->base) {
case NFT_PAYLOAD_LL_HEADER:
@@ -282,18 +297,14 @@ static void nft_payload_set_eval(const struct nft_expr *expr,
csum_offset = offset + priv->csum_offset;
offset += priv->offset;
- if (priv->csum_type == NFT_PAYLOAD_CSUM_INET &&
+ if ((priv->csum_type == NFT_PAYLOAD_CSUM_INET || priv->csum_flags) &&
(priv->base != NFT_PAYLOAD_TRANSPORT_HEADER ||
skb->ip_summed != CHECKSUM_PARTIAL)) {
- if (skb_copy_bits(skb, csum_offset, &sum, sizeof(sum)) < 0)
- goto err;
-
fsum = skb_checksum(skb, offset, priv->len, 0);
tsum = csum_partial(src, priv->len, 0);
- nft_csum_replace(&sum, fsum, tsum);
- if (!skb_make_writable(skb, csum_offset + sizeof(sum)) ||
- skb_store_bits(skb, csum_offset, &sum, sizeof(sum)) < 0)
+ if (priv->csum_type == NFT_PAYLOAD_CSUM_INET &&
+ nft_payload_csum_inet(skb, src, fsum, tsum, csum_offset))
goto err;
if (priv->csum_flags &&
--
2.1.4
^ permalink raw reply related
* [PATCH 3/6] netfilter: nf_tables: fix oob access
From: Pablo Neira Ayuso @ 2017-01-05 11:19 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1483615193-2931-1-git-send-email-pablo@netfilter.org>
From: Florian Westphal <fw@strlen.de>
BUG: KASAN: slab-out-of-bounds in nf_tables_rule_destroy+0xf1/0x130 at addr ffff88006a4c35c8
Read of size 8 by task nft/1607
When we've destroyed last valid expr, nft_expr_next() returns an invalid expr.
We must not dereference it unless it passes != nft_expr_last() check.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_tables_api.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index a019a87e58ee..0db5f9782265 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -2115,7 +2115,7 @@ static void nf_tables_rule_destroy(const struct nft_ctx *ctx,
* is called on error from nf_tables_newrule().
*/
expr = nft_expr_first(rule);
- while (expr->ops && expr != nft_expr_last(rule)) {
+ while (expr != nft_expr_last(rule) && expr->ops) {
nf_tables_expr_destroy(ctx, expr);
expr = nft_expr_next(expr);
}
--
2.1.4
^ permalink raw reply related
* [PATCH 5/6] netfilter: ipt_CLUSTERIP: check duplicate config when initializing
From: Pablo Neira Ayuso @ 2017-01-05 11:19 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1483615193-2931-1-git-send-email-pablo@netfilter.org>
From: Xin Long <lucien.xin@gmail.com>
Now when adding an ipt_CLUSTERIP rule, it only checks duplicate config in
clusterip_config_find_get(). But after that, there may be still another
thread to insert a config with the same ip, then it leaves proc_create_data
to do duplicate check.
It's more reasonable to check duplicate config by ipt_CLUSTERIP itself,
instead of checking it by proc fs duplicate file check. Before, when proc
fs allowed duplicate name files in a directory, It could even crash kernel
because of use-after-free.
This patch is to check duplicate config under the protection of clusterip
net lock when initializing a new config and correct the return err.
Note that it also moves proc file node creation after adding new config, as
proc_create_data may sleep, it couldn't be called under the clusterip_net
lock. clusterip_config_find_get returns NULL if c->pde is null to make sure
it can't be used until the proc file node creation is done.
Suggested-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/ipv4/netfilter/ipt_CLUSTERIP.c | 34 +++++++++++++++++++++++-----------
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/net/ipv4/netfilter/ipt_CLUSTERIP.c b/net/ipv4/netfilter/ipt_CLUSTERIP.c
index 21db00d0362b..a6b8c1a4102b 100644
--- a/net/ipv4/netfilter/ipt_CLUSTERIP.c
+++ b/net/ipv4/netfilter/ipt_CLUSTERIP.c
@@ -144,7 +144,7 @@ clusterip_config_find_get(struct net *net, __be32 clusterip, int entry)
rcu_read_lock_bh();
c = __clusterip_config_find(net, clusterip);
if (c) {
- if (unlikely(!atomic_inc_not_zero(&c->refcount)))
+ if (!c->pde || unlikely(!atomic_inc_not_zero(&c->refcount)))
c = NULL;
else if (entry)
atomic_inc(&c->entries);
@@ -166,14 +166,15 @@ clusterip_config_init_nodelist(struct clusterip_config *c,
static struct clusterip_config *
clusterip_config_init(const struct ipt_clusterip_tgt_info *i, __be32 ip,
- struct net_device *dev)
+ struct net_device *dev)
{
+ struct net *net = dev_net(dev);
struct clusterip_config *c;
- struct clusterip_net *cn = net_generic(dev_net(dev), clusterip_net_id);
+ struct clusterip_net *cn = net_generic(net, clusterip_net_id);
c = kzalloc(sizeof(*c), GFP_ATOMIC);
if (!c)
- return NULL;
+ return ERR_PTR(-ENOMEM);
c->dev = dev;
c->clusterip = ip;
@@ -185,6 +186,17 @@ clusterip_config_init(const struct ipt_clusterip_tgt_info *i, __be32 ip,
atomic_set(&c->refcount, 1);
atomic_set(&c->entries, 1);
+ spin_lock_bh(&cn->lock);
+ if (__clusterip_config_find(net, ip)) {
+ spin_unlock_bh(&cn->lock);
+ kfree(c);
+
+ return ERR_PTR(-EBUSY);
+ }
+
+ list_add_rcu(&c->list, &cn->configs);
+ spin_unlock_bh(&cn->lock);
+
#ifdef CONFIG_PROC_FS
{
char buffer[16];
@@ -195,16 +207,16 @@ clusterip_config_init(const struct ipt_clusterip_tgt_info *i, __be32 ip,
cn->procdir,
&clusterip_proc_fops, c);
if (!c->pde) {
+ spin_lock_bh(&cn->lock);
+ list_del_rcu(&c->list);
+ spin_unlock_bh(&cn->lock);
kfree(c);
- return NULL;
+
+ return ERR_PTR(-ENOMEM);
}
}
#endif
- spin_lock_bh(&cn->lock);
- list_add_rcu(&c->list, &cn->configs);
- spin_unlock_bh(&cn->lock);
-
return c;
}
@@ -410,9 +422,9 @@ static int clusterip_tg_check(const struct xt_tgchk_param *par)
config = clusterip_config_init(cipinfo,
e->ip.dst.s_addr, dev);
- if (!config) {
+ if (IS_ERR(config)) {
dev_put(dev);
- return -ENOMEM;
+ return PTR_ERR(config);
}
dev_mc_add(config->dev, config->clustermac);
}
--
2.1.4
^ permalink raw reply related
* Re: SIOCSIWFREQ while in NL80211_IFTYPE_STATION
From: Johannes Berg @ 2017-01-05 11:38 UTC (permalink / raw)
To: Jorge Ramirez, netdev-u79uwXL29TY76Z2rM5mHXA, Daniel Lezcano
Cc: linux-wireless
In-Reply-To: <685811c3-6247-77fd-8c70-617951886451-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
+linux-wireless, where this should've gone
> I am running a single wlan0 interface in managed mode (no aliases,
> no other wireless interfaces).
> The association with the AP still hasn't happened.
>
> I noticed that if trying to change the frequency to one of the valid
> values, the driver returns EBUSY.
>
> The call stack is
> cfg80211_wext_siwfreq
> -->cfg80211_mgd_wext_siwfreq
> --->cfg80211_set_monitor_channel (notice call to set 'monitor'
> channel
> in managed mode)
> ----> fails with EBUSY
>
> Is therefore the expected behavior to fail under the above
> circumstances
> (managed mode && single wlan0 interface && no association)?
> And if it is, please could you clarify when would it be valid to
> change the frequency in managed mode?
Frankly, I don't remember - all of this is plastered all over with
backward compatibility hooks etc.
How are you running into this? Why are you even trying to do this? You
really shouldn't use wireless extensions any more.
Also, there shouldn't be much reason to be setting the channel anyway,
unless you want to trigger a connection specifically on that channel,
but then when you use nl80211 you get that included in the CONNECT
command there.
Finally, I suspect that this particular backward compatibility hook
can't really work anyway and could be removed, but I'm not sure that
would have the effect you want either.
johannes
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: Synchronize access to mailbox
From: kbuild test robot @ 2017-01-05 11:46 UTC (permalink / raw)
To: Hariprasad Shenai
Cc: kbuild-all, netdev, davem, leedom, nirranjan, ganeshgr,
Hariprasad Shenai
In-Reply-To: <1483595590-12932-1-git-send-email-hariprasad@chelsio.com>
[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]
Hi Hariprasad,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Hariprasad-Shenai/cxgb4-Synchronize-access-to-mailbox/20170105-193032
config: i386-randconfig-x005-201701 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c: In function 'init_one':
>> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:4712:25: error: 'struct adapter' has no member named 'mbox_list'; did you mean 'mbox_lock'?
INIT_LIST_HEAD(&adapter->mbox_list.list);
^~
vim +4712 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
4706
4707 spin_lock_init(&adapter->stats_lock);
4708 spin_lock_init(&adapter->tid_release_lock);
4709 spin_lock_init(&adapter->win0_lock);
4710 spin_lock_init(&adapter->mbox_lock);
4711
> 4712 INIT_LIST_HEAD(&adapter->mbox_list.list);
4713
4714 INIT_WORK(&adapter->tid_release_task, process_tid_release_list);
4715 INIT_WORK(&adapter->db_full_task, process_db_full);
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 37536 bytes --]
^ permalink raw reply
* Re: [net-next PATCH 5/6] i40e: Add TX and RX support in switchdev mode.
From: Or Gerlitz @ 2017-01-05 11:50 UTC (permalink / raw)
To: Samudrala, Sridhar
Cc: Alexander Duyck, John Fastabend, Anjali Singhai Jain,
jakub.kicinski, intel-wired-lan, Linux Netdev List
In-Reply-To: <586D7B4E.2010308@intel.com>
On Thu, Jan 5, 2017 at 12:46 AM, Samudrala, Sridhar
<sridhar.samudrala@intel.com> wrote:
>
>
> On 1/3/2017 3:03 PM, Or Gerlitz wrote:
>>
>> On Fri, Dec 30, 2016 at 7:04 PM, Samudrala, Sridhar
>> <sridhar.samudrala@intel.com> wrote:
>>>
>>> On 12/30/2016 7:31 AM, Or Gerlitz wrote:
>>>>
>>>> Are you exposing switchdev ops for the representators? didn't see that
>>>> or maybe it's in the 4th patch which didn't make it to the list?
>>>
>>> Not at this time. In the future patches when we offload fdb/vlan
>>> functionality, we could use switchdev ops.
>>
>> but wait, this is the switchdev mode... even before doing any
>> offloading, you want (need) your representor netdevices to have the
>> same HW ID marking they are all ports of the same ASIC, this you can
>> do with the switchdev parent ID attribute.
>
> OK. I will add switchdev_port_attr_get() with PORT_PARENT_ID support in v3.
Good, I made this comment, b/c we want to create a well defined user-experience
to be taken into account also by upper virtualization layers.
Another piece there to add is have your VF reps implement the
get_phys_port_name ndo,
where as we explain in commit cb67b832921cfa20ad79bafdc51f1745339d0557 is used
as follows:
Port phys name (ndo_get_phys_port_name) is implemented to allow exporting
to user-space the VF vport number and along with the switchdev port parent
id (phys_switch_id) enable a udev base consistent naming scheme:
SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}=="<phys_switch_id>", \
ATTR{phys_port_name}!="", NAME="$PF_NIC$attr{phys_port_name}"
where phys_switch_id is exposed by the PF (and VF reps) and $PF_NIC is
the name of the PF netdevice.
Or.
^ permalink raw reply
* Re: [PATCH net-next V2 0/3] net/sched: act_pedit: Use offset relative to conventional network headers
From: Jiri Benc @ 2017-01-05 11:54 UTC (permalink / raw)
To: Amir Vadai
Cc: David S. Miller, netdev, Jiri Pirko, Or Gerlitz, Hadar Har-Zion
In-Reply-To: <20170105095454.32644-1-amir@vadai.me>
On Thu, 5 Jan 2017 11:54:51 +0200, Amir Vadai wrote:
> You asked me [1] why did I use specific header names instead of layers (L2, L3...),
> and I explained that it is on purpose, this extra information is planned to be used
> by hardware drivers to offload the action.
>
> Some FW/HW parser APIs are such that they need to get the specific header type (e.g
> IPV4 or IPV6, TCP or UDP) and not only the networking level (e.g network or transport).
Don't we need better API specification (and enforcement) then, though?
See below.
> Usage example:
> $ tc filter add dev enp0s9 protocol ip parent ffff: \
> flower \
> ip_proto tcp \
> dst_port 80 \
> action \
> pedit munge ip ttl add 0xff \
> pedit munge tcp dport set 8080 \
> pipe action mirred egress redirect dev veth0
What happens when one does:
tc filter add ... flower ip_proto udp action pedit munge tcp ...
?
Jiri
^ permalink raw reply
* Re: [net-next PATCH v2 5/6] i40e: Add TX and RX support in switchdev mode.
From: Or Gerlitz @ 2017-01-05 12:08 UTC (permalink / raw)
To: Sridhar Samudrala, jakub.kicinski, John Fastabend, Jiri Pirko
Cc: Alexander Duyck, Anjali Singhai Jain, David Miller,
intel-wired-lan, Linux Netdev List
In-Reply-To: <1483466874-2962-6-git-send-email-sridhar.samudrala@intel.com>
On Tue, Jan 3, 2017 at 8:07 PM, Sridhar Samudrala
<sridhar.samudrala@intel.com> wrote:
> A host based switching entity like a linux bridge or OVS redirects these frames
> to the right VFs via VFPR netdevs. Any frames sent via VFPR netdevs are sent as
> directed transmits to the corresponding VFs. To enable directed transmit, skb
> metadata dst is used to pass the VF id and the frame is requeued to call the PFs
> transmit routine.
Jakub/John, patch #4 which didn't appear in the list had a long discussion [1]
ending with "lets talk on it @ netdev", did we?
Or.
[1] http://marc.info/?t=147457252900002&r=1&w=2
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: Synchronize access to mailbox
From: kbuild test robot @ 2017-01-05 12:22 UTC (permalink / raw)
To: Hariprasad Shenai
Cc: kbuild-all, netdev, davem, leedom, nirranjan, ganeshgr,
Hariprasad Shenai
In-Reply-To: <1483595590-12932-1-git-send-email-hariprasad@chelsio.com>
[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]
Hi Hariprasad,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Hariprasad-Shenai/cxgb4-Synchronize-access-to-mailbox/20170105-193032
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa
All errors (new ones prefixed by >>):
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c: In function 'init_one':
>> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:4712:25: error: 'struct adapter' has no member named 'mbox_list'
INIT_LIST_HEAD(&adapter->mbox_list.list);
^
vim +4712 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
4706
4707 spin_lock_init(&adapter->stats_lock);
4708 spin_lock_init(&adapter->tid_release_lock);
4709 spin_lock_init(&adapter->win0_lock);
4710 spin_lock_init(&adapter->mbox_lock);
4711
> 4712 INIT_LIST_HEAD(&adapter->mbox_list.list);
4713
4714 INIT_WORK(&adapter->tid_release_task, process_tid_release_list);
4715 INIT_WORK(&adapter->db_full_task, process_db_full);
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 48144 bytes --]
^ permalink raw reply
* [PATCH ipsec-next] xfrm: state: do not acquire lock in get_mtu helpers
From: Florian Westphal @ 2017-01-05 12:23 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
Once flow cache gets removed the mtu initialisation happens for every skb
that gets an xfrm attached, so this lock starts to show up in perf.
It is not obvious why this lock is required -- the caller holds
reference on the state struct, type->destructor is only called from the
state gc worker (all state structs on gc list must have refcount 0).
xfrm_init_state already has been called (else private data accessed
by type->get_mtu() would not be set up).
So just remove the lock -- the race on the state (DEAD?) doesn't
matter (could change right after dropping the lock too).
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/xfrm/xfrm_state.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 64e3c82eedf6..53877fea9316 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -2000,16 +2000,13 @@ EXPORT_SYMBOL(xfrm_state_delete_tunnel);
int xfrm_state_mtu(struct xfrm_state *x, int mtu)
{
- int res;
+ const struct xfrm_type *type = READ_ONCE(x->type);
- spin_lock_bh(&x->lock);
if (x->km.state == XFRM_STATE_VALID &&
- x->type && x->type->get_mtu)
- res = x->type->get_mtu(x, mtu);
- else
- res = mtu - x->props.header_len;
- spin_unlock_bh(&x->lock);
- return res;
+ type && type->get_mtu)
+ return type->get_mtu(x, mtu);
+
+ return mtu - x->props.header_len;
}
int __xfrm_init_state(struct xfrm_state *x, bool init_replay)
--
2.7.3
^ permalink raw reply related
* Re: [PATCH] netfilter: xt_connlimit: use rb_entry()
From: Pablo Neira Ayuso @ 2017-01-05 12:26 UTC (permalink / raw)
To: Geliang Tang
Cc: Patrick McHardy, Jozsef Kadlecsik, David S. Miller,
netfilter-devel, coreteam, netdev, linux-kernel
In-Reply-To: <5fab578543b7f15cb416438800e24e70af675835.1482204114.git.geliangtang@gmail.com>
On Tue, Dec 20, 2016 at 10:02:13PM +0800, Geliang Tang wrote:
> To make the code clearer, use rb_entry() instead of container_of() to
> deal with rbtree.
Applied this one to nf-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next V2 0/3] net/sched: act_pedit: Use offset relative to conventional network headers
From: Amir Vadai @ 2017-01-05 12:34 UTC (permalink / raw)
To: Jiri Benc; +Cc: David S. Miller, netdev, Jiri Pirko, Or Gerlitz, Hadar Har-Zion
In-Reply-To: <20170105125414.5640b1b8@griffin>
On Thu, Jan 05, 2017 at 12:54:14PM +0100, Jiri Benc wrote:
> On Thu, 5 Jan 2017 11:54:51 +0200, Amir Vadai wrote:
> > You asked me [1] why did I use specific header names instead of layers (L2, L3...),
> > and I explained that it is on purpose, this extra information is planned to be used
> > by hardware drivers to offload the action.
> >
> > Some FW/HW parser APIs are such that they need to get the specific header type (e.g
> > IPV4 or IPV6, TCP or UDP) and not only the networking level (e.g network or transport).
>
> Don't we need better API specification (and enforcement) then, though?
> See below.
>
> > Usage example:
> > $ tc filter add dev enp0s9 protocol ip parent ffff: \
> > flower \
> > ip_proto tcp \
> > dst_port 80 \
> > action \
> > pedit munge ip ttl add 0xff \
> > pedit munge tcp dport set 8080 \
> > pipe action mirred egress redirect dev veth0
>
> What happens when one does:
>
> tc filter add ... flower ip_proto udp action pedit munge tcp ...
>
> ?
This is a simple action. It is not fool proof - it prevents the user
from getting out of packet bounds, but it is the user responsibility to
provide valid rules.
>
> Jiri
^ permalink raw reply
* Re: [net-next PATCH v2 2/6] i40e: Introduce VF Port Representator(VFPR) netdevs.
From: Jiri Pirko @ 2017-01-05 12:44 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: alexander.h.duyck, john.r.fastabend, anjali.singhai,
jakub.kicinski, davem, intel-wired-lan, netdev
In-Reply-To: <1483466874-2962-3-git-send-email-sridhar.samudrala@intel.com>
Tue, Jan 03, 2017 at 07:07:50PM CET, sridhar.samudrala@intel.com wrote:
>VF Port Representator netdevs are created for each VF if the switch mode
>is set to 'switchdev'. These netdevs can be used to control and configure
>VFs from PFs namespace. They enable exposing VF statistics, configure and
>monitor link state, mtu, filters, fdb/vlan entries etc. of VFs.
>Broadcast filters are not enabled in switchdev mode.
>
>Sample script to create VF port representors
># rmmod i40e; modprobe i40e
># devlink dev eswitch set pci/0000:05:00.0 mode switchdev
># echo 2 > /sys/class/net/enp5s0f0/device/sriov_numvfs
># ip l show
>297: enp5s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop portid 6805ca2e7268 state DOWN mode DEFAULT group default qlen 1000
> link/ether 68:05:ca:2e:72:68 brd ff:ff:ff:ff:ff:ff
> vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off
> vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off
>299: enp5s0f0-vf0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
>300: enp5s0f0-vf1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
>
>Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
>---
> drivers/net/ethernet/intel/i40e/i40e_main.c | 21 ++-
> drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 154 ++++++++++++++++++++-
> drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h | 14 ++
> 3 files changed, 182 insertions(+), 7 deletions(-)
>
>diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
>index c01a620..17428f0 100644
>--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
>+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
>@@ -10938,15 +10938,34 @@ static int i40e_devlink_eswitch_mode_get(struct devlink *devlink, u16 *mode)
> static int i40e_devlink_eswitch_mode_set(struct devlink *devlink, u16 mode)
> {
> struct i40e_pf *pf = devlink_priv(devlink);
>- int err = 0;
>+ struct i40e_vf *vf;
>+ int i, j, err = 0;
>
> if (mode == pf->eswitch_mode)
> goto done;
>
> switch (mode) {
> case DEVLINK_ESWITCH_MODE_LEGACY:
>+ for (i = 0; i < pf->num_alloc_vfs; i++) {
>+ vf = &(pf->vf[i]);
>+ i40e_free_vfpr_netdev(vf);
>+ }
> pf->eswitch_mode = mode;
> break;
>+ case DEVLINK_ESWITCH_MODE_SWITCHDEV:
>+ for (i = 0; i < pf->num_alloc_vfs; i++) {
>+ vf = &(pf->vf[i]);
>+ err = i40e_alloc_vfpr_netdev(vf, i);
>+ if (err) {
>+ for (j = 0; j < i; j++) {
>+ vf = &(pf->vf[j]);
>+ i40e_free_vfpr_netdev(vf);
>+ }
>+ goto done;
>+ }
>+ }
>+ pf->eswitch_mode = mode;
^^^^^^^^^^^^^^^^ wrong indent
^ permalink raw reply
* Re: [PATCH net-next V2 0/3] net/sched: act_pedit: Use offset relative to conventional network headers
From: Jiri Benc @ 2017-01-05 12:44 UTC (permalink / raw)
To: Amir Vadai
Cc: David S. Miller, netdev, Jiri Pirko, Or Gerlitz, Hadar Har-Zion
In-Reply-To: <20170105123458.GA2361@office.localdomain>
On Thu, 5 Jan 2017 14:34:58 +0200, Amir Vadai wrote:
> This is a simple action. It is not fool proof - it prevents the user
> from getting out of packet bounds, but it is the user responsibility to
> provide valid rules.
I think I can live with that. Just wanted to point that out. Especially
with combination with hardware offload (e.g. the hardware should not
hang or reset on that).
Jiri
^ permalink raw reply
* Re: [net-next PATCH v2 5/6] i40e: Add TX and RX support in switchdev mode.
From: Jiri Pirko @ 2017-01-05 12:56 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: alexander.h.duyck, john.r.fastabend, anjali.singhai,
jakub.kicinski, davem, intel-wired-lan, netdev
In-Reply-To: <1483466874-2962-6-git-send-email-sridhar.samudrala@intel.com>
Tue, Jan 03, 2017 at 07:07:53PM CET, sridhar.samudrala@intel.com wrote:
>In switchdev mode, broadcast filter is not enabled on VFs. The broadcasts and
>unknown frames from VFs are received by the PF and passed to corresponding VF
>port representator netdev.
>A host based switching entity like a linux bridge or OVS redirects these frames
>to the right VFs via VFPR netdevs. Any frames sent via VFPR netdevs are sent as
>directed transmits to the corresponding VFs. To enable directed transmit, skb
>metadata dst is used to pass the VF id and the frame is requeued to call the PFs
>transmit routine.
>
>Small script to demonstrate inter VF pings in switchdev mode.
>PF: enp5s0f0, VFs: enp5s2,enp5s2f1 VFPRs:enp5s0f0-vf0, enp5s0f0-vf1
>
># rmmod i40e; modprobe i40e
># devlink dev eswitch set pci/0000:05:00.0 mode switchdev
># echo 2 > /sys/class/net/enp5s0f0/device/sriov_numvfs
># ip link set enp5s0f0 vf 0 mac 00:11:22:33:44:55
># ip link set enp5s0f0 vf 1 mac 00:11:22:33:44:56
># rmmod i40evf; modprobe i40evf
>
>/* Create 2 namespaces and move the VFs to the corresponding ns. */
># ip netns add ns0
># ip link set enp5s2 netns ns0
># ip netns exec ns0 ip addr add 192.168.1.10/24 dev enp5s2
># ip netns exec ns0 ip link set enp5s2 up
># ip netns add ns1
># ip link set enp5s2f1 netns ns1
># ip netns exec ns1 ip addr add 192.168.1.11/24 dev enp5s2f1
># ip netns exec ns1 ip link set enp5s2f1 up
>
>/* bring up pf and vfpr netdevs */
># ip link set enp5s0f0 up
># ip link set enp5s0f0-vf0 up
># ip link set enp5s0f0-vf1 up
>
>/* Create a linux bridge and add vfpr netdevs to it. */
># ip link add vfpr-br type bridge
># ip link set enp5s0f0-vf0 master vfpr-br
># ip link set enp5s0f0-vf1 master vfpr-br
># ip addr add 192.168.1.1/24 dev vfpr-br
># ip link set vfpr-br up
>
># ip netns exec ns0 ping -c3 192.168.1.11
># ip netns exec ns1 ping -c3 192.168.1.10
>
>Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
[...]
>diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
>index 352cf7c..b46ddaa 100644
>--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
>+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
>@@ -1176,16 +1176,37 @@ static bool i40e_alloc_mapped_page(struct i40e_ring *rx_ring,
> * @rx_ring: rx ring in play
> * @skb: packet to send up
> * @vlan_tag: vlan tag for packet
>+ * @lpbk: is it a loopback frame?
> **/
> static void i40e_receive_skb(struct i40e_ring *rx_ring,
>- struct sk_buff *skb, u16 vlan_tag)
>+ struct sk_buff *skb, u16 vlan_tag, bool lpbk)
> {
> struct i40e_q_vector *q_vector = rx_ring->q_vector;
>+ struct i40e_pf *pf = rx_ring->vsi->back;
>+ struct i40e_vf *vf;
>+ struct ethhdr *eth;
>+ int vf_id;
>
> if ((rx_ring->netdev->features & NETIF_F_HW_VLAN_CTAG_RX) &&
> (vlan_tag & VLAN_VID_MASK))
> __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlan_tag);
>
>+ if ((pf->eswitch_mode == DEVLINK_ESWITCH_MODE_LEGACY) || !lpbk)
>+ goto gro_receive;
>+
>+ /* If a loopback packet is received from a VF in switchdev mode, pass the
>+ * frame to the corresponding VFPR netdev based on the source MAC in the frame.
>+ */
>+ eth = (struct ethhdr *)skb_mac_header(skb);
>+ for (vf_id = 0; vf_id < pf->num_alloc_vfs; vf_id++) {
>+ vf = &pf->vf[vf_id];
>+ if (ether_addr_equal(eth->h_source, vf->default_lan_addr.addr)) {
>+ skb->dev = vf->vfpr_netdev;
This sucks :( Is't there any identification coming from rx ring that
would tell you what vf this is? To match vrpr according to a single MAC
address seems a bit awkward. What if there is a macvlan configured
on the VF?
>+ break;
>+ }
>+ }
>+
>+gro_receive:
> napi_gro_receive(&q_vector->napi, skb);
> }
>
[...]
>@@ -2998,3 +3064,19 @@ netdev_tx_t i40e_lan_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
>
> return i40e_xmit_frame_ring(skb, tx_ring);
> }
>+
>+netdev_tx_t i40e_vfpr_netdev_start_xmit(struct sk_buff *skb,
>+ struct net_device *dev)
>+{
>+ struct i40e_vfpr_netdev_priv *priv = netdev_priv(dev);
>+ struct i40e_vf *vf = priv->vf;
>+ struct i40e_pf *pf = vf->pf;
>+ struct i40e_vsi *vsi = pf->vsi[pf->lan_vsi];
>+
>+ skb_dst_drop(skb);
>+ dst_hold(&priv->vfpr_dst->dst);
>+ skb_dst_set(skb, &priv->vfpr_dst->dst);
>+ skb->dev = vsi->netdev;
This dst dance seems a bit odd to me. Why don't you just call
i40e_xmit_frame_ring with an extra arg holding the needed metadata?
>+
>+ return dev_queue_xmit(skb);
>+}
>diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.h b/drivers/net/ethernet/intel/i40e/i40e_txrx.h
>index e065321..850723f 100644
>--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.h
>+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.h
>@@ -366,6 +366,7 @@ struct i40e_ring_container {
>
> bool i40e_alloc_rx_buffers(struct i40e_ring *rxr, u16 cleaned_count);
> netdev_tx_t i40e_lan_xmit_frame(struct sk_buff *skb, struct net_device *netdev);
>+netdev_tx_t i40e_vfpr_netdev_start_xmit(struct sk_buff *skb, struct net_device *netdev);
> void i40e_clean_tx_ring(struct i40e_ring *tx_ring);
> void i40e_clean_rx_ring(struct i40e_ring *rx_ring);
> int i40e_setup_tx_descriptors(struct i40e_ring *tx_ring);
>diff --git a/drivers/net/ethernet/intel/i40e/i40e_type.h b/drivers/net/ethernet/intel/i40e/i40e_type.h
>index edc0abd..c136cc9 100644
>--- a/drivers/net/ethernet/intel/i40e/i40e_type.h
>+++ b/drivers/net/ethernet/intel/i40e/i40e_type.h
>@@ -728,6 +728,9 @@ enum i40e_rx_desc_status_bits {
> #define I40E_RXD_QW1_STATUS_TSYNVALID_SHIFT I40E_RX_DESC_STATUS_TSYNVALID_SHIFT
> #define I40E_RXD_QW1_STATUS_TSYNVALID_MASK \
> BIT_ULL(I40E_RXD_QW1_STATUS_TSYNVALID_SHIFT)
>+#define I40E_RXD_QW1_STATUS_LPBK_SHIFT I40E_RX_DESC_STATUS_LPBK_SHIFT
>+#define I40E_RXD_QW1_STATUS_LPBK_MASK \
>+ BIT_ULL(I40E_RXD_QW1_STATUS_LPBK_SHIFT)
>
> enum i40e_rx_desc_fltstat_values {
> I40E_RX_DESC_FLTSTAT_NO_DATA = 0,
>diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
>index 0c8687d..f0860ef 100644
>--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
>+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
>@@ -1062,6 +1062,7 @@ static int i40e_vfpr_netdev_stop(struct net_device *dev)
> static const struct net_device_ops i40e_vfpr_netdev_ops = {
> .ndo_open = i40e_vfpr_netdev_open,
> .ndo_stop = i40e_vfpr_netdev_stop,
>+ .ndo_start_xmit = i40e_vfpr_netdev_start_xmit,
> };
>
> /**
>@@ -1121,16 +1122,22 @@ int i40e_alloc_vfpr_netdev(struct i40e_vf *vf, u16 vf_num)
>
> priv = netdev_priv(vfpr_netdev);
> priv->vf = &(pf->vf[vf_num]);
>+ priv->vfpr_dst = metadata_dst_alloc(0, METADATA_HW_PORT_MUX, GFP_KERNEL);
I'm missing a patch here. In net-next, metadata_dst_alloc has 2 args.
^ permalink raw reply
* Re: [PATCH v3 3/3] stmmac: adding new glue driver dwmac-dwc-qos-eth
From: Lars Persson @ 2017-01-05 13:11 UTC (permalink / raw)
To: Joao Pinto
Cc: davem@davemloft.net, Niklas Cassel, swarren@nvidia.com,
treding@nvidia.com, netdev@vger.kernel.org
In-Reply-To: <f72953efa2d6a42975b553a6b517c63480f4650b.1483546363.git.jpinto@synopsys.com>
> On 04 Jan 2017, at 17:22 , Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>
> This patch adds a new glue driver called dwmac-dwc-qos-eth which
> was based in the dwc_eth_qos as is. To assure retro-compatibility a slight
> tweak was also added to stmmac_platform.
>
> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
> ---
> changes v2 -> v3:
> - Nothing changed, just to keep up patch set version
> changes v1 -> v2:
> - WOL was not declared in the new glue driver
> - clocks were switched and now fixed (apb_pclk and phy_ref_clk)
>
> .../bindings/net/snps,dwc-qos-ethernet.txt | 3 +
> drivers/net/ethernet/stmicro/stmmac/Kconfig | 9 +
> drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
> .../ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c | 200 +++++++++++++++++++++
> .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 15 +-
> 5 files changed, 225 insertions(+), 3 deletions(-)
> create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
>
> diff --git a/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt b/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt
> index d93f71c..21d27aa 100644
> --- a/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt
> +++ b/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt
> @@ -1,5 +1,8 @@
> * Synopsys DWC Ethernet QoS IP version 4.10 driver (GMAC)
>
> +This binding is deprecated, but it continues to be supported, but new
> +features should be preferably added to the stmmac binding document.
> +
> This binding supports the Synopsys Designware Ethernet QoS (Quality Of Service)
> IP block. The IP supports multiple options for bus type, clocking and reset
> structure, and feature list. Consequently, a number of properties and list
> diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> index ab66248..99594e3 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
> +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> @@ -29,6 +29,15 @@ config STMMAC_PLATFORM
>
> if STMMAC_PLATFORM
>
> +config DWMAC_DWC_QOS_ETH
> + tristate "Support for snps,dwc-qos-ethernet.txt DT binding."
> + select PHYLIB
> + select CRC32
> + select MII
> + depends on OF && HAS_DMA
> + help
> + Support for chips using the snps,dwc-qos-ethernet.txt DT binding.
> +
> config DWMAC_GENERIC
> tristate "Generic driver for DWMAC"
> default STMMAC_PLATFORM
> diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
> index 8f83a86..700c603 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/Makefile
> +++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_DWMAC_SOCFPGA) += dwmac-altr-socfpga.o
> obj-$(CONFIG_DWMAC_STI) += dwmac-sti.o
> obj-$(CONFIG_DWMAC_STM32) += dwmac-stm32.o
> obj-$(CONFIG_DWMAC_SUNXI) += dwmac-sunxi.o
> +obj-$(CONFIG_DWMAC_DWC_QOS_ETH) += dwmac-dwc-qos-eth.o
> obj-$(CONFIG_DWMAC_GENERIC) += dwmac-generic.o
> stmmac-platform-objs:= stmmac_platform.o
> dwmac-altr-socfpga-objs := altr_tse_pcs.o dwmac-socfpga.o
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
> new file mode 100644
> index 0000000..4532a7c
> --- /dev/null
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
> @@ -0,0 +1,200 @@
> +/*
> + * Synopsys DWC Ethernet Quality-of-Service v4.10a linux driver
> + *
> + * Copyright (C) 2016 Joao Pinto <jpinto@synopsys.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/clk-provider.h>
> +#include <linux/device.h>
> +#include <linux/ethtool.h>
> +#include <linux/io.h>
> +#include <linux/ioport.h>
> +#include <linux/module.h>
> +#include <linux/of_net.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/platform_device.h>
> +#include <linux/stmmac.h>
> +
> +#include "stmmac_platform.h"
> +
> +static int dwc_eth_dwmac_config_dt(struct platform_device *pdev,
> + struct plat_stmmacenet_data *plat_dat)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + u32 burst_map = 0;
> + u32 bit_index = 0;
> + u32 a_index = 0;
> +
> + if (!plat_dat->axi) {
> + plat_dat->axi = kzalloc(sizeof(struct stmmac_axi), GFP_KERNEL);
> +
> + if (!plat_dat->axi)
> + return -ENOMEM;
> + }
> +
> + plat_dat->axi->axi_lpi_en = of_property_read_bool(np, "snps,en-lpi");
> + if (of_property_read_u32(np, "snps,write-requests",
> + &plat_dat->axi->axi_wr_osr_lmt)) {
> + /**
> + * Since the register has a reset value of 1, if property
> + * is missing, default to 1.
> + */
> + plat_dat->axi->axi_wr_osr_lmt = 1;
> + } else {
> + /**
> + * If property exists, to keep the behavior from dwc_eth_qos,
> + * subtract one after parsing.
> + */
> + plat_dat->axi->axi_wr_osr_lmt--;
> + }
> +
> + if (of_property_read_u32(np, "read,read-requests",
> + &plat_dat->axi->axi_rd_osr_lmt)) {
> + /**
> + * Since the register has a reset value of 1, if property
> + * is missing, default to 1.
> + */
> + plat_dat->axi->axi_rd_osr_lmt = 1;
> + } else {
> + /**
> + * If property exists, to keep the behavior from dwc_eth_qos,
> + * subtract one after parsing.
> + */
> + plat_dat->axi->axi_rd_osr_lmt--;
> + }
> + of_property_read_u32(np, "snps,burst-map", &burst_map);
> +
> + /* converts burst-map bitmask to burst array */
> + for (bit_index = 0; bit_index < 7; bit_index++) {
> + if (burst_map & (1 << bit_index)) {
> + switch (bit_index) {
> + case 0:
> + plat_dat->axi->axi_blen[a_index] = 4; break;
> + case 1:
> + plat_dat->axi->axi_blen[a_index] = 8; break;
> + case 2:
> + plat_dat->axi->axi_blen[a_index] = 16; break;
> + case 3:
> + plat_dat->axi->axi_blen[a_index] = 32; break;
> + case 4:
> + plat_dat->axi->axi_blen[a_index] = 64; break;
> + case 5:
> + plat_dat->axi->axi_blen[a_index] = 128; break;
> + case 6:
> + plat_dat->axi->axi_blen[a_index] = 256; break;
> + default:
> + break;
> + }
> + a_index++;
> + }
> + }
> +
> + /* dwc-qos needs GMAC4, AAL, TSO and PMT */
> + plat_dat->has_gmac4 = 1;
> + plat_dat->dma_cfg->aal = 1;
> + plat_dat->tso_en = 1;
> + plat_dat->pmt = 1;
> +
> + return 0;
> +}
> +
> +static int dwc_eth_dwmac_probe(struct platform_device *pdev)
> +{
> + struct plat_stmmacenet_data *plat_dat;
> + struct stmmac_resources stmmac_res;
We should initialise the entire stmmac_res with zeros. Right now we leave lpi_irq with an undefined value.
> + struct resource *res;
> + int ret;
> +
> + /**
> + * Since stmmac_platform supports name IRQ only, basic platform
> + * resource initialization is done in the glue logic.
> + */
> + stmmac_res.irq = platform_get_irq(pdev, 0);
> + if (stmmac_res.irq < 0) {
> + if (stmmac_res.irq != -EPROBE_DEFER) {
> + dev_err(&pdev->dev,
> + "IRQ configuration information not found\n");
> + }
> + return stmmac_res.irq;
> + }
> + stmmac_res.wol_irq = stmmac_res.irq;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + stmmac_res.addr = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(stmmac_res.addr))
> + return PTR_ERR(stmmac_res.addr);
> +
> + plat_dat = stmmac_probe_config_dt(pdev, &stmmac_res.mac);
> + if (IS_ERR(plat_dat))
> + return PTR_ERR(plat_dat);
> +
> + plat_dat->stmmac_clk = devm_clk_get(&pdev->dev, "apb_pclk");
> + if (IS_ERR(plat_dat->stmmac_clk)) {
> + dev_err(&pdev->dev, "apb_pclk clock not found.\n");
> + ret = PTR_ERR(plat_dat->stmmac_clk);
> + plat_dat->stmmac_clk = NULL;
> + goto err_remove_config_dt;
> + }
> + clk_prepare_enable(plat_dat->stmmac_clk);
> +
> + plat_dat->pclk = devm_clk_get(&pdev->dev, "phy_ref_clk");
> + if (IS_ERR(plat_dat->pclk)) {
> + dev_err(&pdev->dev, "phy_ref_clk clock not found.\n");
> + ret = PTR_ERR(plat_dat->pclk);
> + plat_dat->pclk = NULL;
> + goto err_out_clk_dis_phy;
> + }
> + clk_prepare_enable(plat_dat->pclk);
> +
> + ret = dwc_eth_dwmac_config_dt(pdev, plat_dat);
> + if (ret)
> + goto err_out_clk_dis_aper;
> +
> + ret = stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
> + if (ret)
> + goto err_out_clk_dis_aper;
> +
> + return 0;
> +
> +err_out_clk_dis_aper:
> + clk_disable_unprepare(plat_dat->pclk);
> +err_out_clk_dis_phy:
> + clk_disable_unprepare(plat_dat->stmmac_clk);
> +err_remove_config_dt:
> + stmmac_remove_config_dt(pdev, plat_dat);
> +
> + return ret;
> +}
> +
> +static int dwc_eth_dwmac_remove(struct platform_device *pdev)
> +{
> + return stmmac_pltfr_remove(pdev);
> +}
> +
> +static const struct of_device_id dwc_eth_dwmac_match[] = {
> + { .compatible = "snps,dwc-qos-ethernet-4.10", },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, dwc_eth_dwmac_match);
> +
> +static struct platform_driver dwc_eth_dwmac_driver = {
> + .probe = dwc_eth_dwmac_probe,
> + .remove = dwc_eth_dwmac_remove,
> + .driver = {
> + .name = "dwc-eth-dwmac",
> + .of_match_table = dwc_eth_dwmac_match,
> + },
> +};
> +module_platform_driver(dwc_eth_dwmac_driver);
> +
> +MODULE_AUTHOR("Joao Pinto <jpinto@synopsys.com>");
> +MODULE_DESCRIPTION("Synopsys DWC Ethernet Quality-of-Service v4.10a driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> index 4e44f9c..00c0f8d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> @@ -181,10 +181,19 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
> mdio = false;
> }
>
> - /* If snps,dwmac-mdio is passed from DT, always register the MDIO */
> - for_each_child_of_node(np, plat->mdio_node) {
> - if (of_device_is_compatible(plat->mdio_node, "snps,dwmac-mdio"))
> + /* exception for dwmac-dwc-qos-eth glue logic */
> + if (of_device_is_compatible(np, "snps,dwc-qos-ethernet-4.10")) {
> + plat->mdio_node = of_get_child_by_name(np, "mdio");
> + } else {
> + /**
> + * If snps,dwmac-mdio is passed from DT, always register
> + * the MDIO
> + */
> + for_each_child_of_node(np, plat->mdio_node) {
> + if (of_device_is_compatible(plat->mdio_node,
> + "snps,dwmac-mdio"))
> break;
> + }
> }
>
> if (plat->mdio_node) {
> --
> 2.9.3
>
Hi Joao
See one comment inline in the patch.
- Lars
^ permalink raw reply
* Re: SIOCSIWFREQ while in NL80211_IFTYPE_STATION
From: Jorge Ramirez @ 2017-01-05 13:27 UTC (permalink / raw)
To: Johannes Berg, netdev, Daniel Lezcano; +Cc: linux-wireless
In-Reply-To: <1483616301.4394.6.camel@sipsolutions.net>
On 01/05/2017 12:38 PM, Johannes Berg wrote:
> +linux-wireless, where this should've gone
nice. thanks and apologies.
>
>> I am running a single wlan0 interface in managed mode (no aliases,
>> no other wireless interfaces).
>> The association with the AP still hasn't happened.
>>
>> I noticed that if trying to change the frequency to one of the valid
>> values, the driver returns EBUSY.
>>
>> The call stack is
>> cfg80211_wext_siwfreq
>> -->cfg80211_mgd_wext_siwfreq
>> --->cfg80211_set_monitor_channel (notice call to set 'monitor'
>> channel
>> in managed mode)
>> ----> fails with EBUSY
>>
>> Is therefore the expected behavior to fail under the above
>> circumstances
>> (managed mode && single wlan0 interface && no association)?
>> And if it is, please could you clarify when would it be valid to
>> change the frequency in managed mode?
> Frankly, I don't remember - all of this is plastered all over with
> backward compatibility hooks etc.
yes, that is also what it seems to me: plenty of sedimentation in that
code path.
>
> How are you running into this? Why are you even trying to do this? You
> really shouldn't use wireless extensions any more.
I am not sure it matters - if I understood your reply, there is no valid
use case to change the frequency in that mode (and all that code should
be removed); it seems to me that it is also your view that userspace
(iwconfig) should be fixed accordingly to not call the extensions?
please let me know if I misunderstood your answer.
I am just trying to understand how the current code is supposed to work
by exercising widely available user-space tools while debugging the kernel.
I noticed the error (EBUSY) just using the wireless tools package as per
its man pages.
$ iwconfig wlan0 freq <frequency>
So, what other tool should we use instead of iwconfig (if the use case
is valid)?
>
> Also, there shouldn't be much reason to be setting the channel anyway,
> unless you want to trigger a connection specifically on that channel,
> but then when you use nl80211 you get that included in the CONNECT
> command there.
> Finally, I suspect that this particular backward compatibility hook
> can't really work anyway and could be removed, but I'm not sure that
> would have the effect you want either.
Actually the frequency gets programmed without errors when reverting
your commit http://tinyurl.com/ho4urp8 (which comes as a surprise as well).
It seems there is some more users doing the same for research purposes.
https://github.com/seemoo-lab/bcm-rpi3/blob/master/kernel/net/wireless/chan.c#L855
>
> johannes
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: b53: Utilize common helpers for u64/MAC
From: kbuild test robot @ 2017-01-05 13:39 UTC (permalink / raw)
To: Florian Fainelli
Cc: kbuild-all, netdev, davem, andrew, vivien.didelot,
volodymyr.bendiuga, Florian Fainelli
In-Reply-To: <20170104215320.19293-1-f.fainelli@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2165 bytes --]
Hi Florian,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-dsa-b53-Utilize-common-helpers-for-u64-MAC/20170105-203441
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64
All errors (new ones prefixed by >>):
In file included from drivers/net/dsa/b53/b53_spi.c:27:0:
drivers/net/dsa/b53/b53_priv.h: In function 'b53_arl_to_entry':
>> drivers/net/dsa/b53/b53_priv.h:336:2: error: implicit declaration of function 'u64_to_ether_addr' [-Werror=implicit-function-declaration]
u64_to_ether_addr(mac_vid, ent->mac);
^~~~~~~~~~~~~~~~~
drivers/net/dsa/b53/b53_priv.h: In function 'b53_arl_from_entry':
>> drivers/net/dsa/b53/b53_priv.h:343:13: error: implicit declaration of function 'ether_addr_to_u64' [-Werror=implicit-function-declaration]
*mac_vid = ether_addr_to_u64(ent->mac);
^~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/u64_to_ether_addr +336 drivers/net/dsa/b53/b53_priv.h
330 {
331 memset(ent, 0, sizeof(*ent));
332 ent->port = fwd_entry & ARLTBL_DATA_PORT_ID_MASK;
333 ent->is_valid = !!(fwd_entry & ARLTBL_VALID);
334 ent->is_age = !!(fwd_entry & ARLTBL_AGE);
335 ent->is_static = !!(fwd_entry & ARLTBL_STATIC);
> 336 u64_to_ether_addr(mac_vid, ent->mac);
337 ent->vid = mac_vid >> ARLTBL_VID_S;
338 }
339
340 static inline void b53_arl_from_entry(u64 *mac_vid, u32 *fwd_entry,
341 const struct b53_arl_entry *ent)
342 {
> 343 *mac_vid = ether_addr_to_u64(ent->mac);
344 *mac_vid |= (u64)(ent->vid & ARLTBL_VID_MASK) << ARLTBL_VID_S;
345 *fwd_entry = ent->port & ARLTBL_DATA_PORT_ID_MASK;
346 if (ent->is_valid)
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 45845 bytes --]
^ permalink raw reply
* Re: SIOCSIWFREQ while in NL80211_IFTYPE_STATION
From: Johannes Berg @ 2017-01-05 14:06 UTC (permalink / raw)
To: Jorge Ramirez, netdev, Daniel Lezcano; +Cc: linux-wireless
In-Reply-To: <92e60cb2-8bb4-df03-3434-4a055f575df0@linaro.org>
> I am not sure it matters - if I understood your reply, there is no
> valid use case to change the frequency in that mode (and all that
> code should be removed);
All of wext *is* being removed - slowly :)
It's not longer default in the kernel configuration now.
IIRC, there actually was a valid use case here - to set the frequency
before you set the SSID - to be able to force a connection on that
channel with wext.
> it seems to me that it is also your view that userspace (iwconfig)
> should be fixed accordingly to not call the extensions?
iwconfig should just be deleted and iw be used :-)
> I am just trying to understand how the current code is supposed to
> work by exercising widely available user-space tools while debugging
> the kernel.
Heh, ok.
> Actually the frequency gets programmed without errors when reverting
> your commit http://tinyurl.com/ho4urp8 (which comes as a surprise as
> well).
Well, it's not my commit, but that makes sense. I suppose we should
treat this as a regression, but reverting that doesn't seem like the
right fix. Actually, I'm not convinced we should do monitor channel
change anyway when you set the frequency with wext, so we can probably
just remove that call there - want to send a patch to that effect?
johannes
^ permalink raw reply
* [PATCH] tg3: Avoid NULL pointer dereference in tg3_get_nstats()
From: Wang Yufen @ 2017-01-05 14:13 UTC (permalink / raw)
To: siva.kallam, prashant, mchan; +Cc: netdev, Yufen Wang
From: Yufen Wang <wangyufen@huawei.com>
A possible NULL pointer dereference in tg3_get_stats64 while doing
tg3_free_consistent.
The following trace is seen when the error is triggered:
[360729.331080] BUG: unable to handle kernel NULL pointer dereference at 0000000000000130
[360729.339357] IP: [<ffffffffa02855a6>] tg3_get_nstats+0x276/0x370 [tg3]
[360729.346072] PGD 0
[360729.348356] Thread overran stack, or stack corrupted
[360729.353573] Oops: 0000 [#1] SMP
[360729.386221] task: ffff880c22dd5c00 ti: ffff881037cb4000 task.ti: ffff881037cb4000
[360729.386227] RIP: 0010:[<ffffffffa02855a6>] tg3_get_nstats+0x276/0x370 [tg3]
[360729.386228] RSP: 0018:ffff881037cb7c98 EFLAGS: 00010206
[360729.386229] RAX: 0000000000000000 RBX: ffff880c1e32e000 RCX: 0000000000005719
[360729.386230] RDX: 0000000000000000 RSI: ffff881037cb7d90 RDI: ffff880852ea08c0
[360729.386230] RBP: ffff881037cb7cc8 R08: ffffffffa02a4ca0 R09: 0000000000000248
[360729.386231] R10: 0000000000000000 R11: ffff881037cb7bbe R12: ffff880852ea08c0
[360729.386232] R13: ffff881037cb7d90 R14: 0000000000000000 R15: ffff8806b7213e80
[360729.386233] FS: 00007fd00c3da740(0000) GS:ffff88085ff00000(0000) knlGS:0000000000000000
[360729.386234] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[360729.386235] CR2: 0000000000000130 CR3: 0000000109df4000 CR4: 00000000001427e0
[360729.386235] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[360729.386236] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[360729.386236] Stack:
[360729.386238] ffff8806b7213e80 00000000132dc9ae ffff880852ea0000 ffff881037cb7d90
[360729.386240] ffff880852ea08c4 ffff880852ea08c0 ffff881037cb7cf8 ffffffffa02856e1
[360729.386241] ffff881037cb7d90 ffff880852ea0000 ffff880852ea0000 ffff881037cb7f48
[360729.386242] Call Trace:
[360729.386247] [<ffffffffa02856e1>] tg3_get_stats64+0x41/0x80 [tg3]
[360729.386249] [<ffffffff8153292e>] dev_get_stats+0x6e/0x200
[360729.386251] [<ffffffff81551927>] dev_seq_printf_stats+0x37/0x120
[360729.386254] [<ffffffff81551a24>] dev_seq_show+0x14/0x30
[360729.386256] [<ffffffff8120cb48>] seq_read+0x238/0x3a0
[360729.386258] [<ffffffff81254fcd>] proc_reg_read+0x3d/0x80
[360729.386260] [<ffffffff811e8b0c>] vfs_read+0x9c/0x170
[360729.386262] [<ffffffff811e965f>] SyS_read+0x7f/0xe0
[360729.386264] [<ffffffff81652289>] system_call_fastpath+0x16/0x1b
This patch avoids the NULL pointer dereference by using !tg3_flag(tp, INIT_COMPLETE)
instate of !tp->hw_stats.
Signed-off-by: Yufen Wang <wangyufen@huawei.com>
---
drivers/net/ethernet/broadcom/tg3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 185e9e0..012f18d 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -14148,7 +14148,7 @@ static struct rtnl_link_stats64 *tg3_get_stats64(struct net_device *dev,
struct tg3 *tp = netdev_priv(dev);
spin_lock_bh(&tp->lock);
- if (!tp->hw_stats) {
+ if (!tg3_flag(tp, INIT_COMPLETE)) {
*stats = tp->net_stats_prev;
spin_unlock_bh(&tp->lock);
return stats;
--
2.7.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox