From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by kanga.kvack.org (Postfix) with ESMTP id E38DF6B000D for ; Tue, 31 Jul 2018 13:10:56 -0400 (EDT) Received: by mail-wr1-f69.google.com with SMTP id s14-v6so12687868wra.0 for ; Tue, 31 Jul 2018 10:10:56 -0700 (PDT) Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc. [2a01:7a0:2:106d:670::1]) by mx.google.com with ESMTPS id z9-v6si9258884wrn.224.2018.07.31.10.10.55 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 31 Jul 2018 10:10:55 -0700 (PDT) Date: Tue, 31 Jul 2018 19:09:57 +0200 From: Florian Westphal Subject: Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation) Message-ID: <20180731170957.o4vhopmzgedpo5sh@breakpoint.cc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Andrey Ryabinin Cc: Theodore Ts'o , Jan Kara , linux-ext4@vger.kernel.org, Greg Kroah-Hartman , Pablo Neira Ayuso , Jozsef Kadlecsik , Florian Westphal , "David S. Miller" , netfilter-devel@vger.kernel.org, coreteam@netfilter.org, netdev@vger.kernel.org, Gerrit Renker , dccp@vger.kernel.org, Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, Eric Dumazet , Alexey Kuznetsov , Hideaki YOSHIFUJI , Ursula Braun , linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, Dmitry Vyukov , Christoph Lameter , Andrew Morton , "linux-mm@kvack.org" , Andrey Konovalov , Linus Torvalds Andrey Ryabinin wrote: > Guys, it seems that we have a lot of code using SLAB_TYPESAFE_BY_RCU cache without constructor. > I think it's nearly impossible to use that combination without having bugs. > It's either you don't really need the SLAB_TYPESAFE_BY_RCU, or you need to have a constructor in kmem_cache. > > Could you guys, please, verify your code if it's really need SLAB_TYPSAFE or constructor? > > E.g. the netlink code look extremely suspicious: > > /* > * Do not use kmem_cache_zalloc(), as this cache uses > * SLAB_TYPESAFE_BY_RCU. > */ > ct = kmem_cache_alloc(nf_conntrack_cachep, gfp); > if (ct == NULL) > goto out; > > spin_lock_init(&ct->lock); > > If nf_conntrack_cachep objects really used in rcu typesafe manner, than 'ct' returned by kmem_cache_alloc might still be > in use by another cpu. So we just reinitialize spin_lock used by someone else? That would be a bug, nf_conn objects are reference counted. spinlock can only be used after object had its refcount incremented. lookup operation on nf_conn object: 1. compare keys 2. attempt to obtain refcount (using _not_zero version) 3. compare keys again after refcount was obtained if any of that fails, nf_conn candidate is skipped.