From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Eric Leblond <eric@regit.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [nft PATCH 0/7] some memory leak fixes
Date: Mon, 17 Jul 2017 17:24:15 +0200 [thread overview]
Message-ID: <20170717152415.GA26229@salvia> (raw)
In-Reply-To: <20170710223255.29885-1-eric@regit.org>
On Tue, Jul 11, 2017 at 12:32:48AM +0200, Eric Leblond wrote:
>
> Hi,
>
> Here's a small patchset fixing some memory leaks in nftables. Most
> of them have been found using ASAN.
Series applied, thanks Eric.
> There is still a problem in memory handling due to the max_errors
> system that stack errors to avoid an exit on first error. The
> consequence is that the bison parser is loosing track of its
> internal stacks and can not call the destructors when there
> is an error in the command.
Probably we need explicit object tracking via list insertion, then
rewind and release them? Would that be possible? I would expect this
triggers a large patchset to do this right.
> If we do set max_errors to 1:
>
> diff --git a/src/main.c b/src/main.c
> index 7fbf00a..183bd0e 100644
> --- a/src/main.c
> +++ b/src/main.c
> @@ -29,7 +29,7 @@
> #include <cli.h>
>
> static struct nft_ctx nft;
> -unsigned int max_errors = 10;
> +unsigned int max_errors = 1;
> #ifdef DEBUG
> unsigned int debug_level;
> #endif
>
> Then there is no more memory leak in case of an invalid command
> but we loose the display of multiple errors.
>
> A possibleway to fix that would be to be able to set max_errors
> via a configuration function. It would be set to 1 by default.
> So users of libnftables will not experiment memleak but we
> could keep the same behavior in nft by setting it to 10
> explicetely.
I would prefer we find a way to fix this without adding this
limitation.
Let me know, thanks!
prev parent reply other threads:[~2017-07-17 15:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-10 22:32 [nft PATCH 0/7] some memory leak fixes Eric Leblond
2017-07-10 22:32 ` [nft PATCH 1/7] src: fix memory leak when listing rules Eric Leblond
2017-07-10 22:32 ` [nft PATCH 2/7] parser: fix memory leak in set creation Eric Leblond
2017-07-10 22:32 ` [nft PATCH 3/7] parser: fix bison warnings Eric Leblond
2017-07-10 22:32 ` [nft PATCH 4/7] parser: error if needed at EOF Eric Leblond
2017-07-10 22:32 ` [nft PATCH 5/7] evaluate: fix build with clang Eric Leblond
2017-07-10 22:32 ` [nft PATCH 6/7] scanner: free filename when destroying scanner Eric Leblond
2017-07-10 22:32 ` [nft PATCH 7/7] cli: fix heap buffer overflow Eric Leblond
2017-07-17 15:24 ` Pablo Neira Ayuso [this message]
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=20170717152415.GA26229@salvia \
--to=pablo@netfilter.org \
--cc=eric@regit.org \
--cc=netfilter-devel@vger.kernel.org \
/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.