Bug 203976 - panic: page fault on regular traffic routing
Summary: panic: page fault on regular traffic routing
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.2-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks: 204186
  Show dependency tree / graph
 
Reported: 2015-10-23 09:42 UTC by ikv
Modified: 2018-10-19 22:07 UTC (History)
1 user (show)

See Also:

Attachments
core dump (159.30 KB, text/plain)
2015-10-23 09:42 UTC, ikv 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description ikv 2015-10-23 09:42:28 UTC 
Created attachment 162382 [details]
core dump

System gets in panic while regular routing tasks, such as nat. Repeating by bittorrent traffic passing throug every time on loads above 70 mbit/s.
The behavour of the 10.2 system on another machine was the same. Both systems network interfaces are bge aggregated by lacp lagg.
Error dump in attachment.
Comment 1 Kristof Provost freebsd_committer freebsd_triage 2015-10-23 11:30:22 UTC 
Can you also add your pf rules?

At first glance this looks like it's probably a PF problem.
Comment 2 ikv 2015-10-23 11:34:11 UTC 
(In reply to Kristof Provost from comment #1)
These rules works fine on freebsd 9.3.
Comment 3 Kristof Provost freebsd_committer freebsd_triage 2015-10-23 11:36:18 UTC 
I'm not suggesting your rules are wrong (the panic should never happen, no matter what the rules are), but knowing what they are is useful during debugging.
Comment 4 ikv 2015-10-23 11:42:05 UTC 
(In reply to Kristof Provost from comment #3)
I wont posting my rules. By the way, i have this problem on 2 different systems with different pf rulesets.
rules are simple - pass, block, nat - nothing extra ordinary. The common thing is hardware - bge interfaces in lagg. (ProLiant DL360p Gen8)
Comment 5 Kristof Provost freebsd_committer freebsd_triage 2015-10-23 11:46:34 UTC 
(In reply to ikv from comment #4)
You can censor the IP addresses, if you like, but knowing what type of scrub options you've got, and if you're using anything like route-to, dup-to, ... is quite useful.
Comment 6 Kristof Provost freebsd_committer freebsd_triage 2015-10-23 11:52:07 UTC 
Are you running with 'scrub fragment crop' or 'scrub fragment drop-ovl' by any chance?

If so, can you confirm that the problem goes away if you switch to 'scrub fragment reassemble'? 

The crop/drop-ovl code has been removed in CURRENT, and I suspect it's the cause of your panics.
Comment 7 ikv 2015-10-23 12:05:38 UTC 
(In reply to Kristof Provost from comment #6)
indeed i use crop. Can't test right at this time since i rolled back to 9.3, but i'll test it soon and reply results.
Comment 8 ikv 2015-10-23 14:56:50 UTC 
(In reply to Kristof Provost from comment #6)
You were right, i replaced "corp" by "reassemble" - now it works fine.
Thanks a lot!
Comment 9 Mark Linimon freebsd_committer freebsd_triage 2015-10-25 13:28:55 UTC 
To submitter: so can this PR be closed now?
Comment 10 ikv 2015-10-26 07:50:10 UTC 
(In reply to Mark Linimon from comment #9)
I think need kernel fixes to prevent such problems in future.
Comment 11 Kristof Provost freebsd_committer freebsd_triage 2015-10-26 14:05:31 UTC 
To be clear: this panic will not happen on CURRENT, because the code (scrub crop/drop-ovl) in which it occurs has been removed.

Right now I don't plan to investigate this problem any further.
Comment 12 Kristof Provost freebsd_committer freebsd_triage 2018-10-19 22:07:06 UTC 
'scrub fragment crop' has been removed, this panic cannot recur.