netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Fasnacht <fasnacht@protonmail.ch>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nft include v2 7/7] scanner: remove parser_state->indesc_idx
Date: Tue, 11 Feb 2020 05:04:17 +0000	[thread overview]
Message-ID: <5YhGob-vtZBW2TpVr0wlC1uha0ngkIOCr9Q7l02x-d2taByz2al-VOPhZ-DTMTk14YwiztBS4SoL2A2qtN9lNpe0pxdXLBAFFYHJNTAwucE=@protonmail.ch> (raw)
In-Reply-To: <20200210223153.siwzx76uhnxurkj2@salvia>

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, February 10, 2020 11:31 PM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:

> On Mon, Feb 10, 2020 at 10:17:28AM +0000, Laurent Fasnacht wrote:
> > static void scanner_pop_indesc(struct parser_state *state)
> > {
> >
> > -   state->indesc_idx--;
> >     if (!list_empty(&state->indesc_list)) {
> >     state->indesc = list_entry(state->indesc->list.prev, struct input_descriptor, list);
> >     } else {
> >     @@ -968,10 +966,6 @@ void scanner_destroy(struct nft_ctx *nft)
> >     {
> >     struct parser_state *state = yyget_extra(nft->scanner);
> >
> > -   do {
> >
> > -       yypop_buffer_state(nft->scanner);
> >
> >
>
> nft_pop_buffer_state calls free().
>
> Are you sure this can be removed without incurring in memleaks?

I'm pretty sure it can, since scanner_destroy is only called from outside of the scanner itself (and I'm expecting calling that function during the parsing might break a lot things ;-).

In my understanding, any file that is being parsed should reach the end of file at some point, and therefore have scanner_pop_buffer called. This is true also in case of parsing errors.

I've tested that understanding by counting the number of yypush and yypop calls in various cases, and by adding an assert in scanner_destroy (which consist in asserting that the "active" part of the stack is empty):

assert(state->indesc->list.next == state->indesc_list.next);

This has succeeded both for the test suite and for the very complex rule set I'm working on currently.

Just as a comment about the stack: in implementation with patch 6/7 applied, it consists in two parts, the active part and the "dangling tail".  The start of the stack is in state->indesc_list, and the active element (in state->indesc) is the end of the active part. All the elements in the active part of the stack have buffer pushed. When parsing a file ends, the buffer is popped and state->indesc is moved (but the input descriptor itself is not removed from the list, so it stays in the tail part until scanner_destroy is called).

      reply	other threads:[~2020-02-11  5:04 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-10 10:17 [PATCH nft include v2 0/7] Improve include behaviour Laurent Fasnacht
2020-02-10 10:17 ` [PATCH nft include v2 1/7] tests: shell: add test for glob includes Laurent Fasnacht
2020-02-12 20:45   ` Pablo Neira Ayuso
2020-02-10 10:17 ` [PATCH nft include v2 2/7] scanner: move the file descriptor to be in the input_descriptor structure Laurent Fasnacht
2020-02-10 22:46   ` Pablo Neira Ayuso
2020-02-10 10:17 ` [PATCH nft include v2 3/7] scanner: move indesc list append in scanner_push_indesc Laurent Fasnacht
2020-02-10 22:46   ` Pablo Neira Ayuso
2020-02-10 10:17 ` [PATCH nft include v2 4/7] scanner: remove parser_state->indescs static array Laurent Fasnacht
2020-02-10 23:32   ` Pablo Neira Ayuso
2020-02-11  4:36     ` Laurent Fasnacht
2020-02-12 20:45   ` Pablo Neira Ayuso
2020-02-10 10:17 ` [PATCH nft include v2 5/7] scanner: correctly compute include depth Laurent Fasnacht
2020-02-10 10:17 ` [PATCH nft include v2 6/7] scanner: fix indesc_list stack to be in the correct order Laurent Fasnacht
2020-02-10 22:33   ` Pablo Neira Ayuso
2020-02-11  4:42     ` Laurent Fasnacht
2020-02-10 10:17 ` [PATCH nft include v2 7/7] scanner: remove parser_state->indesc_idx Laurent Fasnacht
2020-02-10 22:31   ` Pablo Neira Ayuso
2020-02-11  5:04     ` Laurent Fasnacht [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='5YhGob-vtZBW2TpVr0wlC1uha0ngkIOCr9Q7l02x-d2taByz2al-VOPhZ-DTMTk14YwiztBS4SoL2A2qtN9lNpe0pxdXLBAFFYHJNTAwucE=@protonmail.ch' \
    --to=fasnacht@protonmail.ch \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).