All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vasily Averin <vvs@parallels.com>
To: Florian Westphal <fw@strlen.de>
Cc: bridge@lists.linux-foundation.org,
	Patrick McHardy <kaber@trash.net>,
	Stephen Hemminger <stephen@networkplumber.org>,
	netfilter-devel@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Bridge] [PATCH 1/1] superfluous skb->nfct check in br_nf_dev_queue_xmit
Date: Mon, 28 Apr 2014 16:37:08 +0400	[thread overview]
Message-ID: <535E4B74.4050107@parallels.com> (raw)
In-Reply-To: <20140424163243.GN31953@breakpoint.cc>

On 04/24/2014 08:32 PM, Florian Westphal wrote:
> Vasily Averin <vvs@parallels.com> wrote:
>> Please do not apply my patch, probably it breaks processing of VLAN packets.
> 
> Why would it break VLAN?
Sorry, seems it was false alert.

We got report about problem on RHEL6-based OpenVZ kernel:
large UDP and ICMP packets was dropped on bridge without incrementing of any failcounters.
Connection tracking was disabled on this node , nf_conntrack module was unloaded
Ftrace pointed that it was happen because nfct check.

I've unloaded nf_conntrack module and problem was reproduced again
After removing nfct check problem went away.

The check was added by patch that fixed processing of VLAN packets.
I did not tested this scenario and therefore asked to delay processing of my patch,
to investigate this case more carefully.

IS_VLAN_IP() check on RHEL6 kernels seems is not depend on nfct check,
in current mainline we do not have this code at all, 
therefore removing of nfct check should not affect this case too.

Therefore I believe that my patch is still correct, however now I think we also need 
to remove #if IS_ENABLED(CONFIG_NF_CONNTRACK_IPV4) in br_nf_dev_queue_xmit().

> In fact, the same dicussion came up couple of days back and I think the
> nfct test is wrong.  There is no guarantee that skb->nfct == NULL means
> that packet was not defragmented via nf_defrag (e.g. rror in l4 protocol
> tracker, nf_defrag_ipv4 loaded but no nf_conntrack_ipv4)

Thank you for explanation,
In my case ftrace also shows that packets was defragmented in ipv4_conntrack_defrag().
However this module does not depend on NF_CONNTRACK_IPV4.




WARNING: multiple messages have this Message-ID (diff)
From: Vasily Averin <vvs@parallels.com>
To: Florian Westphal <fw@strlen.de>
Cc: bridge@lists.linux-foundation.org,
	Patrick McHardy <kaber@trash.net>,
	Stephen Hemminger <stephen@networkplumber.org>,
	netfilter-devel@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH 1/1] superfluous skb->nfct check in br_nf_dev_queue_xmit
Date: Mon, 28 Apr 2014 16:37:08 +0400	[thread overview]
Message-ID: <535E4B74.4050107@parallels.com> (raw)
In-Reply-To: <20140424163243.GN31953@breakpoint.cc>

On 04/24/2014 08:32 PM, Florian Westphal wrote:
> Vasily Averin <vvs@parallels.com> wrote:
>> Please do not apply my patch, probably it breaks processing of VLAN packets.
> 
> Why would it break VLAN?
Sorry, seems it was false alert.

We got report about problem on RHEL6-based OpenVZ kernel:
large UDP and ICMP packets was dropped on bridge without incrementing of any failcounters.
Connection tracking was disabled on this node , nf_conntrack module was unloaded
Ftrace pointed that it was happen because nfct check.

I've unloaded nf_conntrack module and problem was reproduced again
After removing nfct check problem went away.

The check was added by patch that fixed processing of VLAN packets.
I did not tested this scenario and therefore asked to delay processing of my patch,
to investigate this case more carefully.

IS_VLAN_IP() check on RHEL6 kernels seems is not depend on nfct check,
in current mainline we do not have this code at all, 
therefore removing of nfct check should not affect this case too.

Therefore I believe that my patch is still correct, however now I think we also need 
to remove #if IS_ENABLED(CONFIG_NF_CONNTRACK_IPV4) in br_nf_dev_queue_xmit().

> In fact, the same dicussion came up couple of days back and I think the
> nfct test is wrong.  There is no guarantee that skb->nfct == NULL means
> that packet was not defragmented via nf_defrag (e.g. rror in l4 protocol
> tracker, nf_defrag_ipv4 loaded but no nf_conntrack_ipv4)

Thank you for explanation,
In my case ftrace also shows that packets was defragmented in ipv4_conntrack_defrag().
However this module does not depend on NF_CONNTRACK_IPV4.

  reply	other threads:[~2014-04-28 12:37 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-17 11:15 [Bridge] [PATCH 1/1] superfluous skb->nfct check in br_nf_dev_queue_xmit Vasily Averin
2014-04-20  5:33 ` Vasily Averin
2014-04-20  5:33   ` Vasily Averin
2014-04-24 16:32   ` Florian Westphal
2014-04-24 17:05     ` [Bridge] " Florian Westphal
2014-04-28 12:37     ` Vasily Averin [this message]
2014-04-28 12:37       ` Vasily Averin
2014-04-28 13:16       ` Florian Westphal
2014-04-28 13:16         ` [Bridge] " Florian Westphal
2014-04-28 14:25         ` Vasily Averin
2014-04-28 14:25           ` Vasily Averin
2014-04-28 14:32           ` [Bridge] " Pablo Neira Ayuso
2014-04-28 14:32             ` Pablo Neira Ayuso
2014-04-30  9:06           ` [Bridge] " Vasily Averin
2014-04-30  9:06             ` Vasily Averin
2014-04-30  8:54         ` [PATCH] bridge: Superfluous " Vasily Averin
2014-04-30  9:39           ` Pablo Neira Ayuso
2014-04-30 10:02             ` Florian Westphal
2014-05-04 12:54           ` Pablo Neira Ayuso
2014-05-04 19:04             ` Vasily Averin
2014-05-04 19:25               ` Pablo Neira Ayuso
2014-05-04 20:17                 ` [PATCH v2] bridge: superfluous " Vasily Averin
2014-05-05 14:07                   ` Pablo Neira Ayuso
2014-04-29 14:10   ` [PATCH 1/1] " Patrick McHardy
2014-04-29 14:17     ` [Bridge] " Patrick McHardy

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=535E4B74.4050107@parallels.com \
    --to=vvs@parallels.com \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=fw@strlen.de \
    --cc=kaber@trash.net \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=stephen@networkplumber.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.