All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Arturo Borrero Gonzalez <arturo.borrero.glez@gmail.com>
Cc: Netfilter Development Mailing list <netfilter-devel@vger.kernel.org>
Subject: Re: [ebtables-compat PATCH] ebtables-compat: fix ACCEPT printing by simplifying logic
Date: Thu, 15 Jan 2015 13:51:06 +0100	[thread overview]
Message-ID: <20150115125106.GA8896@salvia> (raw)
In-Reply-To: <CAOkSjBiG0KPZRfJuw2skqDuL8u6nEi8uyQmmSNbdZd4A7UEv0Q@mail.gmail.com>

On Thu, Jan 15, 2015 at 01:44:16PM +0100, Arturo Borrero Gonzalez wrote:
> On 15 January 2015 at 13:32, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > On Tue, Jan 13, 2015 at 06:36:10PM +0100, Arturo Borrero Gonzalez wrote:
> >> The commit bc543af ("ebtables-compat: fix segfault in rules w/o target")
> >> doesn't handle all possible cases of target printing, and ACCEPT is left
> >> behind.
> >>
> >> BTW, the logic of target (-j XXX) printing is a bit weird. This patch
> >> simplifies it.
> >>
> >> I assume:
> >>  * cs->jumpto is only filled by nft_immediate.
> >>  * cs->target is only filled by nft_target.
> >>
> >> So we end with these cases:
> >>  * nft_immediate contains a 'standard' target (ACCEPT, DROP, CONTINUE, RETURN, chain)
> >>   Then cs->jumpto contains the target already. We have the rule.
> >>  * No standard target. If nft_target contains a target, try to load it.
> >>  * Neither nft_target nor nft_immediate exist. Then, assume CONTINUE.
> >>
> >> The printing path is then straight forward: either cs.jumpto or cs.target
> >> contains the target.
> >>
> >> As there isn't support for target extensions yet, there is no way to test the
> >> nft_target (cs.target) path.
> >
> > Not telling this is wrong, but I guess the resulting code to print the
> > target has to converge to what we have in iptables-compat (see
> > iptables/nft-ipv4.c). I mean, the handling should look similar. Could
> > you revisit that and make sure that this and the existing code
> > converge to the point? Thanks.
> 
> I could try to factorize code to a common function, something like:
> void nft_shared_rule_translate_target(char **jumpto, struct
> xtables_target **target)
> void nft_shared_print_target(const char *jumpto, const struct
> xtables_target *target)
> 
> Do you like the idea?

Yes, the more we consolidate the less redundancy. Please, for the
function names, I'd suggest a bit shorter ones: nft_set_target() and
nft_print_target() I'd say.

  reply	other threads:[~2015-01-15 12:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-13 17:36 [ebtables-compat PATCH] ebtables-compat: fix ACCEPT printing by simplifying logic Arturo Borrero Gonzalez
2015-01-15 12:32 ` Pablo Neira Ayuso
2015-01-15 12:44   ` Arturo Borrero Gonzalez
2015-01-15 12:51     ` Pablo Neira Ayuso [this message]
2015-01-15 14:56       ` Arturo Borrero Gonzalez

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=20150115125106.GA8896@salvia \
    --to=pablo@netfilter.org \
    --cc=arturo.borrero.glez@gmail.com \
    --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.