Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753274AbbKZRDW (ORCPT ); Thu, 26 Nov 2015 12:03:22 -0500 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:54019 "EHLO out2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753100AbbKZRDT (ORCPT ); Thu, 26 Nov 2015 12:03:19 -0500 Message-Id: <1448557398.912656.450874953.4CA824F0@webmail.messagingengine.com> X-Sasl-Enc: amngep8v2wXXALQDg+YuSWfTB7tBWDhwHsJycviWRkqS 1448557398 From: Hannes Frederic Sowa To: Eric Dumazet Cc: Rainer Weikusat , Eric Dumazet , Dmitry Vyukov , Benjamin LaHaise , "David S. Miller" , Al Viro , David Howells , Ying Xue , "Eric W. Biederman" , netdev , LKML , syzkaller , Kostya Serebryany , Alexander Potapenko , Sasha Levin MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-227d657c In-Reply-To: <1448553090.24696.71.camel@edumazet-glaptop2.roam.corp.google.com> References: <87poyzj7j2.fsf@doppelsaurus.mobileactivedefense.com> <87io4qevdp.fsf@doppelsaurus.mobileactivedefense.com> <87io4q3u8u.fsf@doppelsaurus.mobileactivedefense.com> <1448471494.24696.18.camel@edumazet-glaptop2.roam.corp.google.com> <87a8q23s2a.fsf@doppelsaurus.mobileactivedefense.com> <1448473891.24696.21.camel@edumazet-glaptop2.roam.corp.google.com> <87610q3pjg.fsf@doppelsaurus.mobileactivedefense.com> <1448476744.24696.25.camel@edumazet-glaptop2.roam.corp.google.com> <87y4dl3m5c.fsf@doppelsaurus.mobileactivedefense.com> <1448481002.24696.30.camel@edumazet-glaptop2.roam.corp.google.com> <1448483017.24696.33.camel@edumazet-glaptop2.roam.corp.google.com> <87two93ig8.fsf@doppelsaurus.mobileactivedefense.com> <1448489350.24696.47.camel@edumazet-glaptop2.roam.corp.google.com> <1448490732.1842763.450231537.5358AF37@webmail.messagingengine.com> <1448491414.24696.60.camel@edumazet-glaptop2.roam.corp.google.com> <1448491950.1848115.450243417.726E2DCB@webmail.messagingengine.com> <87r3jcx4w7.fsf@stressinduktion.org> <1448553090.24696.71.camel@edumazet-glaptop2.roam.corp.google.com> Subject: Re: use-after-free in sock_wake_async Date: Thu, 26 Nov 2015 18:03:18 +0100 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2111 Lines: 58 On Thu, Nov 26, 2015, at 16:51, Eric Dumazet wrote: > On Thu, 2015-11-26 at 14:32 +0100, Hannes Frederic Sowa wrote: > > Hannes Frederic Sowa writes: > > > > > > > I have seen filesystems already doing so in .destroy_inode, that's why I > > > am asking. The allocation happens the same way as we do with sock_alloc, > > > e.g. shmem. I actually thought that struct inode already provides an > > > rcu_head for exactly that reason. > > > > E.g.: > > > +static void sock_destroy_inode(struct inode *inode) > > +{ > > + call_rcu(&inode->i_rcu, sock_cache_free_rcu); > > +} > > I guess you missed few years back why we had to implement > SLAB_DESTROY_BY_RCU for TCP sockets to not destroy performance. I think I wasn't even subscribed to netdev@ at that time, so I probably missed it. Few years back is 7. :} > By adding RCU grace period before reuse of this inode (about 640 bytes > today), you are asking the CPU to evict from its cache precious content, > and slow down some workloads, adding lot of ram pressure, as the cpu > allocating a TCP socket will have to populate its cache for a cold > inode. My rationale was like this: we already have rcu to free the wq, so we don't add any more callbacks as current code. sock_alloc is right now 1136 bytes, which is huge, like 18 cachelines. I wouldn't think it does matter a lot as we thrash anyway. tcp_sock is like 45 cachelines right now, hui. Also isn't the reason why slub exists so it can track memory regions per-cpu. Anyway, I am only speculating why it could be tried. I probably need to do some performance experiments. > The reason we put in a small object the RCU protected fields should be > pretty clear. Yes, I thought about that. > Do not copy code that people wrote in other layers without understanding > the performance implications. Duuh. :) Bye, Hannes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/