All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Sutter <phil@nwl.cc>
To: Florian Westphal <fw@strlen.de>
Cc: Martin Gignac <martin.gignac@gmail.com>,
	netfilter@vger.kernel.org,
	netfilter-devel <netfilter-devel@vger.kernel.org>
Subject: Re: Unable to create a chain called "trace"
Date: Wed, 17 Feb 2021 20:59:37 +0100	[thread overview]
Message-ID: <20210217195937.GA22016@orbyte.nwl.cc> (raw)
In-Reply-To: <20210212122007.GE2766@breakpoint.cc>

Hi,

On Fri, Feb 12, 2021 at 01:20:07PM +0100, Florian Westphal wrote:
> Phil Sutter <phil@nwl.cc> wrote:
> > I didn't find a better way to conditionally parse two following args as
> > strings instead of just a single one. Basically I miss an explicit end
> > condition from which to call BEGIN(0).
> 
> Yes, thats part of the problem.
> 
> > > Seems we need allow "{" for "*" and then count the {} nests so
> > > we can pop off a scanner state stack once we make it back to the
> > > same } level that we had at the last state switch.
> > 
> > What is the problem?
> 
> Detect when we need to exit the current start condition.

I explored my approach further but ended up in an ugly situation due to
the use of 'set' keyword in rules: My code is not context-aware, so upon
recognizing 'set' keyword it switches to spec-condition. I can't simply
detect preceding command-keywords due to them being implicit in nested
notation.

> We may not even be able to do BEGIN(0) if we have multiple, nested
> start conditionals. flex supports start condition stacks, but that
> still leaves the exit/closure issue.
> 
> Example:
> 
> table chain {
>  chain bla {  /* should start to recognize rules, but
> 		 we did not see 'rule' keyword */

My code worked with this after enabling detection of '{' in all
conditions and making it call BEGIN(0) (regardless of nspec value).

> 	ip saddr { ... } /* can't exit rule start condition on } ... */

Maybe we could track nesting block depth in a simple counter?

> 	ip daddr { ... }
>  }  /* should disable rule keywords again */
> 
>  chain dynamic { /* so 'dynamic' is a string here ... */
>  }
> }
> 
> I don't see a solution, perhaps add dummy bison rule(s)
> to explicitly signal closure of e.g. a rule context?

We can't influence start conditions from within bison (if that's what
you had in mind). All we can do is try make flex aware of the current
input context. For instance, detect 'table' followed by '{' to open
"table definition context" and start tracking braces to detect its end.
Though after all I think your assessment of all this being "fragile" is
appropriate. :/

Cheers, Phil

  parent reply	other threads:[~2021-02-17 20:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-08 15:37 Unable to create a chain called "trace" Martin Gignac
2021-02-08 15:49 ` Florian Westphal
2021-02-08 16:47   ` Phil Sutter
2021-02-08 17:14     ` Florian Westphal
2021-02-09 13:56       ` Phil Sutter
2021-02-12  0:05         ` Florian Westphal
2021-02-12 11:40           ` Phil Sutter
2021-02-12 12:20             ` Florian Westphal
2021-02-12 17:09               ` Pablo Neira Ayuso
2021-02-12 17:32                 ` Phil Sutter
2021-02-12 17:54                   ` Pablo Neira Ayuso
2021-02-12 21:07                     ` Phil Sutter
2021-02-12 18:02               ` Balazs Scheidler
2021-02-17 19:59               ` Phil Sutter [this message]
2021-02-17 20:16                 ` Florian Westphal
2021-02-12 12:29     ` Florian Westphal
2021-02-12 12:48       ` Phil Sutter

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=20210217195937.GA22016@orbyte.nwl.cc \
    --to=phil@nwl.cc \
    --cc=fw@strlen.de \
    --cc=martin.gignac@gmail.com \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=netfilter@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.