Hi Xin, As I remember the discussion around introduction of UDP media a few years ago, the developer, Erik Huge, only chose to register TIPC as a udp tunnel user instead of regular udp user because it provides a more efficient way to receive packet in kernel space. With UDP tunnel, we could receive packet directly in a callback, while TIPC had to run in a work queue thread in order to read packets from the socket. So, in reality we don't need any tunnel at all. Another upside is that it is possible to hook in a GSO callback function from the tunnel user, something I am uncertain if we can do as a regular UDP user. Do you have any comments on this? Could it possibly be done differently?
///jon > -----Original Message----- > From: netdev-ow...@vger.kernel.org <netdev-ow...@vger.kernel.org> On > Behalf Of Xin Long > Sent: 17-Jun-19 09:34 > To: network dev <net...@vger.kernel.org> > Cc: da...@davemloft.net; Jon Maloy <jon.ma...@ericsson.com>; Ying Xue > <ying....@windriver.com>; tipc-discussion@lists.sourceforge.net; Marcelo > Ricardo Leitner <marcelo.leit...@gmail.com>; Neil Horman > <nhor...@tuxdriver.com>; Su Yanjun <suyj.f...@cn.fujitsu.com>; David > Ahern <dsah...@gmail.com>; syzkaller-b...@googlegroups.com; Dmitry > Vyukov <dvyu...@google.com>; Pravin B Shelar <pshe...@nicira.com> > Subject: [PATCH net 0/3] net: fix quite a few dst_cache crashes reported by > syzbot > > There are two kinds of crashes reported many times by syzbot with no > reproducer. Call Traces are like: > > BUG: KASAN: slab-out-of-bounds in rt_cache_valid+0x158/0x190 > net/ipv4/route.c:1556 > rt_cache_valid+0x158/0x190 net/ipv4/route.c:1556 > __mkroute_output net/ipv4/route.c:2332 [inline] > ip_route_output_key_hash_rcu+0x819/0x2d50 net/ipv4/route.c:2564 > ip_route_output_key_hash+0x1ef/0x360 net/ipv4/route.c:2393 > __ip_route_output_key include/net/route.h:125 [inline] > ip_route_output_flow+0x28/0xc0 net/ipv4/route.c:2651 > ip_route_output_key include/net/route.h:135 [inline] > ... > > or: > > kasan: GPF could be caused by NULL-ptr deref or user memory access > RIP: 0010:dst_dev_put+0x24/0x290 net/core/dst.c:168 > <IRQ> > rt_fibinfo_free_cpus net/ipv4/fib_semantics.c:200 [inline] > free_fib_info_rcu+0x2e1/0x490 net/ipv4/fib_semantics.c:217 > __rcu_reclaim kernel/rcu/rcu.h:240 [inline] > rcu_do_batch kernel/rcu/tree.c:2437 [inline] > invoke_rcu_callbacks kernel/rcu/tree.c:2716 [inline] > rcu_process_callbacks+0x100a/0x1ac0 kernel/rcu/tree.c:2697 > ... > > They were caused by the fib_nh_common percpu member > 'nhc_pcpu_rth_output' > overwritten by another percpu variable 'dev->tstats' access overflow in tipc > udp media xmit path when counting packets on a non tunnel device. > > The fix is to make udp tunnel work with no tunnel device by allowing not to > count packets on the tstats when the tunnel dev is NULL in Patches 1/3 and > 2/3, then pass a NULL tunnel dev in tipc_udp_tunnel() in Patch 3/3. > > Xin Long (3): > ip_tunnel: allow not to count pkts on tstats by setting skb's dev to > NULL > ip6_tunnel: allow not to count pkts on tstats by passing dev as NULL > tipc: pass tunnel dev as NULL to udp_tunnel(6)_xmit_skb > > include/net/ip6_tunnel.h | 9 ++++++--- net/ipv4/ip_tunnel_core.c | 9 > ++++++--- > net/tipc/udp_media.c | 8 +++----- > 3 files changed, 15 insertions(+), 11 deletions(-) > > -- > 2.1.0 _______________________________________________ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
