From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Phil Sutter <phil@nwl.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 16:32:30 +0200 [thread overview]
Message-ID: <20170718143230.GA6745@salvia> (raw)
In-Reply-To: <20170718091726.GW16375@orbyte.nwl.cc>
On Tue, Jul 18, 2017 at 11:17:26AM +0200, Phil Sutter wrote:
> On Tue, Jul 18, 2017 at 11:09:37AM +0200, Pablo Neira Ayuso wrote:
> > On Tue, Jul 18, 2017 at 11:05:16AM +0200, Phil Sutter wrote:
> > > 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.
> >
> > I suggest you add a new flag to SET_ELEM instead. Userdata area usage
> > is exclusive to userspace.
>
> You mean nft_set_elem_flags? The new flag will indeed be used by
> userspace only: It is set when creating a half-open range and not used
> by the kernel at all.
That's fine indeed.
next prev parent reply other threads:[~2017-07-18 14:32 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
2017-07-18 9:09 ` Pablo Neira Ayuso
2017-07-18 9:17 ` Phil Sutter
2017-07-18 14:32 ` Pablo Neira Ayuso [this message]
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=20170718143230.GA6745@salvia \
--to=pablo@netfilter.org \
--cc=arturo@netfilter.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=phil@nwl.cc \
/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.