Date: Fri, 8 Aug 2014 14:46:50 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Peter Holm <peter@holm.cc> Cc: current@freebsd.org, Bryan Drewery <bdrewery@freebsd.org> Subject: Re: r269147: NULL mp in getnewvnode() via kern_proc_filedesc_out() Message-ID: <20140808114650.GD93733@kib.kiev.ua> In-Reply-To: <20140807061111.GA6625@x2.osted.lan> References: <53E1975D.4010703@FreeBSD.org> <20140806031932.GE93733@kib.kiev.ua> <53E1A76A.1070400@FreeBSD.org> <53E26A6C.4000806@FreeBSD.org> <20140806181512.GK93733@kib.kiev.ua> <20140807061111.GA6625@x2.osted.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
--qK4iY2XH8GKezezA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 07, 2014 at 08:11:11AM +0200, Peter Holm wrote: > On Wed, Aug 06, 2014 at 09:15:12PM +0300, Konstantin Belousov wrote: > > On Wed, Aug 06, 2014 at 12:48:28PM -0500, Bryan Drewery wrote: > > > 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 0xfffffe1247d8e= 7c0 > > > >>>> kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame > > > >>>> 0xfffffe1247d8e840 > > > >>>> sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/fr= ame > > > >>>> 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 0xfffffe1247d8e= a30 > > > >>>> 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 t= o 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 panic= ed ? > > > >> Without full log of the panic messages and backtrace, it is imposs= ible > > > >> 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 = panic > > > > next time this happens. I had it at 0 which was causing the lack of > > > > information in these. > > >=20 > > > Here is the full trace: > > >=20 > > >=20 > > > > 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, tmu= x, tid 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 0xfffff= e1247e76b50 > > > > 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 0xfffffe1247e7= 74e0 > > > > 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 0xff= fffe1247e77840 > > > > sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame= 0xfffffe1247e77900 > > > > sysctl_root_handler_locked() at sysctl_root_handler_locked+0x68/fra= me 0xfffffe1247e77940 > > > > 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= , rsp =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 > >=20 > > Try this. > >=20 > > diff --git a/sys/fs/nullfs/null_vnops.c b/sys/fs/nullfs/null_vnops.c > > index 481644c..e803c24 100644 > > --- a/sys/fs/nullfs/null_vnops.c >=20 > With this patch I get a=20 > panic: Lock (lockmgr) null not locked @ kern/vfs_default.c:523. >=20 > Details @ http://people.freebsd.org/~pho/stress/log/kostik698.txt >=20 Peter tested the updated version of the patch, which fixed both issues in his setup. I committed this variant of the fix as r269708. --qK4iY2XH8GKezezA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT5LiqAAoJEJDCuSvBvK1BTS0QAIem66kaxmYx++vC1YNzdH8w ZvaHGpGtmvXr4mCqdZVGJVveP1jSabcOufpD6PgI6hMBENy0Q31nkeq0bpE4fJll 4BVI0Q9mLhvaKiG4eoLIkjwzVE1YxGMGBfePp9fsZ8Ch8MTvkzcKBlZYAiTn+J3x WqhOSAjFNu1lpILc7CQGTzzD5gIqrJQi75L0VYwxxs3nmVvaFMu+r4BJTu+xqy2i 0fPIBRbWy3wPR7R5af9WQ0O//FJvbREipOA76GS3P4XbD0CKj5mRawTvAUz1XdBn tVmN8N+OSMLlZBz0eDQHoVqFP8uqNDnJMSxb+94klPrV3E9WpS2OWW1k3vYkvqqc dOiSznvZ/EOmgGsFI7mXfJdvOUzeA+A2IV7JzBzSb0XCrjG2kQS3YqV8tfjqZrb8 SyHAJp+slUm+zMqs8TJX9E3a0dDpAJoFu7Gnfwa0wM8ubzbHgET+n0msje3aTjZv kVRqGyBZK/cq89By8hGy++D04jhU4pLGVDc4EBHMwhfek26RtUuoRcJLaw3JK6Vb jTtZGF5IhGJLPWEH4+x7bxUsVJqtuZFV9Raa55lcHfiwz2dX7KtmTw3aEujUD1Ga h3B1WqUpWwIL3VHgykOf2IRGes9xJsar14J1vJpylgylyLwfQITP0CJ3S2AFOj4j 8fhOAS+VoOM3ivHn8dRJ =k/XM -----END PGP SIGNATURE----- --qK4iY2XH8GKezezA--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140808114650.GD93733>