* Re: Corrupted SKB
From: Michael Ma @ 2017-04-19 4:46 UTC (permalink / raw)
To: Cong Wang; +Cc: Linux Kernel Network Developers, jin.oyj
In-Reply-To: <CAM_iQpVOi0FH_quusHHpvREdvpqq6=RjVOQvcjAWGbh1X0_5tA@mail.gmail.com>
2017-04-18 16:12 GMT-07:00 Cong Wang <xiyou.wangcong@gmail.com>:
> On Mon, Apr 17, 2017 at 5:39 PM, Michael Ma <make0818@gmail.com> wrote:
>> Hi -
>>
>> We've implemented a "glue" qdisc similar to mqprio which can associate
>> one qdisc to multiple txqs as the root qdisc. Reference count of the
>> child qdiscs have been adjusted properly in this case so that it
>> represents the number of txqs it has been attached to. However when
>> sending packets we saw the skb from dequeue_skb() corrupted with the
>> following call stack:
>>
>> [exception RIP: netif_skb_features+51]
>> RIP: ffffffff815292b3 RSP: ffff8817f6987940 RFLAGS: 00010246
>>
>> #9 [ffff8817f6987968] validate_xmit_skb at ffffffff815294aa
>> #10 [ffff8817f69879a0] validate_xmit_skb at ffffffff8152a0d9
>> #11 [ffff8817f69879b0] __qdisc_run at ffffffff8154a193
>> #12 [ffff8817f6987a00] dev_queue_xmit at ffffffff81529e03
>>
>> It looks like the skb has already been released since its dev pointer
>> field is invalid.
>>
>> Any clue on how this can be investigated further? My current thought
>> is to add some instrumentation to the place where skb is released and
>> analyze whether there is any race condition happening there. However
>
> Either dropwatch or perf could do the work to instrument kfree_skb().
Thanks - will try it out.
>
>> by looking through the existing code I think the case where one root
>> qdisc is associated with multiple txqs already exists (when mqprio is
>> not used) so not sure why it won't work when we group txqs and assign
>> each group a root qdisc. Any insight on this issue would be much
>> appreciated!
>
> How do you implement ->attach()? How does it work with netdev_pick_tx()?
attach() essentially grafts the default qdisc(pfifo) to each "txq
group" represented by a TC class. For netdev_pick_txq() we use classid
of the socket to select a class based on a "class id base" and the
class to txq mapping defined together with this glue qdisc - it's
pretty much the same as mqprio with the difference of mapping one
class to multiple txqs and selecting the txq through a hash.
^ permalink raw reply
* Re: [PATCH net-next 1/2 v2] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch
From: Roopa Prabhu @ 2017-04-19 4:55 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: davem, netdev, eric.dumazet, jiri, xiyou.wangcong
In-Reply-To: <1492564489-28854-1-git-send-email-jhs@emojatatu.com>
On 4/18/17, 6:14 PM, Jamal Hadi Salim wrote:
> From: Jamal Hadi Salim <jhs@mojatatu.com>
>
> When you dump hundreds of thousands of actions, getting only 32 per
> dump batch even when the socket buffer and memory allocations allow
> is inefficient.
>
> With this change, the user will get as many as possibly fitting
> within the given constraints available to the kernel.
>
> A new top level TLV space is introduced. An attribute
> TCAA_ACT_FLAGS is used to carry the flags indicating the user
> is capable of processing these large dumps. Older user space which
> doesnt set this flag doesnt get the large (than 32) batches.
> The kernel uses the TCAA_ACT_COUNT attribute to tell the user how many
> actions are put in a single batch. As such user space app knows how long
> to iterate (independent of the type of action being dumped)
> instead of hardcoded maximum of 32.
Is the count attribute really needed ?. user space knows how to iterate multiple
attributes of the same type till the end of msg. eg. fdb dumps don't use count.
^ permalink raw reply
* Re: FEC on i.MX 7 transmit queue timeout
From: Stefan Agner @ 2017-04-19 5:01 UTC (permalink / raw)
To: Andy Duan; +Cc: fugang.duan, festevam, netdev, netdev-owner
In-Reply-To: <ed24e51d-499f-597b-0c9f-7f180e257acb@nxp.com>
Hi Andy,
On 2017-04-18 19:24, Andy Duan wrote:
> On 2017年04月19日 03:46, Stefan Agner wrote:
>> Hi,
>>
>> I noticed last week on upstream (v4.11-rc6) on a Colibri iMX7 board that
>> after a while (~10 minutes) the detdev wachdog prints a stacktrace and
>> the driver then continuously dumps the TX ring. I then did a quick test
>> with 4.10, and realized it actually suffers the same issue, so it seems
>> not to be a regression. I use a rootfs mounted over NFS...
>>
>> ------------[ cut here ]------------
>> WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:316
>> dev_watchdog+0x240/0x244
>> NETDEV WATCHDOG: eth0 (fec): transmit queue 2 timed out
>> Modules linked in:
>> CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>> 4.11.0-rc7-00030-g2c4e6bd0c4f0-dirty #330
>> Hardware name: Freescale i.MX7 Dual (Device Tree)
>> [<c02293f0>] (unwind_backtrace) from [<c0225820>] (show_stack+0x10/0x14)
>> [<c0225820>] (show_stack) from [<c050db6c>] (dump_stack+0x90/0xa0)
>> [<c050db6c>] (dump_stack) from [<c023ae68>] (__warn+0xac/0x11c)
>> [<c023ae68>] (__warn) from [<c023af10>] (warn_slowpath_fmt+0x38/0x48)
>> [<c023af10>] (warn_slowpath_fmt) from [<c088bb8c>]
>> (dev_watchdog+0x240/0x244)
>> [<c088bb8c>] (dev_watchdog) from [<c0294798>]
>> (run_timer_softirq+0x24c/0x708)
>> [<c0294798>] (run_timer_softirq) from [<c023f584>]
>> (__do_softirq+0x12c/0x2a8)
>> [<c023f584>] (__do_softirq) from [<c023f8c4>] (irq_exit+0xdc/0x13c)
>> [<c023f8c4>] (irq_exit) from [<c02818ac>]
>> (__handle_domain_irq+0xa4/0xf8)
>> [<c02818ac>] (__handle_domain_irq) from [<c0201624>]
>> (gic_handle_irq+0x34/0xa4)
>> [<c0201624>] (gic_handle_irq) from [<c0226338>] (__irq_svc+0x58/0x8c)
>> Exception stack(0xc1201f30 to 0xc1201f78)
>> 1f20: c0233320 00000000 00000000
>> 01400000
>> 1f40: c1203d80 ffffe000 00000000 00000000 c107bf10 c0e055b5 c1203d34
>> 00000001
>> 1f60: c07d2324 c1201f80 c0222ac8 c0222acc 60000013 ffffffff
>> [<c0226338>] (__irq_svc) from [<c0222acc>] (arch_cpu_idle+0x38/0x3c)
>> [<c0222acc>] (arch_cpu_idle) from [<c0275f24>] (do_idle+0xa8/0x250)
>> [<c0275f24>] (do_idle) from [<c02760e4>] (cpu_startup_entry+0x18/0x1c)
>> [<c02760e4>] (cpu_startup_entry) from [<c1000aa0>]
>> (start_kernel+0x3fc/0x45c)
>> ---[ end trace 5b0c6dc3466a7918 ]---
>> fec 30be0000.ethernet eth0: TX ring dump
>> Nr SC addr len SKB
>> 0 0x1c00 0x00000000 590 (null)
>> 1 0x1c00 0x00000000 590 (null)
>> 2 0x1c00 0x00000000 42 (null)
>> 3 H 0x1c00 0x00000000 42 (null)
>> 4 S 0x0000 0x00000000 0 (null)
>> 5 0x0000 0x00000000 0 (null)
>> 6 0x0000 0x00000000 0 (null)
>> 7 0x0000 0x00000000 0 (null)
>> 8 0x0000 0x00000000 0 (null)
>> 9 0x0000 0x00000000 0 (null)
>> 10 0x0000 0x00000000 0 (null)
>> 11 0x0000 0x00000000 0 (null)
>> 12 0x0000 0x00000000 0 (null)
>> 13 0x0000 0x00000000 0 (null)
>> 14 0x0000 0x00000000 0 (null)
>> 15 0x0000 0x00000000 0 (null)
>> 16 0x0000 0x00000000 0 (null)
>> 17 0x0000 0x00000000 0 (null)
>> 18 0x0000 0x00000000 0 (null)
>> ...
>>
>>
>> A second TX ring dump from 4.10:
>> fec 30be0000.ethernet eth0: TX ring dump
>> Nr SC addr len SKB
>> 0 0x1c00 0x00000000 42 (null)
>> 1 0x1c00 0x00000000 42 (null)
>> 2 0x1c00 0x00000000 90 (null)
>> 3 0x1c00 0x00000000 90 (null)
>> 4 0x1c00 0x00000000 90 (null)
>> 5 0x1c00 0x00000000 218 (null)
>> 6 0x1c00 0x00000000 218 (null)
>> 7 0x1c00 0x00000000 218 (null)
>> 8 0x1c00 0x00000000 90 (null)
>> 9 0x1c00 0x00000000 206 (null)
>> 10 0x1c00 0x00000000 216 (null)
>> 11 0x1c00 0x00000000 216 (null)
>> 12 0x1c00 0x00000000 216 (null)
>> 13 0x1c00 0x00000000 311 (null)
>> 14 0x1c00 0x00000000 178 (null)
>> 15 0x1c00 0x00000000 311 (null)
>> 16 0x1c00 0x00000000 206 (null)
>> 17 H 0x1c00 0x00000000 311 (null)
>> 18 S 0x0000 0x00000000 0 (null)
>> 19 0x0000 0x00000000 0 (null)
> The dump show tx ring is fine.
>
>>
>> The ring dump prints continously, but I can access console every now and
>> then. I noticed that the second interrupt seems static (66441, TX
>> interrupt?):
>> 58: 18 GIC-0 150 Level 30be0000.ethernet
>> 59: 66441 GIC-0 151 Level 30be0000.ethernet
>> 60: 70477 GIC-0 152 Level 30be0000.ethernet
> 150 irq number is for tx/rx queue 1 receive/transmit buffer/frame done.
> 151 irq number is for tx/rx queue 2 receive/transmit buffer/frame done.
> 152 irq number is for tx/rx queue 0 receive/transmit buffer/frame done,
> mii interrupt and others.
>
> i.MX7D enet has three queues for tx and rx.
> It seems netdev pick tx queue 1 rate is very rare by __netdev_pick_tx().
Oh ok I see, and it seems to choose queue 2 fairly often...
>> Anybody else seen this? Any idea?
>>
>> In 4.10 as well as 4.11-rc6 the interrupt counts were just over 65536...
>> pure chance?
>>
>>
> you can use ethtool to set the irq coalesce like:
> ethtool -c eth0 rx-frames 80
> ethtool -c eth0 rx-usecs 600
> ethtool -c eth0 tx-frames 64
> ethtool -c eth0 tx-usenc 700
>
>
> You don't run any test case, just nfs mount rootfs ?
> I will setup one imx7d sdb board to run it.
I noticed it without doing anything, just boot via NFS. There was always
a little bit of activity, at least according to the link (blinks every
~5s).
It seemd that it happened a bit earlier when using iperf to exacerbate
the problem...
I noticed that errata 7885 is not mentioned in the i.MX 7 errata, so I
created a new devtype:
}, {
.name = "imx7d-fec",
.driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT |
FEC_QUIRK_HAS_BUFDESC_EX |
FEC_QUIRK_HAS_CSUM |
FEC_QUIRK_HAS_VLAN |
FEC_QUIRK_BUG_CAPTURE |
FEC_QUIRK_HAS_RACC |
FEC_QUIRK_HAS_COALESCE,
}, {
I had that running for about 6h with iperf, it did not seem to happen
despite lots of traffic and interrupts:
58: 12782877 GIC-0 150 Level 30be0000.ethernet
59: 14607039 GIC-0 151 Level 30be0000.ethernet
60: 32356307 GIC-0 152 Level 30be0000.ethernet
But just when I restarted the same stack trace appeared again....
^ permalink raw reply
* [PATCH 2/2] af_key: Fix sadb_x_ipsecrequest parsing
From: Steffen Klassert @ 2017-04-19 5:10 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <1492578636-621-1-git-send-email-steffen.klassert@secunet.com>
From: Herbert Xu <herbert@gondor.apana.org.au>
The parsing of sadb_x_ipsecrequest is broken in a number of ways.
First of all we're not verifying sadb_x_ipsecrequest_len. This
is needed when the structure carries addresses at the end. Worse
we don't even look at the length when we parse those optional
addresses.
The migration code had similar parsing code that's better but
it also has some deficiencies. The length is overcounted first
of all as it includes the header itself. It also fails to check
the length before dereferencing the sa_family field.
This patch fixes those problems in parse_sockaddr_pair and then
uses it in parse_ipsecrequest.
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/key/af_key.c | 47 ++++++++++++++++++++++++++---------------------
1 file changed, 26 insertions(+), 21 deletions(-)
diff --git a/net/key/af_key.c b/net/key/af_key.c
index 1b0ea80..be8cecc 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -66,6 +66,10 @@ struct pfkey_sock {
struct mutex dump_lock;
};
+static int parse_sockaddr_pair(struct sockaddr *sa, int ext_len,
+ xfrm_address_t *saddr, xfrm_address_t *daddr,
+ u16 *family);
+
static inline struct pfkey_sock *pfkey_sk(struct sock *sk)
{
return (struct pfkey_sock *)sk;
@@ -1939,19 +1943,14 @@ parse_ipsecrequest(struct xfrm_policy *xp, struct sadb_x_ipsecrequest *rq)
/* addresses present only in tunnel mode */
if (t->mode == XFRM_MODE_TUNNEL) {
- u8 *sa = (u8 *) (rq + 1);
- int family, socklen;
+ int err;
- family = pfkey_sockaddr_extract((struct sockaddr *)sa,
- &t->saddr);
- if (!family)
- return -EINVAL;
-
- socklen = pfkey_sockaddr_len(family);
- if (pfkey_sockaddr_extract((struct sockaddr *)(sa + socklen),
- &t->id.daddr) != family)
- return -EINVAL;
- t->encap_family = family;
+ err = parse_sockaddr_pair(
+ (struct sockaddr *)(rq + 1),
+ rq->sadb_x_ipsecrequest_len - sizeof(*rq),
+ &t->saddr, &t->id.daddr, &t->encap_family);
+ if (err)
+ return err;
} else
t->encap_family = xp->family;
@@ -1971,7 +1970,11 @@ parse_ipsecrequests(struct xfrm_policy *xp, struct sadb_x_policy *pol)
if (pol->sadb_x_policy_len * 8 < sizeof(struct sadb_x_policy))
return -EINVAL;
- while (len >= sizeof(struct sadb_x_ipsecrequest)) {
+ while (len >= sizeof(*rq)) {
+ if (len < rq->sadb_x_ipsecrequest_len ||
+ rq->sadb_x_ipsecrequest_len < sizeof(*rq))
+ return -EINVAL;
+
if ((err = parse_ipsecrequest(xp, rq)) < 0)
return err;
len -= rq->sadb_x_ipsecrequest_len;
@@ -2434,7 +2437,6 @@ static int key_pol_get_resp(struct sock *sk, struct xfrm_policy *xp, const struc
return err;
}
-#ifdef CONFIG_NET_KEY_MIGRATE
static int pfkey_sockaddr_pair_size(sa_family_t family)
{
return PFKEY_ALIGN8(pfkey_sockaddr_len(family) * 2);
@@ -2446,7 +2448,7 @@ static int parse_sockaddr_pair(struct sockaddr *sa, int ext_len,
{
int af, socklen;
- if (ext_len < pfkey_sockaddr_pair_size(sa->sa_family))
+ if (ext_len < 2 || ext_len < pfkey_sockaddr_pair_size(sa->sa_family))
return -EINVAL;
af = pfkey_sockaddr_extract(sa, saddr);
@@ -2462,6 +2464,7 @@ static int parse_sockaddr_pair(struct sockaddr *sa, int ext_len,
return 0;
}
+#ifdef CONFIG_NET_KEY_MIGRATE
static int ipsecrequests_to_migrate(struct sadb_x_ipsecrequest *rq1, int len,
struct xfrm_migrate *m)
{
@@ -2469,13 +2472,14 @@ static int ipsecrequests_to_migrate(struct sadb_x_ipsecrequest *rq1, int len,
struct sadb_x_ipsecrequest *rq2;
int mode;
- if (len <= sizeof(struct sadb_x_ipsecrequest) ||
- len < rq1->sadb_x_ipsecrequest_len)
+ if (len < sizeof(*rq1) ||
+ len < rq1->sadb_x_ipsecrequest_len ||
+ rq1->sadb_x_ipsecrequest_len < sizeof(*rq1))
return -EINVAL;
/* old endoints */
err = parse_sockaddr_pair((struct sockaddr *)(rq1 + 1),
- rq1->sadb_x_ipsecrequest_len,
+ rq1->sadb_x_ipsecrequest_len - sizeof(*rq1),
&m->old_saddr, &m->old_daddr,
&m->old_family);
if (err)
@@ -2484,13 +2488,14 @@ static int ipsecrequests_to_migrate(struct sadb_x_ipsecrequest *rq1, int len,
rq2 = (struct sadb_x_ipsecrequest *)((u8 *)rq1 + rq1->sadb_x_ipsecrequest_len);
len -= rq1->sadb_x_ipsecrequest_len;
- if (len <= sizeof(struct sadb_x_ipsecrequest) ||
- len < rq2->sadb_x_ipsecrequest_len)
+ if (len <= sizeof(*rq2) ||
+ len < rq2->sadb_x_ipsecrequest_len ||
+ rq2->sadb_x_ipsecrequest_len < sizeof(*rq2))
return -EINVAL;
/* new endpoints */
err = parse_sockaddr_pair((struct sockaddr *)(rq2 + 1),
- rq2->sadb_x_ipsecrequest_len,
+ rq2->sadb_x_ipsecrequest_len - sizeof(*rq2),
&m->new_saddr, &m->new_daddr,
&m->new_family);
if (err)
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] af_key: Add lock to key dump
From: Steffen Klassert @ 2017-04-19 5:10 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <1492578636-621-1-git-send-email-steffen.klassert@secunet.com>
From: Yuejie Shi <syjcnss@gmail.com>
A dump may come in the middle of another dump, modifying its dump
structure members. This race condition will result in NULL pointer
dereference in kernel. So add a lock to prevent that race.
Fixes: 83321d6b9872 ("[AF_KEY]: Dump SA/SP entries non-atomically")
Signed-off-by: Yuejie Shi <syjcnss@gmail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/key/af_key.c | 46 ++++++++++++++++++++++++++++++++++++++--------
1 file changed, 38 insertions(+), 8 deletions(-)
diff --git a/net/key/af_key.c b/net/key/af_key.c
index c6252ed..1b0ea80 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -63,6 +63,7 @@ struct pfkey_sock {
} u;
struct sk_buff *skb;
} dump;
+ struct mutex dump_lock;
};
static inline struct pfkey_sock *pfkey_sk(struct sock *sk)
@@ -139,6 +140,7 @@ static int pfkey_create(struct net *net, struct socket *sock, int protocol,
{
struct netns_pfkey *net_pfkey = net_generic(net, pfkey_net_id);
struct sock *sk;
+ struct pfkey_sock *pfk;
int err;
if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
@@ -153,6 +155,9 @@ static int pfkey_create(struct net *net, struct socket *sock, int protocol,
if (sk == NULL)
goto out;
+ pfk = pfkey_sk(sk);
+ mutex_init(&pfk->dump_lock);
+
sock->ops = &pfkey_ops;
sock_init_data(sock, sk);
@@ -281,13 +286,23 @@ static int pfkey_do_dump(struct pfkey_sock *pfk)
struct sadb_msg *hdr;
int rc;
+ mutex_lock(&pfk->dump_lock);
+ if (!pfk->dump.dump) {
+ rc = 0;
+ goto out;
+ }
+
rc = pfk->dump.dump(pfk);
- if (rc == -ENOBUFS)
- return 0;
+ if (rc == -ENOBUFS) {
+ rc = 0;
+ goto out;
+ }
if (pfk->dump.skb) {
- if (!pfkey_can_dump(&pfk->sk))
- return 0;
+ if (!pfkey_can_dump(&pfk->sk)) {
+ rc = 0;
+ goto out;
+ }
hdr = (struct sadb_msg *) pfk->dump.skb->data;
hdr->sadb_msg_seq = 0;
@@ -298,6 +313,9 @@ static int pfkey_do_dump(struct pfkey_sock *pfk)
}
pfkey_terminate_dump(pfk);
+
+out:
+ mutex_unlock(&pfk->dump_lock);
return rc;
}
@@ -1793,19 +1811,26 @@ static int pfkey_dump(struct sock *sk, struct sk_buff *skb, const struct sadb_ms
struct xfrm_address_filter *filter = NULL;
struct pfkey_sock *pfk = pfkey_sk(sk);
- if (pfk->dump.dump != NULL)
+ mutex_lock(&pfk->dump_lock);
+ if (pfk->dump.dump != NULL) {
+ mutex_unlock(&pfk->dump_lock);
return -EBUSY;
+ }
proto = pfkey_satype2proto(hdr->sadb_msg_satype);
- if (proto == 0)
+ if (proto == 0) {
+ mutex_unlock(&pfk->dump_lock);
return -EINVAL;
+ }
if (ext_hdrs[SADB_X_EXT_FILTER - 1]) {
struct sadb_x_filter *xfilter = ext_hdrs[SADB_X_EXT_FILTER - 1];
filter = kmalloc(sizeof(*filter), GFP_KERNEL);
- if (filter == NULL)
+ if (filter == NULL) {
+ mutex_unlock(&pfk->dump_lock);
return -ENOMEM;
+ }
memcpy(&filter->saddr, &xfilter->sadb_x_filter_saddr,
sizeof(xfrm_address_t));
@@ -1821,6 +1846,7 @@ static int pfkey_dump(struct sock *sk, struct sk_buff *skb, const struct sadb_ms
pfk->dump.dump = pfkey_dump_sa;
pfk->dump.done = pfkey_dump_sa_done;
xfrm_state_walk_init(&pfk->dump.u.state, proto, filter);
+ mutex_unlock(&pfk->dump_lock);
return pfkey_do_dump(pfk);
}
@@ -2679,14 +2705,18 @@ static int pfkey_spddump(struct sock *sk, struct sk_buff *skb, const struct sadb
{
struct pfkey_sock *pfk = pfkey_sk(sk);
- if (pfk->dump.dump != NULL)
+ mutex_lock(&pfk->dump_lock);
+ if (pfk->dump.dump != NULL) {
+ mutex_unlock(&pfk->dump_lock);
return -EBUSY;
+ }
pfk->dump.msg_version = hdr->sadb_msg_version;
pfk->dump.msg_portid = hdr->sadb_msg_pid;
pfk->dump.dump = pfkey_dump_sp;
pfk->dump.done = pfkey_dump_sp_done;
xfrm_policy_walk_init(&pfk->dump.u.policy, XFRM_POLICY_TYPE_MAIN);
+ mutex_unlock(&pfk->dump_lock);
return pfkey_do_dump(pfk);
}
--
2.7.4
^ permalink raw reply related
* netlink: question about netlink testsuite
From: Yasuhara, Hiroyuki @ 2017-04-19 5:00 UTC (permalink / raw)
To: 'netdev@vger.kernel.org'
Hi,
I'm looking for a testset about netlink function,
for example, making a lot of netlink sockets and
communicating with them in the testset.
If anyone know such a testset, please give me the information.
Regards,
Yasuhara
^ permalink raw reply
* pull request (net): ipsec 2017-04-19
From: Steffen Klassert @ 2017-04-19 5:10 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
Two fixes for af_key:
1) Add a lock to key dump to prevent a NULL pointer dereference.
From Yuejie Shi.
2) Fix slab-out-of-bounds in parse_ipsecrequests.
From Herbert Xu.
Please pull or let me know if there are problems.
Thanks!
The following changes since commit 75514b6654859e0130b512396dc964d2a9e84967:
net: ethernet: ti: cpsw: wake tx queues on ndo_tx_timeout (2017-04-02 19:42:44 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec.git master
for you to fetch changes up to 096f41d3a8fcbb8dde7f71379b1ca85fe213eded:
af_key: Fix sadb_x_ipsecrequest parsing (2017-04-18 08:26:03 +0200)
----------------------------------------------------------------
Herbert Xu (1):
af_key: Fix sadb_x_ipsecrequest parsing
Yuejie Shi (1):
af_key: Add lock to key dump
net/key/af_key.c | 93 ++++++++++++++++++++++++++++++++++++++------------------
1 file changed, 64 insertions(+), 29 deletions(-)
^ permalink raw reply
* Re: question about size of sk_buff and skb_shared_info
From: Code Soldier1 @ 2017-04-19 5:20 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1492562843.10587.153.camel@edumazet-glaptop3.roam.corp.google.com>
On Tue, Apr 18, 2017 at 5:47 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> For the last time, do not top post on netdev.
Sorry about that.
>
> On Tue, 2017-04-18 at 17:15 -0700, Code Soldier1 wrote:
>> I am not suggesting that we do not do cache alignment. That is
>> required for performance. I have gone through this exercise because I
>> need to add a field to sk_buff and I want to do that without causing
>> any adverse effects.
>>
>> Now that we have discovered that there are 40 bytes that can be used
>> without any adverse effect, may I increase skb->cb by 8 bytes ?
>>
>
> skb->cb is already 48 bytes, not 40.
That is not what I am referring to above. What I am pointing out is
that since skb is not a multiple of cache line size it accesses the
whole cache line but uses only part of the cache line, leaving 40
bytes unused. I would like to use 8 out of those 40 bytes to extend
the size of skb->cb.
>
>> If not then may I increase skb_shared_info -- However that would have
>> to be by 64bytes.
>
>
> You will have a very hard time to convince us that this 8 byte field is
> needed on all skbs, regardless of current sk_buff size.
>
Protocols use as much space as needed and leave the rest for future
use. Since there is no overhead, I don't understand the concern. Can
you please elaborate.
--
CS1
^ permalink raw reply
* Re: [PATCH][net-next] esp6: fix incorrect null pointer check on xo
From: Steffen Klassert @ 2017-04-19 5:20 UTC (permalink / raw)
To: David Miller; +Cc: colin.king, netdev
In-Reply-To: <20170418.131253.2065320027211688167.davem@davemloft.net>
On Tue, Apr 18, 2017 at 01:12:53PM -0400, David Miller wrote:
> From: Colin King <colin.king@canonical.com>
> Date: Tue, 18 Apr 2017 15:06:53 +0100
>
> Trimming the CC: list down to something that actually makes
> sense.
>
> > From: Colin Ian King <colin.king@canonical.com>
> >
> > The check for xo being null is incorrect, currently it is checking
> > for non-null, it should be checking for null.
> >
> > Detected with CoverityScan, CID#1429349 ("Dereference after null check")
> >
> > Signed-off-by: Colin Ian King <colin.king@canonical.com>
I've added
Fixes: 7862b4058b9f ("esp: Add gso handlers for esp4 and esp6")
and applied it to ipsec-next, thanks!
>
> At a minimum you should work to check that you are CC:'ing the person
> who added the code you are fixing. You can use "git blame" for this.
>
> Also, Steffen, you need to add the new IPSEC offload files to the
> MAINTAINERS entry for iPSEC.
Yes, will do a patch.
^ permalink raw reply
* RE: FEC on i.MX 7 transmit queue timeout
From: Andy Duan @ 2017-04-19 5:28 UTC (permalink / raw)
To: Stefan Agner
Cc: fugang.duan@freescale.com, festevam@gmail.com,
netdev@vger.kernel.org, netdev-owner@vger.kernel.org
In-Reply-To: <e99d7c93b7819507c6448842015bf836@agner.ch>
From: Stefan Agner <stefan@agner.ch> Sent: Wednesday, April 19, 2017 1:02 PM
>To: Andy Duan <fugang.duan@nxp.com>
>Cc: fugang.duan@freescale.com; festevam@gmail.com;
>netdev@vger.kernel.org; netdev-owner@vger.kernel.org
>Subject: Re: FEC on i.MX 7 transmit queue timeout
>
>Hi Andy,
>
>On 2017-04-18 19:24, Andy Duan wrote:
>> On 2017年04月19日 03:46, Stefan Agner wrote:
>>> Hi,
>>>
>>> I noticed last week on upstream (v4.11-rc6) on a Colibri iMX7 board
>>> that after a while (~10 minutes) the detdev wachdog prints a
>>> stacktrace and the driver then continuously dumps the TX ring. I then
>>> did a quick test with 4.10, and realized it actually suffers the same
>>> issue, so it seems not to be a regression. I use a rootfs mounted over NFS...
>>>
>>> ------------[ cut here ]------------
>>> WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:316
>>> dev_watchdog+0x240/0x244
>>> NETDEV WATCHDOG: eth0 (fec): transmit queue 2 timed out Modules
>>> linked in:
>>> CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>>> 4.11.0-rc7-00030-g2c4e6bd0c4f0-dirty #330 Hardware name: Freescale
>>> i.MX7 Dual (Device Tree) [<c02293f0>] (unwind_backtrace) from
>>> [<c0225820>] (show_stack+0x10/0x14) [<c0225820>] (show_stack) from
>>> [<c050db6c>] (dump_stack+0x90/0xa0) [<c050db6c>] (dump_stack) from
>>> [<c023ae68>] (__warn+0xac/0x11c) [<c023ae68>] (__warn) from
>>> [<c023af10>] (warn_slowpath_fmt+0x38/0x48) [<c023af10>]
>>> (warn_slowpath_fmt) from [<c088bb8c>]
>>> (dev_watchdog+0x240/0x244)
>>> [<c088bb8c>] (dev_watchdog) from [<c0294798>]
>>> (run_timer_softirq+0x24c/0x708)
>>> [<c0294798>] (run_timer_softirq) from [<c023f584>]
>>> (__do_softirq+0x12c/0x2a8)
>>> [<c023f584>] (__do_softirq) from [<c023f8c4>] (irq_exit+0xdc/0x13c)
>>> [<c023f8c4>] (irq_exit) from [<c02818ac>]
>>> (__handle_domain_irq+0xa4/0xf8)
>>> [<c02818ac>] (__handle_domain_irq) from [<c0201624>]
>>> (gic_handle_irq+0x34/0xa4)
>>> [<c0201624>] (gic_handle_irq) from [<c0226338>] (__irq_svc+0x58/0x8c)
>>> Exception stack(0xc1201f30 to 0xc1201f78)
>>> 1f20: c0233320 00000000 00000000
>>> 01400000
>>> 1f40: c1203d80 ffffe000 00000000 00000000 c107bf10 c0e055b5 c1203d34
>>> 00000001
>>> 1f60: c07d2324 c1201f80 c0222ac8 c0222acc 60000013 ffffffff
>>> [<c0226338>] (__irq_svc) from [<c0222acc>] (arch_cpu_idle+0x38/0x3c)
>>> [<c0222acc>] (arch_cpu_idle) from [<c0275f24>] (do_idle+0xa8/0x250)
>>> [<c0275f24>] (do_idle) from [<c02760e4>]
>>> (cpu_startup_entry+0x18/0x1c) [<c02760e4>] (cpu_startup_entry) from
>>> [<c1000aa0>]
>>> (start_kernel+0x3fc/0x45c)
>>> ---[ end trace 5b0c6dc3466a7918 ]---
>>> fec 30be0000.ethernet eth0: TX ring dump
>>> Nr SC addr len SKB
>>> 0 0x1c00 0x00000000 590 (null)
>>> 1 0x1c00 0x00000000 590 (null)
>>> 2 0x1c00 0x00000000 42 (null)
>>> 3 H 0x1c00 0x00000000 42 (null)
>>> 4 S 0x0000 0x00000000 0 (null)
>>> 5 0x0000 0x00000000 0 (null)
>>> 6 0x0000 0x00000000 0 (null)
>>> 7 0x0000 0x00000000 0 (null)
>>> 8 0x0000 0x00000000 0 (null)
>>> 9 0x0000 0x00000000 0 (null)
>>> 10 0x0000 0x00000000 0 (null)
>>> 11 0x0000 0x00000000 0 (null)
>>> 12 0x0000 0x00000000 0 (null)
>>> 13 0x0000 0x00000000 0 (null)
>>> 14 0x0000 0x00000000 0 (null)
>>> 15 0x0000 0x00000000 0 (null)
>>> 16 0x0000 0x00000000 0 (null)
>>> 17 0x0000 0x00000000 0 (null)
>>> 18 0x0000 0x00000000 0 (null)
>>> ...
>>>
>>>
>>> A second TX ring dump from 4.10:
>>> fec 30be0000.ethernet eth0: TX ring dump
>>> Nr SC addr len SKB
>>> 0 0x1c00 0x00000000 42 (null)
>>> 1 0x1c00 0x00000000 42 (null)
>>> 2 0x1c00 0x00000000 90 (null)
>>> 3 0x1c00 0x00000000 90 (null)
>>> 4 0x1c00 0x00000000 90 (null)
>>> 5 0x1c00 0x00000000 218 (null)
>>> 6 0x1c00 0x00000000 218 (null)
>>> 7 0x1c00 0x00000000 218 (null)
>>> 8 0x1c00 0x00000000 90 (null)
>>> 9 0x1c00 0x00000000 206 (null)
>>> 10 0x1c00 0x00000000 216 (null)
>>> 11 0x1c00 0x00000000 216 (null)
>>> 12 0x1c00 0x00000000 216 (null)
>>> 13 0x1c00 0x00000000 311 (null)
>>> 14 0x1c00 0x00000000 178 (null)
>>> 15 0x1c00 0x00000000 311 (null)
>>> 16 0x1c00 0x00000000 206 (null)
>>> 17 H 0x1c00 0x00000000 311 (null)
>>> 18 S 0x0000 0x00000000 0 (null)
>>> 19 0x0000 0x00000000 0 (null)
>> The dump show tx ring is fine.
>>
>>>
>>> The ring dump prints continously, but I can access console every now
>>> and then. I noticed that the second interrupt seems static (66441, TX
>>> interrupt?):
>>> 58: 18 GIC-0 150 Level 30be0000.ethernet
>>> 59: 66441 GIC-0 151 Level 30be0000.ethernet
>>> 60: 70477 GIC-0 152 Level 30be0000.ethernet
>> 150 irq number is for tx/rx queue 1 receive/transmit buffer/frame done.
>> 151 irq number is for tx/rx queue 2 receive/transmit buffer/frame done.
>> 152 irq number is for tx/rx queue 0 receive/transmit buffer/frame
>> done, mii interrupt and others.
>>
>> i.MX7D enet has three queues for tx and rx.
>> It seems netdev pick tx queue 1 rate is very rare by __netdev_pick_tx().
>
>Oh ok I see, and it seems to choose queue 2 fairly often...
>
>>> Anybody else seen this? Any idea?
>>>
>>> In 4.10 as well as 4.11-rc6 the interrupt counts were just over 65536...
>>> pure chance?
>>>
>>>
>> you can use ethtool to set the irq coalesce like:
>> ethtool -c eth0 rx-frames 80
>> ethtool -c eth0 rx-usecs 600
>> ethtool -c eth0 tx-frames 64
>> ethtool -c eth0 tx-usenc 700
>>
>>
>> You don't run any test case, just nfs mount rootfs ?
>> I will setup one imx7d sdb board to run it.
>
>I noticed it without doing anything, just boot via NFS. There was always a little
>bit of activity, at least according to the link (blinks every ~5s).
>
>It seemd that it happened a bit earlier when using iperf to exacerbate the
>problem...
>
>I noticed that errata 7885 is not mentioned in the i.MX 7 errata, so I created a
>new devtype:
>
> }, {
> .name = "imx7d-fec",
> .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT |
> FEC_QUIRK_HAS_BUFDESC_EX | FEC_QUIRK_HAS_CSUM |
> FEC_QUIRK_HAS_VLAN | FEC_QUIRK_BUG_CAPTURE |
> FEC_QUIRK_HAS_RACC | FEC_QUIRK_HAS_COALESCE,
> }, {
>
Upstreaming driver doesn't have the platform_device_id for "imx7d-fec", imx7d enet still use imx6sx-fec device id driver.
It lost FEC_QUIRK_ERR007885 and FEC_QUIRK_HAS_AVB quirk flags.
You can add these.
I validate imx7d sdb board with 4.11.0-rc6, no such problem after nfs mount more than 3.5 hours.
>I had that running for about 6h with iperf, it did not seem to happen despite
>lots of traffic and interrupts:
> 58: 12782877 GIC-0 150 Level 30be0000.ethernet
> 59: 14607039 GIC-0 151 Level 30be0000.ethernet
> 60: 32356307 GIC-0 152 Level 30be0000.ethernet
>
>But just when I restarted the same stack trace appeared again....
>
>--
>Stefan
^ permalink raw reply
* Re: export pcie_flr and remove copies of it in drivers V2
From: Leon Romanovsky @ 2017-04-19 5:37 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Christoph Hellwig, Bjorn Helgaas, Giovanni Cabiddu,
Salvatore Benedetto, Mike Marciniszyn, Dennis Dalessandro,
Derek Chickles, Satanand Burla, Felix Manlunas, Raghu Vatsavayi,
Jeff Kirsher, linux-pci, qat-linux, linux-crypto, linux-rdma,
netdev, linux-kernel
In-Reply-To: <20170418183612.GC25295@bhelgaas-glaptop.roam.corp.google.com>
[-- Attachment #1: Type: text/plain, Size: 844 bytes --]
On Tue, Apr 18, 2017 at 01:36:12PM -0500, Bjorn Helgaas wrote:
> On Fri, Apr 14, 2017 at 09:11:24PM +0200, Christoph Hellwig wrote:
> > Hi all,
> >
> > this exports the PCI layer pcie_flr helper, and removes various opencoded
> > copies of it.
> >
> > Changes since V1:
> > - rebase on top of the pci/virtualization branch
> > - fixed the probe case in __pci_dev_reset
> > - added ACKs from Bjorn
>
> Applied the first three patches:
>
> bc13871ef35a PCI: Export pcie_flr()
> e641c375d414 PCI: Call pcie_flr() from reset_intel_82599_sfp_virtfn()
> 40e0901ea4bf PCI: Call pcie_flr() from reset_chelsio_generic_dev()
>
Bjorn,
How do you suggest to proceed with other patches? They should be applied
to your tree either, because they depend on "bc13871ef35a PCI: Export
pcie_flr()".
Thanks
> to pci/virtualization for v4.12, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH ipsec-next] esp4/6: Fix GSO path for non-GSO SW-crypto packets
From: ilant @ 2017-04-19 5:41 UTC (permalink / raw)
To: Steffen Klassert
Cc: netdev, Boris Pismenny, Yevgeny Kliteynik, Yossi Kuperman,
Ilan Tayari
From: Ilan Tayari <ilant@mellanox.com>
If esp*_offload module is loaded, outbound packets take the
GSO code path, being encapsulated at layer 3, but encrypted
in layer 2. validate_xmit_xfrm calls esp*_xmit for that.
esp*_xmit was wrongfully detecting these packets as going
through hardware crypto offload, while in fact they should
be encrypted in software, causing plaintext leakage to
the network, and also dropping at the receiver side.
Perform the encryption in esp*_xmit, if the SA doesn't have
a hardware offload_handle.
Also, align esp6 code to esp4 logic.
Fixes: fca11ebde3f0 ("esp4: Reorganize esp_output")
Fixes: 383d0350f2cc ("esp6: Reorganize esp_output")
Signed-off-by: Ilan Tayari <ilant@mellanox.com>
---
net/ipv4/esp4_offload.c | 4 ++--
net/ipv6/esp6_offload.c | 7 ++++---
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/esp4_offload.c b/net/ipv4/esp4_offload.c
index f3e33c26dc33..e0666016a764 100644
--- a/net/ipv4/esp4_offload.c
+++ b/net/ipv4/esp4_offload.c
@@ -209,8 +209,8 @@ static int esp_xmit(struct xfrm_state *x, struct sk_buff *skb, netdev_features_
if (!xo)
return -EINVAL;
- if (!(features & NETIF_F_HW_ESP) ||
- (x->xso.offload_handle && x->xso.dev != skb->dev)) {
+ if (!(features & NETIF_F_HW_ESP) || !x->xso.offload_handle ||
+ (x->xso.dev != skb->dev)) {
xo->flags |= CRYPTO_FALLBACK;
hw_offload = false;
}
diff --git a/net/ipv6/esp6_offload.c b/net/ipv6/esp6_offload.c
index 95f10728abaa..d950d43ba255 100644
--- a/net/ipv6/esp6_offload.c
+++ b/net/ipv6/esp6_offload.c
@@ -211,9 +211,10 @@ static int esp6_xmit(struct xfrm_state *x, struct sk_buff *skb, netdev_features
if (!xo)
return -EINVAL;
- if (!(features & NETIF_F_HW_ESP) ||
- (x->xso.offload_handle && x->xso.dev != skb->dev)) {
+ if (!(features & NETIF_F_HW_ESP) || !x->xso.offload_handle ||
+ (x->xso.dev != skb->dev)) {
xo->flags |= CRYPTO_FALLBACK;
+ hw_offload = false;
}
esp.proto = xo->proto;
@@ -254,7 +255,7 @@ static int esp6_xmit(struct xfrm_state *x, struct sk_buff *skb, netdev_features
ipv6_hdr(skb)->payload_len = htons(len);
}
- if (x->xso.offload_handle && !(xo->flags & CRYPTO_FALLBACK))
+ if (hw_offload)
return 0;
esp.seqno = cpu_to_be64(xo->seq.low + ((u64)xo->seq.hi << 32));
--
2.11.0
^ permalink raw reply related
* RE: FEC on i.MX 7 transmit queue timeout
From: Stefan Agner @ 2017-04-19 5:56 UTC (permalink / raw)
To: Andy Duan; +Cc: fugang.duan, festevam, netdev, netdev-owner
In-Reply-To: <AM4PR0401MB2260EBCD552219D3402B68FEFF180@AM4PR0401MB2260.eurprd04.prod.outlook.com>
On 2017-04-18 22:28, Andy Duan wrote:
> From: Stefan Agner <stefan@agner.ch> Sent: Wednesday, April 19, 2017 1:02 PM
>>To: Andy Duan <fugang.duan@nxp.com>
>>Cc: fugang.duan@freescale.com; festevam@gmail.com;
>>netdev@vger.kernel.org; netdev-owner@vger.kernel.org
>>Subject: Re: FEC on i.MX 7 transmit queue timeout
>>
>>Hi Andy,
>>
>>On 2017-04-18 19:24, Andy Duan wrote:
>>> On 2017年04月19日 03:46, Stefan Agner wrote:
>>>> Hi,
>>>>
>>>> I noticed last week on upstream (v4.11-rc6) on a Colibri iMX7 board
>>>> that after a while (~10 minutes) the detdev wachdog prints a
>>>> stacktrace and the driver then continuously dumps the TX ring. I then
>>>> did a quick test with 4.10, and realized it actually suffers the same
>>>> issue, so it seems not to be a regression. I use a rootfs mounted over NFS...
>>>>
>>>> ------------[ cut here ]------------
>>>> WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:316
>>>> dev_watchdog+0x240/0x244
>>>> NETDEV WATCHDOG: eth0 (fec): transmit queue 2 timed out Modules
>>>> linked in:
>>>> CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>>>> 4.11.0-rc7-00030-g2c4e6bd0c4f0-dirty #330 Hardware name: Freescale
>>>> i.MX7 Dual (Device Tree) [<c02293f0>] (unwind_backtrace) from
>>>> [<c0225820>] (show_stack+0x10/0x14) [<c0225820>] (show_stack) from
>>>> [<c050db6c>] (dump_stack+0x90/0xa0) [<c050db6c>] (dump_stack) from
>>>> [<c023ae68>] (__warn+0xac/0x11c) [<c023ae68>] (__warn) from
>>>> [<c023af10>] (warn_slowpath_fmt+0x38/0x48) [<c023af10>]
>>>> (warn_slowpath_fmt) from [<c088bb8c>]
>>>> (dev_watchdog+0x240/0x244)
>>>> [<c088bb8c>] (dev_watchdog) from [<c0294798>]
>>>> (run_timer_softirq+0x24c/0x708)
>>>> [<c0294798>] (run_timer_softirq) from [<c023f584>]
>>>> (__do_softirq+0x12c/0x2a8)
>>>> [<c023f584>] (__do_softirq) from [<c023f8c4>] (irq_exit+0xdc/0x13c)
>>>> [<c023f8c4>] (irq_exit) from [<c02818ac>]
>>>> (__handle_domain_irq+0xa4/0xf8)
>>>> [<c02818ac>] (__handle_domain_irq) from [<c0201624>]
>>>> (gic_handle_irq+0x34/0xa4)
>>>> [<c0201624>] (gic_handle_irq) from [<c0226338>] (__irq_svc+0x58/0x8c)
>>>> Exception stack(0xc1201f30 to 0xc1201f78)
>>>> 1f20: c0233320 00000000 00000000
>>>> 01400000
>>>> 1f40: c1203d80 ffffe000 00000000 00000000 c107bf10 c0e055b5 c1203d34
>>>> 00000001
>>>> 1f60: c07d2324 c1201f80 c0222ac8 c0222acc 60000013 ffffffff
>>>> [<c0226338>] (__irq_svc) from [<c0222acc>] (arch_cpu_idle+0x38/0x3c)
>>>> [<c0222acc>] (arch_cpu_idle) from [<c0275f24>] (do_idle+0xa8/0x250)
>>>> [<c0275f24>] (do_idle) from [<c02760e4>]
>>>> (cpu_startup_entry+0x18/0x1c) [<c02760e4>] (cpu_startup_entry) from
>>>> [<c1000aa0>]
>>>> (start_kernel+0x3fc/0x45c)
>>>> ---[ end trace 5b0c6dc3466a7918 ]---
>>>> fec 30be0000.ethernet eth0: TX ring dump
>>>> Nr SC addr len SKB
>>>> 0 0x1c00 0x00000000 590 (null)
>>>> 1 0x1c00 0x00000000 590 (null)
>>>> 2 0x1c00 0x00000000 42 (null)
>>>> 3 H 0x1c00 0x00000000 42 (null)
>>>> 4 S 0x0000 0x00000000 0 (null)
>>>> 5 0x0000 0x00000000 0 (null)
>>>> 6 0x0000 0x00000000 0 (null)
>>>> 7 0x0000 0x00000000 0 (null)
>>>> 8 0x0000 0x00000000 0 (null)
>>>> 9 0x0000 0x00000000 0 (null)
>>>> 10 0x0000 0x00000000 0 (null)
>>>> 11 0x0000 0x00000000 0 (null)
>>>> 12 0x0000 0x00000000 0 (null)
>>>> 13 0x0000 0x00000000 0 (null)
>>>> 14 0x0000 0x00000000 0 (null)
>>>> 15 0x0000 0x00000000 0 (null)
>>>> 16 0x0000 0x00000000 0 (null)
>>>> 17 0x0000 0x00000000 0 (null)
>>>> 18 0x0000 0x00000000 0 (null)
>>>> ...
>>>>
>>>>
>>>> A second TX ring dump from 4.10:
>>>> fec 30be0000.ethernet eth0: TX ring dump
>>>> Nr SC addr len SKB
>>>> 0 0x1c00 0x00000000 42 (null)
>>>> 1 0x1c00 0x00000000 42 (null)
>>>> 2 0x1c00 0x00000000 90 (null)
>>>> 3 0x1c00 0x00000000 90 (null)
>>>> 4 0x1c00 0x00000000 90 (null)
>>>> 5 0x1c00 0x00000000 218 (null)
>>>> 6 0x1c00 0x00000000 218 (null)
>>>> 7 0x1c00 0x00000000 218 (null)
>>>> 8 0x1c00 0x00000000 90 (null)
>>>> 9 0x1c00 0x00000000 206 (null)
>>>> 10 0x1c00 0x00000000 216 (null)
>>>> 11 0x1c00 0x00000000 216 (null)
>>>> 12 0x1c00 0x00000000 216 (null)
>>>> 13 0x1c00 0x00000000 311 (null)
>>>> 14 0x1c00 0x00000000 178 (null)
>>>> 15 0x1c00 0x00000000 311 (null)
>>>> 16 0x1c00 0x00000000 206 (null)
>>>> 17 H 0x1c00 0x00000000 311 (null)
>>>> 18 S 0x0000 0x00000000 0 (null)
>>>> 19 0x0000 0x00000000 0 (null)
>>> The dump show tx ring is fine.
>>>
>>>>
>>>> The ring dump prints continously, but I can access console every now
>>>> and then. I noticed that the second interrupt seems static (66441, TX
>>>> interrupt?):
>>>> 58: 18 GIC-0 150 Level 30be0000.ethernet
>>>> 59: 66441 GIC-0 151 Level 30be0000.ethernet
>>>> 60: 70477 GIC-0 152 Level 30be0000.ethernet
>>> 150 irq number is for tx/rx queue 1 receive/transmit buffer/frame done.
>>> 151 irq number is for tx/rx queue 2 receive/transmit buffer/frame done.
>>> 152 irq number is for tx/rx queue 0 receive/transmit buffer/frame
>>> done, mii interrupt and others.
>>>
>>> i.MX7D enet has three queues for tx and rx.
>>> It seems netdev pick tx queue 1 rate is very rare by __netdev_pick_tx().
>>
>>Oh ok I see, and it seems to choose queue 2 fairly often...
>>
>>>> Anybody else seen this? Any idea?
>>>>
>>>> In 4.10 as well as 4.11-rc6 the interrupt counts were just over 65536...
>>>> pure chance?
>>>>
>>>>
>>> you can use ethtool to set the irq coalesce like:
>>> ethtool -c eth0 rx-frames 80
>>> ethtool -c eth0 rx-usecs 600
>>> ethtool -c eth0 tx-frames 64
>>> ethtool -c eth0 tx-usenc 700
>>>
>>>
>>> You don't run any test case, just nfs mount rootfs ?
>>> I will setup one imx7d sdb board to run it.
>>
>>I noticed it without doing anything, just boot via NFS. There was always a little
>>bit of activity, at least according to the link (blinks every ~5s).
>>
>>It seemd that it happened a bit earlier when using iperf to exacerbate the
>>problem...
>>
>>I noticed that errata 7885 is not mentioned in the i.MX 7 errata, so I created a
>>new devtype:
>>
>> }, {
>> .name = "imx7d-fec",
>> .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT |
>> FEC_QUIRK_HAS_BUFDESC_EX | FEC_QUIRK_HAS_CSUM |
>> FEC_QUIRK_HAS_VLAN | FEC_QUIRK_BUG_CAPTURE |
>> FEC_QUIRK_HAS_RACC | FEC_QUIRK_HAS_COALESCE,
>> }, {
>>
>
> Upstreaming driver doesn't have the platform_device_id for
> "imx7d-fec", imx7d enet still use imx6sx-fec device id driver.
> It lost FEC_QUIRK_ERR007885 and FEC_QUIRK_HAS_AVB quirk flags.
Also downstream uses imx6sx-fec, at least 4.1.15 GA 2.0.0 release:
http://git.freescale.com/git/cgit.cgi/imx/linux-imx.git/tree/arch/arm/boot/dts/imx7d.dtsi?h=imx_4.1.15_2.0.0_ga#n1380
However, with downstream Linux 4.1 the kernel seems to only use queue 0:
292: 0 GPCV2 118 Edge 30be0000.ethernet
293: 0 GPCV2 119 Edge 30be0000.ethernet
294: 204929 GPCV2 120 Edge 30be0000.ethernet
>
> You can add these.
I guess if i.MX 7 does not suffer ERR007885 it would be good to add a
new devtype, correct? This also needs a device tree change, since
imx6sx-fec is still in the compatible list... I saw that you sent a
patch to add ERR007885 for imx6ul as well ("net: fec: add ERR007885 for
i.MX6ul enet IP").
My earlier run which showed the stack trace again actually still had
imx6sx-fec in the device tree compatible string, and hence used
ERR007885! So I need to test again...
> I validate imx7d sdb board with 4.11.0-rc6, no such problem after nfs
> mount more than 3.5 hours.
>
Hm, the Colibri iMX7 uses a different PHY and only supports fast
ethernet. Also, I do tests on a i.MX 7Solo actually, but I can do test
on a i.MX 7Dual tomorrow. But again, with downstream which only uses
queue 0 the issue did never appear.
^ permalink raw reply
* Re: [PATCH net-next 1/2] Add Cong Wang as TC subsystem co-maintainer
From: Cong Wang @ 2017-04-19 6:01 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: David Miller, Linux Kernel Network Developers, Eric Dumazet,
Jiri Pirko
In-Reply-To: <1492565040-29102-1-git-send-email-jhs@emojatatu.com>
On Tue, Apr 18, 2017 at 6:23 PM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> From: Jamal Hadi Salim <jhs@mojatatu.com>
>
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
I am happy and honored to review net sched patches,
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 2/2] Add Jiri Pirko as TC subsystem co-maintainer
From: Jiri Pirko @ 2017-04-19 6:04 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: davem, netdev, eric.dumazet, xiyou.wangcong
In-Reply-To: <1492565040-29102-2-git-send-email-jhs@emojatatu.com>
Wed, Apr 19, 2017 at 03:24:00AM CEST, jhs@mojatatu.com wrote:
>From: Jamal Hadi Salim <jhs@mojatatu.com>
>
>Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
^ permalink raw reply
* Re: netlink: question about netlink testsuite
From: Cong Wang @ 2017-04-19 6:05 UTC (permalink / raw)
To: Yasuhara, Hiroyuki; +Cc: netdev@vger.kernel.org
In-Reply-To: <8B1169046A4CF54A85F712F74A617BA128039167@g01jpexmbkw01>
Hello,
On Tue, Apr 18, 2017 at 10:00 PM, Yasuhara, Hiroyuki
<h.yasuhara@jp.fujitsu.com> wrote:
> Hi,
>
> I'm looking for a testset about netlink function,
> for example, making a lot of netlink sockets and
> communicating with them in the testset.
>
> If anyone know such a testset, please give me the information.
>
libnl3 contains some test cases, which may be what you
are looking for:
https://github.com/thom311/libnl/tree/master/tests
^ permalink raw reply
* Re: [PATCH net-next 1/2 v2] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch
From: Cong Wang @ 2017-04-19 6:12 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Eric Dumazet, David Miller, Linux Kernel Network Developers,
Jiri Pirko
In-Reply-To: <b00c5e30-47e9-0e71-7980-b57740ac09be@mojatatu.com>
On Tue, Apr 18, 2017 at 7:32 PM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> On 17-04-18 09:49 PM, Eric Dumazet wrote:
>>
>> On Tue, 2017-04-18 at 21:14 -0400, Jamal Hadi Salim wrote:
>>>
>>> From: Jamal Hadi Salim <jhs@mojatatu.com>
>>
>>
>> So there is no more limit ? How user is supposed to size the buffer for
>> recvmsg() ?
>>
>
> That part doesnt change. Ok, I believe more clarity is needed:->
>
> Current code allows only 32 actions to be dumped at a time.
> This code:
>
> So lets i have 128 actions. I can fit them into 10K.
> I do recvmsg(..., 32K). This will make about 32K space for me to fill
> up the 128 actions. But the code only allows me to send 32
> TCA_ACT_MAX_PRIO which takes about 2-3K.
> So I will do 4 runs from kernel->user to get 128 actions ;->
> User space in tc is trained to expect no more than
> TCA_ACT_MAX_PRIO in every batch.
>
> With this change I ask the kernel to fit as many actions as
> possible in the 32K (all these 128 will fit in one batch).
> Then it has to tell user space how many are in that batch
> using TCAA_ACT_COUNT attribute.
>
> Make sense?
Hmm? How do tc filters do dumping? There is no max and no
COUNT attribute either, IIUC.
^ permalink raw reply
* Re: [PATCH v2 net 2/2] net sched actions: decrement module refcount earlier
From: Cong Wang @ 2017-04-19 6:23 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Wolfgang Bumiller, Linux Kernel Network Developers,
David S. Miller
In-Reply-To: <b34fa5f5-5368-672a-be06-4c9801b8114e@mojatatu.com>
On Tue, Apr 18, 2017 at 7:21 PM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> Indeed. Allocate the cookie before init? That way, we fail early
> and dont need to worry about restoring anything.
No, a->act_cookie needs an action pointer first. ;)
> In the case of a replace, do you really want to call tcf_hash_release?
>
Good point. Probably no, we already call it inside ->init().
Something like this...
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 82b1d48d91cc..29ffc348fe2f 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -609,14 +609,12 @@ struct tc_action *tcf_action_init_1(struct net
*net, struct nlattr *nla,
if (cklen > TC_COOKIE_MAX_SIZE) {
err = -EINVAL;
- tcf_hash_release(a, bind);
- goto err_mod;
+ goto err_release;
}
if (nla_memdup_cookie(a, tb) < 0) {
err = -ENOMEM;
- tcf_hash_release(a, bind);
- goto err_mod;
+ goto err_release;
}
}
@@ -629,6 +627,9 @@ struct tc_action *tcf_action_init_1(struct net
*net, struct nlattr *nla,
return a;
+err_release:
+ if (err == ACT_P_CREATED)
+ tcf_hash_release(a, bind);
err_mod:
module_put(a_o->owner);
err_out:
^ permalink raw reply related
* [patch net] mlxsw: spectrum_acl_tcam: Get tcam_region_info returned by FW on PTAR
From: Jiri Pirko @ 2017-04-19 7:54 UTC (permalink / raw)
To: netdev; +Cc: davem, idosch, leonro, mlxsw
From: Jiri Pirko <jiri@mellanox.com>
During PTAR register access, FW processes tcam_region_info passed by
driver and also returns modified tcam_region_info back. This needs to be
stored by driver for any future calls.
Fixes: 22a677661f56 ("mlxsw: spectrum: Introduce ACL core with simple TCAM implementation")
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c
index 7382832..2f192f5 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c
@@ -497,10 +497,15 @@ mlxsw_sp_acl_tcam_region_resize(struct mlxsw_sp *mlxsw_sp,
u16 new_size)
{
char ptar_pl[MLXSW_REG_PTAR_LEN];
+ int err;
mlxsw_reg_ptar_pack(ptar_pl, MLXSW_REG_PTAR_OP_RESIZE,
new_size, region->id, region->tcam_region_info);
- return mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(ptar), ptar_pl);
+ err = mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(ptar), ptar_pl);
+ if (err)
+ return err;
+ mlxsw_reg_ptar_unpack(ptar_pl, region->tcam_region_info);
+ return err;
}
static int
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 net 2/2] net sched actions: decrement module refcount earlier
From: Wolfgang Bumiller @ 2017-04-19 8:09 UTC (permalink / raw)
To: Jamal Hadi Salim, Cong Wang
Cc: Linux Kernel Network Developers, David S. Miller
In-Reply-To: <CAM_iQpVucDgy-=ToNrH1a9h1h7goK33hfY_o30e5Rz1Pqwj4_A@mail.gmail.com>
> On April 19, 2017 at 8:23 AM Cong Wang <xiyou.wangcong@gmail.com> wrote:
>
>
> On Tue, Apr 18, 2017 at 7:21 PM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> > Indeed. Allocate the cookie before init? That way, we fail early
> > and dont need to worry about restoring anything.
>
> No, a->act_cookie needs an action pointer first. ;)
>
> > In the case of a replace, do you really want to call tcf_hash_release?
> >
>
> Good point. Probably no, we already call it inside ->init().
Right, doing this (before your change, and after patching tc to allow
sending overlong cookies):
# tc actions add action ok index 500
# tc actions change action ok index 500 cookie 112233445566778899aabb
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
results in the action disappearing (`tc actions ls action gact` is empty)
And doing this in a loop keeps bumping the module refcount:
# lsmod |grep act_gact
act_gact 16384 8023
If I guard the tcf_hash_release() the way you suggested the action
doesn't disappear with the `change` command, and the module refcount
doesn't grow either.
Tested with the adapted version below (since we still need a second
variable due to err changing):
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 8cc883c063f0..c7e5e437b847 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -555,6 +555,7 @@ struct tc_action *tcf_action_init_1(struct net *net, struct nlattr *nla,
struct nlattr *tb[TCA_ACT_MAX + 1];
struct nlattr *kind;
int err;
+ bool created;
if (name == NULL) {
err = nla_parse_nested(tb, TCA_ACT_MAX, nla, NULL);
@@ -603,20 +604,19 @@ struct tc_action *tcf_action_init_1(struct net *net, struct nlattr *nla,
err = a_o->init(net, nla, est, &a, ovr, bind);
if (err < 0)
goto err_mod;
+ created = err == ACT_P_CREATED;
if (name == NULL && tb[TCA_ACT_COOKIE]) {
int cklen = nla_len(tb[TCA_ACT_COOKIE]);
if (cklen > TC_COOKIE_MAX_SIZE) {
err = -EINVAL;
- tcf_hash_release(a, bind);
- goto err_mod;
+ goto err_release;
}
if (nla_memdup_cookie(a, tb) < 0) {
err = -ENOMEM;
- tcf_hash_release(a, bind);
- goto err_mod;
+ goto err_release;
}
}
@@ -624,11 +624,14 @@ struct tc_action *tcf_action_init_1(struct net *net, struct nlattr *nla,
* if it exists and is only bound to in a_o->init() then
* ACT_P_CREATED is not returned (a zero is).
*/
- if (err != ACT_P_CREATED)
+ if (!created)
module_put(a_o->owner);
return a;
+err_release:
+ if (created)
+ tcf_hash_release(a, bind);
err_mod:
module_put(a_o->owner);
err_out:
^ permalink raw reply related
* Re: [PATCH v2] smsc95xx: Use skb_cow_head to deal with cloned skbs
From: James Hughes @ 2017-04-19 8:33 UTC (permalink / raw)
To: Eric Dumazet
Cc: Woojung.Huh, netdev, Steve Glendinning,
Microchip Linux Driver Support
In-Reply-To: <1492555561.10587.147.camel@edumazet-glaptop3.roam.corp.google.com>
On 18 April 2017 at 23:46, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2017-04-18 at 22:09 +0000, Woojung.Huh@microchip.com wrote:
>> > > @@ -2067,13 +2067,9 @@ static struct sk_buff *smsc95xx_tx_fixup(struct
>> > usbnet *dev,
>> > > /* We do not advertise SG, so skbs should be already linearized */
>> > > BUG_ON(skb_shinfo(skb)->nr_frags);
>> > >
>> > > - if (skb_headroom(skb) < overhead) {
>> > > - struct sk_buff *skb2 = skb_copy_expand(skb,
>> > > - overhead, 0, flags);
>> > > - dev_kfree_skb_any(skb);
>> > > - skb = skb2;
>> > > - if (!skb)
>> > > - return NULL;
>> > > + /* Make writable and expand header space by overhead if required
>> > */
>> > > + if (skb_cow_head(skb, overhead)) {
>> >
>> > I believe you still need to
>> > dev_kfree_skb_any(skb);
>> >
>> I think caller of usbnet_start_xmit() takes care of free when return NULL.
>
> I do not think so. Here is the code in usbnet_start_xmit() :
>
> if (info->tx_fixup) {
> skb = info->tx_fixup (dev, skb, GFP_ATOMIC);
>
> if (!skb) { // Note that skb is NULL now
>
> if (info->flags & FLAG_MULTI_PACKET)
> goto not_drop;
> netif_dbg(dev, tx_err, dev->net, "can't tx_fixup skb\n");
> goto drop;
>
>
> If you really think about it (even before double checking the code in
> usbnet_start_xmit()), that would have been a very serious bug.
>
> Calling dev_kfree_skb_any(skb) in this fixup code, then later from
> usbnet_start_xmit() would have been a double free, or use after free.
>
>
So, I still need to return NULL (as per the code this is replacing) to
indicate failure, but need to free the skb prior to return, as per
fragment below.
/* Make writable and expand header space by overhead if required */
if (skb_cow_head(skb, overhead)) {
dev_kfree_skb_any(skb);
return NULL;
}
Once confirmed, I'll do a another patch.
^ permalink raw reply
* [PATCH] MAINTAINERS: update entry for TI's CPSW driver
From: Sekhar Nori @ 2017-04-19 8:38 UTC (permalink / raw)
To: David S . Miller
Cc: Grygorii Strashko, Linux OMAP Mailing List,
Linux netdev Mailing List
Mugunthan V N, who was reviewing TI's CPSW driver patches is
not working for TI anymore and wont be reviewing patches for
that driver.
Drop Mugunthan as the maintiainer for this driver.
Grygorii continues to be a reviewer. Dave Miller applies the
patches directly and adding a maintainer is actually
misleading since get_maintainer.pl script stops suggesting
that Dave Miller be copied.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 860dacbb5be3..c6d89f004e25 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12684,7 +12684,6 @@ F: drivers/clk/ti/
F: include/linux/clk/ti.h
TI ETHERNET SWITCH DRIVER (CPSW)
-M: Mugunthan V N <mugunthanvnm@ti.com>
R: Grygorii Strashko <grygorii.strashko@ti.com>
L: linux-omap@vger.kernel.org
L: netdev@vger.kernel.org
--
2.9.0
^ permalink raw reply related
* Re: FEC on i.MX 7 transmit queue timeout
From: Andy Duan @ 2017-04-19 8:45 UTC (permalink / raw)
To: Stefan Agner
Cc: fugang.duan@freescale.com, festevam@gmail.com,
netdev@vger.kernel.org, netdev-owner@vger.kernel.org
In-Reply-To: <86b63ee28acfff3426c4a0bf72d848c1@agner.ch>
On 2017年04月19日 13:56, Stefan Agner wrote:
> On 2017-04-18 22:28, Andy Duan wrote:
>> From: Stefan Agner <stefan@agner.ch> Sent: Wednesday, April 19, 2017 1:02 PM
>>> To: Andy Duan <fugang.duan@nxp.com>
>>> Cc: fugang.duan@freescale.com; festevam@gmail.com;
>>> netdev@vger.kernel.org; netdev-owner@vger.kernel.org
>>> Subject: Re: FEC on i.MX 7 transmit queue timeout
>>>
>>> Hi Andy,
>>>
>>> On 2017-04-18 19:24, Andy Duan wrote:
>>>> On 2017年04月19日 03:46, Stefan Agner wrote:
>>>>> Hi,
>>>>>
>>>>> I noticed last week on upstream (v4.11-rc6) on a Colibri iMX7 board
>>>>> that after a while (~10 minutes) the detdev wachdog prints a
>>>>> stacktrace and the driver then continuously dumps the TX ring. I then
>>>>> did a quick test with 4.10, and realized it actually suffers the same
>>>>> issue, so it seems not to be a regression. I use a rootfs mounted over NFS...
>>>>>
>>>>> ------------[ cut here ]------------
>>>>> WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:316
>>>>> dev_watchdog+0x240/0x244
>>>>> NETDEV WATCHDOG: eth0 (fec): transmit queue 2 timed out Modules
>>>>> linked in:
>>>>> CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>>>>> 4.11.0-rc7-00030-g2c4e6bd0c4f0-dirty #330 Hardware name: Freescale
>>>>> i.MX7 Dual (Device Tree) [<c02293f0>] (unwind_backtrace) from
>>>>> [<c0225820>] (show_stack+0x10/0x14) [<c0225820>] (show_stack) from
>>>>> [<c050db6c>] (dump_stack+0x90/0xa0) [<c050db6c>] (dump_stack) from
>>>>> [<c023ae68>] (__warn+0xac/0x11c) [<c023ae68>] (__warn) from
>>>>> [<c023af10>] (warn_slowpath_fmt+0x38/0x48) [<c023af10>]
>>>>> (warn_slowpath_fmt) from [<c088bb8c>]
>>>>> (dev_watchdog+0x240/0x244)
>>>>> [<c088bb8c>] (dev_watchdog) from [<c0294798>]
>>>>> (run_timer_softirq+0x24c/0x708)
>>>>> [<c0294798>] (run_timer_softirq) from [<c023f584>]
>>>>> (__do_softirq+0x12c/0x2a8)
>>>>> [<c023f584>] (__do_softirq) from [<c023f8c4>] (irq_exit+0xdc/0x13c)
>>>>> [<c023f8c4>] (irq_exit) from [<c02818ac>]
>>>>> (__handle_domain_irq+0xa4/0xf8)
>>>>> [<c02818ac>] (__handle_domain_irq) from [<c0201624>]
>>>>> (gic_handle_irq+0x34/0xa4)
>>>>> [<c0201624>] (gic_handle_irq) from [<c0226338>] (__irq_svc+0x58/0x8c)
>>>>> Exception stack(0xc1201f30 to 0xc1201f78)
>>>>> 1f20: c0233320 00000000 00000000
>>>>> 01400000
>>>>> 1f40: c1203d80 ffffe000 00000000 00000000 c107bf10 c0e055b5 c1203d34
>>>>> 00000001
>>>>> 1f60: c07d2324 c1201f80 c0222ac8 c0222acc 60000013 ffffffff
>>>>> [<c0226338>] (__irq_svc) from [<c0222acc>] (arch_cpu_idle+0x38/0x3c)
>>>>> [<c0222acc>] (arch_cpu_idle) from [<c0275f24>] (do_idle+0xa8/0x250)
>>>>> [<c0275f24>] (do_idle) from [<c02760e4>]
>>>>> (cpu_startup_entry+0x18/0x1c) [<c02760e4>] (cpu_startup_entry) from
>>>>> [<c1000aa0>]
>>>>> (start_kernel+0x3fc/0x45c)
>>>>> ---[ end trace 5b0c6dc3466a7918 ]---
>>>>> fec 30be0000.ethernet eth0: TX ring dump
>>>>> Nr SC addr len SKB
>>>>> 0 0x1c00 0x00000000 590 (null)
>>>>> 1 0x1c00 0x00000000 590 (null)
>>>>> 2 0x1c00 0x00000000 42 (null)
>>>>> 3 H 0x1c00 0x00000000 42 (null)
>>>>> 4 S 0x0000 0x00000000 0 (null)
>>>>> 5 0x0000 0x00000000 0 (null)
>>>>> 6 0x0000 0x00000000 0 (null)
>>>>> 7 0x0000 0x00000000 0 (null)
>>>>> 8 0x0000 0x00000000 0 (null)
>>>>> 9 0x0000 0x00000000 0 (null)
>>>>> 10 0x0000 0x00000000 0 (null)
>>>>> 11 0x0000 0x00000000 0 (null)
>>>>> 12 0x0000 0x00000000 0 (null)
>>>>> 13 0x0000 0x00000000 0 (null)
>>>>> 14 0x0000 0x00000000 0 (null)
>>>>> 15 0x0000 0x00000000 0 (null)
>>>>> 16 0x0000 0x00000000 0 (null)
>>>>> 17 0x0000 0x00000000 0 (null)
>>>>> 18 0x0000 0x00000000 0 (null)
>>>>> ...
>>>>>
>>>>>
>>>>> A second TX ring dump from 4.10:
>>>>> fec 30be0000.ethernet eth0: TX ring dump
>>>>> Nr SC addr len SKB
>>>>> 0 0x1c00 0x00000000 42 (null)
>>>>> 1 0x1c00 0x00000000 42 (null)
>>>>> 2 0x1c00 0x00000000 90 (null)
>>>>> 3 0x1c00 0x00000000 90 (null)
>>>>> 4 0x1c00 0x00000000 90 (null)
>>>>> 5 0x1c00 0x00000000 218 (null)
>>>>> 6 0x1c00 0x00000000 218 (null)
>>>>> 7 0x1c00 0x00000000 218 (null)
>>>>> 8 0x1c00 0x00000000 90 (null)
>>>>> 9 0x1c00 0x00000000 206 (null)
>>>>> 10 0x1c00 0x00000000 216 (null)
>>>>> 11 0x1c00 0x00000000 216 (null)
>>>>> 12 0x1c00 0x00000000 216 (null)
>>>>> 13 0x1c00 0x00000000 311 (null)
>>>>> 14 0x1c00 0x00000000 178 (null)
>>>>> 15 0x1c00 0x00000000 311 (null)
>>>>> 16 0x1c00 0x00000000 206 (null)
>>>>> 17 H 0x1c00 0x00000000 311 (null)
>>>>> 18 S 0x0000 0x00000000 0 (null)
>>>>> 19 0x0000 0x00000000 0 (null)
>>>> The dump show tx ring is fine.
>>>>
>>>>> The ring dump prints continously, but I can access console every now
>>>>> and then. I noticed that the second interrupt seems static (66441, TX
>>>>> interrupt?):
>>>>> 58: 18 GIC-0 150 Level 30be0000.ethernet
>>>>> 59: 66441 GIC-0 151 Level 30be0000.ethernet
>>>>> 60: 70477 GIC-0 152 Level 30be0000.ethernet
>>>> 150 irq number is for tx/rx queue 1 receive/transmit buffer/frame done.
>>>> 151 irq number is for tx/rx queue 2 receive/transmit buffer/frame done.
>>>> 152 irq number is for tx/rx queue 0 receive/transmit buffer/frame
>>>> done, mii interrupt and others.
>>>>
>>>> i.MX7D enet has three queues for tx and rx.
>>>> It seems netdev pick tx queue 1 rate is very rare by __netdev_pick_tx().
>>> Oh ok I see, and it seems to choose queue 2 fairly often...
>>>
>>>>> Anybody else seen this? Any idea?
>>>>>
>>>>> In 4.10 as well as 4.11-rc6 the interrupt counts were just over 65536...
>>>>> pure chance?
>>>>>
>>>>>
>>>> you can use ethtool to set the irq coalesce like:
>>>> ethtool -c eth0 rx-frames 80
>>>> ethtool -c eth0 rx-usecs 600
>>>> ethtool -c eth0 tx-frames 64
>>>> ethtool -c eth0 tx-usenc 700
>>>>
>>>>
>>>> You don't run any test case, just nfs mount rootfs ?
>>>> I will setup one imx7d sdb board to run it.
>>> I noticed it without doing anything, just boot via NFS. There was always a little
>>> bit of activity, at least according to the link (blinks every ~5s).
>>>
>>> It seemd that it happened a bit earlier when using iperf to exacerbate the
>>> problem...
>>>
>>> I noticed that errata 7885 is not mentioned in the i.MX 7 errata, so I created a
>>> new devtype:
>>>
>>> }, {
>>> .name = "imx7d-fec",
This is added by you, we never added the platform_device_id.
>>> .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT |
>>> FEC_QUIRK_HAS_BUFDESC_EX | FEC_QUIRK_HAS_CSUM |
>>> FEC_QUIRK_HAS_VLAN | FEC_QUIRK_BUG_CAPTURE |
>>> FEC_QUIRK_HAS_RACC | FEC_QUIRK_HAS_COALESCE,
>>> }, {
>>>
>> Upstreaming driver doesn't have the platform_device_id for
>> "imx7d-fec", imx7d enet still use imx6sx-fec device id driver.
>> It lost FEC_QUIRK_ERR007885 and FEC_QUIRK_HAS_AVB quirk flags.
> Also downstream uses imx6sx-fec, at least 4.1.15 GA 2.0.0 release:
> http://git.freescale.com/git/cgit.cgi/imx/linux-imx.git/tree/arch/arm/boot/dts/imx7d.dtsi?h=imx_4.1.15_2.0.0_ga#n1380
>
> However, with downstream Linux 4.1 the kernel seems to only use queue 0:
> 292: 0 GPCV2 118 Edge 30be0000.ethernet
> 293: 0 GPCV2 119 Edge 30be0000.ethernet
> 294: 204929 GPCV2 120 Edge 30be0000.ethernet
>
yes, queue 0 is for best effort, queue 1 and 2 are for audio/video.
>> You can add these.
> I guess if i.MX 7 does not suffer ERR007885 it would be good to add a
> new devtype, correct? This also needs a device tree change, since
> imx6sx-fec is still in the compatible list... I saw that you sent a
> patch to add ERR007885 for imx6ul as well ("net: fec: add ERR007885 for
> i.MX6ul enet IP").
ERR007885 just to add some cycles before set TDAR that don't take side
effort.
I will confirm the hw issue is fixed or not.
> My earlier run which showed the stack trace again actually still had
> imx6sx-fec in the device tree compatible string, and hence used
> ERR007885! So I need to test again...
>
pls use compatible string "imx6sx-fec" and test again.
>> I validate imx7d sdb board with 4.11.0-rc6, no such problem after nfs
>> mount more than 3.5 hours
> Hm, the Colibri iMX7 uses a different PHY and only supports fast
> ethernet. Also, I do tests on a i.MX 7Solo actually, but I can do test
> on a i.MX 7Dual tomorrow. But again, with downstream which only uses
> queue 0 the issue did never appear.
>
> --
no, my imx7d sdb board running upstreaming kernel 4.11.0-rc6 with three
queues.
So far so good (about 6.5 hours).
^ permalink raw reply
* Re: [Intel-wired-lan] NFS over NAT causes e1000e transmit hangs
From: Neftin, Sasha @ 2017-04-19 8:52 UTC (permalink / raw)
To: Florian Fainelli, Eric Dumazet; +Cc: netdev, intel-wired-lan
In-Reply-To: <9fa24846-3a2d-26d3-2963-f5e6ec6808a5@gmail.com>
On 4/18/2017 22:05, Florian Fainelli wrote:
> On 04/18/2017 12:03 PM, Eric Dumazet wrote:
>> On Tue, 2017-04-18 at 11:18 -0700, Florian Fainelli wrote:
>>> Hi,
>>>
>>> I am using NFS over a NAT with two e1000e adapters and with eth1 being
>>> the LAN interface and eth0 the WAN interface. The kernel is Ubuntu's
>>> 16.10 kernel: 4.8.0-46-generic. The device doing NAT over NFS is just
>>> mounting a remote folder and doing normal execution/file accesses. It's
>>> enough to untar a file from this device onto a NFS share to expose the
>>> problem.
>>>
>>> The transmit hangs look like the ones below, doing a rmmod/insmod does
>>> not help eliminated the problem, nor does a power cycle. Stopping the
>>> NFS over NAT definitively does let the adapter recover.
>> Is this NFS over TCP or UDP ?
> This is NFS over TCP mounted with the following:
>
> type nfs
> (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=2049,timeo=70,retrans=3,sec=sys,local_lock=none,addr=X.X.X.X)
>
> Thanks Eric!
Please, try disable TCP segmentation offload: ethtool -K <adapter> tso off.
^ permalink raw reply
* Re: [PATCH v2 net 1/2] net sched actions: fix access to uninitialized data
From: Daniel Borkmann @ 2017-04-19 9:02 UTC (permalink / raw)
To: Wolfgang Bumiller, netdev; +Cc: Jamal Hadi Salim, David S. Miller, Cong Wang
In-Reply-To: <20170418101322.27666-1-w.bumiller@proxmox.com>
Hi Wolfgang,
On 04/18/2017 12:13 PM, Wolfgang Bumiller wrote:
[...]
Since this patch goes to -net tree and is a bug fix, please
also add a proper analysis into the commit log instead of
just an empty commit message.
A Fixes tag to your bug fix would also be appropriate, so
that this helps tracking follow-ups to the original commit
that introduced the code. For this one, should be:
Fixes: 1045ba77a596 ("net sched actions: Add support for user cookies")
> Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
> Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Thanks,
Daniel
^ 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