From owner-freebsd-current@FreeBSD.ORG Mon Nov 4 17:27:56 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1BFCB49E; Mon, 4 Nov 2013 17:27:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9698F255D; Mon, 4 Nov 2013 17:27:55 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rA4HRjGm013596; Mon, 4 Nov 2013 19:27:45 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rA4HRjGm013596 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rA4HRjUM013595; Mon, 4 Nov 2013 19:27:45 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 4 Nov 2013 19:27:45 +0200 From: Konstantin Belousov To: Bryan Drewery Subject: Re: (r257598) panic: Assertion tmp->tm_pages_used == 0 failed at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316 Message-ID: <20131104172744.GT59496@kib.kiev.ua> References: <5277B0A5.5010506@FreeBSD.org> <20131104162731.GQ59496@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JzPxGqxua12JTMNb" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 17:27:56 -0000 --JzPxGqxua12JTMNb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 04, 2013 at 10:43:06AM -0600, Bryan Drewery wrote: > On 2013-11-04 10:27, Konstantin Belousov wrote: > > On Mon, Nov 04, 2013 at 08:35:17AM -0600, Bryan Drewery wrote: > >> 11.0-CURRENT #87 r257598 > >>=20 > >> During a poudriere build. > >>=20 > >> It creates a tmpfs, builds a port in a jail using that tmpfs and then > >> removes the tmpfs and recreate the tmpfs before building the next=20 > >> port. > >>=20 > >> > panic: Assertion tmp->tm_pages_used =3D=3D 0 failed at /usr/src/sys/= modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316 > >> > cpuid =3D 9 > >> > KDB: stack backtrace: > >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe= 1247ee57a0 > >> > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe1247ee5850 > >> > vpanic() at vpanic+0x126/frame 0xfffffe1247ee5890 > >> > kassert_panic() at kassert_panic+0x136/frame 0xfffffe1247ee5900 > >> > tmpfs_unmount() at tmpfs_unmount+0x163/frame 0xfffffe1247ee5930 > >> > dounmount() at dounmount+0x41f/frame 0xfffffe1247ee59b0 > >> > sys_unmount() at sys_unmount+0x356/frame 0xfffffe1247ee5ae0 > >> > amd64_syscall() at amd64_syscall+0x265/frame 0xfffffe1247ee5bf0 > >> > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247ee5bf0 > >> > --- syscall (22, FreeBSD ELF64, sys_unmount), rip =3D 0x8008a02fa, r= sp =3D 0x7fffffffd198, rbp =3D 0x7fffffffd2b0 --- > >> > Uptime: 44m40s > >>=20 > >> > (kgdb) #0 doadump (textdump=3D1) at pcpu.h:219 > >> > #1 0xffffffff808bcf87 in kern_reboot (howto=3D260) > >> > at /usr/src/sys/kern/kern_shutdown.c:447 > >> > #2 0xffffffff808bd495 in vpanic (fmt=3D, > >> > ap=3D) at /usr/src/sys/kern/kern_shutdown.c= :754 > >> > #3 0xffffffff808bd326 in kassert_panic (fmt=3D) > >> > at /usr/src/sys/kern/kern_shutdown.c:642 > >> > #4 0xffffffff81e159d3 in tmpfs_unmount (mp=3D0xfffff810502cd660, > >> > mntflags=3D) > >> > at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316 > >> > #5 0xffffffff8095e1af in dounmount (mp=3D0xfffff810502cd660, flags= =3D134742016, > >> > td=3D0xfffff8013d57a490) at /usr/src/sys/kern/vfs_mount.c:1324 > >> > #6 0xffffffff8095dd66 in sys_unmount (td=3D0xfffff8013d57a490, > >> > uap=3D0xfffffe1247ee5b80) at /usr/src/sys/kern/vfs_mount.c:1212 > >> > #7 0xffffffff80cb7d75 in amd64_syscall (td=3D0xfffff8013d57a490, tr= aced=3D0) > >> > at subr_syscall.c:134 > >> > #8 0xffffffff80c9c90b in Xfast_syscall () > >> > at /usr/src/sys/amd64/amd64/exception.S:391 > >> > #9 0x00000008008a02fa in ?? () > >=20 > > Do you have core ? > > I want to see the struct tmpfs_mount content for the tmpfs mount point > > which caused the panic. >=20 > Yes. >=20 > Hopefully this is what you're asking for: >=20 > (kgdb) frame > #4 0xffffffff81e159d3 in tmpfs_unmount (mp=3D0xfffff810502cd660,=20 > mntflags=3D) at=20 > /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316 > 316 MPASS(tmp->tm_pages_used =3D=3D 0); >=20 > (kgdb) print *mp > $2 =3D {mnt_mtx =3D {lock_object =3D {lo_name =3D 0xffffffff80f11f09 "str= uct=20 > mount mtx", lo_flags =3D 16973824, lo_data =3D 0, lo_witness =3D=20 > 0xfffffe00006d3b00}, mtx_lock =3D 4}, mnt_gen =3D 1, mnt_list =3D {tqe_ne= xt =3D=20 > 0xfffff8116be06660, tqe_prev =3D 0xfffff81050257688}, mnt_op =3D=20 > 0xffffffff81e1b940, mnt_vfc =3D 0xffffffff81e1ba60, mnt_vnodecovered =3D= =20 > 0xfffff8104fb0c3b0, > mnt_syncer =3D 0x0, mnt_ref =3D 1, mnt_nvnodelist =3D {tqh_first =3D 0= x0,=20 > tqh_last =3D 0xfffff810502cd6c0}, mnt_nvnodelistsize =3D 0,=20 > mnt_activevnodelist =3D {tqh_first =3D 0x0, tqh_last =3D 0xfffff810502cd6= d8},=20 > mnt_activevnodelistsize =3D 0, mnt_writeopcount =3D 1, mnt_kern_flag =3D= =20 > 16777225, mnt_flag =3D 4096, mnt_opt =3D 0xfffff80014424ae0, mnt_optnew = =3D=20 > 0x0, mnt_maxsymlinklen =3D 0, > mnt_stat =3D {f_version =3D 537068824, f_type =3D 135, f_flags =3D 409= 6,=20 > f_bsize =3D 4096, f_iosize =3D 4096, f_blocks =3D 17125058, f_bfree =3D= =20 > 17049291, f_bavail =3D 17049291, f_files =3D 2147483647, f_ffree =3D=20 > 2147473906, f_syncwrites =3D 0, f_asyncwrites =3D 0, f_syncreads =3D 0,= =20 > f_asyncreads =3D 0, f_spare =3D {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, f_namemax= =3D=20 > 255, f_owner =3D 0, f_fsid =3D { > val =3D {-2029977679, 135}}, f_charspare =3D '\0' ,=20 > f_fstypename =3D "tmpfs\000\000\000\000\000\000\000\000\000\000",=20 > f_mntfromname =3D "tmpfs", '\0' , f_mntonname =3D=20 > "/poudriere/data/build/exp-91amd64-default-xzibition/08/usr/local", '\0'= =20 > }, mnt_cred =3D 0xfffff8001418e100, mnt_data =3D=20 > 0xfffff80fedf75700, > mnt_time =3D 0, mnt_iosize_max =3D 65536, mnt_export =3D 0x0, mnt_labe= l =3D=20 > 0x0, mnt_hashseed =3D 4132690418, mnt_lockref =3D 0, mnt_secondary_writes= =3D=20 > 0, mnt_secondary_accwrites =3D 0, mnt_susp_owner =3D 0x0, mnt_gjprovider = =3D=20 > 0x0, mnt_explock =3D {lock_object =3D {lo_name =3D 0xffffffff80f11f1a=20 > "explock", lo_flags =3D 108199936, lo_data =3D 0, lo_witness =3D=20 > 0xfffffe00006eb280}, > lk_lock =3D 1, lk_exslpfail =3D 0, lk_timo =3D 0, lk_pri =3D 96},=20 > mnt_upper_link =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}, mnt_uppers =3D= =20 > {tqh_first =3D 0x0, tqh_last =3D 0xfffff810502cd980}} >=20 > (kgdb) print *(struct tmpfs_mount *)(mp)->mnt_data > $3 =3D {tm_pages_max =3D 18446744073709551615, tm_pages_used =3D=20 > 18446744073709551615, tm_root =3D 0xfffff8104ff44828, tm_nodes_max =3D=20 > 2147483647, tm_ino_unr =3D 0xfffff8002fd65080, tm_nodes_inuse =3D 0,=20 > tm_maxfilesize =3D 9223372036854775807, tm_nodes_used =3D {lh_first =3D 0= x0},=20 > allnode_lock =3D {lock_object =3D {lo_name =3D 0xffffffff81e1aa47 "tmpfs= =20 > allnode lock", > lo_flags =3D 16908288, lo_data =3D 0, lo_witness =3D=20 > 0xfffffe00006ecd80}, mtx_lock =3D 6}, tm_dirent_pool =3D 0xfffff810500bb0= 00,=20 > tm_node_pool =3D 0xfffff81050046000, tm_ronly =3D 0} >=20 > Looks like tm_pages_used is -1. Yes, it looks like it is over-accounted. Are you able to reproduce the panic at will ? My current guess-work is the following, which I think, is the right change anyway. diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c index 9dea3a1..8683e2f 100644 --- a/sys/vm/vm_object.c +++ b/sys/vm/vm_object.c @@ -2099,8 +2099,9 @@ vm_object_coalesce(vm_object_t prev_object, vm_ooffse= t_t prev_offset, if (prev_object =3D=3D NULL) return (TRUE); VM_OBJECT_WLOCK(prev_object); - if (prev_object->type !=3D OBJT_DEFAULT && - prev_object->type !=3D OBJT_SWAP) { + if ((prev_object->type !=3D OBJT_DEFAULT && + prev_object->type !=3D OBJT_SWAP) || + (prev_object->flags & OBJ_TMPFS) !=3D 0) { VM_OBJECT_WUNLOCK(prev_object); return (FALSE); } --JzPxGqxua12JTMNb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSd9kQAAoJEJDCuSvBvK1BfD4P/0zCBAZJIEmWG0KoTdtC3h6m dwqaljM21jh5f2JPjkP/MsNCa+mrrJ1RUAU8j7yniuQ6o7uLPH+V4s/K5kKwSC8q 5kJ6ozdbFvq/6swLriZE+FjB0CmEvlvijcstFYe4zr2/20ZnPdtymZyXgWsuA9lt sH0exeVgWgL2WwGJa1bwQdi9DiYjSoDk4tqigG72MEvlD5QCOX1+076QUgNBqsHG sMKf3PJst7bNraw7ZBpV4Bx4fMMZmy8LYeRMZb87pAOasiinGgaq7wadjDKHtpcy 418UjcrOaJnPW2dTSGvwigfgvh/WTYBEGlrEt+n3Dh4HpvvWAP1PHe9R5Ad7PfyQ Xv91oT+FrqSeLlOpzuUDl/MEps2wXxK75WHTesuTbRwdGnShGTlHYpDP2Mp3Ca4r k+4lH0ZhIzptnQmgG/3/v62wGwrtfmbrqyukj1uSc5U0CnJQsMX4T1yZFzRRBCrO 4pBgZTlJrMJQjapBE8r/9tvvQq1a5qsFXUcSu/+fARthWVjWT9+VsPtGKbMo8n11 tI3MaPS/PSoFGCQ1u6tkO0weNrgpCv2tsYpLzX5ztQ/koUgFBro/Wri8pY56L7aP WN4hkal4QyHfddXIhZmFb4ZUPk/G6QUMNIhrKS8wyHpNEXEqnBIuqgcuQ8/Az/55 nxF7rz901XL2sggYEmwS =Tx3E -----END PGP SIGNATURE----- --JzPxGqxua12JTMNb--