Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp4980023imm; Sun, 22 Jul 2018 10:09:52 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdvmdkwOTmbZeXWN6OHqNkm1LfqZMNfvP+EhrDJQVZ6o+x4NKA9FwLdYlG/Kh+dVJJXGsv3 X-Received: by 2002:a17:902:bc49:: with SMTP id t9-v6mr9720385plz.116.1532279392827; Sun, 22 Jul 2018 10:09:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532279392; cv=none; d=google.com; s=arc-20160816; b=Njibgp6BZfdHAWJA8gW1/IxYC+uIppliveZE5nc4nGtkgLZsLnn8wiqquBVxr6XOqw qHXQqz2xQRacur6l5ocMJojP8k7FUSqu+rKjVBAd8HTY/eEGiCPxh9O+8Cm4sumJzayU LaJDS22C+5TnDcGDqBRDF3DSwD3mMExeJhc4XVIwzjO1Am+v4LWZnoM4mea5iqdI/xwA IL2uQVsBfpCwBI5rMYK9QNDecZUWwtbpFN3y7HLcFAdr1l3GvgeZe1sKw4bZFoDr3z+C CmdfiuOI9szhvH0rZKAAbDzPfOHxkpXQ7urMObpVQMJ0EdFWYuCP0leteNwJpWe+EiMc JDmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date :arc-authentication-results; bh=OfE4beWQYuZzvLScAtvUckrTsvizqMBdUTJIonZLIvs=; b=IXKaaicNR27XVk9pkmCwTOptbU4bYBmo6AwBtnh73HRn7SOurea9g7UdtS10b0NHYq gY3cRxmR3ltWNOozsIwf0vjlBzqGJba9PCZnrOpQVJaUvvrNNFlZh7zDhJUDUeTSh+Fg vC0lYZTXAhBAQQObLBUpcZxWgHuPrZCI4GjZUMaTVFnTzUy0b8aJf9Ut1V4LxvIUT1/h QKw5m2xw7NjBoDgJ/996R/zo2aJ3911xbXAtsNlXsh5e54kQHu8aH98bJYlQtLN+Vv/U nG02cGDUlZRygsXXgYFu+i6Zl500ro+VBHE5+q+xC1QzS2fNgZykRTpjIyYiTfRFn2lk aD3g== 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 t7-v6si6578128pfh.3.2018.07.22.10.09.25; Sun, 22 Jul 2018 10:09: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 S1730222AbeGVSFR (ORCPT + 99 others); Sun, 22 Jul 2018 14:05:17 -0400 Received: from shards.monkeyblade.net ([23.128.96.9]:56998 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729893AbeGVSFQ (ORCPT ); Sun, 22 Jul 2018 14:05:16 -0400 Received: from localhost (unknown [172.58.43.229]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 261CB128F4E9A; Sun, 22 Jul 2018 10:07:56 -0700 (PDT) Date: Sun, 22 Jul 2018 10:07:55 -0700 (PDT) Message-Id: <20180722.100755.19840167505550163.davem@davemloft.net> To: fw@strlen.de Cc: cscnull@gmail.com, pablo@netfilter.org, kadlec@blackhole.kfki.hu, 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 From: David Miller In-Reply-To: <20180722163925.gdfkndldatsoae6x@breakpoint.cc> References: <20180722143354.23722-1-cscnull@gmail.com> <20180722163925.gdfkndldatsoae6x@breakpoint.cc> X-Mailer: Mew version 6.7 on Emacs 26 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Sun, 22 Jul 2018 10:07:57 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Florian Westphal Date: Sun, 22 Jul 2018 18:39:25 +0200 > 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. Hmmm... Any time ->start() succeeds, we set cb_running to true. From that point forward, ->done() will be called at some point at all of the locations that check if cb_running is true and set it to false. This may be deferred all the way to socket destruction, but it will eventually happens. Nothing sets cb_running to false without invoking the ->done() callback. Just because the individual dump invocations don't call ->done() does not mean it will not eventually happen. The dump callbacks, and thus the state data, is live across multiple rounds of recvmsg() calls by the user and that is as-designed.