All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Phil Sutter <phil@nwl.cc>, netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nft] rule: memleak in __do_add_setelems()
Date: Thu, 30 Apr 2020 16:47:14 +0200	[thread overview]
Message-ID: <20200430144714.GA1454@salvia> (raw)
In-Reply-To: <20200430135217.GJ15009@orbyte.nwl.cc>

On Thu, Apr 30, 2020 at 03:52:17PM +0200, Phil Sutter wrote:
> Hi Pablo,
> 
> On Thu, Apr 30, 2020 at 03:08:20PM +0200, Pablo Neira Ayuso wrote:
> > On Thu, Apr 30, 2020 at 02:18:45PM +0200, Pablo Neira Ayuso wrote:
> > > This patch invokes interval_map_decompose() with named sets:
> > > 
> > > ==3402== 2,352 (128 direct, 2,224 indirect) bytes in 1 blocks are definitely lost in loss record 9 of 9
> > > ==3402==    at 0x483577F: malloc (vg_replace_malloc.c:299)
> > > ==3402==    by 0x48996A8: xmalloc (utils.c:36)
> > > ==3402==    by 0x4899778: xzalloc (utils.c:65)
> > > ==3402==    by 0x487CB46: expr_alloc (expression.c:45)
> > > ==3402==    by 0x487E2A0: mapping_expr_alloc (expression.c:1140)
> > > ==3402==    by 0x4898AA8: interval_map_decompose (segtree.c:1095)
> > > ==3402==    by 0x4872BDF: __do_add_setelems (rule.c:1569)
> > > ==3402==    by 0x4872BDF: __do_add_setelems (rule.c:1559)
> > > ==3402==    by 0x4877936: do_command (rule.c:2710)
> > > ==3402==    by 0x489F1CB: nft_netlink.isra.5 (libnftables.c:42)
> > > ==3402==    by 0x489FB07: nft_run_cmd_from_filename (libnftables.c:508)
> > > ==3402==    by 0x10A9AA: main (main.c:455)
> > > 
> > > Fixes: dd44081d91ce ("segtree: Fix add and delete of element in same batch")
> > 
> > This fixes the problem for anonymous sets, still named sets are
> > showing a memleak.
> 
> The change is strange: My fix (dd44081d91ce) was about anonymous sets.

It was about named sets, right?

# nft 'add element t s { 22-25 }; delete element t s { 22-25 }'

I think the cache update is still not needed for anonymous sets, even
if this was not the right fix indeed.

> Since you make the added code apply to non-anonymous sets only, I would
> expect for my testcase to start failing again (I didn't test it,
> though).
> 
> Are we maybe missing a free() somewhere instead?

I think I found the root cause:

https://marc.info/?l=netfilter-devel&m=158825784609307&w=2

  reply	other threads:[~2020-04-30 14:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-30 12:18 [PATCH nft] rule: memleak in __do_add_setelems() Pablo Neira Ayuso
2020-04-30 13:08 ` Pablo Neira Ayuso
2020-04-30 13:52   ` Phil Sutter
2020-04-30 14:47     ` Pablo Neira Ayuso [this message]
2020-04-30 15:41       ` Phil Sutter
2020-04-30 15:46         ` Pablo Neira Ayuso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200430144714.GA1454@salvia \
    --to=pablo@netfilter.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=phil@nwl.cc \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.