Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp4958484imm; Sun, 22 Jul 2018 09:40:57 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcXiqmLWOhrJ25lb9kw4IxIY1VtRGqK1/qFRQT8EOHfMgUhD11mtO48hv5tSZV29rqStu99 X-Received: by 2002:a17:902:aa07:: with SMTP id be7-v6mr9564637plb.109.1532277657542; Sun, 22 Jul 2018 09:40:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532277657; cv=none; d=google.com; s=arc-20160816; b=sLhzBx+eCOq+e0yLQz+tkYqPcEKg4/MwCWTnP0dQgB6jaQBSTT/uaB/NKzWPRDFGmR qr4lDIcNU9jbfyeC5l/LRb9Dv8BJDubXjV2y4ScEH2Xhu4kvJrdsyWCLOkPoEjoeidp7 22MWY1Tn/psYPNMSlqK2CWGxdFi4WQ4ZL7+oOg6FHBDrebu3+SxhD9gu6vYn+57g3RNH IYcqTxFf1z/N701Nsje9fE4EOzOUv0L0sEaOzI0WtF0py6CuUBxWsX9zlHMdOsuIFoh4 Horml++MUNJpiIRJhdR/dgdhZU6UklbW9L7uzBVgK9PQEVXzOky3J5ZHrvAOSRCJPRpy jDlQ== 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=ReZ0sD1Xgt8gYtuSZOGv7H0QbxGxN+xK/EtW3Ae3vE4=; b=tvfYe+6bsW3nYQenJYBhH2HZi65hiq5aeFvFFnlprbgEZhrvm6oKDWYkjhycVZQikT SpVYFnTYlj2GPLmiX8G4LKFXVG/Bc2XaVRHSulFQma8B9d4kYPTsSSMpI/IdPADF3oWJ ms0+8acwtbxU94YYubQv3tuWeHf81/0lz6fLp0RWv14Je3cmerza5FMNc4/jfL4k73Oo uydF4NUH7rn9rScdZNdBx5Qbhb6p+HyvdupbuT5AUT3lYuZKwmMwUaYqQ3EGSjGVhSHS 7DSGuQElOhqvE5ruJ8RDul6NSSDpDh6faeiATIxirhdKzH9wDeMeYmYoz/LyiR60rec6 Lr4g== 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 m12-v6si6709286pgk.305.2018.07.22.09.40.42; Sun, 22 Jul 2018 09:40:57 -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 S1730365AbeGVRg6 (ORCPT + 99 others); Sun, 22 Jul 2018 13:36:58 -0400 Received: from Chamillionaire.breakpoint.cc ([146.0.238.67]:33408 "EHLO Chamillionaire.breakpoint.cc" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729336AbeGVRg6 (ORCPT ); Sun, 22 Jul 2018 13:36:58 -0400 Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.89) (envelope-from ) id 1fhHOH-0003nn-6N; Sun, 22 Jul 2018 18:39:25 +0200 Date: Sun, 22 Jul 2018 18:39:25 +0200 From: Florian Westphal To: Shaochun Chen Cc: pablo@netfilter.org, kadlec@blackhole.kfki.hu, fw@strlen.de, davem@davemloft.net, johannes.berg@intel.com, Jason@zx2c4.com, ktkhai@virtuozzo.com, lucien.xin@gmail.com, xiyou.wangcong@gmail.com, dsahern@gmail.com, netfilter-devel@vger.kernel.org, tom@quantonium.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] netlink: fix memory leak of dump Message-ID: <20180722163925.gdfkndldatsoae6x@breakpoint.cc> References: <20180722143354.23722-1-cscnull@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180722143354.23722-1-cscnull@gmail.com> 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 Shaochun Chen wrote: [ CC ing Tom, as he added ->start() ] > 1) if netlink_dump_start start fail, the memory of c->data will leak. > so free manually after netlink_dump_start return error. > > 2) In netlink_dump_start, ignore the return of netlink_dump. > Because if cb_running is set to true, cb->dump will be call in anyway. > so if netlink_dump_start start successfully, just return -EINTR. This now requires ->start() to not return -EINVAL, else we won't release resources either, this seems fragile to me. I can only think of three ways to address this: 1. Kill ->start() and force all users to defer state allocation to first ->dump() invocation, so existing ->done() can be used to release resources. OR 2. add ->stop() and have core always pair it with ->start(), no matter if dump() got called or not, then convert all places that provide .start to use .stop, not .done. OR 3. change meaning of ->done() so its always called once ->start() was invoked (and returned 0), this requires audit of all places that provide .done to make sure they won't trip. 3) seems to be what Tom intended when he added .start, so probably best to investigate that first.