Re: r269147: NULL mp in getnewvnode() via kern_proc_filedesc_out()

On 8/5/2014 10:19 PM, Konstantin Belousov wrote:
> On Tue, Aug 05, 2014 at 09:47:57PM -0500, Bryan Drewery wrote:
>> Has anyone else encountered this? Got it while running poudriere.
>>
>>> NULL mp in getnewvnode()
>>> [...]
>>> vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfffffe1247d8e540
>>> vn_fullpath() at vn_fullpath+0xc1/frame 0xfffffe1247d8e590
>>> export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfffffe1247d8e7c0
>>> kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame 0xfffffe1247d8e840
>>> sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame 0xfffffe1247d8e900
>>> sysctl_root_handler_locked() at sysctl_root_handler_locked+0x68/frame 0xfffffe1247d8e940
>>> sysctl_root() at sysctl_root+0x18e/frame 0xfffffe1247d8e990
>>> userland_sysctl() at userland_sysctl+0x192/frame 0xfffffe1247d8ea30
>>> sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe1247d8eae0
>>> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247d8ebf0
>>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247d8ebf0
>>
>> Unfortunately I have no dump as the kmem was too large compared to my
>> swap, and I didn't get to the console before some of the text was
>> overwritten. Perhaps it will hit it again soon after reboot and I'll get
>> a core.
>
> "NULL mp in getnewvnode()" is only the printf(), it is not a panic or
> KASSERT.  The event does not stop the machine, nor it prints the
> backtrace.
>
> You mentioned that you was unable to dump, so did the system paniced ?
> Without full log of the panic messages and backtrace, it is impossible
> to start guessing what the problem is.
>
> That said, the printf seemingly outlived its usefulness.
>

Got it. I've set debug.debugger_on_panic=1 to not auto reboot on panic 
next time this happens. I had it at 0 which was causing the lack of 
information in these.

Off-topic, this system has 72gb of ram, 16gb swap. I suspect ZFS ARC is 
typically filling up kmem too much to create a dump. I've limited it to 
50gb but am not fond of limiting it, or kmem, to under 16gb. I see that 
if a page is allocated with VM_ALLOC_NODUMP -> PG_NODUMP then it will be 
excluded from minidumps. It looks like ZFS allocates all of its kmem via 
malloc(9) (zfs_kmem_alloc) though which has no means to pass these flags 
down to the vm system. I am guessing ZFS would need dedicated vm pages 
for this to even make sense though. I suppose I am stuck in this 
situation unless I limit kmem or raise my swap size.

-- 
Regards,
Bryan Drewery