Bug 1089569

Summary: IPTables rule change causes kernel Oops on get_counters after a while
Product: [Fedora] Fedora Reporter: Chris <ccowling.faktortel>
Component: kernelAssignee: Neil Horman <nhorman>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 20CC: ccowling.faktortel, gansalmon, itamar, jonathan, jpopelka, kernel-maint, madhu.chinakonda, mchehab, nhorman, psabata, snadge, twoerner
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
URL: http://pastebin.com/vubJcYE9
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-12-10 15:01:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Kernel Oops Trace none

Description Chris 2014-04-21 00:59:19 UTC 
User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.75.14 (KHTML, like Gecko) Version/7.0.3 Safari/537.75.14
Build Identifier: 

When issuing a change to the IPTables rules we receive a Kernel Oops if the server has been running for a while (>24hrs). Changes are usually blocking an IP , drop rule or similar.

Reproducible: Always

Steps to Reproduce:
1. Run IPTables for > 24hrs
2. Change IPTables rule and apply.

Looking online the only other example we found was with Dell hardware as well. Perhaps specific to Dell r320 hardware?
Actual Results:  
IPTables continues on but provides Oops message (non-tainted).

Expected Results:  
System should continue running with no Oops
Comment 1 Chris 2014-04-21 01:01:12 UTC 
Created attachment 887987 [details]
Kernel Oops Trace
Comment 2 Chris 2014-04-21 01:06:02 UTC 
kernel.x86_64 0:3.13.10-200.fc20
Comment 3 Chris 2014-04-28 22:49:15 UTC 
Does anyone have any ideas on this one?
Comment 4 David Burrows 2014-05-03 00:19:13 UTC 
Maybe this Fedora 18 crash is related?
https://retrace.fedoraproject.org/faf/reports/175630/

This issue might be caused by overflowing counters, or perhaps a race condition.  It would be nice if this could receive some attention, as we have a router in a redundant configuration, which triggers this problem occasionally.  We are now resetting the counters every 24 hours, as a potential workaround, and will report how that goes.
Comment 5 Chris 2014-05-20 23:37:49 UTC 
After much testing from our NOC,running this to Zero the counters before IP tables restart.

/usr/sbin/iptables -L -Z -v -n

and restarting iptables stops kernel panic.

OR

Alternatively you can add it to the daily CRON.

@daily /usr/sbin/iptables -L -Z -v -n
Comment 6 Thomas Woerner 2014-05-28 10:14:50 UTC 
This is not a iptables user land issue. Reassigning to kernel.
Comment 7 Neil Horman 2014-05-28 13:37:19 UTC 
looks like this may well be fixed by commit  c58dd2dd443c26d856a168db108a0cd11c285bf3.  It should apply cleanly to F20.  Can you build and test a kernel with that commit applied and see if it fixes your problem?  Thanks!
Comment 8 Chris 2014-06-09 23:28:46 UTC 
Will give it a shot and report back when tested.
Comment 9 Neil Horman 2014-06-11 10:26:29 UTC 
thanks.
Comment 10 Neil Horman 2014-08-13 12:37:58 UTC 
ping, any results here?
Comment 11 Justin M. Forbes 2014-12-10 15:01:30 UTC 
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
Comment 12 Chris 2020-05-20 05:22:05 UTC 
I can confirm this was resolved by commit c58dd2dd443c26d856a168db108a0cd11c285bf3