All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Ken-ichirou MATSUZAWA <chamaken@gmail.com>
Cc: The netfilter developer mailinglist
	<netfilter-devel@vger.kernel.org>,
	Pablo Neira Ayuso <pablo@netfilter.org>
Subject: Re: [RFC PATCH 1/1 libnetfilter_conntrack] zero value handling of mark and zone
Date: Thu, 12 Jun 2014 02:18:07 +0200	[thread overview]
Message-ID: <20140612001807.GB22240@breakpoint.cc> (raw)
In-Reply-To: <CAGCkEt0oek-eZxd9Xetpyj5iqaHK1c+qqLaNP6MJ58cMNLNnSQ@mail.gmail.com>

Ken-ichirou MATSUZAWA <chamaken@gmail.com> wrote:
> This patch enables comparison of 0 value with mark and zone since
> both CTA_MARK and CTA_ZONE are not set in case of its value is 0.

I think the general idea is right.

When nfct_cmp is invoked with 'full compare' then two conntracks
should be regarded the same if they only differ in 'zone unset'
and 'zone set and it is 0', as a unset zone does imply a 0.

Maybe it is better to alter cmp_meta() and invoke a different
comparator for MARK and ZONE that will give 'extra chance'
when we hit the NFCT_CMP_STRICT conditional, i.e.

>         } else if (flags & NFCT_CMP_STRICT) {

One way might be to add __cmp_harder() which is same as __cmp() but
will invoke cmp() again in the CMP_STRICT case.

Then, cmp_zone() could be altered to do

return nfct_attr_get_u16(ct1) == nfct_attr_get_u16(ct2)

Which should fix this problem (get_u16 of unset attr returns 0).

Alternatively of course we could change __cmp() to always
invoke the cmp() function again in STRICT case but it probably
requires a lot more changes/care since we'd have to fix all the
other attribute specific comparators.

  reply	other threads:[~2014-06-12  0:18 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-11 23:42 [RFC PATCH 1/1 libnetfilter_conntrack] zero value handling of mark and zone Ken-ichirou MATSUZAWA
2014-06-12  0:18 ` Florian Westphal [this message]
2014-06-12  5:19   ` Ken-ichirou MATSUZAWA
2014-06-12  9:48     ` Florian Westphal
2014-06-12 11:33       ` Ken-ichirou MATSUZAWA
2014-06-12 11:59         ` Florian Westphal
2014-06-12 13:43           ` Ken-ichirou MATSUZAWA
2014-06-12 14:05             ` Florian Westphal
2014-06-12 23:12               ` Ken-ichirou MATSUZAWA
2014-06-16  0:04       ` Ken-ichirou MATSUZAWA
2014-06-16 11:41         ` Florian Westphal
2014-06-16 13:20           ` Ken-ichirou MATSUZAWA
2014-06-16 13:24             ` Florian Westphal

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=20140612001807.GB22240@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=chamaken@gmail.com \
    --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 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.