Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp5396842imm; Tue, 31 Jul 2018 10:11:53 -0700 (PDT) X-Google-Smtp-Source: AAOMgpf9CJYBkMUHHCUdc6YQbmQjWLxFFoVJ1e+GjMZKQoUPEe6wxWFYDNK/S0fxoqnhldBUU7hy X-Received: by 2002:a17:902:bc49:: with SMTP id t9-v6mr21197981plz.116.1533057112958; Tue, 31 Jul 2018 10:11:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533057112; cv=none; d=google.com; s=arc-20160816; b=0i/pRYAnNVzflKNHKWl+Jqx7N9tzJ6bq3q4ZCEPIWz3tYrAr8xD/HcXsySB5MAwFPf y1hOyVXZygjbt2Dea7MifvXt++VEBgJeLNHdHskh6r7M2iGsi9LHdM66n9uPgIyV9Qln 0bGSewa8LNbdMtY4rysUQcRTHL3stGygJPa0R8z3Kl45bVPG5fGocVneGWh6IBuNb1vR +qjH2dHNXqxgnbDR/P1S4XZ8k/5ZJ+hQH32X5eeCSNfKq5ntd6Rwowezao++Hs0ZQV6T kKLq98f7DCHq4RArV6uSkosvAVr05k5nMDJow2kCOrG3ZJJSn4Xpr1KEdH+3H8L2stKo HqbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=+p8WvLrE7zBdfFE/vl8JjqNK8619jDHYklQlHNdENYs=; b=K0BvPHbEho+nuTEUddhkbHE9xFREuYjpPDHPbmpMh35f0qyofhtNJZd152S2R+FN+T vwjuCHIc8PLwfHbgLy6AkIeVVt4TQZN7HPXod34ggdLG6zZkxj508jZoLMYG24IScHXT RESoTbYVLCA8JTty5qv0JQQL0TTbaMpmH8S5sSDCp9F0esPxDdOt1hhESKvfG6V764ps KqjdFXfOKnVMv66g1jIqzWBP+f1JKmTPPEifPl+TDr6isVy84NiVDIxtD8ytSXUiYOuK JsjusxjMBarMxve5VD5oXjuDm8hUFVBN1ZrCbgcWeX5LeThcZxfzFNgID5nUY77U+R7X EL2w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b5-v6si13627054pga.227.2018.07.31.10.11.38; Tue, 31 Jul 2018 10:11:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731600AbeGaSwG (ORCPT + 99 others); Tue, 31 Jul 2018 14:52:06 -0400 Received: from Chamillionaire.breakpoint.cc ([146.0.238.67]:43618 "EHLO Chamillionaire.breakpoint.cc" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727269AbeGaSwG (ORCPT ); Tue, 31 Jul 2018 14:52:06 -0400 Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.89) (envelope-from ) id 1fkY9l-0004Cl-I8; Tue, 31 Jul 2018 19:09:57 +0200 Date: Tue, 31 Jul 2018 19:09:57 +0200 From: Florian Westphal 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 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: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.