* Re: [PATCH v13 0/6] flexcan: Add support for powerpc flexcan (freescale p1010)
From: Kumar Gala @ 2011-10-18 5:44 UTC (permalink / raw)
To: Robin Holt
Cc: David S. Miller, Wolfgang Grandegger, Marc Kleine-Budde,
U Bhaskar-B22300, socketcan-core, netdev, PPC list
In-Reply-To: <1313551944-28603-1-git-send-email-holt@sgi.com>
On Aug 16, 2011, at 10:32 PM, Robin Holt wrote:
> David,
>
> The following set of patches have been reviewed by the above parties and
> all comments have been integrated. Although the patches stray from the
> drivers/net/can directory, the diversions are related to changes for
> the flexcan driver.
>
> The patch set is based upon your net-next-2.6 tree's commit 6c37e46.
>
> Could you please queue these up for the next appropriate push to Linus'
> tree?
>
> Thanks,
> Robin Holt
Robin,
Do you remember why we went with just 'fsl,p1010-flexcan' as the device tree compatible? Do we feel the flex can on P1010 isn't the same as on MPC5xxx? or the ARM SoCs?
- k
^ permalink raw reply
* Re: Linux 3.1-rc9
From: Simon Kirby @ 2011-10-18 5:40 UTC (permalink / raw)
To: Linux Kernel Mailing List, netdev
In-Reply-To: <20111012213555.GC24461@hostway.ca>
On Wed, Oct 12, 2011 at 02:35:55PM -0700, Simon Kirby wrote:
> > > patching file kernel/posix-cpu-timers.c
> > > patching file kernel/sched_stats.h
> >
> > yes that would be fine.
>
> This patch (s/raw_//) has been stable on 5 boxes for a day. I'll push to
> another 15 shortly and confirm tomorrow. Meanwhile, we had another ~4
> boxes lock up on 3.1-rc9 _with_ d670ec13 reverted (all CPUs spinning),
> but there weren't enough serial cables to log all of them and we haven't
> been lucky enough to capture anything other than what fits on 80x25.
> I'm hoping it's just the same bug you've already fixed.
Looks to be a different bug. It just happened on a box with serial
console logging, on the same build I was testing the above patch on --
Linus master circa Oct 7th. This seems to be specific to TCP. I'm not
sure what is with all of the doubled backtraces. I've only seen this on
a couple of different boxes so far.
Full log at http://0x.ca/sim/ref/3.1-rc9/3.1-rc9-tcp-lockup.log
First 100 lines:
[516112.140013] BUG: soft lockup - CPU#0 stuck for 22s! [swapper:0]
[516112.144001] Modules linked in: ipmi_devintf ipmi_si ipmi_msghandler xt_recent nf_conntrack_ftp xt_state xt_owner nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 bnx2
[516112.144001] CPU 0
[516112.144001] Modules linked in: ipmi_devintf ipmi_si ipmi_msghandler xt_recent nf_conntrack_ftp xt_state xt_owner nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 bnx2
[516112.144001]
[516112.144001] Pid: 0, comm: swapper Not tainted 3.1.0-rc9-hw+ #48 Dell Inc. PowerEdge 1950/0UR033
[516112.144001] RIP: 0010:[<ffffffff816b6694>] [<ffffffff816b6694>] _raw_spin_lock+0x14/0x20
[516112.144001] RSP: 0018:ffff88022fc03e10 EFLAGS: 00000297
[516112.144001] RAX: 0000000000000100 RBX: ffffffff81022674 RCX: ffffffff81b4df20
[516112.144001] RDX: ffff8801002aebe0 RSI: dead000000200200 RDI: ffff8801002ad188
[516112.144001] RBP: ffff88022fc03e10 R08: 00000000000000f7 R09: 0000000000000000
[516112.144001] R10: 0000000000000000 R11: 0000000000000010 R12: ffff88022fc03d88
[516112.144001] R13: ffffffff816bed1e R14: ffff88022fc03e10 R15: ffffffff81b4df00
[516112.144001] FS: 0000000000000000(0000) GS:ffff88022fc00000(0000) knlGS:0000000000000000
[516112.244020] BUG: soft lockup - CPU#1 stuck for 22s! [kworker/0:0:0]
[516112.244024] Modules linked in: ipmi_devintf ipmi_si ipmi_msghandler xt_recent nf_conntrack_ftp xt_state xt_owner nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 bnx2
[516112.244033] CPU 1
[516112.244035] Modules linked in: ipmi_devintf ipmi_si ipmi_msghandler xt_recent nf_conntrack_ftp xt_state xt_owner nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 bnx2
[516112.244041]
[516112.244044] Pid: 0, comm: kworker/0:0 Not tainted 3.1.0-rc9-hw+ #48 Dell Inc. PowerEdge 1950/0UR033
[516112.244048] RIP: 0010:[<ffffffff816b6694>] [<ffffffff816b6694>] _raw_spin_lock+0x14/0x20
[516112.244057] RSP: 0018:ffff88022fc43e10 EFLAGS: 00000297
[516112.244059] RAX: 0000000000000100 RBX: ffffffff81022674 RCX: ffff880226888020
[516112.244062] RDX: ffff88001ece1aa0 RSI: dead000000200200 RDI: ffff88001ece1f88
[516112.244064] RBP: ffff88022fc43e10 R08: 00000000000000df R09: 0000000000000000
[516112.244066] R10: 0000000000000000 R11: 0000000000000010 R12: ffff88022fc43d88
[516112.244068] R13: ffffffff816bed1e R14: ffff88022fc43e10 R15: ffff880226888000
[516112.244071] FS: 0000000000000000(0000) GS:ffff88022fc40000(0000) knlGS:0000000000000000
[516112.244074] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[516112.244076] CR2: ffffffffff600400 CR3: 0000000126d93000 CR4: 00000000000006e0
[516112.244078] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[516112.244081] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[516112.244083] Process kworker/0:0 (pid: 0, threadinfo ffff880226918000, task ffff880226911640)
[516112.244085] Stack:
[516112.244086] ffff88022fc43e40 ffffffff8162a613 0000000000000000 0000000000000000
[516112.244090] ffff880226888000 ffff88001ece20e0 ffff88022fc43ee0 ffffffff810692dc
[516112.244094] 0000000000000000 ffff880226919fd8 ffff880226919fd8 ffff880226919fd8
[516112.244098] Call Trace:
[516112.244099] <IRQ>
[516112.244105] [<ffffffff8162a613>] tcp_keepalive_timer+0x23/0x260
[516112.244110] [<ffffffff810692dc>] run_timer_softirq+0x1ac/0x310
[516112.244113] [<ffffffff8162a5f0>] ? tcp_init_xmit_timers+0x20/0x20
[516112.244118] [<ffffffff8102e838>] ? lapic_next_event+0x18/0x20
[516112.244121] [<ffffffff81060bf0>] __do_softirq+0xe0/0x1d0
[516112.244125] [<ffffffff816c04ac>] call_softirq+0x1c/0x30
[516112.244129] [<ffffffff81014255>] do_softirq+0x65/0xa0
[516112.244132] [<ffffffff810608fd>] irq_exit+0xad/0xe0
[516112.244135] [<ffffffff8102f569>] smp_apic_timer_interrupt+0x69/0xa0
[516112.244139] [<ffffffff816bed1e>] apic_timer_interrupt+0x6e/0x80
[516112.244140] <EOI>
[516112.244144] [<ffffffff8101a337>] ? mwait_idle+0x117/0x120
[516112.244147] [<ffffffff810120c6>] cpu_idle+0x86/0xe0
[516112.244151] [<ffffffff816ae77c>] start_secondary+0x1a3/0x1e7
[516112.244153] Code: 0f b6 c2 85 c0 c9 0f 95 c0 0f b6 c0 c3 66 2e 0f 1f 84 00 00 00 00 00 55 b8 00 01 00 00 48 89 e5 f0 66 0f c1 07 38 e0 74 06 f3 90 <8a> 07 eb f6 c9 c3 66 0f 1f 44 00 00 55 48 89 e5 9c 58 66 66 90
[516112.244173] Call Trace:
[516112.244174] <IRQ> [<ffffffff8162a613>] tcp_keepalive_timer+0x23/0x260
[516112.244179] [<ffffffff810692dc>] run_timer_softirq+0x1ac/0x310
[516112.244182] [<ffffffff8162a5f0>] ? tcp_init_xmit_timers+0x20/0x20
[516112.244185] [<ffffffff8102e838>] ? lapic_next_event+0x18/0x20
[516112.244188] [<ffffffff81060bf0>] __do_softirq+0xe0/0x1d0
[516112.244191] [<ffffffff816c04ac>] call_softirq+0x1c/0x30
[516112.244194] [<ffffffff81014255>] do_softirq+0x65/0xa0
[516112.244197] [<ffffffff810608fd>] irq_exit+0xad/0xe0
[516112.244199] [<ffffffff8102f569>] smp_apic_timer_interrupt+0x69/0xa0
[516112.244202] [<ffffffff816bed1e>] apic_timer_interrupt+0x6e/0x80
[516112.244204] <EOI> [<ffffffff8101a337>] ? mwait_idle+0x117/0x120
[516112.244209] [<ffffffff810120c6>] cpu_idle+0x86/0xe0
[516112.244212] [<ffffffff816ae77c>] start_secondary+0x1a3/0x1e7
[516112.344023] BUG: soft lockup - CPU#2 stuck for 23s! [php:1486]
[516112.344025] Modules linked in: ipmi_devintf ipmi_si ipmi_msghandler xt_recent nf_conntrack_ftp xt_state xt_owner nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 bnx2
[516112.344033] CPU 2
[516112.344034] Modules linked in: ipmi_devintf ipmi_si ipmi_msghandler xt_recent nf_conntrack_ftp xt_state xt_owner nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 bnx2
[516112.344040]
[516112.344042] Pid: 1486, comm: php Not tainted 3.1.0-rc9-hw+ #48 Dell Inc. PowerEdge 1950/0UR033
[516112.344046] RIP: 0010:[<ffffffff816b6694>] [<ffffffff816b6694>] _raw_spin_lock+0x14/0x20
[516112.344051] RSP: 0000:ffff88022fc83e10 EFLAGS: 00000297
[516112.344053] RAX: 0000000000000100 RBX: ffffffff81022674 RCX: ffff880226920020
[516112.344056] RDX: ffff88022198c660 RSI: dead000000200200 RDI: ffff8800ac758cc8
[516112.344058] RBP: ffff88022fc83e10 R08: 00000000000000ef R09: 0000000000000000
[516112.344060] R10: 000000000000018b R11: 0000000000000010 R12: ffff88022fc83d88
[516112.344062] R13: ffffffff816bed1e R14: ffff88022fc83e10 R15: ffff880226920000
[516112.344065] FS: 00007faafda03720(0000) GS:ffff88022fc80000(0000) knlGS:0000000000000000
[516112.344068] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[516112.344070] CR2: ffffffffff600400 CR3: 00000002223de000 CR4: 00000000000006e0
[516112.344072] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[516112.344075] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[516112.344077] Process php (pid: 1486, threadinfo ffff880039262000, task ffff88003e675900)
[516112.344079] Stack:
[516112.344081] ffff88022fc83e40 ffffffff8162a613 0000000000000000 0000000000000000
[516112.344084] ffff880226920000 ffff8800ac758e20 ffff88022fc83ee0 ffffffff810692dc
[516112.344088] 0000000000000001 ffff880039263fd8 ffff880039263fd8 ffff880039263fd8
[516112.344091] Call Trace:
[516112.344093] <IRQ>
[516112.344099] [<ffffffff8162a613>] tcp_keepalive_timer+0x23/0x260
[516112.344104] [<ffffffff810692dc>] run_timer_softirq+0x1ac/0x310
[516112.344107] [<ffffffff8162a5f0>] ? tcp_init_xmit_timers+0x20/0x20
[516112.344111] [<ffffffff8102e838>] ? lapic_next_event+0x18/0x20
[516112.344115] [<ffffffff81060bf0>] __do_softirq+0xe0/0x1d0
[516112.344119] [<ffffffff816c04ac>] call_softirq+0x1c/0x30
[516112.344123] [<ffffffff81014255>] do_softirq+0x65/0xa0
Simon-
^ permalink raw reply
* [PATCH net-next-2.6] [IPV6] cleanup: remove unused IPV6 stats entries.
From: Kevin Wilson @ 2011-10-18 5:36 UTC (permalink / raw)
To: davem, netdev
[-- Attachment #1: Type: text/plain, Size: 185 bytes --]
Hi,
This cleanup patch removes three unused IPV6 stats entries
from rt6_statistics struct. (ip6_fib.h).
Regards,
wkevils@gmail.com
Signed-off-by: Kevin Wilson <wkevils@gmail.com>
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 1180 bytes --]
diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index 5735a0f..ac6f91b 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -139,11 +139,8 @@ struct fib6_walker_t {
};
struct rt6_statistics {
- __u32 fib_nodes;
__u32 fib_route_nodes;
- __u32 fib_rt_alloc; /* permanent routes */
__u32 fib_rt_entries; /* rt entries in table */
- __u32 fib_rt_cache; /* cache routes */
__u32 fib_discarded_routes;
};
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index fb545ed..7f7a80c 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2672,12 +2672,9 @@ static const struct file_operations ipv6_route_proc_fops = {
static int rt6_stats_seq_show(struct seq_file *seq, void *v)
{
struct net *net = (struct net *)seq->private;
- seq_printf(seq, "%04x %04x %04x %04x %04x %04x %04x\n",
- net->ipv6.rt6_stats->fib_nodes,
+ seq_printf(seq, "%04x %04x %04x %04x\n",
net->ipv6.rt6_stats->fib_route_nodes,
- net->ipv6.rt6_stats->fib_rt_alloc,
net->ipv6.rt6_stats->fib_rt_entries,
- net->ipv6.rt6_stats->fib_rt_cache,
dst_entries_get_slow(&net->ipv6.ip6_dst_ops),
net->ipv6.rt6_stats->fib_discarded_routes);
^ permalink raw reply related
* Re: BUG in skb_pull with e1000e, PPTP, and L2TP
From: Eric Dumazet @ 2011-10-18 3:59 UTC (permalink / raw)
To: Bradley Peterson
Cc: Don, e1000-devel, netdev, Bruce Allan, Jesse Brandeburg,
John Ronciak
In-Reply-To: <1318909879.2571.43.camel@edumazet-laptop>
Le mardi 18 octobre 2011 à 05:51 +0200, Eric Dumazet a écrit :
> Le mardi 18 octobre 2011 à 04:24 +0200, Eric Dumazet a écrit :
>
> > diff --git a/drivers/net/ppp/pptp.c b/drivers/net/ppp/pptp.c
> > index eae542a..d0197e3 100644
> > --- a/drivers/net/ppp/pptp.c
> > +++ b/drivers/net/ppp/pptp.c
> > @@ -305,11 +305,16 @@ static int pptp_rcv_core(struct sock *sk, struct sk_buff *skb)
> > }
> >
> > header = (struct pptp_gre_header *)(skb->data);
> > + headersize = sizeof(*header);
> >
> > /* test if acknowledgement present */
> > if (PPTP_GRE_IS_A(header->ver)) {
> > - __u32 ack = (PPTP_GRE_IS_S(header->flags)) ?
> > - header->ack : header->seq; /* ack in different place if S = 0 */
> > + __u32 ack;
> > +
> > + if (!pskb_may_pull(skb, headersize))
> > + goto drop;
>
> Oh well, this is buggy, I need to set header again, I'll send an updated
> patch
>
[PATCH v2] pptp: pptp_rcv_core() misses pskb_may_pull() call
e1000e uses paged frags, so any layer incorrectly pulling bytes from skb
can trigger a BUG in skb_pull()
[951.142737] [<ffffffff813d2f36>] skb_pull+0x15/0x17
[951.142737] [<ffffffffa0286824>] pptp_rcv_core+0x126/0x19a [pptp]
[951.152725] [<ffffffff813d17c4>] sk_receive_skb+0x69/0x105
[951.163558] [<ffffffffa0286993>] pptp_rcv+0xc8/0xdc [pptp]
[951.165092] [<ffffffffa02800a3>] gre_rcv+0x62/0x75 [gre]
[951.165092] [<ffffffff81410784>] ip_local_deliver_finish+0x150/0x1c1
[951.177599] [<ffffffff81410634>] ? ip_local_deliver_finish+0x0/0x1c1
[951.177599] [<ffffffff81410846>] NF_HOOK.clone.7+0x51/0x58
[951.177599] [<ffffffff81410996>] ip_local_deliver+0x51/0x55
[951.177599] [<ffffffff814105b9>] ip_rcv_finish+0x31a/0x33e
[951.177599] [<ffffffff8141029f>] ? ip_rcv_finish+0x0/0x33e
[951.204898] [<ffffffff81410846>] NF_HOOK.clone.7+0x51/0x58
[951.214651] [<ffffffff81410bb5>] ip_rcv+0x21b/0x246
pptp_rcv_core() is a nice example of a function assuming everything it
needs is available in skb head.
Reported-by: Bradley Peterson <despite@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
drivers/net/ppp/pptp.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ppp/pptp.c b/drivers/net/ppp/pptp.c
index eae542a..29730fd 100644
--- a/drivers/net/ppp/pptp.c
+++ b/drivers/net/ppp/pptp.c
@@ -305,11 +305,18 @@ static int pptp_rcv_core(struct sock *sk, struct sk_buff *skb)
}
header = (struct pptp_gre_header *)(skb->data);
+ headersize = sizeof(*header);
/* test if acknowledgement present */
if (PPTP_GRE_IS_A(header->ver)) {
- __u32 ack = (PPTP_GRE_IS_S(header->flags)) ?
- header->ack : header->seq; /* ack in different place if S = 0 */
+ __u32 ack;
+
+ if (!pskb_may_pull(skb, headersize))
+ goto drop;
+ header = (struct pptp_gre_header *)(skb->data);
+
+ /* ack in different place if S = 0 */
+ ack = PPTP_GRE_IS_S(header->flags) ? header->ack : header->seq;
ack = ntohl(ack);
@@ -318,21 +325,18 @@ static int pptp_rcv_core(struct sock *sk, struct sk_buff *skb)
/* also handle sequence number wrap-around */
if (WRAPPED(ack, opt->ack_recv))
opt->ack_recv = ack;
+ } else {
+ headersize -= sizeof(header->ack);
}
-
/* test if payload present */
if (!PPTP_GRE_IS_S(header->flags))
goto drop;
- headersize = sizeof(*header);
payload_len = ntohs(header->payload_len);
seq = ntohl(header->seq);
- /* no ack present? */
- if (!PPTP_GRE_IS_A(header->ver))
- headersize -= sizeof(header->ack);
/* check for incomplete packet (length smaller than expected) */
- if (skb->len - headersize < payload_len)
+ if (!pskb_may_pull(skb, headersize + payload_len))
goto drop;
payload = skb->data + headersize;
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply related
* Re: BUG in skb_pull with e1000e, PPTP, and L2TP
From: Eric Dumazet @ 2011-10-18 3:51 UTC (permalink / raw)
To: Bradley Peterson
Cc: netdev, Jeff Kirsher, Jesse Brandeburg, Bruce Allan,
Carolyn Wyborny, Don Skidmore, Greg Rose, PJ Waskiewicz,
Alex Duyck, John Ronciak, e1000-devel
In-Reply-To: <1318904666.2571.33.camel@edumazet-laptop>
Le mardi 18 octobre 2011 à 04:24 +0200, Eric Dumazet a écrit :
> diff --git a/drivers/net/ppp/pptp.c b/drivers/net/ppp/pptp.c
> index eae542a..d0197e3 100644
> --- a/drivers/net/ppp/pptp.c
> +++ b/drivers/net/ppp/pptp.c
> @@ -305,11 +305,16 @@ static int pptp_rcv_core(struct sock *sk, struct sk_buff *skb)
> }
>
> header = (struct pptp_gre_header *)(skb->data);
> + headersize = sizeof(*header);
>
> /* test if acknowledgement present */
> if (PPTP_GRE_IS_A(header->ver)) {
> - __u32 ack = (PPTP_GRE_IS_S(header->flags)) ?
> - header->ack : header->seq; /* ack in different place if S = 0 */
> + __u32 ack;
> +
> + if (!pskb_may_pull(skb, headersize))
> + goto drop;
Oh well, this is buggy, I need to set header again, I'll send an updated
patch
header = (struct pptp_gre_header *)(skb->data);
> + ack = (PPTP_GRE_IS_S(header->flags)) ?
> + header->ack : header->seq; /* ack in different place if S = 0 */
>
^ permalink raw reply
* Re: [PATCH] fib_rules: fix unresolved_rules counting
From: Eric Dumazet @ 2011-10-18 3:47 UTC (permalink / raw)
To: Yan, Zheng; +Cc: netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <4E9CD45C.9050608@intel.com>
Le mardi 18 octobre 2011 à 09:20 +0800, Yan, Zheng a écrit :
> we should decrease ops->unresolved_rules when deleting a unresolved rule.
>
> Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
> ---
> diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
> index 3231b46..27071ee 100644
> --- a/net/core/fib_rules.c
> +++ b/net/core/fib_rules.c
> @@ -475,8 +475,11 @@ static int fib_nl_delrule(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg)
>
> list_del_rcu(&rule->list);
>
> - if (rule->action == FR_ACT_GOTO)
> + if (rule->action == FR_ACT_GOTO) {
> ops->nr_goto_rules--;
> + if (rtnl_dereference(rule->ctarget) == NULL)
> + ops->unresolved_rules--;
> + }
>
> /*
> * Check if this rule is a target to any of them. If so,
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: Bug#645589: linux-image-3.0.0-2-amd64: sky2 rx errors on 3.0, 2.6.32 works
From: Ben Hutchings @ 2011-10-18 3:27 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: 645589, Antti Salmela, netdev
In-Reply-To: <20111017074016.6840.77265.reportbug@thor.viidakko.fi>
[-- Attachment #1: Type: text/plain, Size: 1851 bytes --]
On Mon, 2011-10-17 at 10:40 +0300, Antti Salmela wrote:
> Package: linux-2.6
> Version: 3.0.0-5
> Severity: normal
>
>
> sky2 loses packets on 3.0 (-3 and -5) and 3.1-rc7, 2.6.32-38 and
> setting interface to promiscuous works.
>
> [ 60.118244] sky2 0000:02:00.0: eth0: rx error, status 0xb92100 length 185
> [ 62.664370] sky2 0000:02:00.0: eth0: rx error, status 0x602100 length 96
> [ 63.370051] sky2 0000:02:00.0: eth0: rx error, status 0x422100 length 66
> [ 63.714672] sky2 0000:02:00.0: eth0: rx error, status 0x722100 length 114
> [ 64.513458] device eth0 entered promiscuous mode
It looks like this is a bug in accounting of VLAN tags, though I don't
see what difference promiscuous mode should make.
The log messages show that status has the VLAN flag (bit 13) set and the
length field (bits 16:28) equals the length passed into sky2_receive(),
but that function expects the length field to be greater by VLAN_HLEN.
This device is:
[...]
> 02:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller [11ab:4362] (rev 19)
> Subsystem: ASUSTeK Computer Inc. Marvell 88E8053 Gigabit Ethernet controller PCIe (Asus) [1043:8142]
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 16 bytes
> Interrupt: pin A routed to IRQ 43
> Region 0: Memory at cdefc000 (64-bit, non-prefetchable) [size=16K]
> Region 2: I/O ports at c800 [size=256]
> Expansion ROM at cdec0000 [disabled] [size=128K]
> Capabilities: <access denied>
> Kernel driver in use: sky2
[...]
Ben.
--
Ben Hutchings
No political challenge can be met by shopping. - George Monbiot
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [PATCH] pptp: fix skb leak in pptp_xmit()
From: Eric Dumazet @ 2011-10-18 3:01 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Dmitry Kozlov
In case we cant transmit skb, we must free it
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Dmitry Kozlov <xeb@mail.ru>
---
drivers/net/pptp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/pptp.c b/drivers/net/pptp.c
index eae542a..9c0403d 100644
--- a/drivers/net/pptp.c
+++ b/drivers/net/pptp.c
@@ -285,8 +285,10 @@ static int pptp_xmit(struct ppp_channel *chan, struct sk_buff *skb)
ip_send_check(iph);
ip_local_out(skb);
+ return 1;
tx_error:
+ kfree_skb(skb);
return 1;
}
^ permalink raw reply related
* Re: PROBLEM: System call 'sendmsg' of process ospfd (quagga) causes kernel oops
From: Eric Dumazet @ 2011-10-18 2:30 UTC (permalink / raw)
To: Elmar Vonlanthen; +Cc: linux-kernel, netdev, Timo Teräs, Herbert Xu
In-Reply-To: <CA+0Zf5A-8X5MaXC4+BbLKtMb8S8B-Ln_a3JNfz0jR4O-ruefuw@mail.gmail.com>
Le lundi 17 octobre 2011 à 09:16 +0200, Elmar Vonlanthen a écrit :
> 2011/10/14 Eric Dumazet <eric.dumazet@gmail.com>:
> > Please try following patch :
> >
> > [PATCH] ip_gre: dont increase dev->needed_headroom on a live device
> >
> > It seems ip_gre is able to change dev->needed_headroom on the fly.
> >
> > Its is not legal unfortunately and triggers a BUG in raw_sendmsg()
> >
> > skb = sock_alloc_send_skb(sk, ... + LL_ALLOCATED_SPACE(rt->dst.dev)
> >
> > < another cpu change dev->needed_headromm (making it bigger)
> >
> > ...
> > skb_reserve(skb, LL_RESERVED_SPACE(rt->dst.dev));
> >
> > We end with LL_RESERVED_SPACE() being bigger than LL_ALLOCATED_SPACE()
> > -> we crash later because skb head is exhausted.
> >
> > Bug introduced in commit 243aad83 in 2.6.34 (ip_gre: include route
> > header_len in max_headroom calculation)
> >
> > Reported-by: Elmar Vonlanthen <evonlanthen@gmail.com>
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> > CC: Timo Teräs <timo.teras@iki.fi>
> > CC: Herbert Xu <herbert@gondor.apana.org.au>
> > ---
> > diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> > index 8871067..1505dcf 100644
> > --- a/net/ipv4/ip_gre.c
> > +++ b/net/ipv4/ip_gre.c
> > @@ -835,8 +835,6 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
> > if (skb_headroom(skb) < max_headroom || skb_shared(skb)||
> > (skb_cloned(skb) && !skb_clone_writable(skb, 0))) {
> > struct sk_buff *new_skb = skb_realloc_headroom(skb, max_headroom);
> > - if (max_headroom > dev->needed_headroom)
> > - dev->needed_headroom = max_headroom;
> > if (!new_skb) {
> > ip_rt_put(rt);
> > dev->stats.tx_dropped++;
>
> Hello
>
> I tried this patch and I was not able anymore to reproduce the kernel
> oops. So the patch solved the bug.
> Thank you very much!
>
> Would it be possible to add the patch to the long term kernel 2.6.35
> as well? Because this is the one I use at the moment in production.
>
Thanks for testing.
If David/Herbert/Timo agree, then patch should find its way into current
kernel, then to stable trees as well.
Thanks
^ permalink raw reply
* Re: BUG in skb_pull with e1000e, PPTP, and L2TP
From: Eric Dumazet @ 2011-10-18 2:24 UTC (permalink / raw)
To: Bradley Peterson
Cc: netdev, Jeff Kirsher, Jesse Brandeburg, Bruce Allan,
Carolyn Wyborny, Don Skidmore, Greg Rose, PJ Waskiewicz,
Alex Duyck, John Ronciak, e1000-devel
In-Reply-To: <CAJuWrdtOru6KSNTxXhhQNEZUTaX5KvyF7macx4RZYxMzcAo0KQ@mail.gmail.com>
Le lundi 17 octobre 2011 à 17:19 -0500, Bradley Peterson a écrit :
> I have servers running as PPTP and L2TP/IPSec endpoints. They run
> other services, but the VPN endpoints seem to be the problem (the
> problem goes away when VPN is disabled). The servers that are using
> the e1000e driver crash with "kernel BUG at
> include/linux/skbuff.h:1186!" using linux 2.6.38. I saw a similar BUG
> in the same function on 2.6.22, with both e1000e and igb, using 3rd
> party pptp and l2tp modules. I have other servers, running tg3 and
> forcedeth drivers, which don't have this crash.
>
> I can't reproduce the BUG in my development, and it happens randomly
> in production. So, testing is difficult. I'm working on testing with
> 3.0 next.
>
> Here are 3 separate instances of the crash. The traces are different,
> but the BUG is always the same.
>
> Thanks for any pointers or help,
> Bradley Peterson
>
> [32173.294224] ------------[ cut here ]------------
> [32173.298873] kernel BUG at include/linux/skbuff.h:1186!
> [32173.304029] invalid opcode: 0000 [#1] SMP
> [32173.308184] last sysfs file:
> /sys/devices/system/cpu/cpu7/cache/index2/shared_cpu_map
> [32173.316039] CPU 1
> [32173.317891] Modules linked in: authenc esp4 xfrm4_mode_transport
> arc4 ppp_mppe tcp_diag inet_diag xt_NOTRACK iptable_raw pptp gre
> l2tp_ppp pppox ppp_generic slhc l2tp_netlink l
> 2tp_core tun deflate zlib_deflate twofish_generic twofish_x86_64
> twofish_common camellia serpent blowfish cast5 des_generic xcbc rmd160
> sha512_generic sha256_generic crypto_null a
> f_key iptable_nat nf_nat xt_mark iptable_mangle bonding 8021q garp stp
> llc ipv6 sp5100_tco i2c_piix4 i2c_core e1000e amd64_edac_mod serio_raw
> ghes microcode k10temp edac_core hed
> edac_mce_amd raid456 async_raid6_recov async_pq raid6_pq async_xor xor
> async_memcpy async_tx raid1 pata_acpi firewire_ohci ata_generic
> firewire_core crc_itu_t pata_atiixp 3w_9xxx
> [last unloaded: scsi_wait_scan]
> [32173.385465]
> [32173.386965] Pid: 0, comm: kworker/0:0 Not tainted
> 2.6.38.8-32.1.fix.fc14.x86_64 #1 SGI.COM System Product
> Name/KGP(M)E-D16
> [32173.398135] RIP: 0010:[<ffffffff813d2f0d>] [<ffffffff813d2f0d>]
> __skb_pull258] [<ffffffff81410846>] NF_HOOK.clone.7+0x51/0x58
> [32173.588842] [<ffffffff81410bb5>] ip_rcv+0x21b/0x246
> [32173.593816] [<ffffffff813dd584>] __netif_receive_skb+0x426/0x45c
> [32173.599925] [<ffffffff81053443>] ? select_task_rq_fair+0x57a/0x57f
> [32173.606225] [<ffffffff813da220>] ? arch_local_irq_save+0x16/0x1c
> [32173.612337] [<ffffffff813dd495>] __netif_receive_skb+0x337/0x45c
> [32173.618450] [<ffffffff810482c7>] ? check_preempt_curr+0x45/0x70
> [32173.624478] [<ffffffff8104baa0>] ? ttwu_post_activation+0x60/0xf9
> [32173.630669] [<ffffffff813dd641>] process_backlog+0x87/0x15d
> [32173.636351] [<ffffffff8148982f>] ? _raw_spin_unlock_irqrestore+0x17/0x19
> [32173.643165] [<ffffffff813de528>] net_rx_action+0xac/0x1b1
> [32173.648675] [<ffffffff8105efaa>] __do_softirq+0xd2/0x19e
> [32173.654082] [<ffffffff81010fad>] ? paravirt_read_tsc+0x9/0xd
> [32173.659850] [<ffffffff810114d6>] ? sched_clock+0x9/0xd
> [32173.665082] [<ffffffff8100bb5c>] call_softirq+0x1c/0x30
> [32173.670417] [<ffffffff8100d287>] do_softirq+0x46/0x83
> [32173.675565] [<ffffffff8105f132>] irq_exit+0x49/0x8b
> [32173.680547] [<ffffffff81022b66>]
> smp_call_function_single_interrupt+0x25/0x27
> [32173.687786] [<ffffffff8100b7b3>] call_function_single_interrupt+0x13/0x20
> [32173.694662] <EOI>
> [32173.696798] [<ffffffff8102c61d>] ? native_safe_halt+0xb/0xd
> [32173.702508] [<ffffffff81011fac>] ? need_resched+0x23/0x2d
> [32173.708005] [<ffffffff810120fa>] default_idle+0x4e/0x86
> [32173.713345] [<ffffffff8100932a>] cpu_idle+0xaa/0xcc
> [32173.718339] [<ffffffff81482062>] start_secondary+0x20d/0x20f
> [32173.724092] Code: 68 2b b7 d8 00 00 00 03 b7 e0 00 00 00 89 b7 cc
> 00 00 00 c9 c3 55 48 89 e5 66 66 66 66 90 8b 57 68 29 f2 3b 57 6c 89
> 57 68 73 02 <0f> 0b 89 f0 48 03 87 e0 00
> 00 00 48 89 87 e0 00 00 00 c9 c3 55
> [32173.744370] RIP [<ffffffff813d2f0d>] __skb_pull+0x16/0x2a
> [32173.749920] RSP <ffff8800dfa23b80>
> [32173.753820] ---[ end trace 83b8ebd5dde8ff41 ]---
>
>
>
>
>
> [16165.077006] ------------[ cut here ]------------
> [16165.077936] kernel BUG at include/linux/skbuff.h:1186!
> [16165.082856] invalid opcode: 0000 [#1] SMP
> [16165.082856] last sysfs file:
> /sys/devices/virtual/net/ppp29/queues/rx-0/rps_flow_cnt
> [16165.095731] CPU 1
> [16165.095731] Modules linked in: arc4 ppp_mppe tcp_diag inet_diag
> xt_NOTRACK iptable_raw pptp gre l2tp_ppp pppox ppp_generic slhc
> l2tp_netlink l2tp_core tun deflate zlib_deflate
> twofish_generic twofish_x86_64 twofish_common camellia serpent
> blowfish cast5 des_generic xcbc rmd160 sha512_generic sha256_generic
> crypto_null af_key iptable_nat nf_nat xt_mark i
> ptable_mangle bonding 8021q garp stp llc ipv6 sp5100_tco e1000e
> k10temp i2c_piix4 amd64_edac_mod i2c_core edac_core ghes hed
> edac_mce_amd microcode serio_raw raid456 async_raid6_r
> ecov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1
> pata_acpi firewire_ohci ata_generic firewire_core crc_itu_t
> pata_atiixp 3w_9xxx [last unloaded: scsi_wait_scan]
> [16165.163315]
> [16165.163315] Pid: 0, comm: kworker/0:0 Not tainted
> 2.6.38.8-32.1.fix.fc14.x86_64 #1 SGI.COM System Product
> Name/KGP(M)E-D16
> [16165.163315] RIP: 0010:[<ffffffff813d2f0d>] [<ffffffff813d2f0d>]
> __skb_pull+0x16/0x2a
> [16165.163315] RSP: 0018:ffff8800dfa23b80 EFLAGS: 00010287
> [16165.163315] RAX: 0000000000000000 RBX: ffff880141cec000 RCX: 000000000000005c
> [16165.196875] RDX: 000000000000057f RSI: 0000000000000010 RDI: ffff880141cec000
> [16165.203325] RBP: ffff8800dfa23b80 R08: 00000000ff34033f R09: 0000000000000000
> [1616165.384622] [<ffffffff8104a480>] ? update_shares+0xb7/0xf4
> [16165.394969] [<ffffffff813dd641>] process_backlog+0x87/0x15d
> [16165.394969] [<ffffffff81489816>] ? _raw_spin_lock_irq+0x1f/0x21
> [16165.405933] [<ffffffff813de528>] net_rx_action+0xac/0x1b1
> [16165.410153] [<ffffffff8105efaa>] __do_softirq+0xd2/0x19e
> [16165.410153] [<ffffffff81010fad>] ? paravirt_read_tsc+0x9/0xd
> [16165.410153] [<ffffffff810114d6>] ? sched_clock+0x9/0xd
> [16165.410153] [<ffffffff8100bb5c>] call_softirq+0x1c/0x30
> [16165.410153] [<ffffffff8100d287>] do_softirq+0x46/0x83
> [16165.410153] [<ffffffff8105f132>] irq_exit+0x49/0x8b
> [16165.410153] [<ffffffff81022b66>]
> smp_call_function_single_interrupt+0x25/0x27
> [16165.447293] [<ffffffff8100b7b3>] call_function_single_interrupt+0x13/0x20
> [16165.447293] <EOI>
> [16165.459948] [<ffffffff810b8394>] ? rcu_needs_cpu+0x10e/0x1bf
> [16165.465027] [<ffffffff8102c61d>] ? native_safe_halt+0xb/0xd
> [16165.470461] [<ffffffff81011fac>] ? need_resched+0x23/0x2d
> [16165.477519] [<ffffffff810120fa>] default_idle+0x4e/0x86
> [16165.477974] [<ffffffff8100932a>] cpu_idle+0xaa/0xcc
> [16165.477974] [<ffffffff81482062>] start_secondary+0x20d/0x20f
> [16165.477974] Code: 68 2b b7 d8 00 00 00 03 b7 e0 00 00 00 89 b7 cc
> 00 00 00 c9 c3 55 48 89 e5 66 66 66 66 90 8b 57 68 29 f2 3b 57 6c 89
> 57 68 73 02 <0f> 0b 89 f0 48 03 87 e0 00
> 00 00 48 89 87 e0 00 00 00 c9 c3 55
> [16165.477974] RIP [<ffffffff813d2f0d>] __skb_pull+0x16/0x2a
> [16165.477974] RSP <ffff8800dfa23b80>
> [16165.523203] ---[ end trace f793f200ecc5d20f ]---
>
>
>
>
>
> [17950.922006] ------------[ cut here ]------------
> [17950.922941] kernel BUG at include/linux/skbuff.h:1186!
> [17950.928042] invalid opcode: 0000 [#1] SMP
> [17950.928042] last sysfs file:
> /sys/devices/system/cpu/cpu7/cache/index2/shared_cpu_map
> [17950.943036] CPU 7
> [17950.943036] Modules linked in: authenc esp4 xfrm4_mode_transport
> tcp_diag inet_diag xt_NOTRACK iptable_raw arc4 ppp_mppe pptp gre
> l2tp_ppp pppox ppp_generic slhc l2tp_netlink l
> 2tp_core tun deflate zlib_deflate twofish_generic twofish_x86_64
> twofish_common camellia serpent blowfish cast5 des_generic xcbc rmd160
> sha512_generic sha256_generic crypto_null a
> f_key iptable_nat nf_nat xt_mark iptable_mangle bonding 8021q garp stp
> llc ipv6 e1000e sp5100_tco i2c_piix4 k10temp i2c_core amd64_edac_mod
> ghes edac_core hed serio_raw edac_mce_a
> md microcode raid456 async_raid6_recov async_pq raid6_pq async_xor xor
> async_memcpy async_tx raid1 pata_acpi ata_generic firewire_ohci
> firewire_core crc_itu_t pata_atiixp 3w_9xxx
> [last unloaded: scsi_wait_scan]
> [17950.969223]
> [17950.969223] Pid: 0, comm: kworker/0:1 Not tainted
> 2.6.38.8-32.1.fix.fc14.x86_64 #1 SGI.COM System Product
> Name/KGP(M)E-D16
> [17950.969223] RIP: 0010:[<ffffffff813d2f0d>] [<ffffffff813d2f0d>]
> __skb_pull+0x16/0x2a
> [17950.969223] RSP: 0018:ffff8800dfae3b80 EFLAGS: 00010287
> [17950.969223] RAX: 0000000000000000 RBX: ffff88017089f600 RCX: 0000000000000221
> [17951.040852] RDX: 000000000000057f RSI: 0000000000000010 RDI: ffff88017089f600
> [17951.050257] RBP: ffff8800dfae3b80 R08: 0000000000000000 R09: ffff8800dfae39c0
> [17951.050257] R10: ffff88020e362758 R11: ffff880200000001 R12: ffff8800b31eac00
> [17951.050257] R13: ffff88013ba2cc72 R14: ffffffffa0280230 R15: ffff880208362000
> [17951.050257] FS: 00007fb9a3fee7e0(0000) GS:ffff8800dfae0000(0000)
> knlGS:0000000000000000
> [17951.080066] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [17951.087033] CR2: 00007ffb65c2e000 CR3: 000000014ab0a000 CR4: 00000000000006e0
> [17951.087033] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [17951.100032] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [17951.108481] Process kworker/0:1 (pid: 0, threadinfo
> ffff88020f60e000, task ffff88020f611730)
> [17951.117822] Stack:
> [17951.119564] ffff8800dfae3b90 ffffffff813d2f36 ffff8800dfae3bc0
> ffffffffa0286824
> [17951.121222] ffff8800dfae3bf0 ffff8800b31eac00 ffff88017089f600
> 0000000000000000
> [17951.121222] ffff8800dfae3c00 ffffffff813d17c4 0000000000000000
> 0000000000000000
> [17951.121222] Call Trace:
> [17951.142737] <IRQ>
> [17951.142737] [<ffffffff813d2f36>] skb_pull+0x15/0x17
> [17951.142737] [<ffffffffa0286824>] pptp_rcv_core+0x126/0x19a [pptp]
> [17951.152725] [<ffffffff813d17c4>] sk_receive_skb+0x69/0x105
> [17951.163558] [<ffffffffa0286993>] pptp_rcv+0xc8/0xdc [pptp]
> [17951.165092] [<ffffffffa02800a3>] gre_rcv+0x62/0x75 [gre]
> [17951.165092] [<ffffffff81410784>] ip_local_deliver_finish+0x150/0x1c1
> [17951.177599] [<ffffffff81410634>] ? ip_local_deliver_finish+0x0/0x1c1
> [17951.177599] [<ffffffff81410846>] NF_HOOK.clone.7+0x51/0x58
> [17951.177599] [<ffffffff81410996>] ip_local_deliver+0x51/0x55
> [17951.177599] [<ffffffff814105b9>] ip_rcv_finish+0x31a/0x33e
> [17951.177599] [<ffffffff8141029f>] ? ip_rcv_finish+0x0/0x33e
> [17951.204898] [<ffffffff81410846>] NF_HOOK.clone.7+0x51/0x58
> [17951.214651] [<ffffffff81410bb5>] ip_rcv+0x21b/0x246
> [17951.219683] [<ffffffff813dd584>] __netif_receive_skb+0x426/0x45c
> [17951.219683] [<ffffffff813da220>] ? arch_local_irq_save+0x16/0x1c
> [17951.219683] [<ffffffff813dd495>] __netif_receive_skb+0x337/0x45c
> [17951.234702] [<ffffffff81022954>] ?
> native_send_call_func_single_ipi+0x23/0x25
> [17951.245864] [<ffffffff813dd641>] process_backlog+0x87/0x15d
> [17951.247180] [<ffffffff8123f315>] ? timerqueue_add+0x89/0xa8
> [17951.257133] [<ffffffff813de528>] net_rx_action+0xac/0x1b1
> [17951.262265] [<ffffffff8105efaa>] __do_softirq+0xd2/0x19e
> [17951.265220] [<ffffffff81010fad>] ? paravirt_read_tsc+0x9/0xd
> [17951.273703] [<ffffffff810114d6>] ? sched_clock+0x9/0xd
> [17951.274966] [<ffffffff8100bb5c>] call_softirq+0x1c/0x30
> [17951.274966] [<ffffffff8100d287>] do_softirq+0x46/0x83
> [17951.274966] [<ffffffff8105f132>] irq_exit+0x49/0x8b
> [17951.274966] [<ffffffff81022b66>]
> smp_call_function_single_interrupt+0x25/0x27
> [17951.274966] [<ffffffff8100b7b3>] call_function_single_interrupt+0x13/0x20
> [17951.274966] <EOI>
> [17951.274966] [<ffffffff8102c61d>] ? native_safe_halt+0xb/0xd
> [17951.274966] [<ffffffff81011fac>] ? need_resched+0x23/0x2d
> [17951.320741] [<ffffffff810120fa>] default_idle+0x4e/0x86
> [17951.320741] [<ffffffff8100932a>] cpu_idle+0xaa/0xcc
> [17951.320741] [<ffffffff81482062>] start_secondary+0x20d/0x20f
> [17951.320741] Code: 68 2b b7 d8 00 00 00 03 b7 e0 00 00 00 89 b7 cc
> 00 00 00 c9 c3 55 48 89 e5 66 66 66 66 90 8b 57 68 29 f2 3b 57 6c 89
> 57 68 73 02 <0f> 0b 89 f0 48 03 87 e0 00
> 00 00 48 89 87 e0 00 00 00 c9 c3 55
> [17951.352436] RIP [<ffffffff813d2f0d>] __skb_pull+0x16/0x2a
> [17951.352436] RSP <ffff8800dfae3b80>
> [17951.367951] ---[ end trace af7b2da986dde7ca ]---
> --
Could you please try following patch ?
[PATCH] pptp: pptp_rcv_core() misses pskb_may_pull() call
e1000e uses paged frags, so any layer incorrectly pulling bytes from skb
can trigger a BUG in skb_pull()
[951.142737] [<ffffffff813d2f36>] skb_pull+0x15/0x17
[951.142737] [<ffffffffa0286824>] pptp_rcv_core+0x126/0x19a [pptp]
[951.152725] [<ffffffff813d17c4>] sk_receive_skb+0x69/0x105
[951.163558] [<ffffffffa0286993>] pptp_rcv+0xc8/0xdc [pptp]
[951.165092] [<ffffffffa02800a3>] gre_rcv+0x62/0x75 [gre]
[951.165092] [<ffffffff81410784>] ip_local_deliver_finish+0x150/0x1c1
[951.177599] [<ffffffff81410634>] ? ip_local_deliver_finish+0x0/0x1c1
[951.177599] [<ffffffff81410846>] NF_HOOK.clone.7+0x51/0x58
[951.177599] [<ffffffff81410996>] ip_local_deliver+0x51/0x55
[951.177599] [<ffffffff814105b9>] ip_rcv_finish+0x31a/0x33e
[951.177599] [<ffffffff8141029f>] ? ip_rcv_finish+0x0/0x33e
[951.204898] [<ffffffff81410846>] NF_HOOK.clone.7+0x51/0x58
[951.214651] [<ffffffff81410bb5>] ip_rcv+0x21b/0x246
pptp_rcv_core() is a nice example of a function assuming everything it
needs is available in skb head.
Reported-by: Bradley Peterson <despite@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
drivers/net/ppp/pptp.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ppp/pptp.c b/drivers/net/ppp/pptp.c
index eae542a..d0197e3 100644
--- a/drivers/net/ppp/pptp.c
+++ b/drivers/net/ppp/pptp.c
@@ -305,11 +305,16 @@ static int pptp_rcv_core(struct sock *sk, struct sk_buff *skb)
}
header = (struct pptp_gre_header *)(skb->data);
+ headersize = sizeof(*header);
/* test if acknowledgement present */
if (PPTP_GRE_IS_A(header->ver)) {
- __u32 ack = (PPTP_GRE_IS_S(header->flags)) ?
- header->ack : header->seq; /* ack in different place if S = 0 */
+ __u32 ack;
+
+ if (!pskb_may_pull(skb, headersize))
+ goto drop;
+ ack = (PPTP_GRE_IS_S(header->flags)) ?
+ header->ack : header->seq; /* ack in different place if S = 0 */
ack = ntohl(ack);
@@ -318,21 +323,18 @@ static int pptp_rcv_core(struct sock *sk, struct sk_buff *skb)
/* also handle sequence number wrap-around */
if (WRAPPED(ack, opt->ack_recv))
opt->ack_recv = ack;
+ } else {
+ headersize -= sizeof(header->ack);
}
-
/* test if payload present */
if (!PPTP_GRE_IS_S(header->flags))
goto drop;
- headersize = sizeof(*header);
payload_len = ntohs(header->payload_len);
seq = ntohl(header->seq);
- /* no ack present? */
- if (!PPTP_GRE_IS_A(header->ver))
- headersize -= sizeof(header->ack);
/* check for incomplete packet (length smaller than expected) */
- if (skb->len - headersize < payload_len)
+ if (!pskb_may_pull(skb, headersize + payload_len))
goto drop;
payload = skb->data + headersize;
^ permalink raw reply related
* Re: [PATCH 3/7] mlx4_en: Incoming traffic alignment optimizations
From: Eric Dumazet @ 2011-10-18 1:53 UTC (permalink / raw)
To: Yevgeny Petrilin; +Cc: davem, netdev
In-Reply-To: <4E9C8D53.5040006@mellanox.co.il>
Le lundi 17 octobre 2011 à 22:17 +0200, Yevgeny Petrilin a écrit :
> Packet headers are copied to skb linear part (which is IP aligned), so there is no reason for
> the scatter entry to be IP aligned.
>
> Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
> ---
> @@ -91,7 +91,7 @@
> /* Receive fragment sizes; we use at most 4 fragments (for 9600 byte MTU
> * and 4K allocations) */
> enum {
> - FRAG_SZ0 = 512 - NET_IP_ALIGN,
> + FRAG_SZ0 = 2048,
> FRAG_SZ1 = 1024,
> FRAG_SZ2 = 4096,
> FRAG_SZ3 = MLX4_EN_ALLOC_SIZE
Is the 512 -> 2048 change really wanted ? Its not mentioned in changelog
and is confusing.
This means mlx4 lost the ability to use a small frag (512 bytes) to
store small frames.
^ permalink raw reply
* Re: [PATCH 6/7] mlx4_en: Adding rxhash support
From: Eric Dumazet @ 2011-10-18 1:48 UTC (permalink / raw)
To: Yevgeny Petrilin; +Cc: davem, netdev
In-Reply-To: <4E9C8D8B.90606@mellanox.co.il>
Le lundi 17 octobre 2011 à 22:18 +0200, Yevgeny Petrilin a écrit :
> Moving to Toeplitz function in RSS calculation.
> Reporting rxhash in skb.
>
> Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
> rss_context->flags = rss_mask;
> + rss_context->hash_fn = 1;
> + for (i = 0; i < 10; i++)
> + rss_context->rss_key[i] = random32();
>
Thats bit of a problem : Two NICS will have different seeds, and thus
provide different rxhash for a given flow. A bonding of two NICS will
not be able to provide a consistent rxhash.
drivers/net/ethernet/intel/igb/igb_main.c uses a static table to avoid
this problem.
^ permalink raw reply
* [PATCH] fib_rules: fix unresolved_rules counting
From: Yan, Zheng @ 2011-10-18 1:20 UTC (permalink / raw)
To: netdev@vger.kernel.org, davem@davemloft.net
we should decrease ops->unresolved_rules when deleting a unresolved rule.
Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
---
diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
index 3231b46..27071ee 100644
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@ -475,8 +475,11 @@ static int fib_nl_delrule(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg)
list_del_rcu(&rule->list);
- if (rule->action == FR_ACT_GOTO)
+ if (rule->action == FR_ACT_GOTO) {
ops->nr_goto_rules--;
+ if (rtnl_dereference(rule->ctarget) == NULL)
+ ops->unresolved_rules--;
+ }
/*
* Check if this rule is a target to any of them. If so,
^ permalink raw reply related
* Re: [net-next 0/6 v3][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2011-10-18 0:22 UTC (permalink / raw)
To: jeffrey.t.kirsher, tarbal; +Cc: netdev, gospo, sassmann
In-Reply-To: <4E9CC52C.6030902@gmail.com>
From: Jeff Kirsher <tarbal@gmail.com>
Date: Mon, 17 Oct 2011 17:15:40 -0700
> On 10/17/2011 05:12 PM, Jeff Kirsher wrote:
>> The following series contains updates to ixgbe, igbvf and igb.
>> This version of the series contains the following changes:
>>
>> - igb fix/add check if subordinate VFs are assigned to VM's
>> - igbvf fix for trunk VLAN
>> - ixgbe 2 fixes for ethtool and 1 endianess fix
>>
>> -v2 update the igb patch to resolve a variable initialization warning
>> -v3 Drop patch 5 (ixgbe: add hardware time stamping support)
>>
>> The following are changes since commit fd38f734cb8200529e281338514945fcbff2364b:
>> igbvf: convert to ndo_fix_features
>> and are available in the git repository at
>> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git
>>
>> Emil Tantilov (3):
>> ixgbe: fix endianess when writing driver version to firmware
>> ixgbe: allow eeprom writes via ethtool
>> ixgbe: change the eeprom version reported by ethtool
>>
>> Greg Rose (2):
>> igbvf: Fix trunk vlan
>> igb: Check if subordinate VFs are assigned to virtual machines
>>
>> drivers/net/ethernet/intel/igb/igb.h | 3 +
>> drivers/net/ethernet/intel/igb/igb_main.c | 177 ++++++++++++++++++----
>> drivers/net/ethernet/intel/igbvf/netdev.c | 4 +-
>> drivers/net/ethernet/intel/ixgbe/ixgbe.h | 3 +-
>> drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c | 2 +
>> drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 16 +-
>> drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 84 ++++++++++-
>> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 7 +-
>> 8 files changed, 246 insertions(+), 50 deletions(-)
>>
> Grrr, forgot to update the title of the cover page. It *should* be
> "net-next 0/5 v3]..."
No worries, pulled, thanks Jeff!
^ permalink raw reply
* Re: [net-next 0/6 v3][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2011-10-18 0:15 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, gospo, sassmann
In-Reply-To: <1318896767-5374-1-git-send-email-jeffrey.t.kirsher@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1702 bytes --]
On 10/17/2011 05:12 PM, Jeff Kirsher wrote:
> The following series contains updates to ixgbe, igbvf and igb.
> This version of the series contains the following changes:
>
> - igb fix/add check if subordinate VFs are assigned to VM's
> - igbvf fix for trunk VLAN
> - ixgbe 2 fixes for ethtool and 1 endianess fix
>
> -v2 update the igb patch to resolve a variable initialization warning
> -v3 Drop patch 5 (ixgbe: add hardware time stamping support)
>
> The following are changes since commit fd38f734cb8200529e281338514945fcbff2364b:
> igbvf: convert to ndo_fix_features
> and are available in the git repository at
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git
>
> Emil Tantilov (3):
> ixgbe: fix endianess when writing driver version to firmware
> ixgbe: allow eeprom writes via ethtool
> ixgbe: change the eeprom version reported by ethtool
>
> Greg Rose (2):
> igbvf: Fix trunk vlan
> igb: Check if subordinate VFs are assigned to virtual machines
>
> drivers/net/ethernet/intel/igb/igb.h | 3 +
> drivers/net/ethernet/intel/igb/igb_main.c | 177 ++++++++++++++++++----
> drivers/net/ethernet/intel/igbvf/netdev.c | 4 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe.h | 3 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c | 2 +
> drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 16 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 84 ++++++++++-
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 7 +-
> 8 files changed, 246 insertions(+), 50 deletions(-)
>
Grrr, forgot to update the title of the cover page. It *should* be
"net-next 0/5 v3]..."
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]
^ permalink raw reply
* [net-next 5/5] ixgbe: change the eeprom version reported by ethtool
From: Jeff Kirsher @ 2011-10-18 0:12 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1318896767-5374-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
Use 32bit value starting at offset 0x2d for displaying the firmware
version in ethtool. This should work for all current ixgbe HW
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 3 ++-
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 13 +++++++------
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 7 ++++---
3 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index 6c4d693..a8368d5 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -497,7 +497,8 @@ struct ixgbe_adapter {
u64 rsc_total_count;
u64 rsc_total_flush;
u32 wol;
- u16 eeprom_version;
+ u16 eeprom_verh;
+ u16 eeprom_verl;
u16 eeprom_cap;
int node;
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index 7acfce3..70d58c3 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -889,21 +889,22 @@ static void ixgbe_get_drvinfo(struct net_device *netdev,
{
struct ixgbe_adapter *adapter = netdev_priv(netdev);
char firmware_version[32];
+ u32 nvm_track_id;
strncpy(drvinfo->driver, ixgbe_driver_name,
sizeof(drvinfo->driver) - 1);
strncpy(drvinfo->version, ixgbe_driver_version,
sizeof(drvinfo->version) - 1);
- snprintf(firmware_version, sizeof(firmware_version), "%d.%d-%d",
- (adapter->eeprom_version & 0xF000) >> 12,
- (adapter->eeprom_version & 0x0FF0) >> 4,
- adapter->eeprom_version & 0x000F);
+ nvm_track_id = (adapter->eeprom_verh << 16) |
+ adapter->eeprom_verl;
+ snprintf(firmware_version, sizeof(firmware_version), "0x%08x",
+ nvm_track_id);
strncpy(drvinfo->fw_version, firmware_version,
- sizeof(drvinfo->fw_version));
+ sizeof(drvinfo->fw_version) - 1);
strncpy(drvinfo->bus_info, pci_name(adapter->pdev),
- sizeof(drvinfo->bus_info));
+ sizeof(drvinfo->bus_info) - 1);
drvinfo->n_stats = IXGBE_STATS_LEN;
drvinfo->testinfo_len = IXGBE_TEST_LEN;
drvinfo->regdump_len = ixgbe_get_regs_len(netdev);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index fb7d884..8075d11 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7640,6 +7640,10 @@ static int __devinit ixgbe_probe(struct pci_dev *pdev,
}
device_set_wakeup_enable(&adapter->pdev->dev, adapter->wol);
+ /* save off EEPROM version number */
+ hw->eeprom.ops.read(hw, 0x2e, &adapter->eeprom_verh);
+ hw->eeprom.ops.read(hw, 0x2d, &adapter->eeprom_verl);
+
/* pick up the PCI bus settings for reporting later */
hw->mac.ops.get_bus_info(hw);
@@ -7672,9 +7676,6 @@ static int __devinit ixgbe_probe(struct pci_dev *pdev,
"is required.\n");
}
- /* save off EEPROM version number */
- hw->eeprom.ops.read(hw, 0x29, &adapter->eeprom_version);
-
/* reset the hardware with the new settings */
err = hw->mac.ops.start_hw(hw);
--
1.7.6.4
^ permalink raw reply related
* [net-next 3/5] ixgbe: fix endianess when writing driver version to firmware
From: Jeff Kirsher @ 2011-10-18 0:12 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1318896767-5374-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
This patch makes sure that register writes are in little endian and
also converts the reads back to big-endian.
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
index 35fa444..834f044 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
@@ -3341,7 +3341,7 @@ static u8 ixgbe_calculate_checksum(u8 *buffer, u32 length)
* Communicates with the manageability block. On success return 0
* else return IXGBE_ERR_HOST_INTERFACE_COMMAND.
**/
-static s32 ixgbe_host_interface_command(struct ixgbe_hw *hw, u8 *buffer,
+static s32 ixgbe_host_interface_command(struct ixgbe_hw *hw, u32 *buffer,
u32 length)
{
u32 hicr, i;
@@ -3374,7 +3374,7 @@ static s32 ixgbe_host_interface_command(struct ixgbe_hw *hw, u8 *buffer,
*/
for (i = 0; i < dword_len; i++)
IXGBE_WRITE_REG_ARRAY(hw, IXGBE_FLEX_MNG,
- i, *((u32 *)buffer + i));
+ i, cpu_to_le32(buffer[i]));
/* Setting this bit tells the ARC that a new command is pending. */
IXGBE_WRITE_REG(hw, IXGBE_HICR, hicr | IXGBE_HICR_C);
@@ -3398,9 +3398,10 @@ static s32 ixgbe_host_interface_command(struct ixgbe_hw *hw, u8 *buffer,
dword_len = hdr_size >> 2;
/* first pull in the header so we know the buffer length */
- for (i = 0; i < dword_len; i++)
- *((u32 *)buffer + i) =
- IXGBE_READ_REG_ARRAY(hw, IXGBE_FLEX_MNG, i);
+ for (i = 0; i < dword_len; i++) {
+ buffer[i] = IXGBE_READ_REG_ARRAY(hw, IXGBE_FLEX_MNG, i);
+ le32_to_cpus(&buffer[i]);
+ }
/* If there is any thing in data position pull it in */
buf_len = ((struct ixgbe_hic_hdr *)buffer)->buf_len;
@@ -3418,8 +3419,7 @@ static s32 ixgbe_host_interface_command(struct ixgbe_hw *hw, u8 *buffer,
/* Pull in the rest of the buffer (i is where we left off)*/
for (; i < buf_len; i++)
- *((u32 *)buffer + i) =
- IXGBE_READ_REG_ARRAY(hw, IXGBE_FLEX_MNG, i);
+ buffer[i] = IXGBE_READ_REG_ARRAY(hw, IXGBE_FLEX_MNG, i);
out:
return ret_val;
@@ -3465,7 +3465,7 @@ s32 ixgbe_set_fw_drv_ver_generic(struct ixgbe_hw *hw, u8 maj, u8 min,
fw_cmd.pad2 = 0;
for (i = 0; i <= FW_CEM_MAX_RETRIES; i++) {
- ret_val = ixgbe_host_interface_command(hw, (u8 *)&fw_cmd,
+ ret_val = ixgbe_host_interface_command(hw, (u32 *)&fw_cmd,
sizeof(fw_cmd));
if (ret_val != 0)
continue;
--
1.7.6.4
^ permalink raw reply related
* [net-next 4/5] ixgbe: allow eeprom writes via ethtool
From: Jeff Kirsher @ 2011-10-18 0:12 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1318896767-5374-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
Implement support for ethtool -E
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c | 2 +
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 71 ++++++++++++++++++++++
2 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
index e02e911..ef2afef 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
@@ -1305,6 +1305,8 @@ static struct ixgbe_mac_operations mac_ops_82598 = {
static struct ixgbe_eeprom_operations eeprom_ops_82598 = {
.init_params = &ixgbe_init_eeprom_params_generic,
.read = &ixgbe_read_eerd_generic,
+ .write = &ixgbe_write_eeprom_generic,
+ .write_buffer = &ixgbe_write_eeprom_buffer_bit_bang_generic,
.read_buffer = &ixgbe_read_eerd_buffer_generic,
.calc_checksum = &ixgbe_calc_eeprom_checksum_generic,
.validate_checksum = &ixgbe_validate_eeprom_checksum_generic,
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index e102ff6..7acfce3 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -814,6 +814,76 @@ static int ixgbe_get_eeprom(struct net_device *netdev,
return ret_val;
}
+static int ixgbe_set_eeprom(struct net_device *netdev,
+ struct ethtool_eeprom *eeprom, u8 *bytes)
+{
+ struct ixgbe_adapter *adapter = netdev_priv(netdev);
+ struct ixgbe_hw *hw = &adapter->hw;
+ u16 *eeprom_buff;
+ void *ptr;
+ int max_len, first_word, last_word, ret_val = 0;
+ u16 i;
+
+ if (eeprom->len == 0)
+ return -EINVAL;
+
+ if (eeprom->magic != (hw->vendor_id | (hw->device_id << 16)))
+ return -EINVAL;
+
+ max_len = hw->eeprom.word_size * 2;
+
+ first_word = eeprom->offset >> 1;
+ last_word = (eeprom->offset + eeprom->len - 1) >> 1;
+ eeprom_buff = kmalloc(max_len, GFP_KERNEL);
+ if (!eeprom_buff)
+ return -ENOMEM;
+
+ ptr = eeprom_buff;
+
+ if (eeprom->offset & 1) {
+ /*
+ * need read/modify/write of first changed EEPROM word
+ * only the second byte of the word is being modified
+ */
+ ret_val = hw->eeprom.ops.read(hw, first_word, &eeprom_buff[0]);
+ if (ret_val)
+ goto err;
+
+ ptr++;
+ }
+ if ((eeprom->offset + eeprom->len) & 1) {
+ /*
+ * need read/modify/write of last changed EEPROM word
+ * only the first byte of the word is being modified
+ */
+ ret_val = hw->eeprom.ops.read(hw, last_word,
+ &eeprom_buff[last_word - first_word]);
+ if (ret_val)
+ goto err;
+ }
+
+ /* Device's eeprom is always little-endian, word addressable */
+ for (i = 0; i < last_word - first_word + 1; i++)
+ le16_to_cpus(&eeprom_buff[i]);
+
+ memcpy(ptr, bytes, eeprom->len);
+
+ for (i = 0; i < last_word - first_word + 1; i++)
+ cpu_to_le16s(&eeprom_buff[i]);
+
+ ret_val = hw->eeprom.ops.write_buffer(hw, first_word,
+ last_word - first_word + 1,
+ eeprom_buff);
+
+ /* Update the checksum */
+ if (ret_val == 0)
+ hw->eeprom.ops.update_checksum(hw);
+
+err:
+ kfree(eeprom_buff);
+ return ret_val;
+}
+
static void ixgbe_get_drvinfo(struct net_device *netdev,
struct ethtool_drvinfo *drvinfo)
{
@@ -2524,6 +2594,7 @@ static const struct ethtool_ops ixgbe_ethtool_ops = {
.get_link = ethtool_op_get_link,
.get_eeprom_len = ixgbe_get_eeprom_len,
.get_eeprom = ixgbe_get_eeprom,
+ .set_eeprom = ixgbe_set_eeprom,
.get_ringparam = ixgbe_get_ringparam,
.set_ringparam = ixgbe_set_ringparam,
.get_pauseparam = ixgbe_get_pauseparam,
--
1.7.6.4
^ permalink raw reply related
* [net-next 0/6 v3][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2011-10-18 0:12 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann
The following series contains updates to ixgbe, igbvf and igb.
This version of the series contains the following changes:
- igb fix/add check if subordinate VFs are assigned to VM's
- igbvf fix for trunk VLAN
- ixgbe 2 fixes for ethtool and 1 endianess fix
-v2 update the igb patch to resolve a variable initialization warning
-v3 Drop patch 5 (ixgbe: add hardware time stamping support)
The following are changes since commit fd38f734cb8200529e281338514945fcbff2364b:
igbvf: convert to ndo_fix_features
and are available in the git repository at
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git
Emil Tantilov (3):
ixgbe: fix endianess when writing driver version to firmware
ixgbe: allow eeprom writes via ethtool
ixgbe: change the eeprom version reported by ethtool
Greg Rose (2):
igbvf: Fix trunk vlan
igb: Check if subordinate VFs are assigned to virtual machines
drivers/net/ethernet/intel/igb/igb.h | 3 +
drivers/net/ethernet/intel/igb/igb_main.c | 177 ++++++++++++++++++----
drivers/net/ethernet/intel/igbvf/netdev.c | 4 +-
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 3 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c | 2 +
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 16 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 84 ++++++++++-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 7 +-
8 files changed, 246 insertions(+), 50 deletions(-)
--
1.7.6.4
^ permalink raw reply
* [net-next 2/5] igb: Check if subordinate VFs are assigned to virtual machines
From: Jeff Kirsher @ 2011-10-18 0:12 UTC (permalink / raw)
To: davem
Cc: Greg Rose, netdev, gospo, sassmann, Konrad Rzeszutek Wilk,
Christian Benvenuti, Sathya Perla, Dimitris Michailidis,
Jon Mason, James Smart, Jeff Kirsher
In-Reply-To: <1318896767-5374-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Greg Rose <gregory.v.rose@intel.com>
Kvm and the Xen pci-back driver will set a flag in the virtual function
pci device dev_flags when the VF is assigned to a guest VM. Before
destroying subordinate VFs check to see if the flag is set and if so
skip the call to pci_disable_sriov() to avoid system crashes.
Copy the maintainer for the Xen pci-back driver. Also CC'ing
maintainers of all drivers found to call pci_disable_sriov().
V2 - Fix uninitialized variable warning
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Christian Benvenuti <benve@cisco.com>
Cc: Sathya Perla <sathya.perla@emulex.com>
Cc: Dimitris Michailidis <dm@chelsio.com>
Cc: Jon Mason <jdmason@kudzu.us>
Cc: James Smart <james.smart@emulex.com>
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb.h | 3 +
drivers/net/ethernet/intel/igb/igb_main.c | 177 ++++++++++++++++++++++++-----
2 files changed, 150 insertions(+), 30 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb.h b/drivers/net/ethernet/intel/igb/igb.h
index 4c500a7..5594430 100644
--- a/drivers/net/ethernet/intel/igb/igb.h
+++ b/drivers/net/ethernet/intel/igb/igb.h
@@ -72,6 +72,8 @@ struct igb_adapter;
#define IGB_MAX_VF_MC_ENTRIES 30
#define IGB_MAX_VF_FUNCTIONS 8
#define IGB_MAX_VFTA_ENTRIES 128
+#define IGB_82576_VF_DEV_ID 0x10CA
+#define IGB_I350_VF_DEV_ID 0x1520
struct vf_data_storage {
unsigned char vf_mac_addresses[ETH_ALEN];
@@ -83,6 +85,7 @@ struct vf_data_storage {
u16 pf_vlan; /* When set, guest VLAN config not allowed. */
u16 pf_qos;
u16 tx_rate;
+ struct pci_dev *vfdev;
};
#define IGB_VF_FLAG_CTS 0x00000001 /* VF is clear to send data */
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index c10cc71..837adbb 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -162,6 +162,9 @@ static int igb_ndo_set_vf_bw(struct net_device *netdev, int vf, int tx_rate);
static int igb_ndo_get_vf_config(struct net_device *netdev, int vf,
struct ifla_vf_info *ivi);
static void igb_check_vf_rate_limit(struct igb_adapter *);
+static int igb_vf_configure(struct igb_adapter *adapter, int vf);
+static int igb_find_enabled_vfs(struct igb_adapter *adapter);
+static int igb_check_vf_assignment(struct igb_adapter *adapter);
#ifdef CONFIG_PM
static int igb_suspend(struct pci_dev *, pm_message_t);
@@ -2232,8 +2235,12 @@ static void __devexit igb_remove(struct pci_dev *pdev)
/* reclaim resources allocated to VFs */
if (adapter->vf_data) {
/* disable iov and allow time for transactions to clear */
- pci_disable_sriov(pdev);
- msleep(500);
+ if (!igb_check_vf_assignment(adapter)) {
+ pci_disable_sriov(pdev);
+ msleep(500);
+ } else {
+ dev_info(&pdev->dev, "VF(s) assigned to guests!\n");
+ }
kfree(adapter->vf_data);
adapter->vf_data = NULL;
@@ -2270,42 +2277,49 @@ static void __devinit igb_probe_vfs(struct igb_adapter * adapter)
{
#ifdef CONFIG_PCI_IOV
struct pci_dev *pdev = adapter->pdev;
+ int old_vfs = igb_find_enabled_vfs(adapter);
+ int i;
- if (adapter->vfs_allocated_count) {
- adapter->vf_data = kcalloc(adapter->vfs_allocated_count,
- sizeof(struct vf_data_storage),
- GFP_KERNEL);
- /* if allocation failed then we do not support SR-IOV */
- if (!adapter->vf_data) {
- adapter->vfs_allocated_count = 0;
- dev_err(&pdev->dev, "Unable to allocate memory for VF "
- "Data Storage\n");
- }
+ if (old_vfs) {
+ dev_info(&pdev->dev, "%d pre-allocated VFs found - override "
+ "max_vfs setting of %d\n", old_vfs, max_vfs);
+ adapter->vfs_allocated_count = old_vfs;
}
- if (pci_enable_sriov(pdev, adapter->vfs_allocated_count)) {
- kfree(adapter->vf_data);
- adapter->vf_data = NULL;
-#endif /* CONFIG_PCI_IOV */
+ if (!adapter->vfs_allocated_count)
+ return;
+
+ adapter->vf_data = kcalloc(adapter->vfs_allocated_count,
+ sizeof(struct vf_data_storage), GFP_KERNEL);
+ /* if allocation failed then we do not support SR-IOV */
+ if (!adapter->vf_data) {
adapter->vfs_allocated_count = 0;
-#ifdef CONFIG_PCI_IOV
- } else {
- unsigned char mac_addr[ETH_ALEN];
- int i;
- dev_info(&pdev->dev, "%d vfs allocated\n",
- adapter->vfs_allocated_count);
- for (i = 0; i < adapter->vfs_allocated_count; i++) {
- random_ether_addr(mac_addr);
- igb_set_vf_mac(adapter, i, mac_addr);
- }
- /* DMA Coalescing is not supported in IOV mode. */
- if (adapter->flags & IGB_FLAG_DMAC)
- adapter->flags &= ~IGB_FLAG_DMAC;
+ dev_err(&pdev->dev, "Unable to allocate memory for VF "
+ "Data Storage\n");
+ goto out;
}
+
+ if (!old_vfs) {
+ if (pci_enable_sriov(pdev, adapter->vfs_allocated_count))
+ goto err_out;
+ }
+ dev_info(&pdev->dev, "%d VFs allocated\n",
+ adapter->vfs_allocated_count);
+ for (i = 0; i < adapter->vfs_allocated_count; i++)
+ igb_vf_configure(adapter, i);
+
+ /* DMA Coalescing is not supported in IOV mode. */
+ adapter->flags &= ~IGB_FLAG_DMAC;
+ goto out;
+err_out:
+ kfree(adapter->vf_data);
+ adapter->vf_data = NULL;
+ adapter->vfs_allocated_count = 0;
+out:
+ return;
#endif /* CONFIG_PCI_IOV */
}
-
/**
* igb_init_hw_timer - Initialize hardware timer used with IEEE 1588 timestamp
* @adapter: board private structure to initialize
@@ -4917,6 +4931,109 @@ static int igb_notify_dca(struct notifier_block *nb, unsigned long event,
}
#endif /* CONFIG_IGB_DCA */
+#ifdef CONFIG_PCI_IOV
+static int igb_vf_configure(struct igb_adapter *adapter, int vf)
+{
+ unsigned char mac_addr[ETH_ALEN];
+ struct pci_dev *pdev = adapter->pdev;
+ struct e1000_hw *hw = &adapter->hw;
+ struct pci_dev *pvfdev;
+ unsigned int device_id;
+ u16 thisvf_devfn;
+
+ random_ether_addr(mac_addr);
+ igb_set_vf_mac(adapter, vf, mac_addr);
+
+ switch (adapter->hw.mac.type) {
+ case e1000_82576:
+ device_id = IGB_82576_VF_DEV_ID;
+ /* VF Stride for 82576 is 2 */
+ thisvf_devfn = (pdev->devfn + 0x80 + (vf << 1)) |
+ (pdev->devfn & 1);
+ break;
+ case e1000_i350:
+ device_id = IGB_I350_VF_DEV_ID;
+ /* VF Stride for I350 is 4 */
+ thisvf_devfn = (pdev->devfn + 0x80 + (vf << 2)) |
+ (pdev->devfn & 3);
+ break;
+ default:
+ device_id = 0;
+ thisvf_devfn = 0;
+ break;
+ }
+
+ pvfdev = pci_get_device(hw->vendor_id, device_id, NULL);
+ while (pvfdev) {
+ if (pvfdev->devfn == thisvf_devfn)
+ break;
+ pvfdev = pci_get_device(hw->vendor_id,
+ device_id, pvfdev);
+ }
+
+ if (pvfdev)
+ adapter->vf_data[vf].vfdev = pvfdev;
+ else
+ dev_err(&pdev->dev,
+ "Couldn't find pci dev ptr for VF %4.4x\n",
+ thisvf_devfn);
+ return pvfdev != NULL;
+}
+
+static int igb_find_enabled_vfs(struct igb_adapter *adapter)
+{
+ struct e1000_hw *hw = &adapter->hw;
+ struct pci_dev *pdev = adapter->pdev;
+ struct pci_dev *pvfdev;
+ u16 vf_devfn = 0;
+ u16 vf_stride;
+ unsigned int device_id;
+ int vfs_found = 0;
+
+ switch (adapter->hw.mac.type) {
+ case e1000_82576:
+ device_id = IGB_82576_VF_DEV_ID;
+ /* VF Stride for 82576 is 2 */
+ vf_stride = 2;
+ break;
+ case e1000_i350:
+ device_id = IGB_I350_VF_DEV_ID;
+ /* VF Stride for I350 is 4 */
+ vf_stride = 4;
+ break;
+ default:
+ device_id = 0;
+ vf_stride = 0;
+ break;
+ }
+
+ vf_devfn = pdev->devfn + 0x80;
+ pvfdev = pci_get_device(hw->vendor_id, device_id, NULL);
+ while (pvfdev) {
+ if (pvfdev->devfn == vf_devfn)
+ vfs_found++;
+ vf_devfn += vf_stride;
+ pvfdev = pci_get_device(hw->vendor_id,
+ device_id, pvfdev);
+ }
+
+ return vfs_found;
+}
+
+static int igb_check_vf_assignment(struct igb_adapter *adapter)
+{
+ int i;
+ for (i = 0; i < adapter->vfs_allocated_count; i++) {
+ if (adapter->vf_data[i].vfdev) {
+ if (adapter->vf_data[i].vfdev->dev_flags &
+ PCI_DEV_FLAGS_ASSIGNED)
+ return true;
+ }
+ }
+ return false;
+}
+
+#endif
static void igb_ping_all_vfs(struct igb_adapter *adapter)
{
struct e1000_hw *hw = &adapter->hw;
--
1.7.6.4
^ permalink raw reply related
* [net-next 1/5] igbvf: Fix trunk vlan
From: Jeff Kirsher @ 2011-10-18 0:12 UTC (permalink / raw)
To: davem; +Cc: Greg Rose, netdev, gospo, sassmann, Jiri Pirko, Jeff Kirsher
In-Reply-To: <1318896767-5374-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Greg Rose <gregory.v.rose@intel.com>
Changes to clean up the VLAN Rx path by Jiri Pirko broke trunk VLAN.
Trunk VLANs in a VF driver are those set using
"ip link set <pfdev> vf <n> <vlanid>"
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
CC: Jiri Pirko <jpirko@redhat.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igbvf/netdev.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
index 32b3044..23cc40f 100644
--- a/drivers/net/ethernet/intel/igbvf/netdev.c
+++ b/drivers/net/ethernet/intel/igbvf/netdev.c
@@ -102,8 +102,8 @@ static void igbvf_receive_skb(struct igbvf_adapter *adapter,
{
if (status & E1000_RXD_STAT_VP) {
u16 vid = le16_to_cpu(vlan) & E1000_RXD_SPC_VLAN_MASK;
-
- __vlan_hwaccel_put_tag(skb, vid);
+ if (test_bit(vid, adapter->active_vlans))
+ __vlan_hwaccel_put_tag(skb, vid);
}
netif_receive_skb(skb);
}
--
1.7.6.4
^ permalink raw reply related
* Re: [PATCH 2/2] bridge: allow forwarding some link local frames
From: John Fastabend @ 2011-10-18 0:00 UTC (permalink / raw)
To: Ed Swierk
Cc: Brattain, Ross B, Stephen Hemminger, David S. Miller,
netdev@vger.kernel.org
In-Reply-To: <CAF5U64A-o0WHMGZ=x3kRd-bOnscra=oLu8uFju=HB=CF4zNiXQ@mail.gmail.com>
On 10/17/2011 4:36 PM, Ed Swierk wrote:
> On Mon, Oct 17, 2011 at 4:07 PM, Ross Brattain
> <ross.b.brattain@intel.com> wrote:
>> 802.1AB-2009 Section 7.1 Destination address:
>>
>> NOTE 8—The destination MAC address used by a given LLDP agent defines only the scope of transmission and the
>> intended recipient(s) of the LLDPDUs; it plays no part in protocol identification. In particular, the group MAC addresses
>> identified in Table 7-1 are not used exclusively by LLDP; other protocols that require to use a similar transmission scope
>> are free to use the same addresses.
>> ...
>> If you control both end stations you could use the optional group MAC address support, or unicast LLDP.
>>
>> 802.1AB-2009 Section 7.1 Destination address:
>>
>> In addition to the prescribed support for standard group MAC addresses shown in Table 7-1,
>> implementations of LLDP may support the following destination addresses for LLDPDUs:
>> d) Any group MAC address.
>> e) Any individual MAC address.
>> Support for the use of each of these destination addresses, for both transmission and reception of LLDPDUs,
>> is either mandatory, recommended, permitted, or not permitted, according to the type of system in which
>> LLDP is implemented, as shown in Table 7-2.
>
> Thanks for the references. I need to read the updated standards specs
> before jumping to conclusions...
>
>> I have no idea if any LLDP agents support the optional group MAC addresses.
>
> In our application we're both generating and consuming the LLDP
> frames. We're worried about standards conformance to the extent that
> we don't break other tools that might receive the LLDP frames we
> generate. As long as they don't care about the destination MAC address
> of the frames they receive (and they shouldn't), it's definitely
> feasible for us to use the "nearest customer bridge" address
> (01-80-C2-00-00-00) to ensure our LLDP frames traverse Linux bridges.
>
> --Ed
Ed,
Its unclear what you mean by "and they shouldn't". If the other tool
is an LLDP daemon then it will receive the frame and process it as
a nearest customer bridge LLDPDU.
However it looks like your on the right track here. If your adding
a standard TLV you might consider adding support to an existing
agent. For example 'lldpad'.
Thanks,
John.
^ permalink raw reply
* Re: [PATCH] route: fix ICMP redirect validation
From: David Miller @ 2011-10-17 23:43 UTC (permalink / raw)
To: fbl; +Cc: netdev
In-Reply-To: <1317824404-9513-1-git-send-email-fbl@redhat.com>
From: Flavio Leitner <fbl@redhat.com>
Date: Wed, 5 Oct 2011 11:20:04 -0300
> The commit f39925dbde7788cfb96419c0f092b086aa325c0f
> (ipv4: Cache learned redirect information in inetpeer.)
> removed some ICMP packet validations which are required by
> RFC 1122, section 3.2.2.2:
> ...
> A Redirect message SHOULD be silently discarded if the new
> gateway address it specifies is not on the same connected
> (sub-) net through which the Redirect arrived [INTRO:2,
> Appendix A], or if the source of the Redirect is not the
> current first-hop gateway for the specified destination (see
> Section 3.3.1).
>
> Signed-off-by: Flavio Leitner <fbl@redhat.com>
The reason for putting this into the inetpeer cache was so that we
didn't need to consult the routing cache at all. We're working to
remove it at some point, so every dependency matters.
Can you implement this such that only an inetpeer cache probe is
necessary?
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] bridge: allow forwarding some link local frames
From: Ed Swierk @ 2011-10-17 23:36 UTC (permalink / raw)
To: Ross Brattain; +Cc: Stephen Hemminger, David S. Miller, netdev@vger.kernel.org
In-Reply-To: <20111017160715.000024eb@unknown>
On Mon, Oct 17, 2011 at 4:07 PM, Ross Brattain
<ross.b.brattain@intel.com> wrote:
> 802.1AB-2009 Section 7.1 Destination address:
>
> NOTE 8—The destination MAC address used by a given LLDP agent defines only the scope of transmission and the
> intended recipient(s) of the LLDPDUs; it plays no part in protocol identification. In particular, the group MAC addresses
> identified in Table 7-1 are not used exclusively by LLDP; other protocols that require to use a similar transmission scope
> are free to use the same addresses.
> ...
> If you control both end stations you could use the optional group MAC address support, or unicast LLDP.
>
> 802.1AB-2009 Section 7.1 Destination address:
>
> In addition to the prescribed support for standard group MAC addresses shown in Table 7-1,
> implementations of LLDP may support the following destination addresses for LLDPDUs:
> d) Any group MAC address.
> e) Any individual MAC address.
> Support for the use of each of these destination addresses, for both transmission and reception of LLDPDUs,
> is either mandatory, recommended, permitted, or not permitted, according to the type of system in which
> LLDP is implemented, as shown in Table 7-2.
Thanks for the references. I need to read the updated standards specs
before jumping to conclusions...
> I have no idea if any LLDP agents support the optional group MAC addresses.
In our application we're both generating and consuming the LLDP
frames. We're worried about standards conformance to the extent that
we don't break other tools that might receive the LLDP frames we
generate. As long as they don't care about the destination MAC address
of the frames they receive (and they shouldn't), it's definitely
feasible for us to use the "nearest customer bridge" address
(01-80-C2-00-00-00) to ensure our LLDP frames traverse Linux bridges.
--Ed
^ permalink raw reply
* Re: x25: Fix multiple buffer overruns/overreads
From: David Miller @ 2011-10-17 23:32 UTC (permalink / raw)
To: mattjd; +Cc: netdev, eric.dumazet, andrew.hendry
In-Reply-To: <1318653905-13716-1-git-send-email-mattjd@gmail.com>
From: Matthew Daley <mattjd@gmail.com>
Date: Sat, 15 Oct 2011 00:45:02 -0400
> This patchset fixes several buffer overruns/overreads in the X.25
> packet layer. The first patch fixes a particularly nasty remote-triggerable
> buffer overflow, while the rest fix skb overreads on undersized/fragmented
> skbs.
All applied, thanks Matthew!
^ 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