netdev - Re: [PATCH net-next v2 0/7] net: unify dst caching for tunnel devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1461827938.4802.2.camel@redhat.com>
Date:	Thu, 28 Apr 2016 09:18:58 +0200
From:	Paolo Abeni <pabeni@...hat.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	tgraf@...g.ch, pshelar@...ira.com, jbenc@...hat.com,
	hannes@...essinduktion.org, therbert@...gle.com,
	sergei.shtylyov@...entembedded.com
Subject: Re: [PATCH net-next v2 0/7] net: unify dst caching for tunnel
 devices

On Wed, 2016-04-27 at 16:31 -0700, Eric Dumazet wrote:
> On Tue, 2016-02-16 at 20:22 -0500, David Miller wrote:
> > From: Paolo Abeni <pabeni@...hat.com>
> > Date: Fri, 12 Feb 2016 15:43:52 +0100
> > 
> > > This patch series try to unify the dst cache implementations currently
> > > present in the kernel, namely in ip_tunnel.c and ip6_tunnel.c, introducing a
> > > new generic implementation, replacing the existing ones, and then using
> > > the new implementation in other tunnel devices which currently lack it.
> > > 
> > > The new dst implementation is compiled, as built-in, only if any device using
> > > it is enabled.
> > > 
> > > Caching the dst for the tunnel remote address gives small, but measurable,
> > > performance improvement when tunneling over ipv4 (in the 2%-4% range) and
> > > significant ones when tunneling over ipv6 (roughly 60% when no
> > > fragmentation/segmentation take place and the tunnel local address
> > > is not specified).
> > > 
> > > v2:
> > > - move the vxlan dst_cache usage inside the device lookup functions
> > > - fix usage after free for lwt tunnel moving the dst cache storage inside
> > >   the dst_metadata,
> > > - sparse codying style cleanup
> > 
> > Series applied, thanks for doing this work as it is a major improvement.
> 
> Paolo, please check following warning :
> 
> This might be caused by e09acddf873bf775b208b452a4c3a3fd26fa9427
> ("ip_tunnel: replace dst_cache with generic implementation")
> 
> 
> [   73.982267] BUG: using smp_processor_id() in preemptible [00000000] code: ip/10604
> [   73.990978] caller is debug_smp_processor_id+0x17/0x20
> [   73.990981] CPU: 26 PID: 10604 Comm: ip Not tainted 4.6.0-dbx-DEV #1075
> [   73.990982] Hardware name: ...
> [   73.990983]  0000000000000000 ffff881fc11d3b98 ffffffff8140a51f 000000000000001a
> [   73.990987]  ffffffff81a585c5 ffff881fc11d3bc8 ffffffff8142700f 000060bfa000e0c0
> [   73.990989]  ffff881fcb6b0f00 000000009807f60a ffff881fcb6b0f00 ffff881fc11d3bd8
> [   73.990992] Call Trace:
> [   73.990996]  [<ffffffff8140a51f>] dump_stack+0x67/0x98
> [   73.990998]  [<ffffffff8142700f>] check_preemption_disabled+0xef/0x100
> [   73.991000]  [<ffffffff81427057>] debug_smp_processor_id+0x17/0x20
> [   73.991003]  [<ffffffff816bc2cc>] dst_cache_set_ip4+0x2c/0x70
> [   73.991006]  [<ffffffff8174fed1>] ip_tunnel_bind_dev+0x101/0x170
> [   73.991008]  [<ffffffff81750750>] ip_tunnel_ioctl+0x330/0x430
> [   73.991010]  [<ffffffff81750425>] ? ip_tunnel_ioctl+0x5/0x430
> [   73.991012]  [<ffffffff81754b2b>] ipgre_tunnel_ioctl+0xdb/0x160
> [   73.991015]  [<ffffffff816a66f7>] ? rtnl_lock+0x17/0x20
> [   73.991017]  [<ffffffff816b03e5>] dev_ifsioc+0x325/0x370
> [   73.991018]  [<ffffffff816b0662>] dev_ioctl+0xd2/0x630
> [   73.991022]  [<ffffffff8166fc23>] sock_ioctl+0xd3/0x270
> [   73.991025]  [<ffffffff81283643>] do_vfs_ioctl+0x93/0x6f0
> [   73.991026]  [<ffffffff8166ff01>] ? sock_alloc_file+0x91/0x120
> [   73.991029]  [<ffffffff8128fa3c>] ? __fget_light+0x6c/0x90
> [   73.991031]  [<ffffffff81283d2b>] SyS_ioctl+0x8b/0xa0
> [   73.991042]  [<ffffffff817ef2a5>] entry_SYSCALL_64_fastpath+0x18/0xa8

I'm on it right now.

Thank you for the head up.

Paolo