Date: Sun, 13 Jun 2021 09:26:34 +0200 From: "Kristof Provost" <kp@FreeBSD.org> To: "Andriy Gapon" <avg@FreeBSD.org> Cc: net@FreeBSD.org Subject: Re: page fault in pfioctl Message-ID: <CCC8EC26-5CA6-416C-B5C2-117710F489A2@FreeBSD.org> In-Reply-To: <e70da3d3-3546-5a1b-3860-96a8513b71ec@FreeBSD.org> References: <e70da3d3-3546-5a1b-3860-96a8513b71ec@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12 Jun 2021, at 19:59, Andriy Gapon wrote: > Not sure if this has been reported, or maybe even fixed, yet. > The crash happened with stable/13 as of 92f49c769b4 (June 3). > Judging from the time I think that it happened when running a periodic > report (likely 520.pfdenied). > I have the vmcore, can take a look into it on Monday. > > Ah, and I must add that this is a custom kernel configuration with > INVARIANTS. > > Kernel page fault with the following non-sleepable locks held: > exclusive rm pf rulesets (pf rulesets) r = 0 (0xffffffff85558e58) > locked @ /usr/devel/git/trant/sys/netpfil/pf/pf_ioctl.c:2459 > This panic doesn’t seem to ring any bells for me. I’d be interested in seeing what kgdb can pull out of the vmcore. The line number for the lock would suggest it happened in DIOCGETRULENV, and the backtrace suggests it’s during the copyout. I’m just not sure how that’d panic, because we copy out the result of nvlist_pack() (and have checked that for NULL), using the size it gave us. Hopefully the vmcore will be more enlightening. That is fairly new code though, so bugs are not impossible. Best regards, Kristof
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CCC8EC26-5CA6-416C-B5C2-117710F489A2>