From owner-freebsd-current@FreeBSD.ORG Mon Nov 4 22:48:12 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 482BD612 for ; Mon, 4 Nov 2013 22:48:12 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2D73128F0 for ; Mon, 4 Nov 2013 22:48:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rA4MmCil006817 for ; Mon, 4 Nov 2013 22:48:12 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rA4MmBrF006814 for current@freebsd.org; Mon, 4 Nov 2013 22:48:11 GMT (envelope-from bdrewery) Received: (qmail 77302 invoked from network); 4 Nov 2013 16:48:10 -0600 Received: from unknown (HELO roundcube.xk42.net) (10.10.5.5) by sweb.xzibition.com with SMTP; 4 Nov 2013 16:48:10 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 04 Nov 2013 16:48:09 -0600 From: Bryan Drewery To: Konstantin Belousov Subject: Re: (r257598) panic: Assertion =?UTF-8?Q?tmp-=3Etm=5Fpages=5Fused?= =?UTF-8?Q?=20=3D=3D=20=30=20failed=20at=20/usr/src/sys/modules/tmpfs/=2E?= =?UTF-8?Q?=2E/=2E=2E/fs/tmpfs/tmpfs=5Fvfsops=2Ec=3A=33=31=36?= Organization: FreeBSD In-Reply-To: <20131104172744.GT59496@kib.kiev.ua> References: <5277B0A5.5010506@FreeBSD.org> <20131104162731.GQ59496@kib.kiev.ua> <20131104172744.GT59496@kib.kiev.ua> Message-ID: <4cb9ac8e7c03fb6ba1f35f94dbc9f791@shatow.net> X-Sender: bdrewery@FreeBSD.org User-Agent: Roundcube Webmail/0.9.3 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 22:48:12 -0000 On 2013-11-04 11:27, Konstantin Belousov wrote: > 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 >> >> >> >> During a poudriere build. >> >> >> >> 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 >> >> port. >> >> >> >> > panic: Assertion tmp->tm_pages_used == 0 failed at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316 >> >> > cpuid = 9 >> >> > KDB: stack backtrace: >> >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe1247ee57a0 >> >> > 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 = 0x8008a02fa, rsp = 0x7fffffffd198, rbp = 0x7fffffffd2b0 --- >> >> > Uptime: 44m40s >> >> >> >> > (kgdb) #0 doadump (textdump=1) at pcpu.h:219 >> >> > #1 0xffffffff808bcf87 in kern_reboot (howto=260) >> >> > at /usr/src/sys/kern/kern_shutdown.c:447 >> >> > #2 0xffffffff808bd495 in vpanic (fmt=, >> >> > ap=) at /usr/src/sys/kern/kern_shutdown.c:754 >> >> > #3 0xffffffff808bd326 in kassert_panic (fmt=) >> >> > at /usr/src/sys/kern/kern_shutdown.c:642 >> >> > #4 0xffffffff81e159d3 in tmpfs_unmount (mp=0xfffff810502cd660, >> >> > mntflags=) >> >> > at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316 >> >> > #5 0xffffffff8095e1af in dounmount (mp=0xfffff810502cd660, flags=134742016, >> >> > td=0xfffff8013d57a490) at /usr/src/sys/kern/vfs_mount.c:1324 >> >> > #6 0xffffffff8095dd66 in sys_unmount (td=0xfffff8013d57a490, >> >> > uap=0xfffffe1247ee5b80) at /usr/src/sys/kern/vfs_mount.c:1212 >> >> > #7 0xffffffff80cb7d75 in amd64_syscall (td=0xfffff8013d57a490, traced=0) >> >> > at subr_syscall.c:134 >> >> > #8 0xffffffff80c9c90b in Xfast_syscall () >> >> > at /usr/src/sys/amd64/amd64/exception.S:391 >> >> > #9 0x00000008008a02fa in ?? () >> > >> > Do you have core ? >> > I want to see the struct tmpfs_mount content for the tmpfs mount point >> > which caused the panic. >> >> Yes. >> >> Hopefully this is what you're asking for: >> >> (kgdb) frame >> #4 0xffffffff81e159d3 in tmpfs_unmount (mp=0xfffff810502cd660, >> mntflags=) at >> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316 >> 316 MPASS(tmp->tm_pages_used == 0); >> >> (kgdb) print *mp >> $2 = {mnt_mtx = {lock_object = {lo_name = 0xffffffff80f11f09 "struct >> mount mtx", lo_flags = 16973824, lo_data = 0, lo_witness = >> 0xfffffe00006d3b00}, mtx_lock = 4}, mnt_gen = 1, mnt_list = {tqe_next >> = >> 0xfffff8116be06660, tqe_prev = 0xfffff81050257688}, mnt_op = >> 0xffffffff81e1b940, mnt_vfc = 0xffffffff81e1ba60, mnt_vnodecovered = >> 0xfffff8104fb0c3b0, >> mnt_syncer = 0x0, mnt_ref = 1, mnt_nvnodelist = {tqh_first = 0x0, >> tqh_last = 0xfffff810502cd6c0}, mnt_nvnodelistsize = 0, >> mnt_activevnodelist = {tqh_first = 0x0, tqh_last = >> 0xfffff810502cd6d8}, >> mnt_activevnodelistsize = 0, mnt_writeopcount = 1, mnt_kern_flag = >> 16777225, mnt_flag = 4096, mnt_opt = 0xfffff80014424ae0, mnt_optnew = >> 0x0, mnt_maxsymlinklen = 0, >> mnt_stat = {f_version = 537068824, f_type = 135, f_flags = 4096, >> f_bsize = 4096, f_iosize = 4096, f_blocks = 17125058, f_bfree = >> 17049291, f_bavail = 17049291, f_files = 2147483647, f_ffree = >> 2147473906, f_syncwrites = 0, f_asyncwrites = 0, f_syncreads = 0, >> f_asyncreads = 0, f_spare = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, f_namemax >> = >> 255, f_owner = 0, f_fsid = { >> val = {-2029977679, 135}}, f_charspare = '\0' > times>, >> f_fstypename = "tmpfs\000\000\000\000\000\000\000\000\000\000", >> f_mntfromname = "tmpfs", '\0' , f_mntonname = >> "/poudriere/data/build/exp-91amd64-default-xzibition/08/usr/local", >> '\0' >> }, mnt_cred = 0xfffff8001418e100, mnt_data = >> 0xfffff80fedf75700, >> mnt_time = 0, mnt_iosize_max = 65536, mnt_export = 0x0, mnt_label = >> 0x0, mnt_hashseed = 4132690418, mnt_lockref = 0, mnt_secondary_writes >> = >> 0, mnt_secondary_accwrites = 0, mnt_susp_owner = 0x0, mnt_gjprovider = >> 0x0, mnt_explock = {lock_object = {lo_name = 0xffffffff80f11f1a >> "explock", lo_flags = 108199936, lo_data = 0, lo_witness = >> 0xfffffe00006eb280}, >> lk_lock = 1, lk_exslpfail = 0, lk_timo = 0, lk_pri = 96}, >> mnt_upper_link = {tqe_next = 0x0, tqe_prev = 0x0}, mnt_uppers = >> {tqh_first = 0x0, tqh_last = 0xfffff810502cd980}} >> >> (kgdb) print *(struct tmpfs_mount *)(mp)->mnt_data >> $3 = {tm_pages_max = 18446744073709551615, tm_pages_used = >> 18446744073709551615, tm_root = 0xfffff8104ff44828, tm_nodes_max = >> 2147483647, tm_ino_unr = 0xfffff8002fd65080, tm_nodes_inuse = 0, >> tm_maxfilesize = 9223372036854775807, tm_nodes_used = {lh_first = >> 0x0}, >> allnode_lock = {lock_object = {lo_name = 0xffffffff81e1aa47 "tmpfs >> allnode lock", >> lo_flags = 16908288, lo_data = 0, lo_witness = >> 0xfffffe00006ecd80}, mtx_lock = 6}, tm_dirent_pool = >> 0xfffff810500bb000, >> tm_node_pool = 0xfffff81050046000, tm_ronly = 0} >> >> Looks like tm_pages_used is -1. > > Yes, it looks like it is over-accounted. Are you able to reproduce > the panic at will ? Yes I can consistently reproduce this. It for some reason occurs when devel/jna port fails to build. I reproduced it about 6 out of 6 times without your patch. > > My current guess-work is the following, which I think, is the right > change anyway. The patch does fix the issue. Tested 3 times. Thanks! > > 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_ooffset_t prev_offset, > if (prev_object == NULL) > return (TRUE); > VM_OBJECT_WLOCK(prev_object); > - if (prev_object->type != OBJT_DEFAULT && > - prev_object->type != OBJT_SWAP) { > + if ((prev_object->type != OBJT_DEFAULT && > + prev_object->type != OBJT_SWAP) || > + (prev_object->flags & OBJ_TMPFS) != 0) { > VM_OBJECT_WUNLOCK(prev_object); > return (FALSE); > } -- Regards, Bryan Drewery