Date: Wed, 06 Aug 2014 12:48:28 -0500 From: Bryan Drewery <bdrewery@FreeBSD.org> To: current@FreeBSD.org Subject: Re: r269147: NULL mp in getnewvnode() via kern_proc_filedesc_out() Message-ID: <53E26A6C.4000806@FreeBSD.org> In-Reply-To: <53E1A76A.1070400@FreeBSD.org> References: <53E1975D.4010703@FreeBSD.org> <20140806031932.GE93733@kib.kiev.ua> <53E1A76A.1070400@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fDhGJu4KXLr2HuWFh5ALcNiTwtAso7Dc3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 8/5/2014 10:56 PM, Bryan Drewery wrote: > 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. >> >=20 > Got it. I've set debug.debugger_on_panic=3D1 to not auto reboot on pani= c > next time this happens. I had it at 0 which was causing the lack of > information in these. Here is the full trace: > NULL mp in getnewvnode() > VNASSERT failed > 0xfffff806071dc760: tag null, type VDIR > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags () > lock type zfs: EXCL by thread 0xfffff8009a53f490 (pid 1028, tmux, t= id 100881) > vp=3D0xfffff806071dc760, lowervp=3D0xfffff8013157f588 > panic: Don't call insmntque(foo, NULL) > cpuid =3D 5 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe124= 7e76b50 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe1247e76c00 > vpanic() at vpanic+0x126/frame 0xfffffe1247e76c40 > kassert_panic() at kassert_panic+0x139/frame 0xfffffe1247e76cb0 > insmntque1() at insmntque1+0x230/frame 0xfffffe1247e76cf0 > null_nodeget() at null_nodeget+0x158/frame 0xfffffe1247e76d60 > null_lookup() at null_lookup+0xeb/frame 0xfffffe1247e76dd0 > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xf1/frame 0xfffffe1247e76e00 > lookup() at lookup+0x5ad/frame 0xfffffe1247e76e90 > namei() at namei+0x4e4/frame 0xfffffe1247e76f50 > vn_open_cred() at vn_open_cred+0x27a/frame 0xfffffe1247e770a0 > vop_stdvptocnp() at vop_stdvptocnp+0x161/frame 0xfffffe1247e773e0 > null_vptocnp() at null_vptocnp+0x2b/frame 0xfffffe1247e77440 > VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0xf7/frame 0xfffffe1247e77470 > vn_vptocnp_locked() at vn_vptocnp_locked+0x118/frame 0xfffffe1247e774e0= > vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfffffe1247e77540 > vn_fullpath() at vn_fullpath+0xc1/frame 0xfffffe1247e77590 > export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfffffe1247e777c0 > kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame 0xfffffe= 1247e77840 > sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame 0xf= ffffe1247e77900 > sysctl_root_handler_locked() at sysctl_root_handler_locked+0x68/frame 0= xfffffe1247e77940 > sysctl_root() at sysctl_root+0x18e/frame 0xfffffe1247e77990 > userland_sysctl() at userland_sysctl+0x192/frame 0xfffffe1247e77a30 > sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe1247e77ae0 > amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247e77bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247e77bf0 > --- syscall (202, FreeBSD ELF64, sys___sysctl), rip =3D 0x801041fca, rs= p =3D 0x7fffffffd878, rbp =3D 0x7fffffffd8b0 --- > KDB: enter: panic > [ thread pid 1028 tid 100881 ] > Stopped at kdb_enter+0x3e: movq $0,kdb_why > db> call doadump() >=20 > Dump failed. Partition too small. > =3D 0 --=20 Regards, Bryan Drewery --fDhGJu4KXLr2HuWFh5ALcNiTwtAso7Dc3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT4mpsAAoJEDXXcbtuRpfPgAcH/2Qb0KJw9fvh2Ndi0xO1MUqo tkg5Rs2bZyC8iWEkMneSV5aIsvbHG6aOtPJrZD3e60FhK5vIcYiqN+Etk3/kV7Q2 bpgnwYYTNbS6a5ECkDquzRC8+GmCxRrfOXgwacYC7TlViOMXR+Y7iEnIG+ib6gzf ZlVOWPSC9/vXfVIRtWRXWw3ZOTdIWCKm2usHF/1sttSnXQ5cn+ba4WzSg0tQWDYR +hzWU0m8fs+GKu7a+ZBDZCNogITsSrzTkvLeislSykoYBcpmr/MVjbM4IZgxm+3S 7gdceQNR74OkJIrBu67xIXkzJKbj0J2KG1OCfu8GRMc29ByOGeRk+mVo4h/TZnE= =2iRA -----END PGP SIGNATURE----- --fDhGJu4KXLr2HuWFh5ALcNiTwtAso7Dc3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53E26A6C.4000806>