From: Guillaume Nault <g.nault@alphalink.fr>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: netdev@vger.kernel.org, netfilter-devel@vger.kernel.org,
Florian Westphal <fw@strlen.de>,
svimik@gmail.com
Subject: Re: Fw: [Bug 197367] New: NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [nf_conntrack]
Date: Thu, 26 Oct 2017 11:48:09 +0200 [thread overview]
Message-ID: <20171026094809.y3kj7gdtcrzyudrr@alphalink.fr> (raw)
In-Reply-To: <20171024150541.71368011@shemminger-XPS-13-9360>
On Tue, Oct 24, 2017 at 03:05:41PM +0200, Stephen Hemminger wrote:
>
>
> NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [openvpn:1436]
> ----cut----
> CPU: 1 PID: 1436 Comm: openvpn Not tainted 4.8.13-1.el6.elrepo.x86_64 #1
> Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
> task: ffff88003c564300 task.stack: ffff88003bfb0000
> RIP: 0010:[<ffffffffa030859f>] [<ffffffffa030859f>]
> __nf_conntrack_find_get+0x3f/0x330 [nf_conntrack]
> ----cut----
> Call Trace:
> <IRQ>
> [<ffffffffa03084b0>] ? death_by_timeout+0x20/0x20 [nf_conntrack]
> [<ffffffffa0306ceb>] ? nf_ct_get_tuple+0x8b/0xb0 [nf_conntrack]
> [<ffffffffa0308ac0>] nf_conntrack_in+0x1e0/0x530 [nf_conntrack]
> [<ffffffffa032414c>] ipv4_conntrack_in+0x1c/0x20 [nf_conntrack_ipv4]
> [<ffffffff8169f782>] nf_iterate+0x72/0x90
> [<ffffffff816aa68f>] ? ip_rcv_finish+0x16f/0x3d0
> [<ffffffff8169f8dd>] nf_hook_slow+0x3d/0xc0
> [<ffffffff816aad46>] ip_rcv+0x2d6/0x3d0
> [<ffffffffa004a402>] ? virtqueue_add_inbuf+0x2/0x30 [virtio_ring]
> [<ffffffff816aa520>] ? inet_add_protocol+0x50/0x50
> [<ffffffffa00490fa>] ? virtqueue_notify+0x1a/0x40 [virtio_ring]
> [<ffffffff816669e0>] __netif_receive_skb_core+0x5b0/0x9f0
> [<ffffffffa01372d0>] ? start_xmit+0x110/0x210 [virtio_net]
> [<ffffffff810b796a>] ? update_cfs_rq_load_avg+0x29a/0x430
> [<ffffffff8179b640>] ? _raw_read_unlock_bh+0x20/0x30
> [<ffffffffa02d9900>] ? ebt_do_table+0x620/0x690 [ebtables]
> [<ffffffff81666e49>] __netif_receive_skb+0x29/0x70
> [<ffffffff81667067>] netif_receive_skb_internal+0x37/0x90
> [<ffffffff81667ed8>] netif_receive_skb+0x28/0x80
> ----cut----
>
I guess this could be caused by the performance regression that came
with rhtable conversion. The trace is a bit different from what I used
to see though.
If that's really the case, then it's fixed by e1bf1687740c
("netfilter: nat: Revert "netfilter: nat: convert nat bysrc hash to rhashtable"").
prev parent reply other threads:[~2017-10-26 9:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-24 13:05 Fw: [Bug 197367] New: NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [nf_conntrack] Stephen Hemminger
2017-10-26 9:48 ` Guillaume Nault [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=20171026094809.y3kj7gdtcrzyudrr@alphalink.fr \
--to=g.nault@alphalink.fr \
--cc=fw@strlen.de \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=stephen@networkplumber.org \
--cc=svimik@gmail.com \
/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