* Re: kernel panic receiving flooded VXLAN traffic with OVS
From: Jay Vosburgh @ 2014-11-07 21:13 UTC (permalink / raw)
To: Jesse Gross; +Cc: Pravin Shelar, netdev, discuss@openvswitch.org
In-Reply-To: <CAEP_g=_ToXZB14MY4Y+FaYfNj_GHpaX59n3nzDrkALXHBzK1yw@mail.gmail.com>
Jesse Gross <jesse@nicira.com> wrote:
>On Fri, Nov 7, 2014 at 10:34 AM, Jesse Gross <jesse@nicira.com> wrote:
>> On Fri, Nov 7, 2014 at 9:40 AM, Pravin Shelar <pshelar@nicira.com> wrote:
>>> On Thu, Nov 6, 2014 at 5:58 PM, Jay Vosburgh <jay.vosburgh@canonical.com> wrote:
[...]
>>>> I'm not sure if this is an error on the part of the RX / GRO
>>>> processing in assembling the GRO skb, or in how OVS calls skb_segment.
>>>>
>>>
>>> I think this is related skb_segment() issue where it is not able to
>>> handle this type of skb geometry. We need to fix skb-segmentation. I
>>> will investigate it more.
>>
>> One problem that I see is that vxlan_gro_complete() doesn't add
>> SKB_GSO_UDP_TUNNEL to gso_type. This causes us to attempt
>> fragmentation as UDP rather than continuing down to do TCP
>> segmentation. That probably screws up the skb geometry.
>
>I sent out a patch to fix this issue. I'm pretty sure that it is the
>root cause of the originally reported case but I don't have a good way
>to reproduce it so it would be great if you could test it Jay.
I'm having an issue there; when I set up my recreation on
current net-next (3.18-rc2) without your new patch, I get the following
oops when my ovs script does "ovs-vsctl --if-exists del-br br-ex":
[ 18.580812] BUG: unable to handle kernel paging request at 0000000022835df6
[ 18.585532] IP: [<ffffffffa01cc5ec>] ovs_flow_tbl_insert+0xdc/0x1f0 [openvswitch]
[ 18.585532] PGD b016e067 PUD afdf2067 PMD 0
[ 18.585532] Oops: 0002 [#1] SMP
[ 18.585532] Modules linked in: i915 openvswitch libcrc32c video
[ 18.608578] sky2 0000:05:00.0 eth0: Link is up at 1000 Mbps, full duplex, flow control rx
[ 18.585532] drm_kms_helper drm gpio_ich lpc_ich i2c_algo_bit ppdev lp serio_raw coretemp kvm_intel kvm parport_pc parport mac_hid hid_generic usbhid hid psmouse r8169 sky2 mii
[ 18.585532] CPU: 0 PID: 843 Comm: ovs-vswitchd Not tainted 3.18.0-rc2+ #7
[ 18.585532] Hardware name: LENOVO 0829F3U/To be filled by O.E.M., BIOS 90KT15AUS 07/21/2010
[ 18.585532] task: ffff880134af3200 ti: ffff8800b0cc4000 task.ti: ffff8800b0cc4000
[ 18.585532] RIP: 0010:[<ffffffffa01cc5ec>] [<ffffffffa01cc5ec>] ovs_flow_tbl_insert+0xdc/0x1f0 [openvswitch]
[ 18.585532] RSP: 0018:ffff8800b0cc77a8 EFLAGS: 00010212
[ 18.585532] RAX: 00000000432e9568 RBX: ffff880134cb2120 RCX: 0000000001d3d19d
[ 18.585532] RDX: 00000000f4372b69 RSI: 000000006d3fa049 RDI: ffff8800b017c19c
[ 18.585532] RBP: ffff8800b0cc77f8 R08: 0000000022835dc6 R09: 000000000974849a
[ 18.585532] R10: ffffffffa01cc696 R11: 0000000000000004 R12: ffff880134cb2128
[ 18.585532] R13: ffff8800b0cc7850 R14: ffff880134cb2128 R15: ffff8800b2706400
[ 18.585532] FS: 00007f0497d3a980(0000) GS:ffff88013fc00000(0000) knlGS:0000000000000000
[ 18.585532] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 18.585532] CR2: 0000000022835df6 CR3: 00000000b060e000 CR4: 00000000000407f0
[ 18.585532] Stack:
[ 18.585532] ffff8800b017c000 ffff8800b017c000 ffff8800b0cc7a70 ffff8800b017c1c0
[ 18.585532] ffff8800b076b400 ffff8800b017c000 ffff8800b0cc7a70 0000000000000000
[ 18.585532] ffff8800b076b400 ffff880134cb2120 ffff8800b0cc7a38 ffffffffa01c3ed5
[ 18.585532] Call Trace:
[ 18.585532] [<ffffffffa01c3ed5>] ovs_flow_cmd_new+0x175/0x3a0 [openvswitch]
[ 18.585532] [<ffffffff81208688>] ? bh_lru_install+0x178/0x1b0
[ 18.585532] [<ffffffff8137ed83>] ? radix_tree_lookup_slot+0x13/0x30
[ 18.585532] [<ffffffff8165f445>] genl_family_rcv_msg+0x1a5/0x3c0
[ 18.585532] [<ffffffff8165f660>] ? genl_family_rcv_msg+0x3c0/0x3c0
[ 18.585532] [<ffffffff8165f6f1>] genl_rcv_msg+0x91/0xd0
[ 18.585532] [<ffffffff8165d761>] netlink_rcv_skb+0xc1/0xe0
[ 18.585532] [<ffffffff8165dc8c>] genl_rcv+0x2c/0x40
[ 18.585532] [<ffffffff8165ccf6>] netlink_unicast+0xf6/0x200
[ 18.585532] [<ffffffff8165d11d>] netlink_sendmsg+0x31d/0x780
[ 18.585532] [<ffffffff81614173>] sock_sendmsg+0x93/0xd0
[ 18.585532] [<ffffffff8101c375>] ? native_sched_clock+0x35/0x90
[ 18.585532] [<ffffffff8101c3d9>] ? sched_clock+0x9/0x10
[ 18.585532] [<ffffffff810966f5>] ? sched_clock_local+0x25/0x90
[ 18.585532] [<ffffffff81622427>] ? verify_iovec+0x47/0xd0
[ 18.585532] [<ffffffff81614989>] ___sys_sendmsg+0x399/0x3b0
[ 18.585532] [<ffffffff81096cb5>] ? fetch_task_cputime+0x95/0x100
[ 18.585532] [<ffffffff811de4c8>] ? pipe_read+0x1c8/0x2f0
[ 18.585532] [<ffffffff8101c375>] ? native_sched_clock+0x35/0x90
[ 18.585532] [<ffffffff8101c375>] ? native_sched_clock+0x35/0x90
[ 18.585532] [<ffffffff8101c3d9>] ? sched_clock+0x9/0x10
[ 18.585532] [<ffffffff8111cf1c>] ? acct_account_cputime+0x1c/0x20
[ 18.585532] [<ffffffff81096dab>] ? account_user_time+0x8b/0xa0
[ 18.585532] [<ffffffff811f30e5>] ? __fget_light+0x25/0x70
[ 18.585532] [<ffffffff81615082>] __sys_sendmsg+0x42/0x80
[ 18.585532] [<ffffffff816150d2>] SyS_sendmsg+0x12/0x20
[ 18.585532] [<ffffffff817365e4>] tracesys_phase2+0xd8/0xdd
[ 18.585532] Code: 24 e8 4c 8b 45 b0 31 d2 4d 89 b8 48 03 00 00 41 0f b7 4f 28 41 0f b7 77 2a 0f b7 c1 29 ce 49 8d 7c 00 38 c1 fe 02 e8 d4 af 1d e1 <41> 89 40 30 4c 8b 2b 4c 89 c6 4c 89 ef e8 a2 f5 ff ff 8b 43 20
[ 18.585532] RIP [<ffffffffa01cc5ec>] ovs_flow_tbl_insert+0xdc/0x1f0 [openvswitch]
[ 18.585532] RSP <ffff8800b0cc77a8>
[ 18.585532] CR2: 0000000022835df6
[ 18.969812] ---[ end trace fdb3743001087166 ]---
I'll go back to 3.17 to test your patch in the meantime.
-J
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* [PATCH net-next] net: introduce SO_INCOMING_CPU
From: Eric Dumazet @ 2014-11-07 20:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Ying Cai, Willem de Bruijn, Neal Cardwell
From: Eric Dumazet <edumazet@google.com>
Alternative to RPS/RFS is to use hardware support for multi queue.
Then split a set of million of sockets into worker threads, each
one using epoll() to manage events on its own socket pool.
Ideally, we want one thread per RX/TX queue/cpu, but we have no way to
know after accept() or connect() on which queue/cpu a socket is managed.
We normally use one cpu per RX queue (IRQ smp_affinity being properly
set), so remembering on socket structure which cpu delivered last packet
is enough to solve the problem.
After accept(), connect(), or even file descriptor passing around
processes, applications can use :
int cpu;
socklen_t len = sizeof(cpu);
getsockopt(fd, SOL_SOCKET, SO_INCOMING_CPU, &cpu, &len);
And use this information to put the socket into the right silo
for optimal performance, as all networking stack should run
on the appropriate cpu, without need to send IPI (RPS/RFS).
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
arch/alpha/include/uapi/asm/socket.h | 2 ++
arch/avr32/include/uapi/asm/socket.h | 2 ++
arch/cris/include/uapi/asm/socket.h | 2 ++
arch/frv/include/uapi/asm/socket.h | 2 ++
arch/ia64/include/uapi/asm/socket.h | 2 ++
arch/m32r/include/uapi/asm/socket.h | 2 ++
arch/mips/include/uapi/asm/socket.h | 2 ++
arch/mn10300/include/uapi/asm/socket.h | 2 ++
arch/parisc/include/uapi/asm/socket.h | 2 ++
arch/powerpc/include/uapi/asm/socket.h | 2 ++
arch/s390/include/uapi/asm/socket.h | 2 ++
arch/sparc/include/uapi/asm/socket.h | 2 ++
arch/xtensa/include/uapi/asm/socket.h | 2 ++
include/net/sock.h | 12 ++++++++++++
include/uapi/asm-generic/socket.h | 2 ++
net/core/sock.c | 5 +++++
net/ipv4/tcp_ipv4.c | 1 +
net/ipv4/udp.c | 1 +
net/ipv6/tcp_ipv6.c | 1 +
net/ipv6/udp.c | 1 +
net/sctp/ulpqueue.c | 5 +++--
21 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/uapi/asm/socket.h
index 3de1394bcab821984674e89a3ee022cc6dd5f0f2..e2fe0700b3b442bffc1f606b1b8b0bb7759aa157 100644
--- a/arch/alpha/include/uapi/asm/socket.h
+++ b/arch/alpha/include/uapi/asm/socket.h
@@ -87,4 +87,6 @@
#define SO_BPF_EXTENSIONS 48
+#define SO_INCOMING_CPU 49
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/avr32/include/uapi/asm/socket.h b/arch/avr32/include/uapi/asm/socket.h
index 6e6cd159924b1855aa5f1811ad4e4c60b403c431..92121b0f5b989a61c008e0be24030725bab88e36 100644
--- a/arch/avr32/include/uapi/asm/socket.h
+++ b/arch/avr32/include/uapi/asm/socket.h
@@ -80,4 +80,6 @@
#define SO_BPF_EXTENSIONS 48
+#define SO_INCOMING_CPU 49
+
#endif /* _UAPI__ASM_AVR32_SOCKET_H */
diff --git a/arch/cris/include/uapi/asm/socket.h b/arch/cris/include/uapi/asm/socket.h
index ed94e5ed0a238c2750e677ccb806a6bc0a94041a..60f60f5b9b35bd219d7a9834fe5394e8ac5fdbab 100644
--- a/arch/cris/include/uapi/asm/socket.h
+++ b/arch/cris/include/uapi/asm/socket.h
@@ -82,6 +82,8 @@
#define SO_BPF_EXTENSIONS 48
+#define SO_INCOMING_CPU 49
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/frv/include/uapi/asm/socket.h b/arch/frv/include/uapi/asm/socket.h
index ca2c6e6f31c6817780d31a246652adcc9847e373..2c6890209ea60c149bf097c2a1b369519cb8c301 100644
--- a/arch/frv/include/uapi/asm/socket.h
+++ b/arch/frv/include/uapi/asm/socket.h
@@ -80,5 +80,7 @@
#define SO_BPF_EXTENSIONS 48
+#define SO_INCOMING_CPU 49
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/ia64/include/uapi/asm/socket.h b/arch/ia64/include/uapi/asm/socket.h
index a1b49bac7951929127ed08db549218c2c16ccf89..09a93fb566f6c6c6fe29c10c95b931881843d1cd 100644
--- a/arch/ia64/include/uapi/asm/socket.h
+++ b/arch/ia64/include/uapi/asm/socket.h
@@ -89,4 +89,6 @@
#define SO_BPF_EXTENSIONS 48
+#define SO_INCOMING_CPU 49
+
#endif /* _ASM_IA64_SOCKET_H */
diff --git a/arch/m32r/include/uapi/asm/socket.h b/arch/m32r/include/uapi/asm/socket.h
index 6c9a24b3aefa3a4f3048c17a7fa06d97b585ec14..e8589819c2743c6e112b15a245fc3ebd146e6313 100644
--- a/arch/m32r/include/uapi/asm/socket.h
+++ b/arch/m32r/include/uapi/asm/socket.h
@@ -80,4 +80,6 @@
#define SO_BPF_EXTENSIONS 48
+#define SO_INCOMING_CPU 49
+
#endif /* _ASM_M32R_SOCKET_H */
diff --git a/arch/mips/include/uapi/asm/socket.h b/arch/mips/include/uapi/asm/socket.h
index a14baa218c76f14de988ef106bdac5dadc48aceb..2e9ee8c55a103a0337d9f80f71fe9ef28be1154b 100644
--- a/arch/mips/include/uapi/asm/socket.h
+++ b/arch/mips/include/uapi/asm/socket.h
@@ -98,4 +98,6 @@
#define SO_BPF_EXTENSIONS 48
+#define SO_INCOMING_CPU 49
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/mn10300/include/uapi/asm/socket.h b/arch/mn10300/include/uapi/asm/socket.h
index 6aa3ce1854aa9523d46bc28851eddabd59edeb37..f3492e8c9f7009c33e07168df916f7337bef3929 100644
--- a/arch/mn10300/include/uapi/asm/socket.h
+++ b/arch/mn10300/include/uapi/asm/socket.h
@@ -80,4 +80,6 @@
#define SO_BPF_EXTENSIONS 48
+#define SO_INCOMING_CPU 49
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/parisc/include/uapi/asm/socket.h b/arch/parisc/include/uapi/asm/socket.h
index fe35ceacf0e72cad69a43d9b1ce7b8f5ec3da98a..7984a1cab3da980f1f810827967b4b67616eb89b 100644
--- a/arch/parisc/include/uapi/asm/socket.h
+++ b/arch/parisc/include/uapi/asm/socket.h
@@ -79,4 +79,6 @@
#define SO_BPF_EXTENSIONS 0x4029
+#define SO_INCOMING_CPU 0x402A
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/powerpc/include/uapi/asm/socket.h b/arch/powerpc/include/uapi/asm/socket.h
index a9c3e2e18c054a1e952fe33599401de57c6a6544..3474e4ef166df4a573773916b325d0fa9f3b45d0 100644
--- a/arch/powerpc/include/uapi/asm/socket.h
+++ b/arch/powerpc/include/uapi/asm/socket.h
@@ -87,4 +87,6 @@
#define SO_BPF_EXTENSIONS 48
+#define SO_INCOMING_CPU 49
+
#endif /* _ASM_POWERPC_SOCKET_H */
diff --git a/arch/s390/include/uapi/asm/socket.h b/arch/s390/include/uapi/asm/socket.h
index e031332096d7c7b23b5953680289e8f3bcc3b378..8457636c33e1b67a9b7804daa05627839035a8fb 100644
--- a/arch/s390/include/uapi/asm/socket.h
+++ b/arch/s390/include/uapi/asm/socket.h
@@ -86,4 +86,6 @@
#define SO_BPF_EXTENSIONS 48
+#define SO_INCOMING_CPU 49
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/sparc/include/uapi/asm/socket.h b/arch/sparc/include/uapi/asm/socket.h
index 54d9608681b6947ae25dab008f808841d96125c0..4a8003a9416348006cfa85d5bcdf7553c8d23958 100644
--- a/arch/sparc/include/uapi/asm/socket.h
+++ b/arch/sparc/include/uapi/asm/socket.h
@@ -76,6 +76,8 @@
#define SO_BPF_EXTENSIONS 0x0032
+#define SO_INCOMING_CPU 0x0033
+
/* Security levels - as per NRL IPv6 - don't actually do anything */
#define SO_SECURITY_AUTHENTICATION 0x5001
#define SO_SECURITY_ENCRYPTION_TRANSPORT 0x5002
diff --git a/arch/xtensa/include/uapi/asm/socket.h b/arch/xtensa/include/uapi/asm/socket.h
index 39acec0cf0b1d500c1c40f9b523ef3a9a142c2f1..c46f6a696849c6f7f8a34b2cc522b48e04b17380 100644
--- a/arch/xtensa/include/uapi/asm/socket.h
+++ b/arch/xtensa/include/uapi/asm/socket.h
@@ -91,4 +91,6 @@
#define SO_BPF_EXTENSIONS 48
+#define SO_INCOMING_CPU 49
+
#endif /* _XTENSA_SOCKET_H */
diff --git a/include/net/sock.h b/include/net/sock.h
index 6767d75ecb17693eb59a99b8218da4319854ccc0..7789b59c0c400eb99f65d1f0e03cd9773664cf93 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -273,6 +273,7 @@ struct cg_proto;
* @sk_rcvtimeo: %SO_RCVTIMEO setting
* @sk_sndtimeo: %SO_SNDTIMEO setting
* @sk_rxhash: flow hash received from netif layer
+ * @sk_incoming_cpu: record cpu processing incoming packets
* @sk_txhash: computed flow hash for use on transmit
* @sk_filter: socket filtering instructions
* @sk_protinfo: private area, net family specific, when not using slab
@@ -350,6 +351,12 @@ struct sock {
#ifdef CONFIG_RPS
__u32 sk_rxhash;
#endif
+ u16 sk_incoming_cpu;
+ /* 16bit hole
+ * Warned : sk_incoming_cpu can be set from softirq,
+ * Do not use this hole without fully understanding possible issues.
+ */
+
__u32 sk_txhash;
#ifdef CONFIG_NET_RX_BUSY_POLL
unsigned int sk_napi_id;
@@ -833,6 +840,11 @@ static inline int sk_backlog_rcv(struct sock *sk, struct sk_buff *skb)
return sk->sk_backlog_rcv(sk, skb);
}
+static inline void sk_incoming_cpu_update(struct sock *sk)
+{
+ sk->sk_incoming_cpu = raw_smp_processor_id();
+}
+
static inline void sock_rps_record_flow_hash(__u32 hash)
{
#ifdef CONFIG_RPS
diff --git a/include/uapi/asm-generic/socket.h b/include/uapi/asm-generic/socket.h
index ea0796bdcf88404ef0f127eb6e64ba00c16ea856..f541ccefd4acbeb4ad757be9dbf4b67f204bf21d 100644
--- a/include/uapi/asm-generic/socket.h
+++ b/include/uapi/asm-generic/socket.h
@@ -82,4 +82,6 @@
#define SO_BPF_EXTENSIONS 48
+#define SO_INCOMING_CPU 49
+
#endif /* __ASM_GENERIC_SOCKET_H */
diff --git a/net/core/sock.c b/net/core/sock.c
index ac56dd06c306f3712e57ce8e4724c79565589499..0725cf0cb685787b2122606437da53299fb24621 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1213,6 +1213,10 @@ int sock_getsockopt(struct socket *sock, int level, int optname,
v.val = sk->sk_max_pacing_rate;
break;
+ case SO_INCOMING_CPU:
+ v.val = sk->sk_incoming_cpu;
+ break;
+
default:
return -ENOPROTOOPT;
}
@@ -1517,6 +1521,7 @@ struct sock *sk_clone_lock(const struct sock *sk, const gfp_t priority)
newsk->sk_err = 0;
newsk->sk_priority = 0;
+ newsk->sk_incoming_cpu = raw_smp_processor_id();
/*
* Before updating sk_refcnt, we must commit prior changes to memory
* (Documentation/RCU/rculist_nulls.txt for details)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 9c7d7621466b1241f404a5ca11de809dcff2d02a..3893f51972f28271a6d27a763c05495c5c2554f7 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1662,6 +1662,7 @@ process:
goto discard_and_relse;
sk_mark_napi_id(sk, skb);
+ sk_incoming_cpu_update(sk);
skb->dev = NULL;
bh_lock_sock_nested(sk);
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index df19027f44f3d6fbe13dec78d3b085968dbf2329..f52b6081158e87caa5df32e8e5d27dbf314a01b1 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1445,6 +1445,7 @@ static int __udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
if (inet_sk(sk)->inet_daddr) {
sock_rps_save_rxhash(sk, skb);
sk_mark_napi_id(sk, skb);
+ sk_incoming_cpu_update(sk);
}
rc = sock_queue_rcv_skb(sk, skb);
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index ace29b60813cf8a1d7182ad2262cbcbd21810fa7..ac40d23204b5e55da5172c80dafd1d4854b370d5 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1455,6 +1455,7 @@ process:
goto discard_and_relse;
sk_mark_napi_id(sk, skb);
+ sk_incoming_cpu_update(sk);
skb->dev = NULL;
bh_lock_sock_nested(sk);
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 9b6809232b178c16d699ce3d152196b8c4cb096b..0125ca3daf47a4a3333e7462a11550d3e2f96875 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -577,6 +577,7 @@ static int __udpv6_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
if (!ipv6_addr_any(&sk->sk_v6_daddr)) {
sock_rps_save_rxhash(sk, skb);
sk_mark_napi_id(sk, skb);
+ sk_incoming_cpu_update(sk);
}
rc = sock_queue_rcv_skb(sk, skb);
diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c
index d49dc2ed30adb97a809eb37902b9956c366a2862..ce469d648ffbe166f9ae1c5650f481256f31a7f8 100644
--- a/net/sctp/ulpqueue.c
+++ b/net/sctp/ulpqueue.c
@@ -205,9 +205,10 @@ int sctp_ulpq_tail_event(struct sctp_ulpq *ulpq, struct sctp_ulpevent *event)
if (sock_flag(sk, SOCK_DEAD) || (sk->sk_shutdown & RCV_SHUTDOWN))
goto out_free;
- if (!sctp_ulpevent_is_notification(event))
+ if (!sctp_ulpevent_is_notification(event)) {
sk_mark_napi_id(sk, skb);
-
+ sk_incoming_cpu_update(sk);
+ }
/* Check if the user wishes to receive this event. */
if (!sctp_ulpevent_is_enabled(event, &sctp_sk(sk)->subscribe))
goto out_free;
^ permalink raw reply related
* Re: [PATCH v4 net-next] udp: Increment UDP_MIB_IGNOREDMULTI for arriving unmatched multicasts
From: David Miller @ 2014-11-07 20:46 UTC (permalink / raw)
To: raj; +Cc: netdev
In-Reply-To: <20141106183754.8A52829007D9@tardy>
From: raj@tardy.usa.hp.com (Rick Jones)
Date: Thu, 6 Nov 2014 10:37:54 -0800 (PST)
> From: Rick Jones <rick.jones2@hp.com>
>
> As NIC multicast filtering isn't perfect, and some platforms are
> quite content to spew broadcasts, we should not trigger an event
> for skb:kfree_skb when we do not have a match for such an incoming
> datagram. We do though want to avoid sweeping the matter under the
> rug entirely, so increment a suitable statistic.
>
> This incorporates feedback from David L. Stevens, Karl Neiss and Eric
> Dumazet.
>
> V3 - use bool per David Miller
>
> Signed-off-by: Rick Jones <rick.jones2@hp.com>
Applied, thanks Rick.
^ permalink raw reply
* pull request: wireless-next 2014-11-07
From: John W. Linville @ 2014-11-07 20:30 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
[-- Attachment #1: Type: text/plain, Size: 41739 bytes --]
Dave,
Please pull this batch of updates intended for the 3.19 stream!
For the mac80211 bits, Johannes says:
"This relatively large batch of changes is comprised of the following:
* large mac80211-hwsim changes from Ben, Jukka and a bit myself
* OCB/WAVE/11p support from Rostislav on behalf of the Czech Technical
University in Prague and Volkswagen Group Research
* minstrel VHT work from Karl
* more CSA work from Luca
* WMM admission control support in mac80211 (myself)
* various smaller fixes, spelling corrections, and minor API additions"
For the Bluetooth bits, Johan says:
"Here's the first bluetooth-next pull request for 3.19. The vast majority
of patches are for ieee802154 from Alexander Aring with various fixes
and cleanups. There are also several LE/SMP fixes as well as improved
support for handling LE devices that have lost their pairing information
(the patches from Alfonso). Jukka provides a couple of stability fixes
for 6lowpan and Szymon conformance fixes for RFCOMM. For the HCI drivers
we have one new USB ID for an Acer controller as well as a reset
handling fix for H5."
For the Atheros bits, Kalle says:
"Major changes are:
o ethtool support (Ben)
o print dev string prefix with debug hex buffers dump (Michal)
o debugfs file to read calibration data from the firmware verification
purposes (me)
o fix fw_stats debugfs file, now results are more reliable (Michal)
o firmware crash counters via debugfs (Ben&me)
o various tracing points to debug firmware (Rajkumar)
o make it possible to provide firmware calibration data via a file (me)
And we have quite a lot of smaller fixes and clean up."
For the iwlwifi bits, Emmanuel says:
"The big new thing here is netdetect which allows the
firmware to wake up the platform when a specific network
is detected. Along with that I have fixes for d3 operation.
The usual amount of rate scaling stuff - we now support STBC.
The other commit that stands out is Johannes's work on
devcoredump. He basically starts to use the standard
infrastructure he built."
Along with that are the usual sort of updates and such for ath9k,
brcmfmac, wil6210, and a handful of other bits here and there...
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 61ed53deb1c6a4386d8710dbbfcee8779c381931:
Merge tag 'ntb-3.18' of git://github.com/jonmason/ntb (2014-10-19 12:58:22 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git tags/master-2014-11-04
for you to fetch changes up to bf515fb11ab539c76d04f0e3c5216ed41f41d81f:
Merge tag 'mac80211-next-for-john-2014-11-04' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next (2014-11-04 16:18:12 -0500)
----------------------------------------------------------------
Alexander Aring (103):
ieee802154: 6lowpan: fix byteorder for frag tag
ieee802154: reassembly: fix tag byteorder
ieee802154: 6lowpan: fix sign of errno return val
at86rf230: fix errno on tx timeout handling
at86rf230: add missing error handling
at86rf230: correct aret lifs and sifs handling
at86rf230: correct at86rf2xx lifs timings
at86rf230: squash unnecessary dereferencing
at86rf230: add missing enable_irq
at86rf230: fix race condition
at86rf230: fix enable_irq handling on async spi
at86rf230: remove unnecessary print of async error
ieee802154: 6lowpan: improve packet registration
ieee802154: 6lowpan: add RTNL assertion
ieee802154: mac802154: remove FSF address
ieee802154: ieee802154_dev: fix align typo
mac802154: fix typo IEEE802515 to IEEE802154
ieee802154: wpan-phy: change to __aligned(size)
ieee802154: wpan-phy: use blank line after function
ieee802154: wpan-class: fix trailing semicolon
mac802154: move ieee802154_dev.c to main.c
mac802154: move mac802154.h to ieee802154_i.h
mac802154: move wpan.c to iface.c
ieee802154: move wpan-phy.h to cfg802154.h
ieee802154: move wpan-class.c to core.c
ieee802154: move ieee802154 header
MAINTAINERS: add missing headers in 802.15.4
ieee802154: remove fakehard driver
ieee802154: rename ieee802154_dev to ieee802154_hw
mac802154: rename mac802154_priv to ieee802154_local
mac802154: rename mac802154_sub_if_data
mac802154: rename hw subif_data variable to local
mac802154: rename sdata slaves and slaves_mtx
mac802154: introduce hw_to_local function
mac802154: introduce IEEE802154_DEV_TO_SUB_IF
mac802154: rename dev_workqueue to workqueue
mac802154: remove ieee802154_addr from driver_ops
mac802154: tx: move xmit callback to tx file
mac802154: tx: remove kmalloc in xmit hotpath
mac802154: tx: squash multiple dereferencing
mac802154: tx: remove xmit channel context switch
mac802154: add netdev qeue helpers
mac802154: tx: use queue helpers in xmit worker
mac802154: tx: fix error handling while xmit
mac802154: tx: add support for xmit_async callback
mac802154: tx: don't allow if down while sync tx
mac802154: tx: use netdev print helpers
mac802154: tx: cleanup crc calculation
mac802154: tx: move stats tx increment
mac802154: tx: change naming convention
mac802154: tx: add comment at sync xmit callback
at86rf230: asynchronous xmit handling
mac802154: tx: make worker information static
mac802154: tx: use put_unaligned_le16 for copy crc
ieee802154: drivers: use dev_alloc_skb
mac802154: rx: use tasklet instead workqueue
mac802154: rx: document ieee802154_rx() context requirement
mac802154: rx: move receive handling into rx.c
mac802154: tx: remove monitor receive while xmit
mac802154: rx: rename remove mac802154_subif_rx
mac802154: rx: move skb->protocol setting
mac802154: rx: add CHECKSUM_UNNECESSARY
mac802154: rx: add monitor pkt_type information
mac802154: rx: move skb_reset_mac_header
mac802154: rx: move rcu locking
ieee802154: add valid psdu length helper
at86rf230: use ieee802154_is_valid_psdu_len helper
at86rf230: improve receive handling
mac802154: rx: change naming convention
mac802154: monitor: merge into iface implementation
mac802154: main: move open and close into iface
mac802154: declare struct ieee802154_ops as const
mac802154: ops: declare channel and page as u8
mac802154: introduce driver-ops header
mac802154: use driver-ops function wrappers
mac802154: remove might_sleep from driver layer
mac802154: remove driver ops in wpan-phy
mac802154: rework sdata state change to running
mac802154: rename running to started
mac802154: move local started handling
mac802154: add synchronization handling
mac802154: iface: remove assign to zero
mac802154: remove channel attributes from sdata
mac802154: move mac_params functions into mac_cmd
mac802154: cleanup open count handling
ieee802154: introduce sysfs file
mac802154: main: remove unnecessary include
mac802154: remove tab after define
mac802154: add IEEE802154_HW_ARET hw flag
mac802154: add hardware address filter flag
mac802154: add support for promiscuous mode
at86rf230: add support for promiscuous mode
mac802154: separate omit tx/rx flags
mac802154: rx: remove unnecessary parameter
mac802154: rx: simplify crc receive handling
mac802154: rx: add software checksum filtering check
mac802154: rx: remove override pkt_type set to PACKET_HOST
mac802154: rx: use netif_receive_skb
mac802154: rx: add rx stats incrementation
mac802154: rx: monitor receive cleanup
mac802154: rx: add error handling after skb_clone
at86rf230: deliver with checksum
mac802154: add basic support for monitor
Alfonso Acosta (4):
Bluetooth: Refactor arguments of mgmt_device_connected
Bluetooth: Include ADV_IND report in Device Connected event
Bluetooth: Remove redundant check on hci_conn's device class
Bluetooth: Defer connection-parameter removal when unpairing
Anantha Krishnan (1):
Bluetooth: Add support for Acer [0489:e078]
Andrei Otcheretianski (2):
mac80211: export IE splitting function
mac80211: increase U-APSD max service period length
Arend van Spriel (5):
brcmfmac: show firmware error as string in debug message
brcmfmac: remove unused defintion
brcmfmac: do not use firmware error code in driver
brcmsmac: fix statistic counter update function
brcmsmac: expose 802.11 core statistics in debugfs
Arik Nemtsov (5):
mac80211: fix network header breakage during encryption
mac80211: expose TDLS-initiator value to low level driver
mac80211: add stations in order to the station list
mac80211: expose API allowing station iteration
iwlwifi: mvm: remove mvm argument from get_queues_mask
Avinash Patil (1):
mwifiex: channel statistics support for mwifiex
Bartosz Markowski (1):
ath10k: advertise all possible firmware(-api) files
Ben Greear (16):
ath10k: add firmware crash counters
ath10k: support ethtool stats
ath10k: use 64-bit vdev map
mac80211_hwsim: fix memory leak on netlink TX failure
mac80211_hwsim: fix typo, remove unnecessary goto
mac80211-hwsim: add ethtool stats support
mac80211-hwsim: support destroying radio by name
cfg80211: support creating wiphy with suggested name
mac80211: allow creating wiphy devices with suggested name
mac80211-hwsim: support creating radios with specific name
mac80211: support creating wiphy w/out creating wlanX
mac80211-hwsim: support creating wiphy w/out creating wlanX
cfg80211: support configuring vif mac addr on create
mac80211: support creating vifs with specified mac address
mac80211-hwsim: add frequency attribute to netlink pkts
mac80211-hwsim: support SGI-20
Dan Carpenter (3):
ipw2x00: remove unused ->ibss_dfs pointer
ipw2x00: clean up a condition
Bluetooth: 6lowpan: use after free in disconnect_devices()
David Spinadel (1):
iwlwifi: mvm: fix scan condition iterator
Eliad Peller (2):
iwlwifi: mvm: unref SCAN ref on scan completion
mac80211: replace restart_complete() with reconfig_complete()
Emmanuel Grumbach (13):
iwlwifi: configure the LTR
iwlwifi: mvm: BT Coex - update the MPLUT Boost register value
iwlwifi: mvm: BT coex - fix BT prio for probe requests
iwlwifi: dvm: drop non VO frames when flushing
Revert "iwlwifi: mvm: treat EAPOLs like mgmt frames wrt rate"
iwlwifi: pcie: fix polling in various places
mac80211: don't flush when probing the AP
Merge remote-tracking branch 'iwlwifi-fixes/master' into iwlwifi-next
iwlwifi: mvm: remove unneeded NULL pointer check
iwlwifi: pcie: warn if extern fw_debug buffer failed
iwlwifi: pcie: fix recovery from ARC reset in WoWLAN
iwlwifi: mvm: BT Coex - move BT_ANTENNA_COUPLING_THRESHOLD to constants
iwlwifi: mvm: BT Coex - make the multiprio lut a constant
Eran Harary (2):
iwlwifi: always run the secured flow for family 8000
ieee80211: add "max length of AMPDU" enum for VHT
Eyal Shapira (3):
iwlwifi: rs: option to easily disable Tx MIMO
iwlwifi: enable STBC support for 8000 chips
iwlwifi: mvm: rs: add Tx STBC support
Fabian Frederick (5):
net: rfkill: kernel-doc warning fixes
mac80211: directly return ieee80211_vif_use_reserved_context()
mac80211: remove unnecessary null test before debugfs_remove()
Bluetooth: fix shadow warning in hci_disconnect()
cfg80211: fix set but not used warning in nl80211_channel_switch()
Felix Fietkau (11):
ath9k_hw: make support for PC-OEM cards optional
ath9k_hw: remove support for UB124 tx gain table
ath9k: fix processing RXORN interrupts
ath9k: clean up debugfs print of reset causes
ath9k: restart hardware after noise floor calibration failure
ath9k_hw: do not run NF and periodic calibration at the same time
ath9k_hw: start initial NF calibration after PA calibration on <AR9003
ath9k: add support for endian swap of eeprom from platform data
ath9k: allow disabling bands via platform data
ath9k: use a random MAC address if the EEPROM address is invalid
mac80211: add support for driver tx power reporting
Gregory Greenman (1):
iwlwifi: allow to restrict Tx aggregation size per-device
Haim Dreyfuss (1):
iwlwifi: mvm: Add tx power condition to bss_info_changed_ap_ibss
Hante Meuleman (13):
brcmfmac: Add wowl support for USB devices.
brcmfmac: Add wowl support for SDIO devices.
brcmfmac: Add wowl patterns support.
brcmfmac: (clean) Remove usb_rdl.h as it is not needed.
brcmfmac: (clean) Remove packet filter configuration.
brcmfmac: (clean) Move tracepoint related function.
brcmfmac: (clean) Rename files dhd_dbg to debug
brcmfmac: (clean) Rename dhd_bus.h in bus.h
brcmfmac: (clean) Rename dhd_common.c in common.c
brcmfmac: (clean) Rename files wl_cfg80211 to cfg80211
brcmfmac: (clean) Rename sdio related files.
brcmfmac: (clean) Rename sdio related files.
brcmfmac: (clean) Move sdio related function.
Henning Rogge (2):
cfg80211: add ops to query mesh proxy path table
mac80211: implement cfg80211_ops to query mesh proxy path table
Janusz Dziedzic (2):
ath10k: don't create bssid peer for ibss
ath10k: fix WMI scan command length
Joe Perches (3):
ath: change logging functions to return void
iwlwifi: dvm: Fix probable mask then right shift defect
carl9170: Convert byte_rev_table uses to bitrev8
Johan Hedberg (6):
Bluetooth: Pass only crypto context to SMP crypto functions
Bluetooth: Add skeleton for SMP self-tests
Bluetooth: Add self-tests for SMP crypto functions
Bluetooth: Revert SMP self-test patches
Bluetooth: Fix LE connection timeout deadlock
Bluetooth: Fix check for direct advertising
Johannes Berg (14):
mac80211: fix change flags variable signedness
Merge branch 'mac80211' into mac80211-next
cfg80211: make WMM TSPEC support flag an nl80211 feature flag
mac80211: sanity check CW_min/CW_max towards driver
mac80211: add WMM admission control support
mac80211: don't remove tainted keys after not programming
iwlwifi: mvm: improve MCS rate warning
iwlwifi: mvm: flush queues without mutex held
iwlwifi: mvm: port to devcoredump framework
cfg80211: fix integer signedness in chandef_primary_freqs()
mac80211-hwsim: remove spurious newline
mac80211-hwsim: add missing policy entries
cfg80211: avoid using default in interface type switch
mac80211: handle RIC data element in reassociation request
John W. Linville (4):
Merge tag 'for-linville-20141024' of git://github.com/kvalo/ath
Merge tag 'iwlwifi-next-for-john-2014-10-29' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth-next
Merge tag 'mac80211-next-for-john-2014-11-04' of git://git.kernel.org/.../jberg/mac80211-next
Jouni Malinen (2):
cfg80211: Convert del_station() callback to use a param struct
cfg80211: Specify frame and reason code for NL80211_CMD_DEL_STATION
Jukka Rissanen (7):
mac80211-hwsim: Add support for HWSIM_ATTR_DESTROY_RADIO_ON_CLOSE
Bluetooth: 6lowpan: Converting rwlocks to use RCU
Bluetooth: 6lowpan: Fix lockdep splats
Bluetooth: Wrong style spin lock used
mac80211-hwsim: Rename CREATE and DESTROY radio to NEW and DEL radio
mac80211-hwsim: Provide multicast event for HWSIM_CMD_NEW_RADIO
mac80211-hwsim: Provide multicast event for HWSIM_CMD_DEL_RADIO
Julien Catalano (1):
trivial: net/mac802154: Fix Kconfig typo
Kalle Valo (6):
ath10k: don't enable interrupts for the diagnostic window
ath10k: add diag_read() to hif ops
ath10k: add cal_data debugfs file
ath10k: add back enum ath10k_bus
ath10k: refactor ath10k_init_download_firmware()
ath10k: retrieve calibration data from file
Karl Beldan (10):
mac80211: minstrel_ht: fix MCS_GROUP_RATES usage
cfg80211: set the rates mask in connection probes over specified freq
mac80211: fix typo in starting baserate for rts_cts_rate_idx
mac80211: minstrels: fix buffer overflow in HT debugfs rc_stats
mac80211: minstrel_ht: Increase the range of handled rate indexes
mac80211: minstrel_ht: macros adjustments for future VHT_GROUPs
mac80211: minstrel_ht: include type (cck/ht) in rates flag
mac80211: minstrel_ht: add basic support for VHT rates <= 3SS@80MHz
mac80211: minstrel_ht: use group flags instead of index to display rates
mac80211: minstrel_ht: do not always skip ht rates vht_only is true
Larry Finger (1):
rtlwifi: rtl8821ae: Remove extra semicolons
Li RongQing (1):
Bluetooth: 6lowpan: remove unnecessary codes in give_skb_to_upper
Liad Kaufman (2):
mac80211: fix warning on htmldocs for last_tdls_pkt_time
iwlwifi: 8000: fix string given to MODULE_FIRMWARE
Loic Poulain (1):
Bluetooth: HCI H5 peer reset detection
Lorenzo Bianconi (2):
ath9k: do not overwrite AR_PHY_RADAR_1 MSB
ath9k: set pulse_rssi threshold to 15
Luciano Coelho (15):
mac80211: return the vif's chandef in ieee80211_cfg_get_channel()
nl80211: sanity check the channel switch counter value
mac80211: add device_timestamp to the ieee80211_channel_switch struct
mac80211: add extended channel switching capability if the driver supports CSA
mac80211: add pre_channel_switch driver operation
mac80211: add post_channel_switch driver operation
mac80211: wait for the first beacon on the new channel after CSA
mac80211: allow channel switch with multiple channel contexts
iwlwifi: mvm: hold the rtnl when resuming from a d3 test
iwlwifi: mvm: split wowlan handling out of the main suspend function
iwlwifi: mvm: move the check if associated outside of the iterator for wowlan
iwlwifi: mvm: spin off a function to start scan offload
iwlwifi: mvm: add debugfs entry to configure netdetect SSIDs
iwlwifi: mvm: change the iwl_mvm_d3_iface_iterator into a generic function
iwlwifi: mvm: remove unnecessary includes in tt.c
Marcel Holtmann (1):
Bluetooth: Clear LE white list when resetting controller
Martin Townsend (6):
6lowpan: Use skb_cow in IPHC decompression.
Bluetooth: Fix missing channel unlock in l2cap_le_credits
6lowpan: remove skb_deliver from IPHC
6lowpan: fix process_data return values
bluetooth:6lowpan: use consume_skb when packet processed successfully
ieee802154: 6lowpan: rename process_data and lowpan_process_data
Matti Gottlieb (1):
iwlwifi: mvm: ROC - bug fixes around time events and locking
Max Stepanov (1):
iwlwifi: mvm: add MVM_FW_BCAST_FILTER_PASS_ALL option
Michal Kazior (27):
ath10k: workaround fw beaconing bug
ath10k: fix tx/rx chainmask init
ath10k: remove unused pdev_set_channel command
ath10k: deduplicate wmi_channel code
ath10k: deduplicate host mem chunk code
ath10k: relocate wmi attach/deatch functions
ath10k: deduplicate wmi service ready logic
ath10k: clean up phyerr code
ath10k: unify wmi event function names
ath10k: re-work scan start command building
ath10k: print wmi version info
ath10k: dump hex bytes with dev string prefix
ath10k: add debug dump for pci rx
ath10k: split wmi stats parsing
ath10k: rename fw_stats related stuff
ath10k: request fw_stats once on open
ath10k: fix fw stats processing
ath10k: warn on unhandled htt events
mac80211: enable DFS with channel contexts
ath10k: clean up assoc code
ath10k: skip some commands on reassoc
ath10k: clean up sta auth/assoc code
ath10k: simplify computation of mgmt rx band
ath10k: use bss_info as txpower source
ath10k: re-disable interrupts after target init
ath10k: mask/unmask msi fw irq
ath10k: split ce pipe init/alloc further
Rafał Miłecki (1):
bcma: fill core details for every device
Rajkumar Manoharan (6):
ath10k: add support to configure pktlog filter
ath10k: add tracing for ath10k_htt_pktlog
ath10k: add tracing for rx descriptor
ath10k: add tracing for tx info
ath10k: add tracing for frame transmission
ath10k: fix kernel panic while shutting down AP
Rostislav Lisovy (2):
cfg80211: 802.11p OCB mode handling
mac80211: 802.11p OCB mode support
Simon Vincent (2):
ieee802154: 6lowpan: Drop PACKET_OTHERHOST skbs in 6lowpan
ieee802154: mrf24j40: Add support for MRF24J40MC
Stanislaw Gruszka (1):
rt2x00: tune multi-registers I/O timeout
Stephen Hemminger (2):
Bluetooth: spelling fixes
mac80211: fix spelling errors
Sujith Manoharan (25):
ath9k: Use sta_state() callback
ath9k: Enable multi-channel properly
ath9k: Process beacons properly
ath9k: Unify reset API
ath9k: Set ATH_OP_HW_RESET before HW reset
ath9k: Disable beacon tasklet during reset
ath9k: Clear NoA schedule properly
ath9k: Use configurable timeout for flush
ath9k: Fix MCC flush timeout
ath9k: Fix offchannel flush timeout
ath9k: Check for pending frames properly
ath9k: Send AUTHORIZED event only for station mode
ath9k: Fix address management
ath9k: Add a function to check for an active GO
ath9k: Check for active GO in mgd_prepare_tx()
ath9k: Use a helper function for offchannel NoA
ath9k: Use a helper function to set NoA
ath9k: Use a helper function for bmiss
ath9k: Fix RoC expiration
ath9k: Send oneshot NoA
ath9k: Fix HW scan abort
ath9k: Improve flush() in mcc mode
ath9k: Do not start BA when scanning
ath9k: Update AR9580 initvals
ath9k: Update AR955x initvals
Szymon Janc (2):
Bluetooth: Fix RFCOMM NSC response
Bluetooth: Improve RFCOMM __test_pf macro robustness
Varka Bhadram (1):
MAINTAINERS: add cc2520 driver maintainer
Vladimir Kondratiev (5):
wil6210: do not attempt FW recovery if interface is down
wil6210: reset flow updates
wil6210: prevent double disconnect command issuing
wil6210: improve dmesg for fw error handling
wil6210: Add support for large packets
Xinming Hu (1):
mwifiex: add cfg80211 dump_survey handler
MAINTAINERS | 15 +
drivers/bcma/bcma_private.h | 1 +
drivers/bcma/main.c | 9 +-
drivers/bcma/scan.c | 1 +
drivers/bluetooth/ath3k.c | 2 +
drivers/bluetooth/btusb.c | 1 +
drivers/bluetooth/hci_h5.c | 34 +
drivers/net/ieee802154/Kconfig | 10 -
drivers/net/ieee802154/Makefile | 1 -
drivers/net/ieee802154/at86rf230.c | 392 +++----
drivers/net/ieee802154/cc2520.c | 70 +-
drivers/net/ieee802154/fakehard.c | 427 --------
drivers/net/ieee802154/fakelb.c | 92 +-
drivers/net/ieee802154/mrf24j40.c | 104 +-
drivers/net/wireless/ath/ath.h | 2 +-
drivers/net/wireless/ath/ath10k/ce.c | 83 +-
drivers/net/wireless/ath/ath10k/ce.h | 21 +-
drivers/net/wireless/ath/ath10k/core.c | 111 +-
drivers/net/wireless/ath/ath10k/core.h | 82 +-
drivers/net/wireless/ath/ath10k/debug.c | 891 ++++++++++++----
drivers/net/wireless/ath/ath10k/debug.h | 40 +-
drivers/net/wireless/ath/ath10k/hif.h | 10 +
drivers/net/wireless/ath/ath10k/htt.h | 2 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 20 +-
drivers/net/wireless/ath/ath10k/htt_tx.c | 2 +
drivers/net/wireless/ath/ath10k/hw.h | 17 +-
drivers/net/wireless/ath/ath10k/mac.c | 517 +++++----
drivers/net/wireless/ath/ath10k/mac.h | 1 +
drivers/net/wireless/ath/ath10k/pci.c | 203 ++--
drivers/net/wireless/ath/ath10k/spectral.c | 34 +-
drivers/net/wireless/ath/ath10k/spectral.h | 8 +-
drivers/net/wireless/ath/ath10k/trace.h | 163 +++
drivers/net/wireless/ath/ath10k/txrx.c | 1 +
drivers/net/wireless/ath/ath10k/wmi.c | 1116 +++++++++++---------
drivers/net/wireless/ath/ath10k/wmi.h | 273 ++---
drivers/net/wireless/ath/ath6kl/cfg80211.c | 4 +-
drivers/net/wireless/ath/ath6kl/common.h | 2 +-
drivers/net/wireless/ath/ath6kl/debug.c | 28 +-
drivers/net/wireless/ath/ath6kl/debug.h | 13 +-
drivers/net/wireless/ath/ath9k/Kconfig | 5 +
drivers/net/wireless/ath/ath9k/Makefile | 3 +-
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 7 +-
drivers/net/wireless/ath/ath9k/ar9002_calib.c | 42 +-
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 11 +-
drivers/net/wireless/ath/ath9k/ar9003_hw.c | 3 -
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 7 +-
drivers/net/wireless/ath/ath9k/ar9003_rtt.h | 36 +
.../net/wireless/ath/ath9k/ar955x_1p0_initvals.h | 8 +-
.../net/wireless/ath/ath9k/ar9580_1p0_initvals.h | 144 ++-
drivers/net/wireless/ath/ath9k/ath9k.h | 15 +-
drivers/net/wireless/ath/ath9k/calib.c | 6 +-
drivers/net/wireless/ath/ath9k/calib.h | 2 +-
drivers/net/wireless/ath/ath9k/channel.c | 319 ++++--
drivers/net/wireless/ath/ath9k/debug.c | 49 +-
drivers/net/wireless/ath/ath9k/debug.h | 1 +
drivers/net/wireless/ath/ath9k/eeprom_def.c | 31 +-
drivers/net/wireless/ath/ath9k/hw-ops.h | 7 +-
drivers/net/wireless/ath/ath9k/hw.c | 43 +-
drivers/net/wireless/ath/ath9k/hw.h | 26 +-
drivers/net/wireless/ath/ath9k/init.c | 7 +
drivers/net/wireless/ath/ath9k/link.c | 12 +-
drivers/net/wireless/ath/ath9k/main.c | 200 +++-
drivers/net/wireless/ath/ath9k/pci.c | 6 +
drivers/net/wireless/ath/ath9k/reg.h | 33 +-
drivers/net/wireless/ath/ath9k/tx99.c | 4 +-
drivers/net/wireless/ath/carl9170/phy.c | 4 +-
drivers/net/wireless/ath/wil6210/cfg80211.c | 5 +-
drivers/net/wireless/ath/wil6210/main.c | 95 +-
drivers/net/wireless/ath/wil6210/netdev.c | 2 +-
drivers/net/wireless/ath/wil6210/txrx.c | 7 +-
drivers/net/wireless/ath/wil6210/txrx.h | 4 +-
drivers/net/wireless/ath/wil6210/wil6210.h | 13 +-
drivers/net/wireless/ath/wil6210/wmi.c | 4 +-
drivers/net/wireless/brcm80211/brcmfmac/Makefile | 10 +-
drivers/net/wireless/brcm80211/brcmfmac/bcdc.c | 6 +-
drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 51 +-
drivers/net/wireless/brcm80211/brcmfmac/btcoex.c | 6 +-
.../brcm80211/brcmfmac/{dhd_bus.h => bus.h} | 11 +-
.../brcmfmac/{wl_cfg80211.c => cfg80211.c} | 85 +-
.../brcmfmac/{wl_cfg80211.h => cfg80211.h} | 9 +-
drivers/net/wireless/brcm80211/brcmfmac/chip.c | 2 +-
drivers/net/wireless/brcm80211/brcmfmac/common.c | 168 +++
.../net/wireless/brcm80211/brcmfmac/commonring.c | 2 +-
.../brcm80211/brcmfmac/{dhd_linux.c => core.c} | 8 +-
.../wireless/brcm80211/brcmfmac/{dhd.h => core.h} | 7 +-
.../brcm80211/brcmfmac/{dhd_dbg.c => debug.c} | 6 +-
.../brcm80211/brcmfmac/{dhd_dbg.h => debug.h} | 6 +-
.../net/wireless/brcm80211/brcmfmac/dhd_common.c | 400 -------
drivers/net/wireless/brcm80211/brcmfmac/feature.c | 11 +-
drivers/net/wireless/brcm80211/brcmfmac/firmware.c | 2 +-
drivers/net/wireless/brcm80211/brcmfmac/flowring.c | 6 +-
drivers/net/wireless/brcm80211/brcmfmac/fweh.c | 4 +-
drivers/net/wireless/brcm80211/brcmfmac/fwil.c | 84 +-
.../net/wireless/brcm80211/brcmfmac/fwil_types.h | 89 +-
drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c | 8 +-
drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c | 6 +-
drivers/net/wireless/brcm80211/brcmfmac/of.c | 4 +-
drivers/net/wireless/brcm80211/brcmfmac/p2p.c | 6 +-
drivers/net/wireless/brcm80211/brcmfmac/pcie.c | 4 +-
drivers/net/wireless/brcm80211/brcmfmac/proto.c | 6 +-
.../brcm80211/brcmfmac/{dhd_sdio.c => sdio.c} | 55 +-
.../brcm80211/brcmfmac/{sdio_host.h => sdio.h} | 8 +-
.../net/wireless/brcm80211/brcmfmac/tracepoint.c | 15 +
drivers/net/wireless/brcm80211/brcmfmac/usb.c | 142 ++-
drivers/net/wireless/brcm80211/brcmfmac/usb_rdl.h | 75 --
drivers/net/wireless/brcm80211/brcmfmac/vendor.c | 6 +-
drivers/net/wireless/brcm80211/brcmsmac/debug.c | 166 ++-
drivers/net/wireless/brcm80211/brcmsmac/main.c | 18 +-
drivers/net/wireless/ipw2x00/ipw2200.c | 2 +-
drivers/net/wireless/ipw2x00/libipw.h | 5 -
drivers/net/wireless/ipw2x00/libipw_module.c | 15 +-
drivers/net/wireless/ipw2x00/libipw_rx.c | 21 +-
drivers/net/wireless/iwlegacy/4965-mac.c | 2 +-
drivers/net/wireless/iwlegacy/4965.h | 5 +-
drivers/net/wireless/iwlwifi/Kconfig | 1 +
drivers/net/wireless/iwlwifi/dvm/lib.c | 4 +-
drivers/net/wireless/iwlwifi/dvm/mac80211.c | 25 +-
drivers/net/wireless/iwlwifi/iwl-8000.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-config.h | 12 +
drivers/net/wireless/iwlwifi/iwl-drv.c | 3 -
drivers/net/wireless/iwlwifi/iwl-fw.h | 1 -
drivers/net/wireless/iwlwifi/iwl-trans.h | 6 +-
drivers/net/wireless/iwlwifi/mvm/coex.c | 13 +-
drivers/net/wireless/iwlwifi/mvm/coex_legacy.c | 14 +-
drivers/net/wireless/iwlwifi/mvm/constants.h | 5 +
drivers/net/wireless/iwlwifi/mvm/d3.c | 318 +++---
drivers/net/wireless/iwlwifi/mvm/debugfs.c | 201 ++--
drivers/net/wireless/iwlwifi/mvm/fw-api-power.h | 35 +-
drivers/net/wireless/iwlwifi/mvm/fw-api.h | 1 +
drivers/net/wireless/iwlwifi/mvm/fw.c | 9 +
drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c | 5 +-
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 152 ++-
drivers/net/wireless/iwlwifi/mvm/mvm.h | 18 +-
drivers/net/wireless/iwlwifi/mvm/ops.c | 16 +-
drivers/net/wireless/iwlwifi/mvm/rs.c | 80 +-
drivers/net/wireless/iwlwifi/mvm/rs.h | 2 +
drivers/net/wireless/iwlwifi/mvm/scan.c | 38 +-
drivers/net/wireless/iwlwifi/mvm/sta.c | 2 +-
drivers/net/wireless/iwlwifi/mvm/time-event.c | 2 +-
drivers/net/wireless/iwlwifi/mvm/tt.c | 4 -
drivers/net/wireless/iwlwifi/mvm/tx.c | 14 +-
drivers/net/wireless/iwlwifi/mvm/utils.c | 37 +
drivers/net/wireless/iwlwifi/pcie/trans.c | 67 +-
drivers/net/wireless/mac80211_hwsim.c | 462 ++++++--
drivers/net/wireless/mac80211_hwsim.h | 25 +-
drivers/net/wireless/mwifiex/cfg80211.c | 75 +-
drivers/net/wireless/mwifiex/decl.h | 10 +
drivers/net/wireless/mwifiex/fw.h | 16 +
drivers/net/wireless/mwifiex/main.c | 6 +
drivers/net/wireless/mwifiex/main.h | 6 +-
drivers/net/wireless/mwifiex/scan.c | 76 +-
drivers/net/wireless/mwifiex/sta_cmdresp.c | 2 +-
drivers/net/wireless/rt2x00/rt2500usb.c | 10 +-
drivers/net/wireless/rt2x00/rt2x00usb.c | 4 +-
drivers/net/wireless/rt2x00/rt2x00usb.h | 39 +-
drivers/net/wireless/rtlwifi/rtl8821ae/phy.c | 12 +-
drivers/net/wireless/ti/wlcore/main.c | 23 +-
drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c | 4 +-
include/linux/ath9k_platform.h | 3 +
include/linux/ieee80211.h | 22 +-
include/{net => linux}/ieee802154.h | 23 +-
include/linux/nl802154.h | 4 -
include/net/6lowpan.h | 12 +-
include/net/af_ieee802154.h | 4 -
include/net/bluetooth/hci_core.h | 8 +-
include/net/cfg80211.h | 84 +-
include/net/{wpan-phy.h => cfg802154.h} | 22 +-
include/net/ieee802154_netdev.h | 6 +-
include/net/mac80211.h | 138 ++-
include/net/mac802154.h | 124 ++-
include/net/nl802154.h | 4 -
include/uapi/linux/nl80211.h | 32 +-
net/6lowpan/iphc.c | 71 +-
net/bluetooth/6lowpan.c | 284 +++--
net/bluetooth/hci_conn.c | 14 +-
net/bluetooth/hci_core.c | 16 +-
net/bluetooth/hci_event.c | 50 +-
net/bluetooth/hci_sock.c | 2 +-
net/bluetooth/l2cap_core.c | 7 +-
net/bluetooth/mgmt.c | 83 +-
net/bluetooth/rfcomm/core.c | 6 +-
net/bluetooth/smp.c | 34 +-
net/ieee802154/6lowpan_rtnl.c | 108 +-
net/ieee802154/Makefile | 4 +-
net/ieee802154/af802154.h | 4 -
net/ieee802154/af_ieee802154.c | 4 -
net/ieee802154/{wpan-class.c => core.c} | 79 +-
net/ieee802154/dgram.c | 6 +-
net/ieee802154/header_ops.c | 3 +-
net/ieee802154/ieee802154.h | 4 -
net/ieee802154/netlink.c | 4 -
net/ieee802154/nl-mac.c | 27 +-
net/ieee802154/nl-phy.c | 6 +-
net/ieee802154/nl_policy.c | 4 -
net/ieee802154/raw.c | 4 -
net/ieee802154/reassembly.c | 8 +-
net/ieee802154/reassembly.h | 4 +-
net/ieee802154/sysfs.c | 94 ++
net/ieee802154/sysfs.h | 9 +
net/mac80211/Kconfig | 18 +
net/mac80211/Makefile | 3 +-
net/mac80211/agg-tx.c | 5 -
net/mac80211/cfg.c | 180 +++-
net/mac80211/chan.c | 5 +-
net/mac80211/debug.h | 10 +
net/mac80211/debugfs_key.c | 12 +-
net/mac80211/driver-ops.h | 74 +-
net/mac80211/ieee80211_i.h | 80 +-
net/mac80211/iface.c | 30 +-
net/mac80211/key.c | 11 +-
net/mac80211/main.c | 38 +-
net/mac80211/mesh.h | 3 +
net/mac80211/mesh_pathtbl.c | 31 +
net/mac80211/mlme.c | 281 ++++-
net/mac80211/ocb.c | 250 +++++
net/mac80211/rate.c | 2 +-
net/mac80211/rc80211_minstrel.c | 2 +-
net/mac80211/rc80211_minstrel_debugfs.c | 12 +-
net/mac80211/rc80211_minstrel_ht.c | 313 ++++--
net/mac80211/rc80211_minstrel_ht.h | 40 +-
net/mac80211/rc80211_minstrel_ht_debugfs.c | 48 +-
net/mac80211/rx.c | 35 +
net/mac80211/sta_info.c | 4 +-
net/mac80211/sta_info.h | 1 +
net/mac80211/status.c | 3 +-
net/mac80211/tdls.c | 8 +-
net/mac80211/trace.h | 100 +-
net/mac80211/tx.c | 15 +
net/mac80211/util.c | 132 ++-
net/mac80211/wep.c | 2 -
net/mac80211/wme.c | 33 +-
net/mac80211/wme.h | 2 -
net/mac80211/wpa.c | 5 -
net/mac802154/Kconfig | 2 +-
net/mac802154/Makefile | 4 +-
net/mac802154/driver-ops.h | 226 ++++
net/mac802154/ieee802154_dev.c | 415 --------
net/mac802154/{mac802154.h => ieee802154_i.h} | 87 +-
net/mac802154/iface.c | 466 ++++++++
net/mac802154/llsec.c | 4 +-
net/mac802154/mac_cmd.c | 36 +-
net/mac802154/main.c | 265 +++++
net/mac802154/mib.c | 240 ++---
net/mac802154/monitor.c | 117 --
net/mac802154/rx.c | 311 ++++--
net/mac802154/tx.c | 154 +--
net/mac802154/util.c | 55 +
net/mac802154/wpan.c | 599 -----------
net/wireless/Makefile | 2 +-
net/wireless/chan.c | 10 +-
net/wireless/core.c | 77 +-
net/wireless/core.h | 12 +
net/wireless/nl80211.c | 206 +++-
net/wireless/ocb.c | 88 ++
net/wireless/rdev-ops.h | 55 +-
net/wireless/sme.c | 13 +-
net/wireless/trace.h | 97 +-
net/wireless/util.c | 5 +-
258 files changed, 10107 insertions(+), 6017 deletions(-)
delete mode 100644 drivers/net/ieee802154/fakehard.c
rename drivers/net/wireless/brcm80211/brcmfmac/{dhd_bus.h => bus.h} (98%)
rename drivers/net/wireless/brcm80211/brcmfmac/{wl_cfg80211.c => cfg80211.c} (98%)
rename drivers/net/wireless/brcm80211/brcmfmac/{wl_cfg80211.h => cfg80211.h} (98%)
create mode 100644 drivers/net/wireless/brcm80211/brcmfmac/common.c
rename drivers/net/wireless/brcm80211/brcmfmac/{dhd_linux.c => core.c} (99%)
rename drivers/net/wireless/brcm80211/brcmfmac/{dhd.h => core.h} (98%)
rename drivers/net/wireless/brcm80211/brcmfmac/{dhd_dbg.c => debug.c} (98%)
rename drivers/net/wireless/brcm80211/brcmfmac/{dhd_dbg.h => debug.h} (98%)
delete mode 100644 drivers/net/wireless/brcm80211/brcmfmac/dhd_common.c
rename drivers/net/wireless/brcm80211/brcmfmac/{dhd_sdio.c => sdio.c} (98%)
rename drivers/net/wireless/brcm80211/brcmfmac/{sdio_host.h => sdio.h} (98%)
delete mode 100644 drivers/net/wireless/brcm80211/brcmfmac/usb_rdl.h
rename include/{net => linux}/ieee802154.h (94%)
rename include/net/{wpan-phy.h => cfg802154.h} (77%)
rename net/ieee802154/{wpan-class.c => core.c} (60%)
create mode 100644 net/ieee802154/sysfs.c
create mode 100644 net/ieee802154/sysfs.h
create mode 100644 net/mac80211/ocb.c
create mode 100644 net/mac802154/driver-ops.h
delete mode 100644 net/mac802154/ieee802154_dev.c
rename net/mac802154/{mac802154.h => ieee802154_i.h} (73%)
create mode 100644 net/mac802154/iface.c
create mode 100644 net/mac802154/main.c
delete mode 100644 net/mac802154/monitor.c
create mode 100644 net/mac802154/util.c
delete mode 100644 net/mac802154/wpan.c
create mode 100644 net/wireless/ocb.c
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] asix: Do full reset during ax88772_bind
From: David Miller @ 2014-11-07 20:30 UTC (permalink / raw)
To: ckeepax
Cc: jeffrey.t.kirsher, m.stam, emilgoode, linux-usb, netdev,
linux-kernel
In-Reply-To: <1415288981-3862-1-git-send-email-ckeepax@opensource.wolfsonmicro.com>
From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date: Thu, 6 Nov 2014 15:49:41 +0000
> commit 3cc81d85ee01 ("asix: Don't reset PHY on if_up for ASIX 88772")
> causes the ethernet on Arndale to no longer function. This appears to
> be because the Arndale ethernet requires a full reset before it will
> function correctly, however simply reverting the above patch causes
> problems with ethtool settings getting reset.
>
> It seems the problem is that the ethernet is not properly reset during
> bind, and indeed the code in ax88772_bind that resets the device is a
> very small subset of the actual ax88772_reset function. This patch uses
> ax88772_reset in place of the existing reset code in ax88772_bind which
> removes some code duplication and fixes the ethernet on Arndale.
>
> It is still possible that the original patch causes some issues with
> suspend and resume but that seems like a separate issue and I haven't
> had a chance to test that yet.
>
> Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
> Tested-by: Riku Voipio <riku.voipio@linaro.org>
> ---
>
> Hi,
>
> I wasn't 100% sure which branch to base this off so I based it on Dave
> Miller's net-next branch, which seemed logical.
Since it fixes a regression that is upstream already, I'm applying this
to the net tree.
Thanks.
^ permalink raw reply
* Re: kernel panic receiving flooded VXLAN traffic with OVS
From: Jesse Gross @ 2014-11-07 20:27 UTC (permalink / raw)
To: Pravin Shelar; +Cc: Jay Vosburgh, netdev, discuss@openvswitch.org
In-Reply-To: <CAEP_g=95s37umz-hLGH0-sB32RcW+t+1dJ=_Eg1jMt4HYG+gEg@mail.gmail.com>
On Fri, Nov 7, 2014 at 10:34 AM, Jesse Gross <jesse@nicira.com> wrote:
> On Fri, Nov 7, 2014 at 9:40 AM, Pravin Shelar <pshelar@nicira.com> wrote:
>> On Thu, Nov 6, 2014 at 5:58 PM, Jay Vosburgh <jay.vosburgh@canonical.com> wrote:
>>>
>>> I am able to reproduce a kernel panic on an system using
>>> openvswitch when receiving VXLAN traffic under a very specific set of
>>> circumstances. This occurs with a recent net-next as well as an Ubuntu
>>> 3.13 kernel. I'm not sure if the error lies in OVS, GRO, or elsewhere.
>>>
>>> In summary, when the system receives multiple VXLAN encapsulated
>>> TCP segments for a different system (not intended for local reception)
>>> that are from the middle of an active connection (received due to a switch
>>> flood), and are tagged to a VLAN not configured on the local host, then
>>> the system panics in skb_segment when OVS calls __skb_gso_segment on the
>>> GRO skb prior to performing an upcall to user space.
>>>
>>> The panic occurs in skbuff.c:skb_segment(), at the BUG_ON around
>>> line 3036:
>>>
>>> struct sk_buff *skb_segment(struct sk_buff *head_skb,
>>> netdev_features_t features)
>>> {
>>> [...]
>>> skb_shinfo(nskb)->tx_flags = skb_shinfo(head_skb)->tx_flags &
>>> SKBTX_SHARED_FRAG;
>>>
>>> while (pos < offset + len) {
>>> if (i >= nfrags) {
>>> BUG_ON(skb_headlen(list_skb));
>>>
>>> i = 0;
>>>
>>>
>>> The BUG_ON triggers because the skbs that have been GRO
>>> accumulated are partially or entirely linear, depending upon the receiving
>>> network device (sky2 is partial, enic is entire). The receive buffers end
>>> up being linear evidently because the mtu is set to 9000, and
>>> __netdev_alloc_skb calls __alloc_skb (and thus kmalloc) instead of
>>> __netdev_alloc_frag followed by build_skb.
>>>
>>> The foreign-VLAN VXLAN TCP segments are not processed as normal
>>> VXLAN traffic, as there is no listener on the VLAN in question, so once
>>> GRO processes them, they are sent directly to ovs_vport_receive. The
>>> panic stack appears as follows:
>>>
>>> [ 6558.812214] kernel BUG at net/core/skbuff.c:3025!
>>> [ 6558.812214] invalid opcode: 0000 [#1] SMP
>>> [ 6558.812214] Modules linked in: veth 8021q garp mrp bonding xt_tcpudp bridge stp llc iptable_filter ip_tables x_tables openvswitch vxlan ip6_udp_tunnel udp_tunnel gre libcrc32c i915 video drm_kms_helper coretemp drm kvm_intel kvm gpio_ich ppdev parport_pc lp lpc_ich serio_raw i2c_algo_bit parport mac_hid hid_generic usbhid hid psmouse r8169 mii sky2
>>> [ 6558.812214] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 3.17.0-rc7-testola+ #5
>>> [ 6558.812214] Hardware name: LENOVO 0829F3U/To be filled by O.E.M., BIOS 90KT15AUS 07/21/2010
>>> [ 6558.812214] task: ffff880139eb3200 ti: ffff880139ed0000 task.ti: ffff880139ed0000
>>> [ 6558.812214] RIP: 0010:[<ffffffff81616bc2>] [<ffffffff81616bc2>] skb_segment+0x9d2/0xa00
>>> [ 6558.812214] RSP: 0018:ffff880139ed3610 EFLAGS: 00010216
>>> [ 6558.812214] RAX: 00000000000002dc RBX: ffff8800a3be5e00 RCX: ffff8800b10a26f0
>>> [ 6558.812214] RDX: 0000000000000074 RSI: ffff8800b10a2600 RDI: ffff8800b10a2000
>>> [ 6558.812214] RBP: ffff880139ed36e0 R08: 0000000000000022 R09: 0000000000000000
>>> [ 6558.812214] R10: ffff8800b11e6000 R11: 00000000000005ca R12: ffff8800b10a20f0
>>> [ 6558.812214] R13: 0000000000000000 R14: ffff8800b116cb00 R15: 0000000000000074
>>> [ 6558.812214] FS: 0000000000000000(0000) GS:ffff88013fc00000(0000) knlGS:0000000000000000
>>> [ 6558.812214] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>>> [ 6558.812214] CR2: 00007fa906f4f148 CR3: 00000000b2a46000 CR4: 00000000000407f0
>>> [ 6558.812214] Stack:
>>> [ 6558.812214] 00000000000016a0 ffff880031353800 ffffffffffffffde ffff8800000005ca
>>> [ 6558.812214] 0000000000000022 0000000000000040 ffff8800b11e6000 00000001000016a0
>>> [ 6558.812214] 0000000000000000 0000000000000022 00000000000005a8 ffff8800a3be5e00
>>> [ 6558.812214] Call Trace:
>>> [ 6558.812214] [<ffffffff8168c97f>] udp4_ufo_fragment+0x10f/0x1a0
>>> [ 6558.812214] [<ffffffff81695c51>] inet_gso_segment+0x141/0x370
>>> [ 6558.812214] [<ffffffff810aa2c8>] ? __wake_up_common+0x58/0x90
>>> [ 6558.812214] [<ffffffff81624f4f>] skb_mac_gso_segment+0x9f/0x100
>>> [ 6558.812214] [<ffffffff81625016>] __skb_gso_segment+0x66/0xd0
>>> [ 6558.812214] [<ffffffffa01d4c91>] queue_gso_packets+0x41/0x130 [openvswitch]
>>> [ 6558.812214] [<ffffffff8121aa4d>] ? ep_poll_safewake+0x2d/0x30
>>> [ 6558.812214] [<ffffffff8121b03d>] ? ep_poll_callback+0xcd/0x170
>>> [ 6558.812214] [<ffffffff810aa2c8>] ? __wake_up_common+0x58/0x90
>>> [ 6558.812214] [<ffffffff810aa860>] ? __wake_up_sync_key+0x50/0x60
>>> [ 6558.812214] [<ffffffff8161c232>] ? __skb_flow_dissect+0x162/0x4c0
>>> [ 6558.812214] [<ffffffff8172001f>] ? __slab_free+0xfe/0x2c3
>>> [ 6558.812214] [<ffffffff816107af>] ? kfree_skbmem+0x3f/0xa0
>>> [ 6558.812214] [<ffffffff8161c5ba>] ? __skb_get_hash+0x2a/0x160
>>> [ 6558.812214] [<ffffffffa01d609e>] ovs_dp_upcall+0x2e/0x70 [openvswitch]
>>> [ 6558.812214] [<ffffffffa01d6193>] ovs_dp_process_packet+0xb3/0xd0 [openvswitch]
>>> [ 6558.812214] [<ffffffffa01dc860>] ovs_vport_receive+0x60/0x80 [openvswitch]
>>> [ 6558.812214] [<ffffffff811828f1>] ? zone_statistics+0x81/0xa0
>>> [ 6558.812214] [<ffffffff81617819>] ? skb_gro_receive+0x559/0x5f0
>>> [ 6558.812214] [<ffffffff81695ada>] ? inet_gro_receive+0x1da/0x210
>>> [ 6558.812214] [<ffffffffa01dd10a>] netdev_frame_hook+0xca/0x130 [openvswitch]
>>> [ 6558.812214] [<ffffffff816233aa>] __netif_receive_skb_core+0x1ba/0x7a0
>>> [ 6558.812214] [<ffffffff816239a8>] __netif_receive_skb+0x18/0x60
>>> [ 6558.812214] [<ffffffff81623a13>] netif_receive_skb_internal+0x23/0x90
>>> [ 6558.812214] [<ffffffff8168cefa>] ? udp4_gro_complete+0x6a/0x70
>>> [ 6558.812214] [<ffffffff81623b94>] napi_gro_complete+0xa4/0xe0
>>> [ 6558.812214] [<ffffffff81623c3d>] napi_gro_flush+0x6d/0x90
>>> [ 6558.812214] [<ffffffff81623c7e>] napi_complete+0x1e/0x50
>>> [ 6558.812214] [<ffffffffa0006538>] sky2_poll+0xa38/0xd80 [sky2]
>>> [ 6558.812214] [<ffffffff81623e02>] net_rx_action+0x152/0x250
>>> [ 6558.812214] [<ffffffff81070aa5>] __do_softirq+0xf5/0x2e0
>>> [ 6558.812214] [<ffffffff81070cc0>] run_ksoftirqd+0x30/0x50
>>> [ 6558.812214] [<ffffffff8108e0ff>] smpboot_thread_fn+0xff/0x1b0
>>> [ 6558.812214] [<ffffffff8108e000>] ? SyS_setgroups+0x1a0/0x1a0
>>> [ 6558.812214] [<ffffffff8108a5a2>] kthread+0xd2/0xf0
>>> [ 6558.812214] [<ffffffff8108a4d0>] ? kthread_create_on_node+0x180/0x180
>>> [ 6558.812214] [<ffffffff81729e3c>] ret_from_fork+0x7c/0xb0
>>> [ 6558.812214] [<ffffffff8108a4d0>] ? kthread_create_on_node+0x180/0x180
>>> [ 6558.812214] Code: 8b 44 24 70 44 8b 4c 24 30 44 8b 5c 24 18 8b 54 24 08 48 8b 0c 24 0f 85 0f fd ff ff e9 06 fd ff ff 0f 1f 84 00 00 00 00 00 0f 0b <0f> 0b 0f 0b c6 44 24 3b 01 e9 28 f7 ff ff e8 76 db 10 00 0f 0b
>>> [ 6558.812214] RIP [<ffffffff81616bc2>] skb_segment+0x9d2/0xa00
>>> [ 6558.812214] RSP <ffff880139ed3610>
>>>
>>> I'm not sure if this is an error on the part of the RX / GRO
>>> processing in assembling the GRO skb, or in how OVS calls skb_segment.
>>>
>>
>> I think this is related skb_segment() issue where it is not able to
>> handle this type of skb geometry. We need to fix skb-segmentation. I
>> will investigate it more.
>
> One problem that I see is that vxlan_gro_complete() doesn't add
> SKB_GSO_UDP_TUNNEL to gso_type. This causes us to attempt
> fragmentation as UDP rather than continuing down to do TCP
> segmentation. That probably screws up the skb geometry.
I sent out a patch to fix this issue. I'm pretty sure that it is the
root cause of the originally reported case but I don't have a good way
to reproduce it so it would be great if you could test it Jay.
^ permalink raw reply
* [PATCH net] udptunnel: Add SKB_GSO_UDP_TUNNEL during gro_complete.
From: Jesse Gross @ 2014-11-07 20:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Jay Vosburgh
When doing GRO processing for UDP tunnels, we never add
SKB_GSO_UDP_TUNNEL to gso_type - only the type of the inner protocol
is added (such as SKB_GSO_TCPV4). The result is that if the packet is
later resegmented we will do GSO but not treat it as a tunnel. This
results in UDP fragmentation and since that is not the original layout
of the skb, a panic in skb_segment().
Reported-by: Jay Vosburgh <jay.vosburgh@canonical.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
---
This problem occurs back to 3.14 for VXLAN but the FOU portion needs to
be removed for kernels other than the 'net' tree.
---
drivers/net/vxlan.c | 2 ++
include/net/udp_tunnel.h | 9 +++++++++
net/ipv4/fou.c | 2 ++
3 files changed, 13 insertions(+)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index ca30982..cfb892b 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -621,6 +621,8 @@ static int vxlan_gro_complete(struct sk_buff *skb, int nhoff)
int vxlan_len = sizeof(struct vxlanhdr) + sizeof(struct ethhdr);
int err = -ENOSYS;
+ udp_tunnel_gro_complete(skb, nhoff);
+
eh = (struct ethhdr *)(skb->data + nhoff + sizeof(struct vxlanhdr));
type = eh->h_proto;
diff --git a/include/net/udp_tunnel.h b/include/net/udp_tunnel.h
index a47790b..2a50a70 100644
--- a/include/net/udp_tunnel.h
+++ b/include/net/udp_tunnel.h
@@ -100,6 +100,15 @@ static inline struct sk_buff *udp_tunnel_handle_offloads(struct sk_buff *skb,
return iptunnel_handle_offloads(skb, udp_csum, type);
}
+static inline void udp_tunnel_gro_complete(struct sk_buff *skb, int nhoff)
+{
+ struct udphdr *uh;
+
+ uh = (struct udphdr *)(skb->data + nhoff - sizeof(struct udphdr));
+ skb_shinfo(skb)->gso_type |= uh->check ?
+ SKB_GSO_UDP_TUNNEL_CSUM : SKB_GSO_UDP_TUNNEL;
+}
+
static inline void udp_tunnel_encap_enable(struct socket *sock)
{
#if IS_ENABLED(CONFIG_IPV6)
diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c
index 32e7892..606c520 100644
--- a/net/ipv4/fou.c
+++ b/net/ipv4/fou.c
@@ -133,6 +133,8 @@ static int fou_gro_complete(struct sk_buff *skb, int nhoff)
int err = -ENOSYS;
const struct net_offload **offloads;
+ udp_tunnel_gro_complete(skb, nhoff);
+
rcu_read_lock();
offloads = NAPI_GRO_CB(skb)->is_ipv6 ? inet6_offloads : inet_offloads;
ops = rcu_dereference(offloads[proto]);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] cdc-ether: implement MULTICAST flag on the device
From: David Miller @ 2014-11-07 20:19 UTC (permalink / raw)
To: oneukum; +Cc: olivier.blin, netdev
In-Reply-To: <1415283554-27024-1-git-send-email-oneukum@suse.de>
From: Oliver Neukum <oneukum@suse.de>
Date: Thu, 6 Nov 2014 15:19:14 +0100
> Olivier having laid the groundwork this patch transmits the
> multicast flag to the device to save some bus traffic.
>
> Signed-off-by: Oliver Neukum <oneukum@suse.de>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH RFC net-next 0/5] *** Introduce 4 AD link speed ***
From: David Miller @ 2014-11-07 20:19 UTC (permalink / raw)
To: Jianhua.Xie; +Cc: netdev
In-Reply-To: <1415274772-8029-1-git-send-email-Jianhua.Xie@freescale.com>
From: Xie Jianhua <Jianhua.Xie@freescale.com>
Date: Thu, 6 Nov 2014 19:52:47 +0800
> From: Jianhua Xie <Jianhua.Xie@freescale.com>
>
> User Key bits in Port key of AD mode are yet not used. This series
> expands speed type bits and shrinks unused user Key bits in AD mode
> Port Key, introduces 4 AD link speed: 2.5G/20G/40G/56G, and fixes
> aggregated link bandwidth calculation based on new link speed.
I think you can compress patches #2 to #5 into one single patch.
^ permalink raw reply
* Re: [patch net-next 10/10] rocker: implement L2 bridge offloading
From: David Miller @ 2014-11-07 20:16 UTC (permalink / raw)
To: jiri
Cc: netdev, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl
In-Reply-To: <1415265610-9338-11-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 6 Nov 2014 10:20:10 +0100
> unsigned port_number;
"unsigned int"
> + unsigned port_number;
Likewise.
^ permalink raw reply
* Re: [patch net-next 09/10] rocker: implement rocker ofdpa flow table manipulation
From: David Miller @ 2014-11-07 20:16 UTC (permalink / raw)
To: jiri
Cc: netdev, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl
In-Reply-To: <1415265610-9338-10-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 6 Nov 2014 10:20:09 +0100
> +#define ROCKER_OP_FLAG_REMOVE (1 << 0)
> +#define ROCKER_OP_FLAG_NOWAIT (1 << 1)
> +#define ROCKER_OP_FLAG_LEARNED (1 << 2)
These can be defined to BIT(0), BIT(1), BIT(2).
> + hash_for_each_possible(rocker->group_tbl, found,
> + entry, match->group_id)
> + if (found->group_id == match->group_id)
> + return found;
Please enclose multi-line basic blocks inside of curly braces.
^ permalink raw reply
* Re: [patch net-next 06/10] bridge: introduce fdb offloading via switchdev
From: David Miller @ 2014-11-07 20:12 UTC (permalink / raw)
To: jiri
Cc: netdev, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl
In-Reply-To: <1415265610-9338-7-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 6 Nov 2014 10:20:06 +0100
> @@ -132,8 +133,12 @@ static void fdb_del_hw(struct net_bridge *br, const unsigned char *addr)
>
> static void fdb_delete(struct net_bridge *br, struct net_bridge_fdb_entry *f)
> {
> - if (f->is_static)
> + if (f->is_static) {
> fdb_del_hw(br, f->addr.addr);
> + if (f->dst)
> + netdev_sw_port_fdb_del(f->dst->dev,
> + f->addr.addr, f->vlan_id);
> + }
>
> hlist_del_rcu(&f->hlist);
> fdb_notify(br, f, RTM_DELNEIGH);
I think we should now adjust the name of fdb_*_hw() because
fdb_del_hw() sounds like a function that would do what
netdev_sw_port_fdb_del() actually does, remove the fdb entry from the
hardware. But it just removes an address from the device's unicast
filter.
Rename them to something like fdb_*_hw_address() of fdb_*_hw_addr().
Thanks.
^ permalink raw reply
* Re: [patch net-next 05/10] rocker: introduce rocker switch driver
From: David Miller @ 2014-11-07 20:08 UTC (permalink / raw)
To: jiri
Cc: netdev, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl
In-Reply-To: <1415265610-9338-6-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 6 Nov 2014 10:20:05 +0100
> +#include <generated/utsrelease.h>
The version of this driver is not the version of the kernel, please do not
pretend that it is.
Define a proper DRV_MODULE_VERSION and MODULE_VERSION() like other drivers
do rather than using UTS_RELEASE or whatever.
> +static u32 rocker_msix_vector(struct rocker *rocker, unsigned vector)
Please do not use plain "unsigned", always say "unsigned int".
> +#ifdef CONFIG_NET_SWITCHDEV
> + .ndo_sw_parent_id_get = rocker_port_sw_parent_id_get,
> +#endif
Maybe better to just make the driver depend upon NET_SWITCHDEV?
> +struct rocker_desc {
> + u64 buf_addr;
> + u64 cookie;
> + u16 buf_size;
> + u16 tlv_size;
> + u16 resv[5];
> + u16 comp_err;
> +} __packed __aligned(8);
This __packed seems unnecessary, and __packed should always be avoided
when possible because it generates terrible code on some cpus.
> +/* Rocker DMA TLV struct */
> +struct rocker_tlv {
> + u32 type;
> + u16 len;
> +} __packed __aligned(8);
Likewise.
^ permalink raw reply
* Re: [PATCH net-next] PPC: bpf_jit_comp: add SKF_AD_HATYPE instruction
From: David Miller @ 2014-11-07 19:50 UTC (permalink / raw)
To: kda; +Cc: netdev, linuxppc-dev, alexei.starovoitov, dborkman, felix
In-Reply-To: <1415253755-4001-1-git-send-email-kda@linux-powerpc.org>
From: Denis Kirjanov <kda@linux-powerpc.org>
Date: Thu, 6 Nov 2014 09:02:35 +0300
> Add BPF extension SKF_AD_HATYPE to ppc JIT to check
> the hw type of the interface
>
> JIT off:
> [ 69.106783] test_bpf: #20 LD_HATYPE 48 48 PASS
> JIT on:
> [ 64.721757] test_bpf: #20 LD_HATYPE 7 6 PASS
>
> CC: Alexei Starovoitov<alexei.starovoitov@gmail.com>
> CC: Daniel Borkmann<dborkman@redhat.com>
> CC: Philippe Bergheaud<felix@linux.vnet.ibm.com>
> Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
Can I get some reviews please?
Thanks.
^ permalink raw reply
* Re: [PATCH net 3/5] fm10k: Implement ndo_gso_check()
From: Vick, Matthew @ 2014-11-07 19:49 UTC (permalink / raw)
To: Joe Stringer
Cc: alexander.duyck@gmail.com, netdev@vger.kernel.org,
Dept-GELinuxNICDev@qlogic.com, linux-kernel@vger.kernel.org,
sathya.perla@emulex.com, Kirsher, Jeffrey T, Linux NICS,
amirv@mellanox.com, shahed.shaikh@qlogic.com, therbert@google.com,
Or Gerlitz
In-Reply-To: <201411071805.18119.joestringer@nicira.com>
On 11/6/14, 9:05 PM, "Joe Stringer" <joestringer@nicira.com> wrote:
>Let's merge both discussions into one thread (pick here or there). We
>have
>this suggestion or the one which simply checks for tunnels and
>inner+outer
>header lengths. Do you have a preference between them?
Agreed with merging the thread--consider it merged!
Reflecting on this some more, I prefer the latter option (checking tunnels
and header lengths). I'm leaning towards pushing the header length check
into fm10k_tx_encap_offload and then making fm10k_gso_check call that with
the gso_type. So, it's really the most recent version of the patch you
proposed:
static bool fm10k_gso_check(struct sk_buff *skb, struct net_device *dev)
{
if ((skb_shinfo(skb)->gso_type & (SKB_GSO_UDP_TUNNEL | SKB_GSO_GRE)) &&
!fm10k_tx_encap_offload(skb))
return false;
return true;
}
plus the header length being checked in fm10k_tx_encap_offload. The only
nit would be that I'd just return the conditional instead of having
"return true" or "return false" lines.
The tunnel length check really should be there in fm10k_tx_encap_offload
anyway, so I'll get a patch together for that one.
>We could introduce an "skb_is_gso_encap()" or similar for this purpose.
>Checking for SKB_GSO_UDP_TUNNEL or SKB_GSO_GRE is pretty closely tied to
>what
>fm10k_tx_encap_offload() checks for though; it might not even make sense
>to call
>it if some of the other SKB_GSO_* flags are raised.
A fair point. On the other hand, we have to check the header length both
in the GSO and non-GSO cases anyway, so only having the check in
fm10k_tx_encap_offload and calling it from fm10k_gso_check wouldn't be as
duplicative. What do you think about that approach?
As an aside: the more I think about this, the more I think Tom's right and
that each driver really should have it's own ndo_gso_check() for this.
With fm10k and i40e being different, we're already at 40% of the current
drivers being different. I'll leave it to Or to comment on whether the
other drivers could share the check in some manner.
Cheers,
Matthew
^ permalink raw reply
* Re: kernel panic receiving flooded VXLAN traffic with OVS
From: Jesse Gross @ 2014-11-07 18:34 UTC (permalink / raw)
To: Pravin Shelar; +Cc: Jay Vosburgh, netdev, discuss@openvswitch.org
In-Reply-To: <CALnjE+r-s-usJoHq0E74QdorKX2H2cx429xwmsQ2kh+tzp1Y-g@mail.gmail.com>
On Fri, Nov 7, 2014 at 9:40 AM, Pravin Shelar <pshelar@nicira.com> wrote:
> On Thu, Nov 6, 2014 at 5:58 PM, Jay Vosburgh <jay.vosburgh@canonical.com> wrote:
>>
>> I am able to reproduce a kernel panic on an system using
>> openvswitch when receiving VXLAN traffic under a very specific set of
>> circumstances. This occurs with a recent net-next as well as an Ubuntu
>> 3.13 kernel. I'm not sure if the error lies in OVS, GRO, or elsewhere.
>>
>> In summary, when the system receives multiple VXLAN encapsulated
>> TCP segments for a different system (not intended for local reception)
>> that are from the middle of an active connection (received due to a switch
>> flood), and are tagged to a VLAN not configured on the local host, then
>> the system panics in skb_segment when OVS calls __skb_gso_segment on the
>> GRO skb prior to performing an upcall to user space.
>>
>> The panic occurs in skbuff.c:skb_segment(), at the BUG_ON around
>> line 3036:
>>
>> struct sk_buff *skb_segment(struct sk_buff *head_skb,
>> netdev_features_t features)
>> {
>> [...]
>> skb_shinfo(nskb)->tx_flags = skb_shinfo(head_skb)->tx_flags &
>> SKBTX_SHARED_FRAG;
>>
>> while (pos < offset + len) {
>> if (i >= nfrags) {
>> BUG_ON(skb_headlen(list_skb));
>>
>> i = 0;
>>
>>
>> The BUG_ON triggers because the skbs that have been GRO
>> accumulated are partially or entirely linear, depending upon the receiving
>> network device (sky2 is partial, enic is entire). The receive buffers end
>> up being linear evidently because the mtu is set to 9000, and
>> __netdev_alloc_skb calls __alloc_skb (and thus kmalloc) instead of
>> __netdev_alloc_frag followed by build_skb.
>>
>> The foreign-VLAN VXLAN TCP segments are not processed as normal
>> VXLAN traffic, as there is no listener on the VLAN in question, so once
>> GRO processes them, they are sent directly to ovs_vport_receive. The
>> panic stack appears as follows:
>>
>> [ 6558.812214] kernel BUG at net/core/skbuff.c:3025!
>> [ 6558.812214] invalid opcode: 0000 [#1] SMP
>> [ 6558.812214] Modules linked in: veth 8021q garp mrp bonding xt_tcpudp bridge stp llc iptable_filter ip_tables x_tables openvswitch vxlan ip6_udp_tunnel udp_tunnel gre libcrc32c i915 video drm_kms_helper coretemp drm kvm_intel kvm gpio_ich ppdev parport_pc lp lpc_ich serio_raw i2c_algo_bit parport mac_hid hid_generic usbhid hid psmouse r8169 mii sky2
>> [ 6558.812214] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 3.17.0-rc7-testola+ #5
>> [ 6558.812214] Hardware name: LENOVO 0829F3U/To be filled by O.E.M., BIOS 90KT15AUS 07/21/2010
>> [ 6558.812214] task: ffff880139eb3200 ti: ffff880139ed0000 task.ti: ffff880139ed0000
>> [ 6558.812214] RIP: 0010:[<ffffffff81616bc2>] [<ffffffff81616bc2>] skb_segment+0x9d2/0xa00
>> [ 6558.812214] RSP: 0018:ffff880139ed3610 EFLAGS: 00010216
>> [ 6558.812214] RAX: 00000000000002dc RBX: ffff8800a3be5e00 RCX: ffff8800b10a26f0
>> [ 6558.812214] RDX: 0000000000000074 RSI: ffff8800b10a2600 RDI: ffff8800b10a2000
>> [ 6558.812214] RBP: ffff880139ed36e0 R08: 0000000000000022 R09: 0000000000000000
>> [ 6558.812214] R10: ffff8800b11e6000 R11: 00000000000005ca R12: ffff8800b10a20f0
>> [ 6558.812214] R13: 0000000000000000 R14: ffff8800b116cb00 R15: 0000000000000074
>> [ 6558.812214] FS: 0000000000000000(0000) GS:ffff88013fc00000(0000) knlGS:0000000000000000
>> [ 6558.812214] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [ 6558.812214] CR2: 00007fa906f4f148 CR3: 00000000b2a46000 CR4: 00000000000407f0
>> [ 6558.812214] Stack:
>> [ 6558.812214] 00000000000016a0 ffff880031353800 ffffffffffffffde ffff8800000005ca
>> [ 6558.812214] 0000000000000022 0000000000000040 ffff8800b11e6000 00000001000016a0
>> [ 6558.812214] 0000000000000000 0000000000000022 00000000000005a8 ffff8800a3be5e00
>> [ 6558.812214] Call Trace:
>> [ 6558.812214] [<ffffffff8168c97f>] udp4_ufo_fragment+0x10f/0x1a0
>> [ 6558.812214] [<ffffffff81695c51>] inet_gso_segment+0x141/0x370
>> [ 6558.812214] [<ffffffff810aa2c8>] ? __wake_up_common+0x58/0x90
>> [ 6558.812214] [<ffffffff81624f4f>] skb_mac_gso_segment+0x9f/0x100
>> [ 6558.812214] [<ffffffff81625016>] __skb_gso_segment+0x66/0xd0
>> [ 6558.812214] [<ffffffffa01d4c91>] queue_gso_packets+0x41/0x130 [openvswitch]
>> [ 6558.812214] [<ffffffff8121aa4d>] ? ep_poll_safewake+0x2d/0x30
>> [ 6558.812214] [<ffffffff8121b03d>] ? ep_poll_callback+0xcd/0x170
>> [ 6558.812214] [<ffffffff810aa2c8>] ? __wake_up_common+0x58/0x90
>> [ 6558.812214] [<ffffffff810aa860>] ? __wake_up_sync_key+0x50/0x60
>> [ 6558.812214] [<ffffffff8161c232>] ? __skb_flow_dissect+0x162/0x4c0
>> [ 6558.812214] [<ffffffff8172001f>] ? __slab_free+0xfe/0x2c3
>> [ 6558.812214] [<ffffffff816107af>] ? kfree_skbmem+0x3f/0xa0
>> [ 6558.812214] [<ffffffff8161c5ba>] ? __skb_get_hash+0x2a/0x160
>> [ 6558.812214] [<ffffffffa01d609e>] ovs_dp_upcall+0x2e/0x70 [openvswitch]
>> [ 6558.812214] [<ffffffffa01d6193>] ovs_dp_process_packet+0xb3/0xd0 [openvswitch]
>> [ 6558.812214] [<ffffffffa01dc860>] ovs_vport_receive+0x60/0x80 [openvswitch]
>> [ 6558.812214] [<ffffffff811828f1>] ? zone_statistics+0x81/0xa0
>> [ 6558.812214] [<ffffffff81617819>] ? skb_gro_receive+0x559/0x5f0
>> [ 6558.812214] [<ffffffff81695ada>] ? inet_gro_receive+0x1da/0x210
>> [ 6558.812214] [<ffffffffa01dd10a>] netdev_frame_hook+0xca/0x130 [openvswitch]
>> [ 6558.812214] [<ffffffff816233aa>] __netif_receive_skb_core+0x1ba/0x7a0
>> [ 6558.812214] [<ffffffff816239a8>] __netif_receive_skb+0x18/0x60
>> [ 6558.812214] [<ffffffff81623a13>] netif_receive_skb_internal+0x23/0x90
>> [ 6558.812214] [<ffffffff8168cefa>] ? udp4_gro_complete+0x6a/0x70
>> [ 6558.812214] [<ffffffff81623b94>] napi_gro_complete+0xa4/0xe0
>> [ 6558.812214] [<ffffffff81623c3d>] napi_gro_flush+0x6d/0x90
>> [ 6558.812214] [<ffffffff81623c7e>] napi_complete+0x1e/0x50
>> [ 6558.812214] [<ffffffffa0006538>] sky2_poll+0xa38/0xd80 [sky2]
>> [ 6558.812214] [<ffffffff81623e02>] net_rx_action+0x152/0x250
>> [ 6558.812214] [<ffffffff81070aa5>] __do_softirq+0xf5/0x2e0
>> [ 6558.812214] [<ffffffff81070cc0>] run_ksoftirqd+0x30/0x50
>> [ 6558.812214] [<ffffffff8108e0ff>] smpboot_thread_fn+0xff/0x1b0
>> [ 6558.812214] [<ffffffff8108e000>] ? SyS_setgroups+0x1a0/0x1a0
>> [ 6558.812214] [<ffffffff8108a5a2>] kthread+0xd2/0xf0
>> [ 6558.812214] [<ffffffff8108a4d0>] ? kthread_create_on_node+0x180/0x180
>> [ 6558.812214] [<ffffffff81729e3c>] ret_from_fork+0x7c/0xb0
>> [ 6558.812214] [<ffffffff8108a4d0>] ? kthread_create_on_node+0x180/0x180
>> [ 6558.812214] Code: 8b 44 24 70 44 8b 4c 24 30 44 8b 5c 24 18 8b 54 24 08 48 8b 0c 24 0f 85 0f fd ff ff e9 06 fd ff ff 0f 1f 84 00 00 00 00 00 0f 0b <0f> 0b 0f 0b c6 44 24 3b 01 e9 28 f7 ff ff e8 76 db 10 00 0f 0b
>> [ 6558.812214] RIP [<ffffffff81616bc2>] skb_segment+0x9d2/0xa00
>> [ 6558.812214] RSP <ffff880139ed3610>
>>
>> I'm not sure if this is an error on the part of the RX / GRO
>> processing in assembling the GRO skb, or in how OVS calls skb_segment.
>>
>
> I think this is related skb_segment() issue where it is not able to
> handle this type of skb geometry. We need to fix skb-segmentation. I
> will investigate it more.
One problem that I see is that vxlan_gro_complete() doesn't add
SKB_GSO_UDP_TUNNEL to gso_type. This causes us to attempt
fragmentation as UDP rather than continuing down to do TCP
segmentation. That probably screws up the skb geometry.
^ permalink raw reply
* Re: kernel panic receiving flooded VXLAN traffic with OVS
From: Pravin Shelar @ 2014-11-07 17:40 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev, discuss@openvswitch.org
In-Reply-To: <19014.1415325508@famine>
On Thu, Nov 6, 2014 at 5:58 PM, Jay Vosburgh <jay.vosburgh@canonical.com> wrote:
>
> I am able to reproduce a kernel panic on an system using
> openvswitch when receiving VXLAN traffic under a very specific set of
> circumstances. This occurs with a recent net-next as well as an Ubuntu
> 3.13 kernel. I'm not sure if the error lies in OVS, GRO, or elsewhere.
>
> In summary, when the system receives multiple VXLAN encapsulated
> TCP segments for a different system (not intended for local reception)
> that are from the middle of an active connection (received due to a switch
> flood), and are tagged to a VLAN not configured on the local host, then
> the system panics in skb_segment when OVS calls __skb_gso_segment on the
> GRO skb prior to performing an upcall to user space.
>
> The panic occurs in skbuff.c:skb_segment(), at the BUG_ON around
> line 3036:
>
> struct sk_buff *skb_segment(struct sk_buff *head_skb,
> netdev_features_t features)
> {
> [...]
> skb_shinfo(nskb)->tx_flags = skb_shinfo(head_skb)->tx_flags &
> SKBTX_SHARED_FRAG;
>
> while (pos < offset + len) {
> if (i >= nfrags) {
> BUG_ON(skb_headlen(list_skb));
>
> i = 0;
>
>
> The BUG_ON triggers because the skbs that have been GRO
> accumulated are partially or entirely linear, depending upon the receiving
> network device (sky2 is partial, enic is entire). The receive buffers end
> up being linear evidently because the mtu is set to 9000, and
> __netdev_alloc_skb calls __alloc_skb (and thus kmalloc) instead of
> __netdev_alloc_frag followed by build_skb.
>
> The foreign-VLAN VXLAN TCP segments are not processed as normal
> VXLAN traffic, as there is no listener on the VLAN in question, so once
> GRO processes them, they are sent directly to ovs_vport_receive. The
> panic stack appears as follows:
>
> [ 6558.812214] kernel BUG at net/core/skbuff.c:3025!
> [ 6558.812214] invalid opcode: 0000 [#1] SMP
> [ 6558.812214] Modules linked in: veth 8021q garp mrp bonding xt_tcpudp bridge stp llc iptable_filter ip_tables x_tables openvswitch vxlan ip6_udp_tunnel udp_tunnel gre libcrc32c i915 video drm_kms_helper coretemp drm kvm_intel kvm gpio_ich ppdev parport_pc lp lpc_ich serio_raw i2c_algo_bit parport mac_hid hid_generic usbhid hid psmouse r8169 mii sky2
> [ 6558.812214] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 3.17.0-rc7-testola+ #5
> [ 6558.812214] Hardware name: LENOVO 0829F3U/To be filled by O.E.M., BIOS 90KT15AUS 07/21/2010
> [ 6558.812214] task: ffff880139eb3200 ti: ffff880139ed0000 task.ti: ffff880139ed0000
> [ 6558.812214] RIP: 0010:[<ffffffff81616bc2>] [<ffffffff81616bc2>] skb_segment+0x9d2/0xa00
> [ 6558.812214] RSP: 0018:ffff880139ed3610 EFLAGS: 00010216
> [ 6558.812214] RAX: 00000000000002dc RBX: ffff8800a3be5e00 RCX: ffff8800b10a26f0
> [ 6558.812214] RDX: 0000000000000074 RSI: ffff8800b10a2600 RDI: ffff8800b10a2000
> [ 6558.812214] RBP: ffff880139ed36e0 R08: 0000000000000022 R09: 0000000000000000
> [ 6558.812214] R10: ffff8800b11e6000 R11: 00000000000005ca R12: ffff8800b10a20f0
> [ 6558.812214] R13: 0000000000000000 R14: ffff8800b116cb00 R15: 0000000000000074
> [ 6558.812214] FS: 0000000000000000(0000) GS:ffff88013fc00000(0000) knlGS:0000000000000000
> [ 6558.812214] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 6558.812214] CR2: 00007fa906f4f148 CR3: 00000000b2a46000 CR4: 00000000000407f0
> [ 6558.812214] Stack:
> [ 6558.812214] 00000000000016a0 ffff880031353800 ffffffffffffffde ffff8800000005ca
> [ 6558.812214] 0000000000000022 0000000000000040 ffff8800b11e6000 00000001000016a0
> [ 6558.812214] 0000000000000000 0000000000000022 00000000000005a8 ffff8800a3be5e00
> [ 6558.812214] Call Trace:
> [ 6558.812214] [<ffffffff8168c97f>] udp4_ufo_fragment+0x10f/0x1a0
> [ 6558.812214] [<ffffffff81695c51>] inet_gso_segment+0x141/0x370
> [ 6558.812214] [<ffffffff810aa2c8>] ? __wake_up_common+0x58/0x90
> [ 6558.812214] [<ffffffff81624f4f>] skb_mac_gso_segment+0x9f/0x100
> [ 6558.812214] [<ffffffff81625016>] __skb_gso_segment+0x66/0xd0
> [ 6558.812214] [<ffffffffa01d4c91>] queue_gso_packets+0x41/0x130 [openvswitch]
> [ 6558.812214] [<ffffffff8121aa4d>] ? ep_poll_safewake+0x2d/0x30
> [ 6558.812214] [<ffffffff8121b03d>] ? ep_poll_callback+0xcd/0x170
> [ 6558.812214] [<ffffffff810aa2c8>] ? __wake_up_common+0x58/0x90
> [ 6558.812214] [<ffffffff810aa860>] ? __wake_up_sync_key+0x50/0x60
> [ 6558.812214] [<ffffffff8161c232>] ? __skb_flow_dissect+0x162/0x4c0
> [ 6558.812214] [<ffffffff8172001f>] ? __slab_free+0xfe/0x2c3
> [ 6558.812214] [<ffffffff816107af>] ? kfree_skbmem+0x3f/0xa0
> [ 6558.812214] [<ffffffff8161c5ba>] ? __skb_get_hash+0x2a/0x160
> [ 6558.812214] [<ffffffffa01d609e>] ovs_dp_upcall+0x2e/0x70 [openvswitch]
> [ 6558.812214] [<ffffffffa01d6193>] ovs_dp_process_packet+0xb3/0xd0 [openvswitch]
> [ 6558.812214] [<ffffffffa01dc860>] ovs_vport_receive+0x60/0x80 [openvswitch]
> [ 6558.812214] [<ffffffff811828f1>] ? zone_statistics+0x81/0xa0
> [ 6558.812214] [<ffffffff81617819>] ? skb_gro_receive+0x559/0x5f0
> [ 6558.812214] [<ffffffff81695ada>] ? inet_gro_receive+0x1da/0x210
> [ 6558.812214] [<ffffffffa01dd10a>] netdev_frame_hook+0xca/0x130 [openvswitch]
> [ 6558.812214] [<ffffffff816233aa>] __netif_receive_skb_core+0x1ba/0x7a0
> [ 6558.812214] [<ffffffff816239a8>] __netif_receive_skb+0x18/0x60
> [ 6558.812214] [<ffffffff81623a13>] netif_receive_skb_internal+0x23/0x90
> [ 6558.812214] [<ffffffff8168cefa>] ? udp4_gro_complete+0x6a/0x70
> [ 6558.812214] [<ffffffff81623b94>] napi_gro_complete+0xa4/0xe0
> [ 6558.812214] [<ffffffff81623c3d>] napi_gro_flush+0x6d/0x90
> [ 6558.812214] [<ffffffff81623c7e>] napi_complete+0x1e/0x50
> [ 6558.812214] [<ffffffffa0006538>] sky2_poll+0xa38/0xd80 [sky2]
> [ 6558.812214] [<ffffffff81623e02>] net_rx_action+0x152/0x250
> [ 6558.812214] [<ffffffff81070aa5>] __do_softirq+0xf5/0x2e0
> [ 6558.812214] [<ffffffff81070cc0>] run_ksoftirqd+0x30/0x50
> [ 6558.812214] [<ffffffff8108e0ff>] smpboot_thread_fn+0xff/0x1b0
> [ 6558.812214] [<ffffffff8108e000>] ? SyS_setgroups+0x1a0/0x1a0
> [ 6558.812214] [<ffffffff8108a5a2>] kthread+0xd2/0xf0
> [ 6558.812214] [<ffffffff8108a4d0>] ? kthread_create_on_node+0x180/0x180
> [ 6558.812214] [<ffffffff81729e3c>] ret_from_fork+0x7c/0xb0
> [ 6558.812214] [<ffffffff8108a4d0>] ? kthread_create_on_node+0x180/0x180
> [ 6558.812214] Code: 8b 44 24 70 44 8b 4c 24 30 44 8b 5c 24 18 8b 54 24 08 48 8b 0c 24 0f 85 0f fd ff ff e9 06 fd ff ff 0f 1f 84 00 00 00 00 00 0f 0b <0f> 0b 0f 0b c6 44 24 3b 01 e9 28 f7 ff ff e8 76 db 10 00 0f 0b
> [ 6558.812214] RIP [<ffffffff81616bc2>] skb_segment+0x9d2/0xa00
> [ 6558.812214] RSP <ffff880139ed3610>
>
> I'm not sure if this is an error on the part of the RX / GRO
> processing in assembling the GRO skb, or in how OVS calls skb_segment.
>
I think this is related skb_segment() issue where it is not able to
handle this type of skb geometry. We need to fix skb-segmentation. I
will investigate it more.
> -J
>
> ---
> -Jay Vosburgh, jay.vosburgh@canonical.com
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] stmmac: platform: fix sparse warnings
From: David Miller @ 2014-11-07 17:25 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: peppe.cavallaro, netdev, vbridgers2013
In-Reply-To: <1415371602-12049-1-git-send-email-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Fri, 7 Nov 2014 16:46:42 +0200
> This patch fixes the following sparse warnings. One is fixed by casting return
> value to a return type of the function. The others by creating a specific
> stmmac_platform.h which provides the bits related to the platform driver.
>
> drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c:59:29: warning: incorrect type in return expression (different address spaces)
> drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c:59:29: expected void *
> drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c:59:29: got void [noderef] <asn:2>*reg
>
> drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c:64:29: warning: symbol 'meson6_dwmac_data' was not declared. Should it be static?
> drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c:354:29: warning: symbol 'stih4xx_dwmac_data' was not declared. Should it be static?
> drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c:361:29: warning: symbol 'stid127_dwmac_data' was not declared. Should it be static?
> drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c:133:29: warning: symbol 'sun7i_gmac_data' was not declared. Should it be static?
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] stmmac: remove custom implementation of print_hex_dump()
From: David Miller @ 2014-11-07 17:20 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: joe, peppe.cavallaro, netdev, vbridgers2013
In-Reply-To: <1415371992-12915-1-git-send-email-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Fri, 7 Nov 2014 16:53:12 +0200
> There is a kernel helper to dump buffers in a hexdecimal format. This patch
> substitutes the open coded function by calling that helper.
>
> The output is slightly changed:
> - no lead space
> - ASCII part will be printed along with the dump
> - offset is longer than 3 characters (now 8)
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> Since v1:
> - address Joe's comments
> - describe output change
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 10 ++--------
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCHv4 1/1] net: fec: fix regression on i.MX28 introduced by rx_copybreak support
From: David Miller @ 2014-11-07 17:09 UTC (permalink / raw)
To: festevam
Cc: LW, netdev, fabio.estevam, Frank.Li, linux-kernel, rmk+kernel,
linux-arm-kernel, stefan.wahren
In-Reply-To: <CAOMZO5Cb1=Nvzu8EHqmV+K+W+ZJxzL1=5MnK6hDSstwh9ruweA@mail.gmail.com>
From: Fabio Estevam <festevam@gmail.com>
Date: Fri, 7 Nov 2014 10:26:15 -0200
> On Fri, Nov 7, 2014 at 7:02 AM, Lothar Waßmann <LW@karo-electronics.de> wrote:
>> commit 1b7bde6d659d ("net: fec: implement rx_copybreak to improve rx performance")
>> introduced a regression for i.MX28. The swap_buffer() function doing
>> the endian conversion of the received data on i.MX28 may access memory
>> beyond the actual packet size in the DMA buffer. fec_enet_copybreak()
>> does not copy those bytes, so that the last bytes of a packet may be
>> filled with invalid data after swapping.
>> This will likely lead to checksum errors on received packets.
>> E.g. when trying to mount an NFS rootfs:
>> UDP: bad checksum. From 192.168.1.225:111 to 192.168.100.73:44662 ulen 36
>>
>> Do the byte swapping and copying to the new skb in one go if
>> necessary.
>>
>> Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
>
> With this patch I am able to NFS mount on mx28 again. Thanks, Lothar!
>
> Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Applied, thanks everyone.
^ permalink raw reply
* RE: [net-next 6/9] ixgbe: fix X540 Completion timeout
From: Skidmore, Donald C @ 2014-11-07 17:06 UTC (permalink / raw)
To: Sergei Shtylyov, Kirsher, Jeffrey T, davem@davemloft.net
Cc: netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
jogreene@redhat.com
In-Reply-To: <545CD898.7060403@cogentembedded.com>
> -----Original Message-----
> From: Sergei Shtylyov [mailto:sergei.shtylyov@cogentembedded.com]
> Sent: Friday, November 07, 2014 6:35 AM
> To: Kirsher, Jeffrey T; davem@davemloft.net
> Cc: Skidmore, Donald C; netdev@vger.kernel.org; nhorman@redhat.com;
> sassmann@redhat.com; jogreene@redhat.com
> Subject: Re: [net-next 6/9] ixgbe: fix X540 Completion timeout
>
> Hello.
>
> On 11/7/2014 11:57 AM, Jeff Kirsher wrote:
>
> > From: Don Skidmore <donald.c.skidmore@intel.com>
>
> > On topologies including few levels of PCIe switching X540 can run into
> > an unexpected completion error. We get around this by waiting after
> > enabling loopback a sufficient amount of time until Tx Data Fetch is
> > sent. We then poll the pending transaction bit to ensure we received
> > the completion. Only then do we go on to clear the buffers.
>
> > Signed-of-by: Don Skidmore <donald.c.skidmore@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> > ---
> > drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 21
> ++++++++++++++++++++-
> > 1 file changed, 20 insertions(+), 1 deletion(-)
>
> > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
> > b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
> > index b5f484b..e314b53 100644
> > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
> > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
> [...]
> > @@ -3600,6 +3601,24 @@ void ixgbe_clear_tx_pending(struct ixgbe_hw
> *hw)
> > hlreg0 = IXGBE_READ_REG(hw, IXGBE_HLREG0);
> > IXGBE_WRITE_REG(hw, IXGBE_HLREG0, hlreg0 |
> IXGBE_HLREG0_LPBK);
> >
> > + /* wait for a last completion before clearing buffers */
> > + IXGBE_WRITE_FLUSH(hw);
> > + usleep_range(3000, 6000);
> > +
> > + /* Before proceeding, make sure that the PCIe block does not have
> > + * transactions pending.
> > + */
> > + poll = ixgbe_pcie_timeout_poll(hw);
> > + for (i = 0; i < poll; i++) {
> > + usleep_range(100, 200);
> > + value = ixgbe_read_pci_cfg_word(hw,
> IXGBE_PCI_DEVICE_STATUS);
> > + if (ixgbe_removed(hw->hw_addr))
> > + goto out;
>
> Why not just *break*?
>
> > + if (!(value &
> IXGBE_PCI_DEVICE_STATUS_TRANSACTION_PENDING))
> > + goto out;
>
> Likewise.
>
> > + }
> > +
> > +out:
> > /* initiate cleaning flow for buffers in the PCIe transaction layer */
> > gcr_ext = IXGBE_READ_REG(hw, IXGBE_GCR_EXT);
> > IXGBE_WRITE_REG(hw, IXGBE_GCR_EXT,
>
> WBR, Sergei
Your right the breaks would be much cleaner, thanks for pointing it out. :) I can resubmit the patch threw Jeff or send a new one, whatever is preferred.
- Don Skidmore <donald.c.skidmore@intel.com>
^ permalink raw reply
* Re: [PATCH net-next 2/2] r8152: adjust rtl_start_rx
From: David Miller @ 2014-11-07 16:35 UTC (permalink / raw)
To: hayeswang-Rasf1IRRPZFBDgjK7y7TUQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1394712342-15778-90-Taiwan-albertk-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
From: Hayes Wang <hayeswang-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
Date: Fri, 7 Nov 2014 17:55:11 +0800
> Submit all the rx buffers, even though a error occurs. Otherwise
> the buffers which are not submitted would be lost until next
> rtl_start_rx() is called. Besides, the fail buffer could be
> re-submitted later.
>
> Signed-off-by: Hayes Wang <hayeswang-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
Does this even work?
If you leave a hole in the ring, the device is going to stop there
anyways.
So better to replenish the next time you call into this function
rather than leaving gaps in your receive ring.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* [PATCH iproute2] ip netns: Identify netns for the current process
From: Vadim Kochan @ 2014-11-07 16:25 UTC (permalink / raw)
To: netdev; +Cc: Vadim Kochan
As 'ip' util will share the same netns from the caller
process then we can just look at /proc/self/.. to show
the netns of the current process by:
ip netns id
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
---
ip/ipnetns.c | 22 ++++++++++------------
man/man8/ip-netns.8 | 7 ++++---
2 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/ip/ipnetns.c b/ip/ipnetns.c
index 90a496f..1c8aa02 100644
--- a/ip/ipnetns.c
+++ b/ip/ipnetns.c
@@ -59,7 +59,7 @@ static int usage(void)
fprintf(stderr, "Usage: ip netns list\n");
fprintf(stderr, " ip netns add NAME\n");
fprintf(stderr, " ip netns delete NAME\n");
- fprintf(stderr, " ip netns identify PID\n");
+ fprintf(stderr, " ip netns identify [PID]\n");
fprintf(stderr, " ip netns pids NAME\n");
fprintf(stderr, " ip netns exec NAME cmd ...\n");
fprintf(stderr, " ip netns monitor\n");
@@ -299,19 +299,17 @@ static int netns_identify(int argc, char **argv)
struct dirent *entry;
if (argc < 1) {
- fprintf(stderr, "No pid specified\n");
- return -1;
- }
- if (argc > 1) {
+ pidstr = "self";
+ } else if (argc > 1) {
fprintf(stderr, "extra arguments specified\n");
return -1;
- }
- pidstr = argv[0];
-
- if (!is_pid(pidstr)) {
- fprintf(stderr, "Specified string '%s' is not a pid\n",
- pidstr);
- return -1;
+ } else {
+ pidstr = argv[0];
+ if (!is_pid(pidstr)) {
+ fprintf(stderr, "Specified string '%s' is not a pid\n",
+ pidstr);
+ return -1;
+ }
}
snprintf(net_path, sizeof(net_path), "/proc/%s/ns/net", pidstr);
diff --git a/man/man8/ip-netns.8 b/man/man8/ip-netns.8
index 6aa6e93..74343ed 100644
--- a/man/man8/ip-netns.8
+++ b/man/man8/ip-netns.8
@@ -21,7 +21,7 @@ ip-netns \- process network namespace management
.ti -8
.BR "ip netns identify"
-.I PID
+.RI "[ " PID " ]"
.ti -8
.BR "ip netns pids"
@@ -85,10 +85,11 @@ persists until it has no more users. ip netns delete may fail if
the mount point is in use in another mount namespace.
.TP
-.B ip netns identify PID - Report network namespaces names for process
+.B ip netns identify [PID] - Report network namespaces names for process
.sp
This command walks through /var/run/netns and finds all the network
-namespace names for network namespace of the specified process.
+namespace names for network namespace of the specified process, if PID is
+not specified then the current process will be used.
.TP
.B ip netns pids NAME - Report processes in the named network namespace
--
2.1.3
^ permalink raw reply related
* Re: [PATCH] asix: Do full reset during ax88772_bind
From: David Miller @ 2014-11-07 16:32 UTC (permalink / raw)
To: M.Stam
Cc: ckeepax, jeffrey.t.kirsher, emilgoode, linux-usb, netdev,
linux-kernel
In-Reply-To: <C89EFD3CD56F64468D3D206D683A8D22039FFEDE@ldam-msx2.fugro-nl.local>
From: "Stam, Michel [FINT]" <M.Stam@fugro.nl>
Date: Fri, 7 Nov 2014 09:27:26 +0100
> Please add;
>
> Tested-by: Michel Stam <m.stam@fugro.nl>
You're making two critical mistakes here in how you are replying to
this patch.
First, do not top post. Quote the commit message, then add your
Tested-by or other tag afterwards.
And most importantly, do not provide the entire patch again. That
makes a brand new entry in patchwork, rather than adding your
Tested-by to the original patch.
These mistakes make more work for everyone trying to get this
change into the tree, including me. So please respond and
discuss patches like everyone else does by not top-posting and
not posting the entire patch in your response.
Thanks.
^ permalink raw reply
* Re: am335x: cpsw: phy ignores max-speed setting
From: Yegor Yefremov @ 2014-11-07 16:27 UTC (permalink / raw)
To: Mugunthan V N; +Cc: Florian Fainelli, netdev, mpa, lsorense, Daniel Mack
In-Reply-To: <545CEF35.9080405@ti.com>
On Fri, Nov 7, 2014 at 5:11 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
> On Friday 07 November 2014 12:41 PM, Yegor Yefremov wrote:
>> On Thu, Nov 6, 2014 at 5:58 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>> On 11/06/2014 08:25 AM, Yegor Yefremov wrote:
>>>> I' m trying to override max-speed setting for both CPSW connected
>>>> PHYs. This is my DTS section for configuring CPSW:
>>>>
>>>> &mac {
>>>> pinctrl-names = "default", "sleep";
>>>> pinctrl-0 = <&cpsw_default>;
>>>> pinctrl-1 = <&cpsw_sleep>;
>>>> dual_emac = <1>;
>>>>
>>>> status = "okay";
>>>> };
>>>>
>>>> &davinci_mdio {
>>>> pinctrl-names = "default", "sleep";
>>>> pinctrl-0 = <&davinci_mdio_default>;
>>>> pinctrl-1 = <&davinci_mdio_sleep>;
>>>>
>>>> status = "okay";
>>>> };
>>>>
>>>> &cpsw_emac0 {
>>>> phy_id = <&davinci_mdio>, <0>;
>>>> phy-mode = "rgmii-id";
>>>> dual_emac_res_vlan = <1>;
>>>> max-speed = <100>;
>>>> };
>>>>
>>>> &cpsw_emac1 {
>>>> phy_id = <&davinci_mdio>, <1>;
>>>> phy-mode = "rgmii-id";
>>>> dual_emac_res_vlan = <2>;
>>>> max-speed = <100>;
>>>> };
>>>>
>>>> But in drivers/net/phy/phy_device.c->of_set_phy_supported() routine I
>>>> don't get through node check, i.e. node == NULL. Any idea why?
>>>
>>> Yes, because the 'max-speed' property is placed at the Ethernet MAC node
>>> level, not the PHY node as of_set_phy_supported() expect its.
>>>
>>> This driver does not appear to use the standard Ethernet PHY device tree
>>> node, so I am not sure what are your options here.
>>
>> The SoC has a complex structure, i.e. Ethernet controller has a switch
>> inside with two slaves.
>>
>> A workaround would be perhaps to handle this option in cpsw driver.
>>
>> Mugunthan, what do you think about this?
>
> Yes, CPSW is different from what linux networking is designed for, it
> has two ethernet slave and acts as a Layer 2 switch.
>
> * If you need on a run time basis you can change the supported speed via
> ethtool advertise interface
> * If needed on boot for nfs then need to think of how it can be achieved
> in cpsw driver. Will have a look and update this thread.
ethtool is working, but requires a custom script, so DTS solution
would suite better.
Thanks.
Yegor
^ 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