Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp877448imm; Wed, 1 Aug 2018 06:48:04 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeDnbO9dv/9YDaqou4rLuu+IUzF23zvDNk5z4ew/3yfeomZEW9n3VTCHc2Ijxo9r7Im6SQ0 X-Received: by 2002:a65:5004:: with SMTP id f4-v6mr24801024pgo.54.1533131284476; Wed, 01 Aug 2018 06:48:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533131284; cv=none; d=google.com; s=arc-20160816; b=KeL4iV1JXE6Tb8yJq+wqZSEe9jGoO+uat5VdPF+JmSPzs9a58QB0W5G1NjiDrCgEAi pwkROhi4T1y+453zO7Y92gW4WPhiCuFg+1eJBrQ1q0yqpVEeZ3zk6f6c2i2RkUB5Sqjo CCQldNjSivcfsoG1FyrTQrqW9fQOeEUgk62DWBWeDEwXSMiHkd4hthyMnM6dcGlKay0b SGiP+VaZjTXUjbyVqq0U1uj+Czv4LNPBcFRYpVa1BmTjKmINndcRTMm7Sspr7M+LXLs/ Dqqhs16cFlhsB8nVIsjOCbrDV0VyM4FwX6Am8ywTnqbTDCeqvk7y/S5EDjRrxDJYgD6i 1UVw== 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=5g07O2t1dHswJSB013Jic8qxjVZ9d/3dr+Pjn0idJjI=; b=Sdfuv12eLWFpuzCuOoLr53IWMhQ/MVPjsRMLrA/aCbyrBqTbuAWpKlNGn7OA8uGd2t In67MNhWsZuRK4EXREa+JiX2e0QYLs/Z+wKeeoAK/sfqDX7S7DP36futAY100OGJAZXi 2AyKxMNUz/K1e3l16Bu0ph65CauwpFa4W1aBRSQmhlQHfUQrGMaxpH9V8WMV0y8AlnH2 EphGTRGM0EM1Qrq5dU2qHl3WdpYiRx+cKFppPIfQC2SEwYM+cbzpM/f6MpUk1LICqb1k B/O3vBX+Zeadf8YvX/jtET4VOacxz5jvZ59D7PYWR1301abkDGYGhPYw8+k/Dpne464n NdzQ== 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 l88-v6si16762631pfi.179.2018.08.01.06.47.48; Wed, 01 Aug 2018 06:48:04 -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 S2389423AbeHAPcu (ORCPT + 99 others); Wed, 1 Aug 2018 11:32:50 -0400 Received: from Chamillionaire.breakpoint.cc ([146.0.238.67]:47588 "EHLO Chamillionaire.breakpoint.cc" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389217AbeHAPct (ORCPT ); Wed, 1 Aug 2018 11:32:49 -0400 Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.89) (envelope-from ) id 1fkrSO-00029X-Oq; Wed, 01 Aug 2018 15:46:28 +0200 Date: Wed, 1 Aug 2018 15:46:28 +0200 From: Florian Westphal To: Dmitry Vyukov Cc: Florian Westphal , Linus Torvalds , Christoph Lameter , Andrey Ryabinin , Theodore Ts'o , Jan Kara , linux-ext4@vger.kernel.org, Greg Kroah-Hartman , Pablo Neira Ayuso , Jozsef Kadlecsik , David Miller , NetFilter , coreteam@netfilter.org, Network Development , Gerrit Renker , dccp@vger.kernel.org, Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Dave Airlie , intel-gfx , DRI , Eric Dumazet , Alexey Kuznetsov , Hideaki YOSHIFUJI , Ursula Braun , linux-s390 , Linux Kernel Mailing List , Andrew Morton , linux-mm , Andrey Konovalov Subject: Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation) Message-ID: <20180801134628.ueyzwg2gszrvk2hc@breakpoint.cc> References: <01000164f169bc6b-c73a8353-d7d9-47ec-a782-90aadcb86bfb-000000@email.amazonses.com> <20180801103537.d36t3snzulyuge7g@breakpoint.cc> <20180801114048.ufkr7zwmir7ps3vl@breakpoint.cc> 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 Dmitry Vyukov wrote: > If that scenario is possible that a fix would be to make Looks possible. > __nf_conntrack_find_get ever return NULL iff it got NULL from > ____nf_conntrack_find (not if any of the checks has failed). I don't see why we need to restart on nf_ct_is_dying(), but other than that this seems ok.