Re: page fault in pfioctl

On 13/06/2021 11:19, Kristof Provost wrote:
> On 13 Jun 2021, at 09:41, Andriy Gapon <avg@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