From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4265AC4360C for ; Thu, 10 Oct 2019 18:36:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0FCD020B7C for ; Thu, 10 Oct 2019 18:36:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BtpcT8QF" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726788AbfJJSgo (ORCPT ); Thu, 10 Oct 2019 14:36:44 -0400 Received: from mail-pg1-f196.google.com ([209.85.215.196]:44057 "EHLO mail-pg1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726007AbfJJSgo (ORCPT ); Thu, 10 Oct 2019 14:36:44 -0400 Received: by mail-pg1-f196.google.com with SMTP id e10so213413pgd.11 for ; Thu, 10 Oct 2019 11:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tOmO4TKHm16DClzfcXRVekZnE4Pzae9554ZSqpGnQas=; b=BtpcT8QFG7edZBSS1TEqho8k+vBnuo4VQDPFZGWgcN4vuj/ol7Gp/8FdJ3chxCd9qZ HpiGsLAIn0g8hNm4vLiUYtLeb3FTtox8k7UQCBCf5hobq2XGPn94NiyshMWAYNQlplw0 4AR0txN5QokKV3ubtTFiqHLeaFJA+GCZVsFQmzTl3J6qpSChpD5W83GrxEePCqXgotfA /fCEXO/dejrky37jKe3rpGRAKFRB6cikH0GzwD7DxgLgA0uLjmPVGu3QYg5VBCarVFAm yrnp82ZarmVHkLNOcXhBpv/tv60bqScQPC8Nn7mckJ1G5QzGwgcfuw4nYHQddxcPDkr6 Ljvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tOmO4TKHm16DClzfcXRVekZnE4Pzae9554ZSqpGnQas=; b=eWVQQ+wNirA2g4XA+Er1v1sZdAqrJavtDS2Vz6Z9BCfvTi4AtoYXUHC3hEC7BPoI2D QsGoJh8Mo31FHgKX2XUXtFzO1GmO6mPA/Vzu8Bkyzb19/oCTxH4iEdlAohYwqdT4WaMN SzOIRTtPFmFopjbA8NG/gQ1KwxBPIDvElMTUeaNuEFxz88m6OBqpQkA8nkxk/WCjQxbx TJuMbz26OlWUjIbyV2T/9kxggqJzlo6zmEbJHSRG+SeLOBy9qg3wQTqE/MZW0RDSXwDX RVDLsoLFK6AOJmz3F09Gtzsb8RsTW7cA8b4y6VMfDXf9DTNNWszvs48rylGcwvL0OwNU /zdw== X-Gm-Message-State: APjAAAVkVLEskuSdQDA7MLyXK/I+o+TAC6X6Vqf9Lebd2OmyusFjF1aD eCtazf6J+CTpg/Oo9IOmQhZKHFHslgUAKuptxwc= X-Google-Smtp-Source: APXvYqycXXRjEIa7e2H98e2EQdP1WTKogNoYfo0eroBKMQfyLACFYUysZP6LoblIIshNQ3bZqfrqHVpkiWrP50GlkSA= X-Received: by 2002:a62:28b:: with SMTP id 133mr11802787pfc.242.1570732601725; Thu, 10 Oct 2019 11:36:41 -0700 (PDT) MIME-Version: 1.0 References: <20191008053507.252202-1-zenczykowski@gmail.com> <20191008053507.252202-2-zenczykowski@gmail.com> <20191008060414.GB25052@breakpoint.cc> In-Reply-To: From: Cong Wang Date: Thu, 10 Oct 2019 11:36:30 -0700 Message-ID: Subject: Re: [PATCH 2/2] netfilter: revert "conntrack: silent a memory leak warning" To: =?UTF-8?Q?Maciej_=C5=BBenczykowski?= Cc: Florian Westphal , "David S . Miller" , Linux NetDev , Eric Dumazet , Pablo Neira Ayuso Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Oct 8, 2019 at 12:10 AM Maciej =C5=BBenczykowski wrote: > > Here's my reasoning: > > old =3D ct->ext; > > //... stuff that doesn't change old. > > alloc =3D max(newlen, NF_CT_EXT_PREALLOC); <-- will be >=3D 128, > so not zero > kmemleak_not_leak(old); > new =3D __krealloc(old, alloc, gfp); > if (!new) > return NULL; <--- if we return here, ct->ext still > holds old, so no leak. > > if (!old) { > memset(new->offset, 0, sizeof(new->offset)); > ct->ext =3D new; <--- old is NULL so can't leak > } else if (new !=3D old) { > kfree_rcu(old, rcu); <-- we free old, so doesn't leak > rcu_assign_pointer(ct->ext, new); > } <--- else new =3D=3D old && it's still in ct->ext, so it doesn'= t leak > So you conclude as it is not leak too? Then what are you trying to fix? I am becoming more confused after this. :-/ > Basically AFAICT our use of __krealloc() is exactly like krealloc() > except instead of kfree() we do kfree_rcu(). > > And thus I don't understand the need for kmemleak_not_leak(old). kfree_rcu() is a callback deferred after a grace period, so if we allocate the memory again before that callback, it is reported to kmemleak as a memory leak unless we mark it as not, right? Or kfree_rcu() works nicely with kmemleak which I am not aware of? Thanks.