netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Florian Westphal <fw@strlen.de>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nf] netfilter: conntrack: resched in nf_ct_iterate_cleanup
Date: Mon, 1 Feb 2016 18:38:21 +0100	[thread overview]
Message-ID: <20160201173821.GA1247@salvia> (raw)
In-Reply-To: <1453285003-21040-1-git-send-email-fw@strlen.de>

On Wed, Jan 20, 2016 at 11:16:43AM +0100, Florian Westphal wrote:
> Ulrich reports soft lockup with following (shortened) callchain:
> 
> NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s!
> __netif_receive_skb_core+0x6e4/0x774
> process_backlog+0x94/0x160
> net_rx_action+0x88/0x178
> call_do_softirq+0x24/0x3c
> do_softirq+0x54/0x6c
> __local_bh_enable_ip+0x7c/0xbc
> nf_ct_iterate_cleanup+0x11c/0x22c [nf_conntrack]
> masq_inet_event+0x20/0x30 [nf_nat_masquerade_ipv6]
> atomic_notifier_call_chain+0x1c/0x2c
> ipv6_del_addr+0x1bc/0x220 [ipv6]
> 
> Problem is that nf_ct_iterate_cleanup can run for a very long time
> since it can be interrupted by softirq processing.
> Moreover, atomic_notifier_call_chain runs with rcu readlock held.
> 
> So lets call cond_resched() in nf_ct_iterate_cleanup and defer
> the call to a work queue for the atomic_notifier_call_chain case.
> 
> We also need another cond_resched in get_next_corpse, since we
> have to deal with iter() always returning false, in that case
> get_next_corpse will walk entire conntrack table.

Applied, thanks.

> Reported-by: Ulrich Weber <uw@ocedo.com>
> Tested-by: Ulrich Weber <uw@ocedo.com>
> Signed-off-by: Florian Westphal <fw@strlen.de>
> ---
> I had a look at converting the ipv6 notifier to a blocking one
> but I found this too difficult (RTNL held?  How to defer notifier calls
> from packet path)?  Just doing it for masquerade is a lot simpler:
> - we only care about NETDEV_DOWN, so no extra work needed in most cases
> - can just ignore the notification if too much work is already queued

Probably adding a defered notifier chain variant which allows
blocking, ie. moving this code to core infrastructure, just an idea.

  reply	other threads:[~2016-02-01 17:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-20 10:16 [PATCH nf] netfilter: conntrack: resched in nf_ct_iterate_cleanup Florian Westphal
2016-02-01 17:38 ` Pablo Neira Ayuso [this message]
  -- strict thread matches above, loose matches on Subject: below --
2015-12-09 17:30 Florian Westphal
2015-12-11 11:42 ` Pablo Neira Ayuso
2015-12-11 11:53   ` Florian Westphal
2015-12-11 14:43 ` Florian Westphal
2015-12-11 17:16   ` Pablo Neira Ayuso
2015-12-11 17:21     ` 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=20160201173821.GA1247@salvia \
    --to=pablo@netfilter.org \
    --cc=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.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).