Summary: | pf_unlink_state mutex unlock page fault panic | ||||||
---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Daniel Ponte <amigan> | ||||
Component: | kern | Assignee: | freebsd-pf (Nobody) <pf> | ||||
Status: | New --- | ||||||
Severity: | Affects Only Me | CC: | amigan, franco, mike, zlei | ||||
Priority: | --- | Keywords: | crash | ||||
Version: | 14.1-STABLE | ||||||
Hardware: | amd64 | ||||||
OS: | Any | ||||||
Attachments: |
|
Description
Daniel Ponte
2024-06-21 20:20:16 UTC
(In reply to Daniel Ponte from comment #0) All right, first off: did you mean eff27c3872300 rather than ff27c3872300? Secondly, what is your setup? Post your ruleset and network configuration. Are you using pfsync, pflog, ....? Lastly, build an INVARIANTS kernel and see what assertions you hit. The panic seems to show us locking a hashrow that the state is not in, which explains the panic on mutex unlock (because we're unlocking a different mutex from the one we locked), but there's no obvious way for that to happen. That would be why it's important to provide setup details! (In reply to Kristof Provost from comment #1) Yes, eff27c3872300, sorry. This machine is primarily a NAT, IPv6 and VPN gateway for my home network, but has some other roles (nginx reverse proxy, xmpp server, asterisk PBX). My ruleset is pretty complex and makes use of policy-based routing. The machine runs a vnet jail. I would rather not post the ruleset but would be happy to email it. I use pflogd, but no pfsync. (In reply to Kristof Provost from comment #1) With INVARIANTS: panic: pfsync_drop: st->sync_state == q core.txt excerpt attached. uname commit hash differs due to local (non kernel) modifications; this is built from the same eff27c3872300 tree. Created attachment 251655 [details]
INVARIANTS core.txt excerpt
(In reply to Daniel Ponte from comment #4) In comment #2 you stated there's no pfsync, yet this panic is in pfsync. It's very hard to debug things if you're not supplying the requested information. It's downright impossible if the information that is provided is wrong. Provide all of the previously requested information, including the full diff against upstream, and ensure it is accurate. Is this what it is now? Being harsh to people will to report and help squash bugs to subsystems you actively maintain? ;) Cheers, Franco The diff against upstream is a patch to make rtadvd(8) deprecate addresses on shutdown. It has nothing to do with this crash. I am not trying to be difficult, but my ruleset is 327 lines long and I will need to anonymize it, which will take time. I'm not certain your tone is warranted; I know my configuration is complex and tends to uncover bugs like this, which I have tried to report every time I encounter them. I am trying to help the Project. And yes, pfsync is present in the kernel, but is not being used at all. Removing pfsync from the kernel config has resolved this crash. (In reply to Kristof Provost from comment #5) > (In reply to Daniel Ponte from comment #4) > In comment #2 you stated there's no pfsync, yet this panic is in pfsync. `vnet_pfsync_init()` vnet sysinit routine would unconditionally calls `pfsync_pointers_init()` [1]. I think that is why Daniel@ found > Removing pfsync from the kernel config has resolved this crash 1. https://cgit.freebsd.org/src/tree/sys/netpfil/pf/if_pfsync.c#n3112 |