Date: Sun, 05 Mar 2017 21:42:59 +0900 From: "Kristof Provost" <kp@FreeBSD.org> To: Ross <basarevych@gmail.com> Cc: freebsd-pf@freebsd.org Subject: Re: sonewconn: pru_attach() failed and kernel panic in PF Message-ID: <D0CD7B4C-2C21-4ABE-9F1B-41E5414A9A8A@FreeBSD.org> In-Reply-To: <CANmv3=xB0Kce4ZQ4GYBE0cNpam0jzGPX7dSYSVBPiT-sryCyHA@mail.gmail.com> References: <CANmv3=xB0Kce4ZQ4GYBE0cNpam0jzGPX7dSYSVBPiT-sryCyHA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27 Feb 2017, at 21:08, Ross wrote: > Hello > > One of my machines panics almost every day. It is always like this: > first > there is a number of messages about "sonewconn: pcb > 0xfffff80085478740: > pru_attach() failed" at the same time and then panic. Here's an > example: > > ... many lines of sonewconn ... > Feb 27 13:41:43 core kernel: sonewconn: pcb 0xfffff8008575bcb0: > pru_attach() failed > Feb 27 13:41:43 core kernel: I wonder if you’re running low on memory by any chance. I think I know why you’re crashing, but I suspect your root problem is that you’re running low on memory and that’s why you’re seeing the pru_attach() failures, and eventually running into the pf panic. > Feb 27 13:41:43 core kernel: KDB: stack backtrace: > Feb 27 13:41:43 core kernel: #0 0xffffffff80b312c7 at > kdb_backtrace+0x67 > Feb 27 13:41:43 core kernel: #1 0xffffffff80ae5c92 at vpanic+0x182 > Feb 27 13:41:43 core kernel: #2 0xffffffff80ae5b03 at panic+0x43 > Feb 27 13:41:43 core kernel: #3 0xffffffff80fd6d51 at trap_fatal+0x351 > Feb 27 13:41:43 core kernel: #4 0xffffffff80fd6f43 at > trap_pfault+0x1e3 > Feb 27 13:41:43 core kernel: #5 0xffffffff80fd64ec at trap+0x26c > Feb 27 13:41:43 core kernel: #6 0xffffffff80fb9d61 at calltrap+0x8 > Feb 27 13:41:43 core kernel: #7 0xffffffff80e4185e at > uma_zfree_arg+0x4fe > Feb 27 13:41:43 core kernel: #8 0xffffffff82442165 at > pf_get_translation+0x2c5 There’s only a couple of calls to uma_zfree() in pf_get_translations(). These are: * uma_zfree(V_pf_state_key_z, skp); * uma_zfree(V_pf_state_key_z, *nkp); * uma_zfree(V_pf_state_key_z, *skp); Going by the inconsistent pointer use the first one is rather suspect. Looking a bit deeper, pf_get_translation() is only called from one place, and it always passes stack variables for skp and nkp, so the first call ends up trying to free that, which won’t work too well. That’s a bug (and I’ll fix it), but you’re only running into it because pf_state_key_clone() returned NULL, which will only happen under memory pressure. > What should I do to fix it? > You’ll need to look at your system and figure out who’s running away with all of your memory. Regards, Kristof
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D0CD7B4C-2C21-4ABE-9F1B-41E5414A9A8A>