Netdev List
 help / color / mirror / Atom feed
* [PATCH net-next 1/2] trace: events: add a few neigh tracepoints
From: Roopa Prabhu @ 2019-02-14 17:15 UTC (permalink / raw)
  To: davem; +Cc: netdev, dsa
In-Reply-To: <1550164511-21195-1-git-send-email-roopa@cumulusnetworks.com>

From: Roopa Prabhu <roopa@cumulusnetworks.com>

The goal here is to trace neigh state changes covering all possible
neigh update paths. Plus have a specific trace point in neigh_update
to cover flags sent to neigh_update.

Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
 include/trace/events/neigh.h | 204 +++++++++++++++++++++++++++++++++++++++++++
 net/core/net-traces.c        |   8 ++
 2 files changed, 212 insertions(+)
 create mode 100644 include/trace/events/neigh.h

diff --git a/include/trace/events/neigh.h b/include/trace/events/neigh.h
new file mode 100644
index 0000000..ed10353
--- /dev/null
+++ b/include/trace/events/neigh.h
@@ -0,0 +1,204 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM neigh
+
+#if !defined(_TRACE_NEIGH_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_NEIGH_H
+
+#include <linux/skbuff.h>
+#include <linux/netdevice.h>
+#include <linux/tracepoint.h>
+#include <net/neighbour.h>
+
+#define neigh_state_str(state)				\
+	__print_symbolic(state,				\
+		{ NUD_INCOMPLETE, "incomplete" },	\
+		{ NUD_REACHABLE, "reachable" },		\
+		{ NUD_STALE, "stale" },			\
+		{ NUD_DELAY, "delay" },			\
+		{ NUD_PROBE, "probe" },			\
+		{ NUD_FAILED, "failed" })
+
+TRACE_EVENT(neigh_update,
+
+	TP_PROTO(struct neighbour *n, const u8 *lladdr, u8 new,
+		 u32 flags, u32 nlmsg_pid),
+
+	TP_ARGS(n, lladdr, new, flags, nlmsg_pid),
+
+	TP_STRUCT__entry(
+		__field(u32, family)
+		__string(dev, (n->dev ? n->dev->name : "NULL"))
+		__array(u8, lladdr, MAX_ADDR_LEN)
+		__field(u8, lladdr_len)
+		__field(u8, flags)
+		__field(u8, nud_state)
+		__field(u8, type)
+		__field(u8, dead)
+		__field(int, refcnt)
+		__array(__u8, primary_key4, 4)
+		__array(__u8, primary_key6, 16)
+		__field(unsigned long, confirmed)
+		__field(unsigned long, updated)
+		__field(unsigned long, used)
+		__array(u8, new_lladdr, MAX_ADDR_LEN)
+		__field(u8, new_state)
+		__field(u32, update_flags)
+		__field(u32, pid)
+	),
+
+	TP_fast_assign(
+		int lladdr_len = (n->dev ? n->dev->addr_len : MAX_ADDR_LEN);
+		struct in6_addr *pin6;
+		__be32 *p32;
+
+		__entry->family = n->tbl->family;
+		__assign_str(dev, (n->dev ? n->dev->name : "NULL"));
+		__entry->lladdr_len = lladdr_len;
+		memcpy(__entry->lladdr, n->ha, lladdr_len);
+		__entry->flags = n->flags;
+		__entry->nud_state = n->nud_state;
+		__entry->type = n->type;
+		__entry->dead = n->dead;
+		__entry->refcnt = refcount_read(&n->refcnt);
+		pin6 = (struct in6_addr *)__entry->primary_key6;
+		p32 = (__be32 *)__entry->primary_key4;
+
+		if (n->tbl->family == AF_INET)
+			*p32 = *(__be32 *)n->primary_key;
+		else
+			*p32 = 0;
+
+#if IS_ENABLED(CONFIG_IPV6)
+		if (n->tbl->family == AF_INET6) {
+			pin6 = (struct in6_addr *)__entry->primary_key6;
+			*pin6 = *(struct in6_addr *)n->primary_key;
+		} else
+#endif
+		{
+			ipv6_addr_set_v4mapped(*p32, pin6);
+		}
+		__entry->confirmed = n->confirmed;
+		__entry->updated = n->updated;
+		__entry->used = n->used;
+		if (lladdr)
+			memcpy(__entry->new_lladdr, lladdr, lladdr_len);
+		__entry->new_state = new;
+		__entry->update_flags = flags;
+		__entry->pid = nlmsg_pid;
+	),
+
+	TP_printk("family %d dev %s lladdr %s flags %02x nud_state %s type %02x "
+		  "dead %d refcnt %d primary_key4 %pI4 primary_key6 %pI6c "
+		  "confirmed %lu updated %lu used %lu new_lladdr %s "
+		  "new_state %02x update_flags %02x pid %d",
+		  __entry->family, __get_str(dev),
+		  __print_hex_str(__entry->lladdr, __entry->lladdr_len),
+		  __entry->flags, neigh_state_str(__entry->nud_state),
+		  __entry->type, __entry->dead, __entry->refcnt,
+		  __entry->primary_key4, __entry->primary_key6,
+		  __entry->confirmed, __entry->updated, __entry->used,
+		  __print_hex_str(__entry->new_lladdr, __entry->lladdr_len),
+		  __entry->new_state,
+		  __entry->update_flags, __entry->pid)
+);
+
+DECLARE_EVENT_CLASS(neigh__update,
+	TP_PROTO(struct neighbour *n, int err),
+	TP_ARGS(n, err),
+	TP_STRUCT__entry(
+		__field(u32, family)
+		__string(dev, (n->dev ? n->dev->name : "NULL"))
+		__array(u8, lladdr, MAX_ADDR_LEN)
+		__field(u8, lladdr_len)
+		__field(u8, flags)
+		__field(u8, nud_state)
+		__field(u8, type)
+		__field(u8, dead)
+		__field(int, refcnt)
+		__array(__u8, primary_key4, 4)
+		__array(__u8, primary_key6, 16)
+		__field(unsigned long, confirmed)
+		__field(unsigned long, updated)
+		__field(unsigned long, used)
+		__field(u32, err)
+	),
+
+	TP_fast_assign(
+		int lladdr_len = (n->dev ? n->dev->addr_len : MAX_ADDR_LEN);
+		struct in6_addr *pin6;
+		__be32 *p32;
+
+		__entry->family = n->tbl->family;
+		__assign_str(dev, (n->dev ? n->dev->name : "NULL"));
+		__entry->lladdr_len = lladdr_len;
+		memcpy(__entry->lladdr, n->ha, lladdr_len);
+		__entry->flags = n->flags;
+		__entry->nud_state = n->nud_state;
+		__entry->type = n->type;
+		__entry->dead = n->dead;
+		__entry->refcnt = refcount_read(&n->refcnt);
+		pin6 = (struct in6_addr *)__entry->primary_key6;
+		p32 = (__be32 *)__entry->primary_key4;
+
+		if (n->tbl->family == AF_INET)
+			*p32 = *(__be32 *)n->primary_key;
+		else
+			*p32 = 0;
+
+#if IS_ENABLED(CONFIG_IPV6)
+		if (n->tbl->family == AF_INET6) {
+			pin6 = (struct in6_addr *)__entry->primary_key6;
+			*pin6 = *(struct in6_addr *)n->primary_key;
+		} else
+#endif
+		{
+			ipv6_addr_set_v4mapped(*p32, pin6);
+		}
+
+		__entry->confirmed = n->confirmed;
+		__entry->updated = n->updated;
+		__entry->used = n->used;
+		__entry->err = err;
+	),
+
+	TP_printk("family %d dev %s lladdr %s flags %02x nud_state %s type %02x "
+		  "dead %d refcnt %d primary_key4 %pI4 primary_key6 %pI6c "
+		  "confirmed %lu updated %lu used %lu err %d",
+		  __entry->family, __get_str(dev),
+		  __print_hex_str(__entry->lladdr, __entry->lladdr_len),
+		  __entry->flags, neigh_state_str(__entry->nud_state),
+		  __entry->type, __entry->dead, __entry->refcnt,
+		  __entry->primary_key4, __entry->primary_key6,
+		  __entry->confirmed, __entry->updated, __entry->used,
+		  __entry->err)
+);
+
+DEFINE_EVENT(neigh__update, neigh_update_done,
+	TP_PROTO(struct neighbour *neigh, int err),
+	TP_ARGS(neigh, err)
+);
+
+DEFINE_EVENT(neigh__update, neigh_timer_handler,
+	TP_PROTO(struct neighbour *neigh, int err),
+	TP_ARGS(neigh, err)
+);
+
+DEFINE_EVENT(neigh__update, neigh_event_send_done,
+	TP_PROTO(struct neighbour *neigh, int err),
+	TP_ARGS(neigh, err)
+);
+
+DEFINE_EVENT(neigh__update, neigh_event_send_dead,
+	TP_PROTO(struct neighbour *neigh, int err),
+	TP_ARGS(neigh, err)
+);
+
+DEFINE_EVENT(neigh__update, neigh_cleanup_and_release,
+	TP_PROTO(struct neighbour *neigh, int rc),
+	TP_ARGS(neigh, rc)
+);
+
+#endif /* _TRACE_NEIGH_H */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
diff --git a/net/core/net-traces.c b/net/core/net-traces.c
index 419af6d..470b179 100644
--- a/net/core/net-traces.c
+++ b/net/core/net-traces.c
@@ -43,6 +43,14 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(fdb_delete);
 EXPORT_TRACEPOINT_SYMBOL_GPL(br_fdb_update);
 #endif
 
+#include <trace/events/neigh.h>
+EXPORT_TRACEPOINT_SYMBOL_GPL(neigh_update);
+EXPORT_TRACEPOINT_SYMBOL_GPL(neigh_update_done);
+EXPORT_TRACEPOINT_SYMBOL_GPL(neigh_timer_handler);
+EXPORT_TRACEPOINT_SYMBOL_GPL(neigh_event_send_done);
+EXPORT_TRACEPOINT_SYMBOL_GPL(neigh_event_send_dead);
+EXPORT_TRACEPOINT_SYMBOL_GPL(neigh_cleanup_and_release);
+
 EXPORT_TRACEPOINT_SYMBOL_GPL(kfree_skb);
 
 EXPORT_TRACEPOINT_SYMBOL_GPL(napi_poll);
-- 
2.1.4


^ permalink raw reply related

* Re: [Bug reporting] kernel panic during handle the dst unreach icmp msg.
From: Eric Dumazet @ 2019-02-14 17:15 UTC (permalink / raw)
  To: soukjin.bae, netdev@vger.kernel.org
  Cc: 박종언, Steffen Klassert, Herbert Xu
In-Reply-To: <20190214074641epcms1p1db1c5589f96718a440a166328eec9ebd@epcms1p1>



On 02/13/2019 11:46 PM, 배석진 wrote:
> Dear all,
> 
> 
> https://www.mail-archive.com/netdev@vger.kernel.org/msg256527.html
> 
> as we concerned before at above mail thread,
> we faced a problem cased by not removed socket.
> 
> (from now, 'the socket' means the socket alloced at 0xFFFFFFC0051E5E00)
> 
> #1. the socket is state in TIME_WAIT1. maybe it's process closed the socket.
>     below is memory dump information with Trace32.
> 
>   (struct sock *)0xFFFFFFC0051E5E00 = 0xFFFFFFC0051E5E00 = end+0x3FF9E4CE00 -> (
>     __sk_common = (
>        ...
>        skc_rcv_saddr = 0x0200A8C0,   ==> 192.168.0.2
>        ...
>        skc_state = 4,                ==> TIME_WAIT1
>        ...
>        skc_flags = 0x4301,           ==> SOCK_DEAD(0x01) set
> 
> 
> #2. user changed WIFI AP to another one, so previous netdevice deleted and destroied it's sockets.
> 
> [60392.948657][4:            netd] 02-13 00:39:32.095  5249  5323 I NetdDestroyed 30 sockets on 192.168.0.2 in 2.7 ms
> [60392.948705][4:            netd] 02-13 00:39:32.095  5249  5323 D Netdnotify() code: 614, msg: Address removed 192.168.0.2/24 wlan0 128 0
> 
>   --> the socket will be exist for a while.
>       because of 'sock_diag_destory() -> tcp_abort()' can not call tcp_done() for the socket.
>       but clearing the socket's sk_write_queue by calling tcp_write_queue_purge(sk).
> 
> 
> #3. icmp msg(dst unreach) came for sent packet by the socket.
>     to retransmit them, lookup sk and fint it. (because the socket still exist)
>     but it's sk_write_queue was already cleared so has no skb to send.
>     and make the kernel bug.
> 
> <4>[60392.948306] I[1:    ksoftirqd/1:   19] ------------[ cut here ]------------
> <0>[60392.948334] I[1:    ksoftirqd/1:   19] kernel BUG at net/ipv4/tcp_ipv4.c:519!
> <2>[60392.948344] I[1:    ksoftirqd/1:   19] sec_debug_set_extra_info_fault = BUG / 0xffffff80090351d0
> <0>[60392.948386] I[1:    ksoftirqd/1:   19] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> ...
> <4>[60392.950676] I[1:    ksoftirqd/1:   19] PC is at tcp_v4_err+0x4b0/0x4bc
> <4>[60392.950684] I[1:    ksoftirqd/1:   19] LR is at tcp_v4_err+0x3ac/0x4bc
> 
> 
> 370 void tcp_v4_err(struct sk_buff *icmp_skb, u32 info)
> 371 {
>         ...
> 516		icsk->icsk_rto = inet_csk_rto_backoff(icsk, TCP_RTO_MAX);
> 517
> 518		skb = tcp_write_queue_head(sk);
> 519		BUG_ON(!skb);
> 520
> 521		tcp_mstamp_refresh(tp);
> 
> 
> we know that the line 519 removed on latest state. instead this will be shown to kernel panic.
> how about below change? do not retransmit packets when socket was already closed.
> 
> best regards,
> 
> 
> 
> From: soukjin bae <soukjin.bae@samsung.com>
> Date: Wen, 14 Jan 2019 14:26:35 +0900
> Subject: net: Don't retransmit packets when socket was already closed
>  
> Signed-off-by: soukjin bae <soukjin.bae@samsung.com>
> Signed-off-by: jongeon park <jongeon.park@samsung.com>
> ---
>  net/ipv4/tcp_ipv4 | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/net/ipv4/tcp_ipv4 b/net/ipv4/tcp_ipv4
> index fe4daf6..654bd19 100755
> --- a/net/ipv4/tcp_ipv4
> +++ b/net/ipv4/tcp_ipv4
> 
> @@ -442,6 +465,10 @@ void tcp_v4_err(struct sk_buff *icmp_skb, u32 info)
>  		err = EPROTO;
>  		break;
>  	case ICMP_DEST_UNREACH:
> +		/* Don't retransmit packets when socket was already closed */
> +		if (sock_flag(sk, SOCK_DEAD))
> +			goto out;
> +
>  		if (code > NR_ICMP_UNREACH)
>  			goto out;
> 

I do not believe this patch is needed.

You probably hit another more serious bug, but since you do not post the full stack trace
it is hard to help.

Are you using vti tunnel ?

I just got a syzbot report that might give us a clue :

(I suspect commit 61220ab349485d911083d0b7990ccd3db6c63297 vti6: Enable namespace changing
was wrong, since vti tunnels have t->net assigned to a struct net without holding a reference)

So we end up freeing a struct net (and associated resources) too soon.


BUG: KASAN: slab-out-of-bounds in atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
BUG: KASAN: slab-out-of-bounds in queued_spin_trylock include/asm-generic/qspinlock.h:69 [inline]
BUG: KASAN: slab-out-of-bounds in do_raw_spin_trylock+0x6a/0x180 kernel/locking/spinlock_debug.c:119
Read of size 4 at addr ffff888066405d9c by task syz-executor.4/10575

CPU: 0 PID: 10575 Comm: syz-executor.4 Not tainted 5.0.0-rc6+ #70
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x172/0x1f0 lib/dump_stack.c:113
 print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
 kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
 check_memory_region_inline mm/kasan/generic.c:185 [inline]
 check_memory_region+0x123/0x190 mm/kasan/generic.c:191
 kasan_check_read+0x11/0x20 mm/kasan/common.c:100
 atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
 queued_spin_trylock include/asm-generic/qspinlock.h:69 [inline]
 do_raw_spin_trylock+0x6a/0x180 kernel/locking/spinlock_debug.c:119
 __raw_spin_trylock include/linux/spinlock_api_smp.h:89 [inline]
 _raw_spin_trylock+0x1c/0x80 kernel/locking/spinlock.c:128
 spin_trylock include/linux/spinlock.h:339 [inline]
 icmp_xmit_lock net/ipv4/icmp.c:219 [inline]
 icmp_send+0x54c/0x1400 net/ipv4/icmp.c:665
 ipv4_link_failure+0x2c/0x210 net/ipv4/route.c:1187
 dst_link_failure include/net/dst.h:427 [inline]
 vti6_xmit net/ipv6/ip6_vti.c:514 [inline]
 vti6_tnl_xmit+0x10db/0x1c6e net/ipv6/ip6_vti.c:553
 __netdev_start_xmit include/linux/netdevice.h:4385 [inline]
 netdev_start_xmit include/linux/netdevice.h:4394 [inline]
 xmit_one net/core/dev.c:3278 [inline]
 dev_hard_start_xmit+0x1b2/0x980 net/core/dev.c:3294
 __dev_queue_xmit+0x26e5/0x2fe0 net/core/dev.c:3864
 dev_queue_xmit+0x18/0x20 net/core/dev.c:3897
 neigh_direct_output+0x16/0x20 net/core/neighbour.c:1516
 neigh_output include/net/neighbour.h:508 [inline]
 ip_finish_output2+0x949/0x1740 net/ipv4/ip_output.c:229
 ip_finish_output+0x73c/0xd50 net/ipv4/ip_output.c:317
 NF_HOOK_COND include/linux/netfilter.h:278 [inline]
 ip_output+0x21f/0x670 net/ipv4/ip_output.c:405
 dst_output include/net/dst.h:444 [inline]
 ip_local_out+0xc4/0x1b0 net/ipv4/ip_output.c:124
 __ip_queue_xmit+0x86f/0x1bf0 net/ipv4/ip_output.c:505
 ip_queue_xmit+0x5a/0x70 include/net/ip.h:198
 __tcp_transmit_skb+0x1a5f/0x3680 net/ipv4/tcp_output.c:1160
 tcp_transmit_skb net/ipv4/tcp_output.c:1176 [inline]
 tcp_write_xmit+0xe89/0x5160 net/ipv4/tcp_output.c:2401
 __tcp_push_pending_frames+0xb4/0x350 net/ipv4/tcp_output.c:2577
 tcp_send_fin+0x149/0xbb0 net/ipv4/tcp_output.c:3122
 tcp_close+0xddf/0x10c0 net/ipv4/tcp.c:2405
 inet_release+0x105/0x1f0 net/ipv4/af_inet.c:428
 __sock_release+0xd3/0x250 net/socket.c:579
 sock_close+0x1b/0x30 net/socket.c:1139
 __fput+0x2df/0x8d0 fs/file_table.c:278
 ____fput+0x16/0x20 fs/file_table.c:309
 task_work_run+0x14a/0x1c0 kernel/task_work.c:113
 tracehook_notify_resume include/linux/tracehook.h:188 [inline]
 exit_to_usermode_loop+0x273/0x2c0 arch/x86/entry/common.c:166
 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
 syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
 do_syscall_32_irqs_on arch/x86/entry/common.c:341 [inline]
 do_fast_syscall_32+0xa9d/0xc98 arch/x86/entry/common.c:397
 entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
RIP: 0023:0xf7fe8869
Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 14 24 c3 8b 3c 24 c3 90 90 90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 002b:000000000845fdac EFLAGS: 00000216 ORIG_RAX: 0000000000000006
RAX: 0000000000000000 RBX: 0000000000000004 RCX: 0000000000000000
RDX: 0000000000000005 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000

Allocated by task 9609:
 save_stack+0x45/0xd0 mm/kasan/common.c:73
 set_track mm/kasan/common.c:85 [inline]
 __kasan_kmalloc mm/kasan/common.c:496 [inline]
 __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:469
 kasan_kmalloc mm/kasan/common.c:504 [inline]
 kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:411
 kmem_cache_alloc_node+0x144/0x710 mm/slab.c:3633
 alloc_task_struct_node kernel/fork.c:158 [inline]
 dup_task_struct kernel/fork.c:845 [inline]
 copy_process.part.0+0x1d08/0x79a0 kernel/fork.c:1753
 copy_process kernel/fork.c:1710 [inline]
 _do_fork+0x257/0xfe0 kernel/fork.c:2227
 __do_compat_sys_x86_clone arch/x86/ia32/sys_ia32.c:240 [inline]
 __se_compat_sys_x86_clone arch/x86/ia32/sys_ia32.c:236 [inline]
 __ia32_compat_sys_x86_clone+0xbc/0x140 arch/x86/ia32/sys_ia32.c:236
 do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline]
 do_int80_syscall_32+0x14d/0x670 arch/x86/entry/common.c:349
 entry_INT80_compat+0x76/0x80 arch/x86/entry/entry_64_compat.S:413

Freed by task 9627:
 save_stack+0x45/0xd0 mm/kasan/common.c:73
 set_track mm/kasan/common.c:85 [inline]
 __kasan_slab_free+0x102/0x150 mm/kasan/common.c:458
 kasan_slab_free+0xe/0x10 mm/kasan/common.c:466
 __cache_free mm/slab.c:3487 [inline]
 kmem_cache_free+0x86/0x260 mm/slab.c:3749
 free_task_struct kernel/fork.c:163 [inline]
 free_task+0xdd/0x120 kernel/fork.c:458
 __put_task_struct+0x20a/0x4e0 kernel/fork.c:731
 put_task_struct include/linux/sched/task.h:98 [inline]
 delayed_put_task_struct+0x1fd/0x350 kernel/exit.c:181
 __rcu_reclaim kernel/rcu/rcu.h:240 [inline]
 rcu_do_batch kernel/rcu/tree.c:2452 [inline]
 invoke_rcu_callbacks kernel/rcu/tree.c:2773 [inline]
 rcu_process_callbacks+0x928/0x1390 kernel/rcu/tree.c:2754
 __do_softirq+0x266/0x95a kernel/softirq.c:292

The buggy address belongs to the object at ffff888066404540
 which belongs to the cache task_struct(81:syz5) of size 6080
The buggy address is located 156 bytes to the right of
 6080-byte region [ffff888066404540, ffff888066405d00)
The buggy address belongs to the page:
page:ffffea0001990100 count:1 mapcount:0 mapping:ffff888092e85080 index:0x0 compound_mapcount: 0
flags: 0x1fffc0000010200(slab|head)
raw: 01fffc0000010200 ffffea00026efe08 ffffea0002554f08 ffff888092e85080
raw: 0000000000000000 ffff888066404540 0000000100000001 ffff8880602fe480
page dumped because: kasan: bad access detected
page->mem_cgroup:ffff8880602fe480

Memory state around the buggy address:
 ffff888066405c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888066405d00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff888066405d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                            ^
 ffff888066405e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff888066405e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

^ permalink raw reply

* [PATCH net-next 2/2] neigh: hook tracepoints in neigh update code
From: Roopa Prabhu @ 2019-02-14 17:15 UTC (permalink / raw)
  To: davem; +Cc: netdev, dsa
In-Reply-To: <1550164511-21195-1-git-send-email-roopa@cumulusnetworks.com>

From: Roopa Prabhu <roopa@cumulusnetworks.com>

hook tracepoints at the end of functions that
update a neigh entry. neigh_update gets an additional
tracepoint to trace the update flags and old and new
neigh states.

Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
 net/core/neighbour.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 4230400..30f6fd8 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -42,6 +42,8 @@
 #include <linux/inetdevice.h>
 #include <net/addrconf.h>
 
+#include <trace/events/neigh.h>
+
 #define DEBUG
 #define NEIGH_DEBUG 1
 #define neigh_dbg(level, fmt, ...)		\
@@ -102,6 +104,7 @@ static void neigh_cleanup_and_release(struct neighbour *neigh)
 	if (neigh->parms->neigh_cleanup)
 		neigh->parms->neigh_cleanup(neigh);
 
+	trace_neigh_cleanup_and_release(neigh, 0);
 	__neigh_notify(neigh, RTM_DELNEIGH, 0, 0);
 	call_netevent_notifiers(NETEVENT_NEIGH_UPDATE, neigh);
 	neigh_release(neigh);
@@ -1095,6 +1098,8 @@ static void neigh_timer_handler(struct timer_list *t)
 	if (notify)
 		neigh_update_notify(neigh, 0);
 
+	trace_neigh_timer_handler(neigh, 0);
+
 	neigh_release(neigh);
 }
 
@@ -1165,6 +1170,7 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
 	else
 		write_unlock(&neigh->lock);
 	local_bh_enable();
+	trace_neigh_event_send_done(neigh, rc);
 	return rc;
 
 out_dead:
@@ -1172,6 +1178,7 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
 		goto out_unlock_bh;
 	write_unlock_bh(&neigh->lock);
 	kfree_skb(skb);
+	trace_neigh_event_send_dead(neigh, 1);
 	return 1;
 }
 EXPORT_SYMBOL(__neigh_event_send);
@@ -1227,6 +1234,8 @@ static int __neigh_update(struct neighbour *neigh, const u8 *lladdr,
 	struct net_device *dev;
 	int update_isrouter = 0;
 
+	trace_neigh_update(neigh, lladdr, new, flags, nlmsg_pid);
+
 	write_lock_bh(&neigh->lock);
 
 	dev    = neigh->dev;
@@ -1393,6 +1402,8 @@ static int __neigh_update(struct neighbour *neigh, const u8 *lladdr,
 	if (notify)
 		neigh_update_notify(neigh, nlmsg_pid);
 
+	trace_neigh_update_done(neigh, err);
+
 	return err;
 }
 
-- 
2.1.4


^ permalink raw reply related

* Re: [PATCH net-next] net: ip6_gre: Give ERSPAN a fill_info link op of its own
From: Petr Machata @ 2019-02-14 17:17 UTC (permalink / raw)
  To: Lorenzo Bianconi; +Cc: netdev@vger.kernel.org
In-Reply-To: <20190214111002.GB16752@localhost.localdomain>


Lorenzo Bianconi <lorenzo.bianconi@redhat.com> writes:

> Does it fix reported issue?

It does. Can you please formally send this? I'll retest and add my
Tested-by.

Thanks,
Petr

^ permalink raw reply

* Re: [PATCH] isdn:hisax: Replace dev_kfree_skb_any by dev_consume_skb_any
From: David Miller @ 2019-02-14 17:22 UTC (permalink / raw)
  To: huang.zijiang
  Cc: isdn, natechancellor, yuehaibing, baijiaju1990, netdev,
	linux-kernel, wang.yi59
In-Reply-To: <1550126399-28063-1-git-send-email-huang.zijiang@zte.com.cn>

From: Huang Zijiang <huang.zijiang@zte.com.cn>
Date: Thu, 14 Feb 2019 14:39:59 +0800

> The skb should be freed by dev_consume_skb_any() in hfcpci_fill_fifo()
> when bcs->tx_skb is still used. The bcs->tx_skb is be replaced by
> skb_dequeue(&bcs->squeue), so the original bcs->tx_skb should
> be consumed(not drop).
> 
> Signed-off-by: Huang Zijiang <huang.zijiang@zte.com.cn>

Applied, thanks.

^ permalink raw reply

* [net-next] net: stmmac: handle endianness in dwmac4_get_timestamp
From: Alexandre Torgue @ 2019-02-14 17:26 UTC (permalink / raw)
  To: Giuseppe Cavallaro, Jose Abreu, davem
  Cc: netdev, linux-stm32, linux-arm-kernel, linux-kernel,
	Alexandre Torgue

GMAC IP is little-endian and used on several kind of CPU (big or little
endian). Main callbacks functions of the stmmac drivers take care about
it. It was not the case for dwmac4_get_timestamp function.

Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
index 20299f6..736e296 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@ -241,15 +241,18 @@ static inline void dwmac4_get_timestamp(void *desc, u32 ats, u64 *ts)
 static int dwmac4_rx_check_timestamp(void *desc)
 {
 	struct dma_desc *p = (struct dma_desc *)desc;
+	unsigned int rdes0 = le32_to_cpu(p->des0);
+	unsigned int rdes1 = le32_to_cpu(p->des1);
+	unsigned int rdes3 = le32_to_cpu(p->des3);
 	u32 own, ctxt;
 	int ret = 1;
 
-	own = p->des3 & RDES3_OWN;
-	ctxt = ((p->des3 & RDES3_CONTEXT_DESCRIPTOR)
+	own = rdes3 & RDES3_OWN;
+	ctxt = ((rdes3 & RDES3_CONTEXT_DESCRIPTOR)
 		>> RDES3_CONTEXT_DESCRIPTOR_SHIFT);
 
 	if (likely(!own && ctxt)) {
-		if ((p->des0 == 0xffffffff) && (p->des1 == 0xffffffff))
+		if ((rdes0 == 0xffffffff) && (rdes1 == 0xffffffff))
 			/* Corrupted value */
 			ret = -EINVAL;
 		else
-- 
2.7.4


^ permalink raw reply related

* Re: [PATCH] net:dl2k: Modify the code style escaping the warning
From: David Miller @ 2019-02-14 17:27 UTC (permalink / raw)
  To: huang.zijiang
  Cc: quentin.monnet, jakub.kicinski, henrik, dsahern, netdev,
	linux-kernel, wang.yi59
In-Reply-To: <1550126431-28152-1-git-send-email-huang.zijiang@zte.com.cn>

From: Huang Zijiang <huang.zijiang@zte.com.cn>
Date: Thu, 14 Feb 2019 14:40:31 +0800

> modify the code style in order to removing the following warning
> when excute the script checkpatch.pl
> WARNING: space prohibited between function name and open parenthesis '('
> 
> Signed-off-by: Huang Zijiang <huang.zijiang@zte.com.cn>

Applied.

^ permalink raw reply

* [PATCH net-next] sfc: ensure recovery after allocation failures
From: Bert Kenward @ 2019-02-14 17:27 UTC (permalink / raw)
  To: Dave Miller; +Cc: linux-net-drivers, netdev, Robert Stonehouse

From: Robert Stonehouse <rstonehouse@solarflare.com>

After failing to allocate a receive buffer the driver may fail to ever
request additional allocations. EF10 NICs require new receive buffers to
be pushed in batches of eight or more. The test for whether a slow fill
should be scheduled failed to take account of this. There is little
downside to *always* requesting a slow fill if we failed to allocate a
buffer, so the condition has been removed completely. The timer that
triggers the request for a refill has also been shortened.

Signed-off-by: Robert Stonehouse <rstonehouse@solarflare.com>
Signed-off-by: Bert Kenward <bkenward@solarflare.com>
---
 drivers/net/ethernet/sfc/efx.c | 2 +-
 drivers/net/ethernet/sfc/rx.c  | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
index 3643015a55cf..bc655ffc9e02 100644
--- a/drivers/net/ethernet/sfc/efx.c
+++ b/drivers/net/ethernet/sfc/efx.c
@@ -915,7 +915,7 @@ efx_realloc_channels(struct efx_nic *efx, u32 rxq_entries, u32 txq_entries)
 
 void efx_schedule_slow_fill(struct efx_rx_queue *rx_queue)
 {
-	mod_timer(&rx_queue->slow_fill, jiffies + msecs_to_jiffies(100));
+	mod_timer(&rx_queue->slow_fill, jiffies + msecs_to_jiffies(10));
 }
 
 static bool efx_default_channel_want_txqs(struct efx_channel *channel)
diff --git a/drivers/net/ethernet/sfc/rx.c b/drivers/net/ethernet/sfc/rx.c
index 396ff01298cd..8702ab44d80b 100644
--- a/drivers/net/ethernet/sfc/rx.c
+++ b/drivers/net/ethernet/sfc/rx.c
@@ -360,8 +360,7 @@ void efx_fast_push_rx_descriptors(struct efx_rx_queue *rx_queue, bool atomic)
 		rc = efx_init_rx_buffers(rx_queue, atomic);
 		if (unlikely(rc)) {
 			/* Ensure that we don't leave the rx queue empty */
-			if (rx_queue->added_count == rx_queue->removed_count)
-				efx_schedule_slow_fill(rx_queue);
+			efx_schedule_slow_fill(rx_queue);
 			goto out;
 		}
 	} while ((space -= batch_size) >= batch_size);
-- 
2.20.1


^ permalink raw reply related

* Re: [PATCH 1/2] net:ethernet:cadence: Replace dev_kfree_skb_any by dev_consume_skb_any
From: David Miller @ 2019-02-14 17:27 UTC (permalink / raw)
  To: huang.zijiang; +Cc: nicolas.ferre, netdev, linux-kernel, wang.yi59
In-Reply-To: <1550126478-28316-1-git-send-email-huang.zijiang@zte.com.cn>

From: Huang Zijiang <huang.zijiang@zte.com.cn>
Date: Thu, 14 Feb 2019 14:41:18 +0800

> The skb should be freed by dev_consume_skb_any() in macb_pad_and_fcs()
> when *skb is still used. The *skb is be replaced by nskb, so the
> original *skb should be consumed(not drop).
> 
> Signed-off-by: Huang Zijiang <huang.zijiang@zte.com.cn>

Applied.

^ permalink raw reply

* Re: [PATCH] net:dl2k: Replace dev_kfree_skb_irq by dev_consume_skb_irq
From: David Miller @ 2019-02-14 17:27 UTC (permalink / raw)
  To: huang.zijiang
  Cc: quentin.monnet, jakub.kicinski, henrik, dsahern, netdev,
	linux-kernel, wang.yi59
In-Reply-To: <1550126456-28233-1-git-send-email-huang.zijiang@zte.com.cn>

From: Huang Zijiang <huang.zijiang@zte.com.cn>
Date: Thu, 14 Feb 2019 14:40:56 +0800

> dev_consume_skb_irq() should be called when skb xmit
> done.It makes drop profiles more friendly.
> 
> Signed-off-by: Huang Zijiang <huang.zijiang@zte.com.cn>

Applied.

^ permalink raw reply

* Re: [rdma-rc PATCH 2/2] iw_cxgb4: cq/qp mask depends on bar2 pages in a host page
From: Raju Rangoju @ 2019-02-14 17:28 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: davem@davemloft.net, linux-rdma@vger.kernel.org,
	netdev@vger.kernel.org, swise@opengridcomputing.com
In-Reply-To: <20190214154127.GD1725@mellanox.com>

On Thursday, February 02/14/19, 2019 at 15:41:34 +0000, Jason Gunthorpe wrote:
> On Thu, Feb 14, 2019 at 05:40:54PM +0530, Raju Rangoju wrote:
> > Adjust the cq/qp mask based on no.of bar2 pages in a host page.
> > 
> > For user-mode rdma, the granularity of the BAR2 memory mapped
> > to a user rdma process during queue allocation must be based
> > on the host page size. The lld attributes udb_density and
> > ucq_density are used to figure out how many sge contexts are
> > in a bar2 page. So the rdev->qpmask and rdev->cqmask in
> > iw_cxgb4 need to now be adjusted based on how many sge bar2
> > pages are in a host page.
> 
> Why is this rc? Do certain arches fail to work or something?
>

Yes, this series fixes a regression that was introduced by commit
2391b0030e (v5.0-rc1~129^2~272)

> Jason

^ permalink raw reply

* Re: [PATCH 2/2] net: Replace dev_kfree_skb_any by dev_consume_skb_any
From: David Miller @ 2019-02-14 17:28 UTC (permalink / raw)
  To: huang.zijiang
  Cc: linux-net-drivers, ecree, bkenward, netdev, linux-kernel,
	wang.yi59
In-Reply-To: <1550126533-28462-1-git-send-email-huang.zijiang@zte.com.cn>

From: Huang Zijiang <huang.zijiang@zte.com.cn>
Date: Thu, 14 Feb 2019 14:42:13 +0800

> The skb should be freed by dev_consume_skb_any() efx_tx_tso_fallback()
> when skb is still used. The skb is be replaced by segments, so the
> original skb should be consumed(not drop).
> 
> Signed-off-by: Huang Zijiang <huang.zijiang@zte.com.cn>

Applied with Sergei's suggested commit message fixups.

Thanks.

^ permalink raw reply

* Re: [PATCH] net: hns: Fix object reference leaks in hns_dsaf_roce_reset()
From: David Miller @ 2019-02-14 17:29 UTC (permalink / raw)
  To: huang.zijiang
  Cc: yisen.zhuang, salil.mehta, lipeng321, liuyonglong, yuehaibing,
	keescook, wangxi11, netdev, linux-kernel, wang.yi59
In-Reply-To: <1550126505-28394-1-git-send-email-huang.zijiang@zte.com.cn>

From: Huang Zijiang <huang.zijiang@zte.com.cn>
Date: Thu, 14 Feb 2019 14:41:45 +0800

> The of_find_device_by_node() takes a reference to the underlying device
> structure, we should release that reference.
> 
> Signed-off-by: Huang Zijiang <huang.zijiang@zte.com.cn>

Applied, thank you.

^ permalink raw reply

* Re: [PATCH] net: phy: at803x: disable delay only for RGMII mode
From: David Miller @ 2019-02-14 17:33 UTC (permalink / raw)
  To: marc.w.gonzalez
  Cc: vkoul, linux-arm-msm, bjorn.andersson, netdev, niklas.cassel,
	andrew, f.fainelli, nsekhar, peter.ujfalusi
In-Reply-To: <d566afe6-4c63-a59f-0141-cc979b29aedf@free.fr>

From: Marc Gonzalez <marc.w.gonzalez@free.fr>
Date: Thu, 14 Feb 2019 17:46:54 +0100

> On 14/02/2019 17:38, David Miller wrote:
> 
>> From: Vinod Koul <vkoul@kernel.org>
>> Date: Tue, 12 Feb 2019 19:49:22 +0530
>> 
>>> diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
>>> index 8ff12938ab47..7b54b54e3316 100644
>>> --- a/drivers/net/phy/at803x.c
>>> +++ b/drivers/net/phy/at803x.c
>>> @@ -110,6 +110,18 @@ static int at803x_debug_reg_mask(struct phy_device *phydev, u16 reg,
>>>  	return phy_write(phydev, AT803X_DEBUG_DATA, val);
>>>  }
>>>  
>>> +static inline int at803x_enable_rx_delay(struct phy_device *phydev)
>>> +{
>>> +	return at803x_debug_reg_mask(phydev, AT803X_DEBUG_REG_0, 0,
>>> +				     AT803X_DEBUG_RX_CLK_DLY_EN);
>>> +}
>>> +
>>> +static inline int at803x_enable_tx_delay(struct phy_device *phydev)
>>> +{
>>> +	return at803x_debug_reg_mask(phydev, AT803X_DEBUG_REG_5, 0,
>>> +				     AT803X_DEBUG_TX_CLK_DLY_EN);
>>> +}
>>> +
>> 
>> Please do not use the inline directive in foo.c files, let the compiler
>> decide.
> 
> Isn't the compiler free to ignore the "inline" hint?

I'm not going into this, but our rules are to not use the inline keyword
except in header files where they are required in order to not emit a
static copy of the function into every file that includes the header.

^ permalink raw reply

* Re: [PATCH iproute2] lib/libnetlink: ensure a minimum of 32KB for the buffer used in rtnl_recvmsg()
From: David Ahern @ 2019-02-14 17:34 UTC (permalink / raw)
  To: Michal Kubecek, netdev
  Cc: Eric Dumazet, Stephen Hemminger, Eric Dumazet, Hangbin Liu,
	Phil Sutter
In-Reply-To: <20190214134945.GJ25518@unicorn.suse.cz>

On 2/14/19 6:49 AM, Michal Kubecek wrote:
> On Tue, Feb 12, 2019 at 07:04:17PM -0700, David Ahern wrote:
>>
>> Do we know of any single message sizes > 32k? 2d34851cd341 cites
>> increasing VF's but at some point there is a limit. If not, the whole
>> PEEK thing should go away and we just malloc 32k (or 64k) buffers for
>> each recvmsg.
> 
> IFLA_VF_LIST is by far the biggest thing I have seen so far. I don't
> remember exact numbers but the issue with 32KB buffer (for the whole
> RTM_NELINK message) was encountered by some of our customers with NICs
> having 120 or 128 VFs.
> 
> There is a bigger issue with IFLA_VFINFO_LIST, though, as it's an
> attribute so that netlink limits its size to 64 KB. IIRC with current
> size of IFLA_VF_INFO this would be reached with 270-280 VFs (I'm sure
> the number was higer than 256 but not too much higher.)
> 
> This would mean unless we let something else grow too much, the whole
> message shouldn't get much bigger than 64 KB. And if we can find some
> other solution (e.g. passing VF information in separate messages if
> client declares support), even 32 KB would be more than enough.

That's what I was asking, thanks. So 32kB today is sufficient, 64kB has
future buffer. So this whole PEEK and allocate the message size is
overkill. It could just as easily been bumped from 32kB to 64kB in the
original patch and been good for a while.

^ permalink raw reply

* Re: [RFC bpf-next 0/7] net: flow_dissector: trigger BPF hook when called from eth_get_headlen
From: Stanislav Fomichev @ 2019-02-14 17:35 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: Willem de Bruijn, Stanislav Fomichev, Network Development,
	David Miller, Alexei Starovoitov, Daniel Borkmann, simon.horman,
	Willem de Bruijn
In-Reply-To: <20190214063848.7zr5ph3ijp3wmjgx@ast-mbp.dhcp.thefacebook.com>

On 02/13, Alexei Starovoitov wrote:
> On Wed, Feb 13, 2019 at 09:57:25PM -0800, Stanislav Fomichev wrote:
> > 
> > > That 'stuck with __sk_buff' is what bothers me.
> > I might have use the wrong word here. I don't think there is another
> > option to be honest. Using __sk_buff makes flow dissector programs work
> > with fragmented packets;
> 
> good point. indeed real skb is essential.
> 
> > > It's an indication that api wasn't thought through if first thing
> > > it needs is this fake skb hack.
> > > If bpf_flow.c is a realistic example of such flow dissector prog
> > > it means that real skb fields are accessed.
> > > In particular skb->vlan_proto, skb->protocol.
> > I do manually set skb->protocol to eth->h_proto in my proposal. This is later
> > correctly handled by bpf_flow.c: parse_eth_proto() is called on skb->protocol
> > and we correctly handle bpf_htons(ETH_P_8021Q) there. So existing
> > bpf_flow.c works as expected.
> ...
> > The goal of this patch series was to essentially make this skb/no-skb
> > context transparent to the bpf_flow.c (i.e. no changes from the user
> > flow programs). Adding another flow dissector for eth_get_headlen case
> > also seems as a no go.
> 
> The problem with this thinking is assumption that bpf_flow.c is the only program.
I agree, it's a bad assumption, but it is sort of a reference implementation,
I don't expect other users to do something wildly different. Hopefully :-)

> Since ctx of flow_dissector prog type is 'struct __sk_buff'
> all fields should be valid or the verifier has to reject access
> to fields that were not set.
> You cannot "manually set skb->protocol to eth->h_proto" in fake skb
> and ignore the rest.
Ugh, I did expect that we only allow a minimal set of __sk_buff fields
to be allowed from the flow dissector program type, but that's not the
case. We explicitly prohibit access only to
family/ips/ports/tc_classid/tstamp/wire_len, everything else is readable :-/
Any idea why?
Stuff like ingress_ifindex/ifindex/hash/mark/queue_mapping, does flow dissector
programs really need to know that?

For the most part, using zero-initialized fake skb looks fine, except:
* infindex, where we do skb->dev->ifndex (skb->dev is NULL)
* gso_segs, where we do skb_shinfo(skb)->gso_segs (we are missing
  shinfo)

So there is indeed a couple of problems.

How do you feel about tightening down the access to sk_buff fields from
the flow dissector program type? That is an API change, but I don't see why
existing users should use those fields. Let's allow access only to
len/data/data_end, protocol, vlan_{present,tci,proto}, cb, flow_keys,
that should be enough to dissect the packet (I also looked at C-based
implementation, it doesn't use anything besides that).
We can always rollback if somebody complains about.

^ permalink raw reply

* Re: [PATCH net-next] net: ip6_gre: Give ERSPAN a fill_info link op of its own
From: Petr Machata @ 2019-02-14 17:39 UTC (permalink / raw)
  To: David Miller
  Cc: netdev@vger.kernel.org, kuznet@ms2.inr.ac.ru,
	yoshfuji@linux-ipv6.org, lorenzo.bianconi@redhat.com
In-Reply-To: <20190214.090847.1049635913680945391.davem@davemloft.net>


David Miller <davem@davemloft.net> writes:

> From: Petr Machata <petrm@mellanox.com>
>
>> Fixes: c706863bc890 ("net: ip6_gre: always reports o_key to userspace")
>> CC: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
>> Signed-off-by: Petr Machata <petrm@mellanox.com>
>
> This commit you are fixing exists in the 'net' tree, therefore this is
> a bug fix and should be targetted at 'net'.

My mistake, I misread the follows-precedes tags at the commit.

Lorenzo, when you send your version, please send it to net.

Thanks,
Petr

^ permalink raw reply

* Re: [PATCH net-next v2 0/2]cxgb4/cxgb4vfSupport for SGE doorbell queue timer
From: David Miller @ 2019-02-14 17:39 UTC (permalink / raw)
  To: vishal; +Cc: netdev, nirranjan, indranil, dt
In-Reply-To: <1550148556-3531-1-git-send-email-vishal@chelsio.com>

From: Vishal Kulkarni <vishal@chelsio.com>
Date: Thu, 14 Feb 2019 18:19:14 +0530

> This series of patchs add SGE doorbell queue timer for faster DMA completions.
> 
> Patch 1 Implements SGE doorbell queue timer
> 
> Patch 2 Adds ethtool capability to set/get SGE doorbell queue timer tick
> 
> ---
> v2
> - Reverse christmas tree formatting for local variables.

Series applied.

^ permalink raw reply

* Have needs for?
From: Cindy @ 2019-02-11 10:16 UTC (permalink / raw)
  To: netdev

Do you have needs for retouching your photos? Or do deep etching and
masking for your photos,

We are the image service provider who can do this for you.

Please send photos to start testing, then you cam judge the quality of our
service.

Thanks,
Cindy
















Dorsdten


Nettetal


^ permalink raw reply

* Re: [PATCH net-next] net: ip6_gre: Give ERSPAN a fill_info link op of its own
From: lorenzo.bianconi @ 2019-02-14 17:40 UTC (permalink / raw)
  To: Petr Machata
  Cc: David Miller, netdev@vger.kernel.org, kuznet@ms2.inr.ac.ru,
	yoshfuji@linux-ipv6.org
In-Reply-To: <87wom2i81l.fsf@mellanox.com>

> 
> David Miller <davem@davemloft.net> writes:
> 
> > From: Petr Machata <petrm@mellanox.com>
> >
> >> Fixes: c706863bc890 ("net: ip6_gre: always reports o_key to userspace")
> >> CC: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
> >> Signed-off-by: Petr Machata <petrm@mellanox.com>
> >
> > This commit you are fixing exists in the 'net' tree, therefore this is
> > a bug fix and should be targetted at 'net'.
> 
> My mistake, I misread the follows-precedes tags at the commit.
> 
> Lorenzo, when you send your version, please send it to net.

I will do, thanks for testing.

Regards,
Lorenzo

> 
> Thanks,
> Petr

^ permalink raw reply

* Re: [patch net-next] lib: objagg: fix handling of object with 0 users when assembling hints
From: David Miller @ 2019-02-14 17:42 UTC (permalink / raw)
  To: jiri; +Cc: netdev, mlxsw
In-Reply-To: <20190214143907.3275-1-jiri@resnulli.us>

From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 14 Feb 2019 15:39:07 +0100

> From: Jiri Pirko <jiri@mellanox.com>
> 
> It is possible that there might be an originally parent object with 0
> direct users that is in hints no longer considered as parent. Then the
> weight of this object is 0 and current code ignores him. That's why the
> total amount of hint objects might be lower than for the original
> objagg and WARN_ON is hit. Fix this be considering 0 weight valid.
> 
> Fixes: 9069a3817d82 ("lib: objagg: implement optimization hints assembly and use hints for object creation")
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>

Applied, thanks Jiri.

^ permalink raw reply

* Re: [PATCH net] net: i825xx: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
From: David Miller @ 2019-02-14 17:43 UTC (permalink / raw)
  To: albin_yang; +Cc: netdev, yang.wei9
In-Reply-To: <1550155538-4253-1-git-send-email-albin_yang@163.com>

From: Yang Wei <albin_yang@163.com>
Date: Thu, 14 Feb 2019 22:45:38 +0800

> From: Yang Wei <yang.wei9@zte.com.cn>
> 
> dev_consume_skb_irq() should be called in i596_interrupt() when skb
> xmit done. It makes drop profiles(dropwatch, perf) more friendly.
> 
> Signed-off-by: Yang Wei <yang.wei9@zte.com.cn>

Applied.

^ permalink raw reply

* Re: [PATCH net] net: xilinx: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
From: David Miller @ 2019-02-14 17:43 UTC (permalink / raw)
  To: albin_yang
  Cc: netdev, michal.simek, anirudh, John.Linn, radhey.shyam.pandey,
	andrew, yang.wei9
In-Reply-To: <1550155858-4340-1-git-send-email-albin_yang@163.com>

From: Yang Wei <albin_yang@163.com>
Date: Thu, 14 Feb 2019 22:50:58 +0800

> From: Yang Wei <yang.wei9@zte.com.cn>
> 
> dev_consume_skb_irq() should be called when skb xmit done. It makes
> drop profiles(dropwatch, perf) more friendly.
> 
> Signed-off-by: Yang Wei <yang.wei9@zte.com.cn>

Applied.

^ permalink raw reply

* Re: [PATCH net] net: packetengines: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
From: David Miller @ 2019-02-14 17:43 UTC (permalink / raw)
  To: albin_yang; +Cc: netdev, yang.wei9
In-Reply-To: <1550155948-4404-1-git-send-email-albin_yang@163.com>

From: Yang Wei <albin_yang@163.com>
Date: Thu, 14 Feb 2019 22:52:28 +0800

> From: Yang Wei <yang.wei9@zte.com.cn>
> 
> dev_consume_skb_irq() should be called when skb xmit done. It makes
> drop profiles(dropwatch, perf) more friendly.
> 
> Signed-off-by: Yang Wei <yang.wei9@zte.com.cn>

Applied.

^ permalink raw reply

* Re: [PATCH net] net: arc_emac: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
From: David Miller @ 2019-02-14 17:43 UTC (permalink / raw)
  To: albin_yang; +Cc: netdev, andrew, yang.wei9
In-Reply-To: <1550156010-4458-1-git-send-email-albin_yang@163.com>

From: Yang Wei <albin_yang@163.com>
Date: Thu, 14 Feb 2019 22:53:30 +0800

> From: Yang Wei <yang.wei9@zte.com.cn>
> 
> dev_consume_skb_irq() should be called in arc_emac_tx_clean() when
> skb xmit done. It makes drop profiles(dropwatch, perf) more friendly.
> 
> Signed-off-by: Yang Wei <yang.wei9@zte.com.cn>

Applied.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox