[Bug 1082] Hard lockup when inserting nft rules (esp. ct rule)

[bugzilla-daemon at netfilter.org]

https://bugzilla.netfilter.org/show_bug.cgi?id=1082

--- Comment #2 from Wang Jian <larkwang at gmail.com> ---
> What do you mean by loading the "modified ruleset"? So as soon as you invoke some specific command you experience problems?

Sorry for the confusion. I am trying to replay the situation.

It's very clear that modified or not, is not relevant. We loaded the ruleset
before we added traffic to the server, no problem. We wanted to load ruleset
again after we added some traffic (about 200M-500M bps) for additional
permission, the server lockuped.

The modification gives us a chance to catch the problem.

> Now you say that the lockup only happens if the last rule using 'reject' is there?

I didn't say 'reject'. I said 'ct state'. But seriously, I didn't check which
one of 'reject' or 'ct state' is the culprit.

> I'm getting confused here. So the backup server does not experience any problem at all with this ruleset?

No, backup server doesn't experience problem. We did this after work time.
There was no much traffic load on it at that time.

> Please provide more specific information to make sure this is a bug in nftables, such as backtraces.

I will if I can.

The hard lockup is hard lockup, and the server just freezes. No single
character is emitted on console or in logs.

After we move traffic from the server, loading the ruleset doesn't cause
lockup.

My wild guess is that when there is high traffic (so there are connection
tracking manipulation operations), inserting 'ct state' rule is racy. When
traffic is low, the problem will not be triggered.

I can't reproduce the lockup on line as my will, because certain vpn link is
business critical. I can have a 5 minutes window per day, including reboot
(reboot needs 1 minutes), at most.

BTW, we tried various kernels, and excluded hardware problems (not 100%
excluded though). I will stress test it.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20160818/5ed662ef/attachment.html>