* 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
* Re: [PATCH net-next] ipv6: remove a rcu_read_lock in ndisc_constructor
From: David Miller @ 2011-10-17 23:28 UTC (permalink / raw)
To: rongqing.li; +Cc: netdev
In-Reply-To: <1317707015-2432-1-git-send-email-rongqing.li@windriver.com>
From: <rongqing.li@windriver.com>
Date: Tue, 4 Oct 2011 13:43:35 +0800
> From: Roy.Li <rongqing.li@windriver.com>
>
> in6_dev_get(dev) takes a reference on struct inet6_dev, we dont need
> rcu locking in ndisc_constructor()
>
> Signed-off-by: Roy.Li <rongqing.li@windriver.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 0/2] MAINTAINERS: can: the mailinglist moved to vger.kernel.org
From: David Miller @ 2011-10-17 23:23 UTC (permalink / raw)
To: mkl; +Cc: linux-can, netdev
In-Reply-To: <1318879920-25280-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Mon, 17 Oct 2011 21:31:58 +0200
> Hello,
>
> the BerliOS project will close with the end of the year, so we moved our
> mailinglist to vger.kernel.org, it's now linux-can@vger.kernel.org.
>
> This patch series change the mailinglist in MAINTAINERS and remove all other
> references from the source tree. As David pointed out, automated tool will
> use MAINTAINERS to gather this information.
>
> cheers, Marc
>
> The following changes since commit fd38f734cb8200529e281338514945fcbff2364b:
>
> igbvf: convert to ndo_fix_features (2011-10-16 13:18:47 -0700)
>
> are available in the git repository at:
> git.pengutronix.de:/git/mkl/linux-2.6.git can/mailinglist-for-net-next
That URL prompts me for a password, so I applied these patches by hand
to net-next, thanks.
^ permalink raw reply
* Re: [PATCH v3] net/flow: Fix potential memory leak
From: David Miller @ 2011-10-17 23:19 UTC (permalink / raw)
To: huajun.li.lee; +Cc: eric.dumazet, netdev
In-Reply-To: <CA+v9cxZ=ZYQ_nUXp-8M1Kciia2F6F0MZpq-kKGE4J-ayEGeScw@mail.gmail.com>
From: Huajun Li <huajun.li.lee@gmail.com>
Date: Wed, 28 Sep 2011 16:51:39 +0800
> While preparing net flow caches, once a fail may cause potential
> memory leak , fix it.
>
> Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: net [BUG-FIX][PATCH 1/1] udplite: fast-path computation of checksum coverage
From: David Miller @ 2011-10-17 23:07 UTC (permalink / raw)
To: gerrit; +Cc: netdev
In-Reply-To: <20111017213447.GA4061@gerrit.erg.abdn.ac.uk>
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Date: Mon, 17 Oct 2011 15:34:47 -0600
> can you please consider the fix below -- the checksum coverage in
> UDP-Lite had been broken for over half a year; then reported by
> Thomas. I have tested the patch below in various scenarios with IPv4
> and IPv6, on localhost, and between multiple hosts.
Applied, thanks a lot Gerrit.
^ permalink raw reply
* Re: [PATCH 2/2] bridge: allow forwarding some link local frames
From: Ross Brattain @ 2011-10-17 23:07 UTC (permalink / raw)
To: Ed Swierk; +Cc: Stephen Hemminger, David S. Miller, netdev@vger.kernel.org
In-Reply-To: <CAF5U64D36-Kb+KN6kNskE6yaPW6G_Ue8-OcskseKWoBEPQdVUA@mail.gmail.com>
On Mon, 17 Oct 2011 14:09:34 -0700
Ed Swierk <eswierk@bigswitch.com> wrote:
> Interesting, I didn't realize LLDP could use any of those addresses.
>
> I finally got a peek at the hot-off-the-presses IEEE 802.1Q-2011, and
> notice that 01-80-C2-00-00-0E is now assigned as "Individual LAN Scope
> group address, Nearest bridge group address" rather than dedicated to
> LLDP specifically.
>
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.
> Since our application is generating the LLDP frames we could change it
> to use -00 or -03 and let the Linux bridge drop the -0E frames.
>
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.
I have no idea if any LLDP agents support the optional group MAC addresses.
--
Ross
^ permalink raw reply
* Re: EHEA updates
From: David Miller @ 2011-10-17 23:06 UTC (permalink / raw)
To: cascardo; +Cc: netdev, anton
In-Reply-To: <1318606272-27647-1-git-send-email-cascardo@linux.vnet.ibm.com>
From: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Date: Fri, 14 Oct 2011 12:30:57 -0300
> This is a rebase of Anton's patches on top of net-next HEAD, commit
> 7ae60b3. Besides the conflicts with the latest patches, some trivia were
> fixed as suggested.
>
> Ben Hutchings' suggestions about doing packet split and NAPI fixes were
> taken into consideration, but not done on this round.
>
> The result was tested between two LPARs and also using a switch, with
> ICMP and TCP tests.
Nice work, all applied, thanks.
^ permalink raw reply
* Re: [net-next 0/6 v2][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2011-10-17 22:53 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com
In-Reply-To: <20111017.184922.373702739993889767.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]
On Mon, 2011-10-17 at 15:49 -0700, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Mon, 17 Oct 2011 05:20:56 -0700
>
> > 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
> >
> > 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
>
> Patch #5 adding timestamp offloading for ixgbe has some legitimate
> pushback from Richard Cochran, why don't we defer that patch while that
> discussion transpires?
>
> I'm perfectly fine with the other patches in this series.
>
> Please respin the remaining 5 patches into a pull request and I'll
> take them into net-next, thanks Jeff!
>
Sounds good, I have that ready in an hour or so.
Thanks!
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: pull request: wireless-next 2011-10-17
From: David Miller @ 2011-10-17 22:49 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20111017202332.GE8948-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Mon, 17 Oct 2011 16:23:33 -0400
> I neglected to identify the HEAD and sign...
>
> commit 41ebe9cde738a972d05c7282e09f5ed54cff0e8d
Pulled, thanks John.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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