netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Florian Westphal <fw@strlen.de>, netfilter-devel@vger.kernel.org
Subject: Re: [RFC PATCH -next] netfilter: nfqueue: add ability to dump list of supported attributes
Date: Thu, 20 Jun 2013 23:40:03 +0200	[thread overview]
Message-ID: <20130620214003.GA16008@breakpoint.cc> (raw)
In-Reply-To: <20130620182701.GA8769@localhost>

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Tue, Jun 04, 2013 at 05:37:53PM +0200, Florian Westphal wrote:
> > Allows userspace to dump the list of known (extended) attributes.
> > For SKB_INFO, we set all the info flag bits supported by the running kernel.
> > 
> > The latter is required because absence of some bits in the info attribute will
> > either mean "skb did not have the property" OR "this kernel doesn't know about
> > this flag".
> >
> > Signed-off-by: Florian Westphal <fw@strlen.de>
> > ---
> >  Recent discussion of the
> >  "netfilter: nf_queue: add NFQA_SKB_CSUM_NOTVERIFIED info flag" patch
> >  (http://patchwork.ozlabs.org/patch/246460/) shows that we'll need
> >  to tell userspace the supported info bits in the NFAQ_SKB_INFO attribute.
> 
> After going back to this issue, I think I prefer to enqueue:
> 
> netfilter: nf_queue: add NFQA_SKB_CSUM_NOTVERIFIED info flag
> 
> to net-next, and ask for -stable submission once this hits net, as it
> will be fixing an inconsistent behaviour. Another reason for that is
> that such patch is fairly small (~16 LOC).
> 
> Both approaches we discussed that are:
> 
> a) adding a new config flags
> 
> and
> 
> b) adding this infrastructure
> 
> look a bit too much to me just to resolve this.
> 
> Once this patch hits -stable, we can consistently say that:
> 
> NFQA_SKB_CSUMNOTREADY
> NFQA_SKB_GSO
> NFQA_SKB_CSUM_NOTVERIFIED
> 
> are obtained via NFQA_CFG_F_GSO.
> 
> For user-space application running with different, they can still send
> every configuration incrementally, so you spot a message telling what
> is available and what is not. I planned to use this to add GSO support
> for the user-space helper infrastructure.
> 
> Let me know.

I have no objections.

However, we cannot escape this forever -- it will be insanity to just
ask for -stable submission whenever a new flag is added and expect noone
to yell at us :-)

But for the time being, sure, b) _is_ overkill.

      reply	other threads:[~2013-06-20 21:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-04 15:37 [RFC PATCH -next] netfilter: nfqueue: add ability to dump list of supported attributes Florian Westphal
2013-06-20 18:27 ` Pablo Neira Ayuso
2013-06-20 21:40   ` Florian Westphal [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=20130620214003.GA16008@breakpoint.cc \
    --to=fw@strlen.de \
    --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).