From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Marc Dionne <marc.c.dionne@gmail.com>
Cc: Florian Westphal <fw@strlen.de>, netdev <netdev@vger.kernel.org>,
regressions@leemhuis.info, netfilter-devel@vger.kernel.org
Subject: Re: Multi-thread udp 4.7 regression, bisected to 71d8c47fc653
Date: Tue, 5 Jul 2016 14:28:03 +0200 [thread overview]
Message-ID: <20160705122803.GA26862@salvia> (raw)
In-Reply-To: <CAB9dFds7KQxihReHhW9CXJeY9+=4BPema3ZawVA89U45QL5uBw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]
Hi,
On Mon, Jul 04, 2016 at 09:35:28AM -0300, Marc Dionne wrote:
> If there is no quick fix, seems like a revert should be considered:
> - Looks to me like the commit attempts to fix a long standing bug
> (exists at least as far back as 3.5,
> https://bugzilla.kernel.org/show_bug.cgi?id=52991)
> - The above bug has a simple workaround (at least for us) that we
> implemented more than 3 years ago
I guess the workaround consists of using a rule to NOTRACK this
traffic. Or there is any custom patch that you've used on your side to
resolve this?
> - The commit reverts cleanly, restoring the original behaviour
> - From that bug report, bind was one of the affected applications; I
> would suspect that this regression is likely to affect bind as well
>
> I'd be more than happy to test suggested fixes or give feedback with
> debugging patches, etc.
Could you monitor
# conntrack -S
or alternatively (if conntrack utility not available in your system):
# cat /proc/net/stat/nf_conntrack
?
Please, watch for insert_failed and drop statistics.
Are you observing any splat or just large packet drops? Could you
compile your kernel with lockdep on and retest?
Is there any chance I can get your test file that generates the UDP
client threads to reproduce this here?
I'm also attaching a patch to drop old ct that lost race path out from
hashtable locks to avoid releasing the ct object while holding the
locks, although I couldn't come up with any interaction so far
triggering the condition that you're observing.
Thanks.
[-- Attachment #2: x.patch --]
[-- Type: text/x-diff, Size: 1917 bytes --]
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index 62c42e9..98a71f1 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -638,7 +638,8 @@ static void nf_ct_acct_merge(struct nf_conn *ct, enum ip_conntrack_info ctinfo,
/* Resolve race on insertion if this protocol allows this. */
static int nf_ct_resolve_clash(struct net *net, struct sk_buff *skb,
enum ip_conntrack_info ctinfo,
- struct nf_conntrack_tuple_hash *h)
+ struct nf_conntrack_tuple_hash *h,
+ struct nf_conn **old_ct)
{
/* This is the conntrack entry already in hashes that won race. */
struct nf_conn *ct = nf_ct_tuplehash_to_ctrack(h);
@@ -649,7 +650,7 @@ static int nf_ct_resolve_clash(struct net *net, struct sk_buff *skb,
!nf_ct_is_dying(ct) &&
atomic_inc_not_zero(&ct->ct_general.use)) {
nf_ct_acct_merge(ct, ctinfo, (struct nf_conn *)skb->nfct);
- nf_conntrack_put(skb->nfct);
+ *old_ct = (struct nf_conn *)skb->nfct;
/* Assign conntrack already in hashes to this skbuff. Don't
* modify skb->nfctinfo to ensure consistent stateful filtering.
*/
@@ -667,7 +668,7 @@ __nf_conntrack_confirm(struct sk_buff *skb)
const struct nf_conntrack_zone *zone;
unsigned int hash, reply_hash;
struct nf_conntrack_tuple_hash *h;
- struct nf_conn *ct;
+ struct nf_conn *ct, *old_ct = NULL;
struct nf_conn_help *help;
struct nf_conn_tstamp *tstamp;
struct hlist_nulls_node *n;
@@ -771,11 +772,14 @@ __nf_conntrack_confirm(struct sk_buff *skb)
out:
nf_ct_add_to_dying_list(ct);
- ret = nf_ct_resolve_clash(net, skb, ctinfo, h);
+ ret = nf_ct_resolve_clash(net, skb, ctinfo, h, &old_ct);
dying:
nf_conntrack_double_unlock(hash, reply_hash);
NF_CT_STAT_INC(net, insert_failed);
local_bh_enable();
+ if (old_ct)
+ nf_ct_put(old_ct);
+
return ret;
}
EXPORT_SYMBOL_GPL(__nf_conntrack_confirm);
next prev parent reply other threads:[~2016-07-05 12:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-27 13:41 Multi-thread udp 4.7 regression, bisected to 71d8c47fc653 Marc Dionne
2016-06-27 14:22 ` Florian Westphal
2016-06-27 14:46 ` Marc Dionne
2016-06-27 15:38 ` Florian Westphal
2016-06-27 17:21 ` Marc Dionne
2016-07-04 12:35 ` Marc Dionne
2016-07-05 12:28 ` Pablo Neira Ayuso [this message]
2016-07-10 19:48 ` Marc Dionne
2016-07-11 16:26 ` Pablo Neira Ayuso
2016-07-11 21:17 ` Marc Dionne
2016-07-12 14:25 ` Pablo Neira Ayuso
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=20160705122803.GA26862@salvia \
--to=pablo@netfilter.org \
--cc=fw@strlen.de \
--cc=marc.c.dionne@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=regressions@leemhuis.info \
/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.