On 13/06/2021 11:19, Kristof Provost wrote:
On 13 Jun 2021, at 09:41, Andriy Gapon <a...@freebsd.org> wrote:
Based on
the panic message (page fault with non-sleepable locks held), it seems that
the problem is with holding the lock across the copyout. Usually that
won't panic, but if the destination happens to be paged out... And only
with INVARIANTS, I guess...
Oh right. Thanks. I’ve gotten bitten by that one before, but had clearly
garbage collected the memory.
I’ll fix this one and check for others on Monday.
I’ll also see of we can persuade copyout to always panic on this bug, not
just when the destination memory is actually paged out. That way we’ll catch
this in the regression tests in the future.
I upgraded to the latest stable/13 and hit a fresh panic of the same type.
This time it's in pf_getstatus() and it's a copyout while 'pf rulesets' lock is
held.
<118>Enabling pf
Kernel page fault with the following non-sleepable locks held:
shared rm pf rulesets (pf rulesets) r = 0 (0xffffffff85764020) locked @
/usr/devel/git/trant/sys/netpfil/pf/pf_ioctl.c:4945
stack backtrace:
#0 0xffffffff808cb43d at witness_debugger+0x6d
#1 0xffffffff808cc2ab at witness_warn+0x21b
#2 0xffffffff80b567f1 at trap_pfault+0x71
#3 0xffffffff80b55df8 at trap+0x288
#4 0xffffffff80b56b59 at trap_check+0x29
#5 0xffffffff80b32298 at calltrap+0x8
#6 0xffffffff8574cae8 at pf_getstatus+0x548
#7 0xffffffff85747430 at pfioctl+0x2590
#8 0xffffffff8073854f at devfs_ioctl+0xcf
#9 0xffffffff80bd8c26 at VOP_IOCTL_APV+0x96
#10 0xffffffff8094c424 at VOP_IOCTL+0x34
#11 0xffffffff80947600 at vn_ioctl+0xc0
#12 0xffffffff80738a3e at devfs_ioctl_f+0x1e
#13 0xffffffff808cf8fb at fo_ioctl+0xb
#14 0xffffffff808cf897 at kern_ioctl+0x1d7
#15 0xffffffff808cf60d at sys_ioctl+0x12d
#16 0xffffffff80b57353 at syscallenter+0x163
#17 0xffffffff80b57025 at amd64_syscall+0x15
--
Andriy Gapon
