netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Phil Sutter <phil@nwl.cc>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org,
	Arturo Borrero Gonzalez <arturo@netfilter.org>
Subject: Re: [nft PATCH 1/2] monitor: Rewrite SETELEM callback
Date: Tue, 18 Jul 2017 11:05:16 +0200	[thread overview]
Message-ID: <20170718090516.GU16375@orbyte.nwl.cc> (raw)
In-Reply-To: <20170717171629.GA2221@salvia>

On Mon, Jul 17, 2017 at 07:16:29PM +0200, Pablo Neira Ayuso wrote:
> On Mon, Jul 17, 2017 at 06:41:14PM +0200, Phil Sutter wrote:
> > On Mon, Jul 17, 2017 at 06:30:18PM +0200, Pablo Neira Ayuso wrote:
> > > On Mon, Jul 17, 2017 at 05:06:05PM +0200, Phil Sutter wrote:
> > > [...]
> > > > +static int netlink_events_setelem_newgen_cb(const struct nlmsghdr *nlh,
> > > > +					    int type,
> > > > +					    struct netlink_mon_handler *monh)
> > > > +{
> > > > +	setelem_cache_print_default(monh);
> > > > +
> > > > +	return MNL_CB_OK;
> > > >  }
> > > 
> > > I would really like we don't rely on newgen for this. If there is no
> > > way to catch a case with the existing way we represent this, then we
> > > probably need to fix things from the kernel.
> > > 
> > > Before we follow that patch, I would like to understand what corner
> > > case is pushing us to use the newgen event.
> > 
> > It is required for half-open ranges occurring at the end of the
> > transaction: For those, we only get a single element without
> > EXPR_F_INTERVAL_END flag set. Since this could also be the first part of
> > a regular range, monitor has to wait for what's next - which is in doubt
> > only the NEWGEN message.
> > 
> > Maybe we could introduce a new flag to mark these?
> 
> Right, I think we need the new flag indeed, only for userspace.
> 
> Would you propose one and the specific semantics for it?

My current PoC passes the additional flag as userdata attribute so the
kernel won't reject the element due to unknown flag. Is that fine with
you? I'm trying to avoid changing the kernel so the solution is
backwards compatible.

Cheers, Phil

  reply	other threads:[~2017-07-18  9:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-17 15:06 [nft PATCH v2 0/2] monitor: Fix printing of range elements in named sets Phil Sutter
2017-07-17 15:06 ` [nft PATCH 1/2] monitor: Rewrite SETELEM callback Phil Sutter
2017-07-17 16:30   ` Pablo Neira Ayuso
2017-07-17 16:41     ` Phil Sutter
2017-07-17 17:16       ` Pablo Neira Ayuso
2017-07-18  9:05         ` Phil Sutter [this message]
2017-07-18  9:09           ` Pablo Neira Ayuso
2017-07-18  9:17             ` Phil Sutter
2017-07-18 14:32               ` Pablo Neira Ayuso
2017-07-17 15:06 ` [nft PATCH 2/2] tests: Add basic monitor testing framework 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=20170718090516.GU16375@orbyte.nwl.cc \
    --to=phil@nwl.cc \
    --cc=arturo@netfilter.org \
    --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).