* net [BUG-FIX][PATCH 1/1] udplite: fast-path computation of checksum coverage
From: Gerrit Renker @ 2011-10-17 21:34 UTC (permalink / raw)
To: David S. Miller, netdev
Hi Dave,
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.
Gerrit
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Patch <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
udplite: fast-path computation of checksum coverage
Commit 903ab86d195cca295379699299c5fc10beba31c7 of 1 March this year ("udp: Add
lockless transmit path") introduced a new fast TX path that broke the checksum
coverage computation of UDP-lite, which so far depended on up->len (only set
if the socket is locked and 0 in the fast path).
Fixed by providing both fast- and slow-path computation of checksum coverage.
The latter can be removed when UDP(-lite)v6 also uses a lockless transmit path.
Reported-by: Thomas Volkert <thomas@homer-conferencing.com>
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
include/net/udplite.h | 63 ++++++++++++++++++++++++--------------------------
1 file changed, 31 insertions(+), 32 deletions(-)
--- a/include/net/udplite.h
+++ b/include/net/udplite.h
@@ -66,40 +66,34 @@ static inline int udplite_checksum_init(struct sk_buff *skb, struct udphdr *uh)
return 0;
}
-static inline int udplite_sender_cscov(struct udp_sock *up, struct udphdr *uh)
+/* Slow-path computation of checksum. Socket is locked. */
+static inline __wsum udplite_csum_outgoing(struct sock *sk, struct sk_buff *skb)
{
+ const struct udp_sock *up = udp_sk(skb->sk);
int cscov = up->len;
+ __wsum csum = 0;
- /*
- * Sender has set `partial coverage' option on UDP-Lite socket
- */
- if (up->pcflag & UDPLITE_SEND_CC) {
+ if (up->pcflag & UDPLITE_SEND_CC) {
+ /*
+ * Sender has set `partial coverage' option on UDP-Lite socket.
+ * The special case "up->pcslen == 0" signifies full coverage.
+ */
if (up->pcslen < up->len) {
- /* up->pcslen == 0 means that full coverage is required,
- * partial coverage only if 0 < up->pcslen < up->len */
- if (0 < up->pcslen) {
- cscov = up->pcslen;
- }
- uh->len = htons(up->pcslen);
+ if (0 < up->pcslen)
+ cscov = up->pcslen;
+ udp_hdr(skb)->len = htons(up->pcslen);
}
- /*
- * NOTE: Causes for the error case `up->pcslen > up->len':
- * (i) Application error (will not be penalized).
- * (ii) Payload too big for send buffer: data is split
- * into several packets, each with its own header.
- * In this case (e.g. last segment), coverage may
- * exceed packet length.
- * Since packets with coverage length > packet length are
- * illegal, we fall back to the defaults here.
- */
+ /*
+ * NOTE: Causes for the error case `up->pcslen > up->len':
+ * (i) Application error (will not be penalized).
+ * (ii) Payload too big for send buffer: data is split
+ * into several packets, each with its own header.
+ * In this case (e.g. last segment), coverage may
+ * exceed packet length.
+ * Since packets with coverage length > packet length are
+ * illegal, we fall back to the defaults here.
+ */
}
- return cscov;
-}
-
-static inline __wsum udplite_csum_outgoing(struct sock *sk, struct sk_buff *skb)
-{
- int cscov = udplite_sender_cscov(udp_sk(sk), udp_hdr(skb));
- __wsum csum = 0;
skb->ip_summed = CHECKSUM_NONE; /* no HW support for checksumming */
@@ -115,16 +109,21 @@ static inline __wsum udplite_csum_outgoing(struct sock *sk, struct sk_buff *skb)
return csum;
}
+/* Fast-path computation of checksum. Socket may not be locked. */
static inline __wsum udplite_csum(struct sk_buff *skb)
{
- struct sock *sk = skb->sk;
- int cscov = udplite_sender_cscov(udp_sk(sk), udp_hdr(skb));
+ const struct udp_sock *up = udp_sk(skb->sk);
const int off = skb_transport_offset(skb);
- const int len = skb->len - off;
+ int len = skb->len - off;
+ if ((up->pcflag & UDPLITE_SEND_CC) && up->pcslen < len) {
+ if (0 < up->pcslen)
+ len = up->pcslen;
+ udp_hdr(skb)->len = htons(up->pcslen);
+ }
skb->ip_summed = CHECKSUM_NONE; /* no HW support for checksumming */
- return skb_checksum(skb, off, min(cscov, len), 0);
+ return skb_checksum(skb, off, len, 0);
}
extern void udplite4_register(void);
^ permalink raw reply
* Re: [PATCH] Disable TCP_DEBUG and FASTRETRANS_DEBUG by default
From: David Miller @ 2011-10-17 21:52 UTC (permalink / raw)
To: dpmcgee; +Cc: netdev, kuznet, jmorris, yoshfuji, kaber, linux-kernel
In-Reply-To: <1318883125-29500-1-git-send-email-dpmcgee@gmail.com>
From: Dan McGee <dpmcgee@gmail.com>
Date: Mon, 17 Oct 2011 15:25:24 -0500
> If these are truly debug options, they should be turned off by default
> and can be tweaked if necessary. Fix one usage of the flag to use #if
> instead of #ifdef so defining to zero is acceptable.
>
> Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Illegal window shrinks are a serious issue, and the fact that everyone
will see those messages by default and sometimes report them has been
tremendously useful.
^ permalink raw reply
* [PATCH] net: change capability used by socket options IP{,V6}_TRANSPARENT
From: Maciej Żenczykowski @ 2011-10-17 22:16 UTC (permalink / raw)
To: Maciej Żenczykowski
Cc: netdev, Balazs Scheidler, Maciej Żenczykowski
In-Reply-To: <20110920.154213.888729603269720228.davem@redhat.com>
From: Maciej Żenczykowski <maze@google.com>
Up till now the IP{,V6}_TRANSPARENT socket options (which actually set
the same bit in the socket struct) have required CAP_NET_ADMIN
privileges to set or clear the option.
- we make clearing the bit not require any privileges.
- we deprecate using CAP_NET_ADMIN for this purpose.
- we allow CAP_NET_RAW to set this bit, because raw
sockets already effectively allow you to emulate socket
transparency.
- we print a warning (but allow it) if you try to set the socket
option with CAP_NET_ADMIN privs, but without CAP_NET_RAW.
Signed-off-by: Maciej Żenczykowski <maze@google.com>
---
include/linux/capability.h | 3 ++-
net/ipv4/ip_sockglue.c | 20 ++++++++++++++++----
net/ipv6/ipv6_sockglue.c | 23 ++++++++++++++++++-----
3 files changed, 36 insertions(+), 10 deletions(-)
diff --git a/include/linux/capability.h b/include/linux/capability.h
index c421123..ce34ae3 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -198,7 +198,7 @@ struct cpu_vfs_cap_data {
/* Allow modification of routing tables */
/* Allow setting arbitrary process / process group ownership on
sockets */
-/* Allow binding to any address for transparent proxying */
+/* Allow binding to any address for transparent proxying (deprecated) */
/* Allow setting TOS (type of service) */
/* Allow setting promiscuous mode */
/* Allow clearing driver statistics */
@@ -210,6 +210,7 @@ struct cpu_vfs_cap_data {
/* Allow use of RAW sockets */
/* Allow use of PACKET sockets */
+/* Allow binding to any address for transparent proxying */
#define CAP_NET_RAW 13
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 8905e92..74f7d30 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -961,12 +961,24 @@ mc_msf_out:
break;
case IP_TRANSPARENT:
- if (!capable(CAP_NET_ADMIN)) {
- err = -EPERM;
- break;
- }
if (optlen < 1)
goto e_inval;
+ /* Always allow clearing the transparent proxy socket option.
+ * The pre-3.2 permission for setting this was CAP_NET_ADMIN,
+ * and this is still supported - but deprecated. As of Linux
+ * 3.2 the proper permission is CAP_NET_RAW.
+ */
+ if (!!val && !capable(CAP_NET_RAW)) {
+ if (!capable(CAP_NET_ADMIN)) {
+ err = -EPERM;
+ break;
+ }
+ printk_once(KERN_WARNING "%s (%d): "
+ "deprecated: attempt to set socket option "
+ "IP_TRANSPARENT with CAP_NET_ADMIN but "
+ "without CAP_NET_RAW.\n",
+ current->comm, task_pid_nr(current));
+ }
inet->transparent = !!val;
break;
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 2fbda5f..7c4f5ce 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -343,13 +343,26 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
break;
case IPV6_TRANSPARENT:
- if (!capable(CAP_NET_ADMIN)) {
- retv = -EPERM;
- break;
- }
if (optlen < sizeof(int))
goto e_inval;
- /* we don't have a separate transparent bit for IPV6 we use the one in the IPv4 socket */
+ /* Always allow clearing the transparent proxy socket option.
+ * The pre-3.2 permission for setting this was CAP_NET_ADMIN,
+ * and this is still supported - but deprecated. As of Linux
+ * 3.2 the proper permission is CAP_NET_RAW.
+ */
+ if (valbool && !capable(CAP_NET_RAW)) {
+ if (!capable(CAP_NET_ADMIN)) {
+ retv = -EPERM;
+ break;
+ }
+ printk_once(KERN_WARNING "%s (%d): "
+ "deprecated: attempt to set socket option "
+ "IPV6_TRANSPARENT with CAP_NET_ADMIN but "
+ "without CAP_NET_RAW.\n",
+ current->comm, task_pid_nr(current));
+ }
+ /* we don't have a separate transparent bit for IPv6,
+ * so we just use the one in the IPv4 socket */
inet_sk(sk)->transparent = valbool;
retv = 0;
break;
--
1.7.3.1
^ permalink raw reply related
* BUG in skb_pull with e1000e, PPTP, and L2TP
From: Bradley Peterson @ 2011-10-17 22:19 UTC (permalink / raw)
To: netdev; +Cc: e1000-devel, Bruce Allan, Jesse Brandeburg, John Ronciak
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 ]---
------------------------------------------------------------------------------
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
* Re: [PATCH] net: change capability used by socket options IP{,V6}_TRANSPARENT
From: Maciej Żenczykowski @ 2011-10-17 22:19 UTC (permalink / raw)
To: Maciej Żenczykowski; +Cc: netdev, Balazs Scheidler
In-Reply-To: <1318889783-23183-1-git-send-email-zenczykowski@gmail.com>
I still think we need a more precise permission for this, but possibly
not quite as specific as a separate capability just for transparent.
Maybe RAW should be split into RAW_READ (eavesdropping) and RAW_WRITE (spoof).
Either way, I'll leave that for another day.
--
Maciej A. Żenczykowski
Kernel Networking Developer @ Google
^ permalink raw reply
* [PATCH 0/7] mlx4_en: Data path optimizations and bug fix.
From: Yevgeny Petrilin @ 2011-10-17 20:16 UTC (permalink / raw)
To: davem; +Cc: netdev, yevgenyp
Hello Dave,
This series of patches presents a bug fix (VLAN table overflow),
some alignment optimizations for better HW performance, RXHASH support.
Updated driver version.
Patches are generated against net-next tree.
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 -
drivers/net/ethernet/mellanox/mlx4/en_port.c | 6 ++++
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 32 +++++++++++++++----------
drivers/net/ethernet/mellanox/mlx4/en_tx.c | 2 -
drivers/net/ethernet/mellanox/mlx4/fw.c | 1
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 9 ++++---
drivers/net/ethernet/mellanox/mlx4/port.c | 15 ++++++-----
include/linux/mlx4/device.h | 1
8 files changed, 44 insertions(+), 24 deletions(-)
Thanks,
Yevgeny
^ permalink raw reply
* [PATCH 1/7] mlx4: Fix vlan table overflow
From: Yevgeny Petrilin @ 2011-10-17 20:16 UTC (permalink / raw)
To: davem; +Cc: netdev, yevgenyp
Prevent overflow when trying to register more Vlans then the Vlan table in
HW is configured to.
Need to take into account that the first 2 entries are reserved.
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
---
drivers/net/ethernet/mellanox/mlx4/port.c | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/port.c b/drivers/net/ethernet/mellanox/mlx4/port.c
index 609e0ec..163a314 100644
--- a/drivers/net/ethernet/mellanox/mlx4/port.c
+++ b/drivers/net/ethernet/mellanox/mlx4/port.c
@@ -65,7 +65,7 @@ void mlx4_init_vlan_table(struct mlx4_dev *dev, struct mlx4_vlan_table *table)
table->entries[i] = 0;
table->refs[i] = 0;
}
- table->max = 1 << dev->caps.log_num_vlans;
+ table->max = (1 << dev->caps.log_num_vlans) - MLX4_VLAN_REGULAR;
table->total = 0;
}
@@ -354,6 +354,13 @@ int mlx4_register_vlan(struct mlx4_dev *dev, u8 port, u16 vlan, int *index)
int free = -1;
mutex_lock(&table->mutex);
+
+ if (table->total == table->max) {
+ /* No free vlan entries */
+ err = -ENOSPC;
+ goto out;
+ }
+
for (i = MLX4_VLAN_REGULAR; i < MLX4_MAX_VLAN_NUM; i++) {
if (free < 0 && (table->refs[i] == 0)) {
free = i;
@@ -375,12 +382,6 @@ int mlx4_register_vlan(struct mlx4_dev *dev, u8 port, u16 vlan, int *index)
goto out;
}
- if (table->total == table->max) {
- /* No free vlan entries */
- err = -ENOSPC;
- goto out;
- }
-
/* Register new MAC */
table->refs[free] = 1;
table->entries[free] = cpu_to_be32(vlan | MLX4_VLAN_VALID);
--
1.7.7
^ permalink raw reply related
* [PATCH 2/7] mlx4_en: Controlling FCS header removal
From: Yevgeny Petrilin @ 2011-10-17 20:17 UTC (permalink / raw)
To: davem; +Cc: netdev, yevgenyp
Canceling FCS removal where FW allows for better alignment
of incoming data.
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 4 ++++
drivers/net/ethernet/mellanox/mlx4/fw.c | 1 +
include/linux/mlx4/device.h | 1 +
3 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 37cc9e5..fbf1dcf 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -806,6 +806,10 @@ static int mlx4_en_config_rss_qp(struct mlx4_en_priv *priv, int qpn,
qpn, ring->cqn, context);
context->db_rec_addr = cpu_to_be64(ring->wqres.db.dma);
+ /* Cancel FCS removal if FW allows */
+ if (mdev->dev->caps.flags & MLX4_DEV_CAP_FLAG_FCS_KEEP)
+ context->param3 |= cpu_to_be32(1 << 29);
+
err = mlx4_qp_to_ready(mdev->dev, &ring->wqres.mtt, context, qp, state);
if (err) {
mlx4_qp_remove(mdev->dev, qp);
diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.c b/drivers/net/ethernet/mellanox/mlx4/fw.c
index 7eb8ba8..ed452dd 100644
--- a/drivers/net/ethernet/mellanox/mlx4/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.c
@@ -101,6 +101,7 @@ static void dump_dev_cap_flags(struct mlx4_dev *dev, u64 flags)
[25] = "Router support",
[30] = "IBoE support",
[32] = "Unicast loopback support",
+ [34] = "FCS header control",
[38] = "Wake On LAN support",
[40] = "UDP RSS support",
[41] = "Unicast VEP steering support",
diff --git a/include/linux/mlx4/device.h b/include/linux/mlx4/device.h
index 53ef894..2366f94 100644
--- a/include/linux/mlx4/device.h
+++ b/include/linux/mlx4/device.h
@@ -75,6 +75,7 @@ enum {
MLX4_DEV_CAP_FLAG_UD_MCAST = 1LL << 21,
MLX4_DEV_CAP_FLAG_IBOE = 1LL << 30,
MLX4_DEV_CAP_FLAG_UC_LOOPBACK = 1LL << 32,
+ MLX4_DEV_CAP_FLAG_FCS_KEEP = 1LL << 34,
MLX4_DEV_CAP_FLAG_WOL = 1LL << 38,
MLX4_DEV_CAP_FLAG_UDP_RSS = 1LL << 40,
MLX4_DEV_CAP_FLAG_VEP_UC_STEER = 1LL << 41,
--
1.7.7
^ permalink raw reply related
* [PATCH 3/7] mlx4_en: Incoming traffic alignment optimizations
From: Yevgeny Petrilin @ 2011-10-17 20:17 UTC (permalink / raw)
To: davem; +Cc: netdev, yevgenyp
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>
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 12 +++---------
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 2 +-
2 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index fbf1dcf..8ae1eb5 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -744,15 +744,9 @@ void mlx4_en_calc_rx_buf(struct net_device *dev)
(eff_mtu > buf_size + frag_sizes[i]) ?
frag_sizes[i] : eff_mtu - buf_size;
priv->frag_info[i].frag_prefix_size = buf_size;
- if (!i) {
- priv->frag_info[i].frag_align = NET_IP_ALIGN;
- priv->frag_info[i].frag_stride =
- ALIGN(frag_sizes[i] + NET_IP_ALIGN, SMP_CACHE_BYTES);
- } else {
- priv->frag_info[i].frag_align = 0;
- priv->frag_info[i].frag_stride =
- ALIGN(frag_sizes[i], SMP_CACHE_BYTES);
- }
+ priv->frag_info[i].frag_align = 0;
+ priv->frag_info[i].frag_stride =
+ ALIGN(frag_sizes[i], SMP_CACHE_BYTES);
priv->frag_info[i].last_offset = mlx4_en_last_alloc_offset(
priv, priv->frag_info[i].frag_stride,
priv->frag_info[i].frag_align);
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
index 3b753f7..013cda2 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
@@ -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
--
1.7.7
^ permalink raw reply related
* [PATCH 4/7] mlx4_en: Checksum counters per ring
From: Yevgeny Petrilin @ 2011-10-17 20:17 UTC (permalink / raw)
To: davem; +Cc: netdev, yevgenyp
Not updating common counters from data path.
The checksum counters are per ring, summarizing them when collecting statistics.
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
---
drivers/net/ethernet/mellanox/mlx4/en_port.c | 6 ++++++
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 6 +++---
drivers/net/ethernet/mellanox/mlx4/en_tx.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 3 +++
4 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_port.c b/drivers/net/ethernet/mellanox/mlx4/en_port.c
index 9d27555..03c84cd 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_port.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_port.c
@@ -214,15 +214,21 @@ int mlx4_en_DUMP_ETH_STATS(struct mlx4_en_dev *mdev, u8 port, u8 reset)
stats->rx_packets = 0;
stats->rx_bytes = 0;
+ priv->port_stats.rx_chksum_good = 0;
+ priv->port_stats.rx_chksum_none = 0;
for (i = 0; i < priv->rx_ring_num; i++) {
stats->rx_packets += priv->rx_ring[i].packets;
stats->rx_bytes += priv->rx_ring[i].bytes;
+ priv->port_stats.rx_chksum_good += priv->rx_ring[i].csum_ok;
+ priv->port_stats.rx_chksum_none += priv->rx_ring[i].csum_none;
}
stats->tx_packets = 0;
stats->tx_bytes = 0;
+ priv->port_stats.tx_chksum_offload = 0;
for (i = 0; i < priv->tx_ring_num; i++) {
stats->tx_packets += priv->tx_ring[i].packets;
stats->tx_bytes += priv->tx_ring[i].bytes;
+ priv->port_stats.tx_chksum_offload += priv->tx_ring[i].tx_csum;
}
stats->rx_errors = be64_to_cpu(mlx4_en_stats->PCS) +
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 8ae1eb5..45b1a3d 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -587,7 +587,7 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
if (likely(dev->features & NETIF_F_RXCSUM)) {
if ((cqe->status & cpu_to_be16(MLX4_CQE_STATUS_IPOK)) &&
(cqe->checksum == cpu_to_be16(0xffff))) {
- priv->port_stats.rx_chksum_good++;
+ ring->csum_ok++;
/* This packet is eligible for LRO if it is:
* - DIX Ethernet (type interpretation)
* - TCP/IP (v4)
@@ -627,11 +627,11 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
ip_summed = CHECKSUM_UNNECESSARY;
} else {
ip_summed = CHECKSUM_NONE;
- priv->port_stats.rx_chksum_none++;
+ ring->csum_none++;
}
} else {
ip_summed = CHECKSUM_NONE;
- priv->port_stats.rx_chksum_none++;
+ ring->csum_none++;
}
skb = mlx4_en_rx_skb(priv, rx_desc, skb_frags,
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
index 6e03de0..f199460 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
@@ -695,7 +695,7 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct net_device *dev)
if (likely(skb->ip_summed == CHECKSUM_PARTIAL)) {
tx_desc->ctrl.srcrb_flags |= cpu_to_be32(MLX4_WQE_CTRL_IP_CSUM |
MLX4_WQE_CTRL_TCP_UDP_CSUM);
- priv->port_stats.tx_chksum_offload++;
+ ring->tx_csum++;
}
if (unlikely(priv->validate_loopback)) {
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
index 013cda2..89fb57c 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
@@ -249,6 +249,7 @@ struct mlx4_en_tx_ring {
struct mlx4_srq dummy;
unsigned long bytes;
unsigned long packets;
+ unsigned long tx_csum;
spinlock_t comp_lock;
struct mlx4_bf bf;
bool bf_enabled;
@@ -275,6 +276,8 @@ struct mlx4_en_rx_ring {
void *rx_info;
unsigned long bytes;
unsigned long packets;
+ unsigned long csum_ok;
+ unsigned long csum_none;
};
--
1.7.7
^ permalink raw reply related
* [PATCH 5/7] mlx4_en: Recording rx queue for gro packets
From: Yevgeny Petrilin @ 2011-10-17 20:18 UTC (permalink / raw)
To: davem; +Cc: netdev, yevgenyp
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 45b1a3d..f42c7a6 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -618,6 +618,7 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
__vlan_hwaccel_put_tag(gro_skb, vid);
}
+ skb_record_rx_queue(gro_skb, cq->ring);
napi_gro_frags(&cq->napi);
goto next;
--
1.7.7
^ permalink raw reply related
* [PATCH 6/7] mlx4_en: Adding rxhash support
From: Yevgeny Petrilin @ 2011-10-17 20:18 UTC (permalink / raw)
To: davem; +Cc: netdev, yevgenyp
Moving to Toeplitz function in RSS calculation.
Reporting rxhash in skb.
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 9 +++++++++
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index c4c4be4..78d776b 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -1084,7 +1084,7 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
dev->vlan_features = dev->hw_features;
- dev->hw_features |= NETIF_F_RXCSUM;
+ dev->hw_features |= NETIF_F_RXCSUM | NETIF_F_RXHASH;
dev->features = dev->hw_features | NETIF_F_HIGHDMA |
NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX |
NETIF_F_HW_VLAN_FILTER;
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index f42c7a6..ae5feed 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -618,6 +618,9 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
__vlan_hwaccel_put_tag(gro_skb, vid);
}
+ if (dev->features & NETIF_F_RXHASH)
+ gro_skb->rxhash = be32_to_cpu(cqe->immed_rss_invalid);
+
skb_record_rx_queue(gro_skb, cq->ring);
napi_gro_frags(&cq->napi);
@@ -651,6 +654,9 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
skb->protocol = eth_type_trans(skb, dev);
skb_record_rx_queue(skb, cq->ring);
+ if (dev->features & NETIF_F_RXHASH)
+ skb->rxhash = be32_to_cpu(cqe->immed_rss_invalid);
+
if (be32_to_cpu(cqe->vlan_my_qpn) &
MLX4_CQE_VLAN_PRESENT_MASK)
__vlan_hwaccel_put_tag(skb, be16_to_cpu(cqe->sl_vid));
@@ -865,6 +871,9 @@ int mlx4_en_config_rss_steer(struct mlx4_en_priv *priv)
(rss_map->base_qpn));
rss_context->default_qpn = cpu_to_be32(rss_map->base_qpn);
rss_context->flags = rss_mask;
+ rss_context->hash_fn = 1;
+ for (i = 0; i < 10; i++)
+ rss_context->rss_key[i] = random32();
if (priv->mdev->profile.udp_rss)
rss_context->base_qpn_udp = rss_context->default_qpn;
--
1.7.7
^ permalink raw reply related
* [PATCH 7/7] mlx4_en: Updating driver version
From: Yevgeny Petrilin @ 2011-10-17 20:18 UTC (permalink / raw)
To: davem; +Cc: netdev, yevgenyp
Driver version updated to 1.5.4.2
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
---
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
index 89fb57c..d62c65c 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
@@ -51,8 +51,8 @@
#include "en_port.h"
#define DRV_NAME "mlx4_en"
-#define DRV_VERSION "1.5.4.1"
-#define DRV_RELDATE "March 2011"
+#define DRV_VERSION "1.5.4.2"
+#define DRV_RELDATE "October 2011"
#define MLX4_EN_MSG_LEVEL (NETIF_MSG_LINK | NETIF_MSG_IFDOWN)
--
1.7.7
^ permalink raw reply related
* Re: BUG in skb_pull with e1000e, PPTP, and L2TP
From: Stephen Hemminger @ 2011-10-17 22:25 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>
On Mon, 17 Oct 2011 17:19:53 -0500
Bradley Peterson <despite@gmail.com> wrote:
> using 3rd
> party pptp and l2tp modules.
More than likely your 3rd party modules are buggy and
can't handle all the possible types of skb layout.
I have seen out of tree code that can't handle non-linear
skb's. You need to take it up with the those developer.
^ permalink raw reply
* Re: BUG in skb_pull with e1000e, PPTP, and L2TP
From: Bradley Peterson @ 2011-10-17 22:30 UTC (permalink / raw)
To: Stephen Hemminger
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: <20111017152531.144b16a1@nehalam.linuxnetplumber.net>
On Mon, Oct 17, 2011 at 5:25 PM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> On Mon, 17 Oct 2011 17:19:53 -0500
> Bradley Peterson <despite@gmail.com> wrote:
>
>> using 3rd
>> party pptp and l2tp modules.
>
> More than likely your 3rd party modules are buggy and
> can't handle all the possible types of skb layout.
> I have seen out of tree code that can't handle non-linear
> skb's. You need to take it up with the those developer.
>
Oh, I should've been more clear -- I am no longer using any 3rd party
modules. That referred to my previous setup with 2.6.22 (I knew
better than to report that). This bug is with 2.6.38 using in-tree
modules.
Bradley Peterson
^ permalink raw reply
* Re: [net-next 0/6 v2][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2011-10-17 22:49 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1318854062-3628-1-git-send-email-jeffrey.t.kirsher@intel.com>
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!
^ 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
* 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: 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: [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: 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 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: [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 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: 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