NetBSD Problem Report #56338
From paul@whooppee.com Fri Jul 30 12:44:53 2021
Return-Path: <paul@whooppee.com>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 6088A1A921F
for <gnats-bugs@gnats.NetBSD.org>; Fri, 30 Jul 2021 12:44:53 +0000 (UTC)
Message-Id: <20210730124449.92BBE30F2C4@speedy.whooppee.com>
Date: Fri, 30 Jul 2021 05:44:49 -0700 (PDT)
From: paul@whooppee.com
Reply-To: paul@whooppee.com
To: gnats-bugs@NetBSD.org
Subject: Installing qt5-qtdeclarative leaves a dangling reference to /tmp
X-Send-Pr-Version: 3.95
>Number: 56338
>Category: pkg
>Synopsis: Installing qt5-qtdeclarative leaves a dangling reference to something in /tmp
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: pkg-manager
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Jul 30 12:45:00 +0000 2021
>Closed-Date: Sat May 21 01:14:39 +0000 2022
>Last-Modified: Sat May 21 01:15:01 +0000 2022
>Originator: Paul Goyette
>Release: NetBSD 9.99.87
>Organization:
+--------------------+--------------------------+----------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org |
| | | pgoyette99@gmail.com |
+--------------------+--------------------------+----------------------+
>Environment:
System: NetBSD speedy.whooppee.com 9.99.87 NetBSD 9.99.87 (SPEEDY 2021-07-23 13:58:03 UTC) #0: Sat Jul 24 00:01:27 UTC 2021 paul@speedy.whooppee.com:/build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY amd64
Architecture: x86_64
Machine: amd64
>Description:
Installing the qt5-qtdeclarative package leaves some sort of dangling
reference to something in /tmp. In the case of using a chroot sandbox
(as created by mksandbox), and having a separate tmpfs for $SB/tmp the
dangling reference prevents one from unmounting the tmpfs.
>How-To-Repeat:
1. Create a sandbox using mksandbox, for example $SB
2. Mount a tmpfs file system on $SB/tmp
3. (optional) Use $SB/sandbox to "enter" the chroot, build a whole lot
of packages (in my case, about 545 of them), and exit the chroot
via ^D.
4. Verify that all is OK using ``umount $SB/tmp'', then remount the
tmpfs
5. "Enter" the sandbox again, and build qt5-qtdeclarative package
6. Exit the chroot via ^D, and try to umount the tmpfs. Observe the
EBUSY response.
>Fix:
Unknown
>Release-Note:
>Audit-Trail:
From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: pkg/56338: Installing qt5-qtdeclaraative leaves a dangling
reference to /tmp
Date: Fri, 30 Jul 2021 05:48:51 -0700 (PDT)
Please also note that fstat(1) shows no open files on the tmpfs, which
makes it difficult to debug further.
From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: pkg/56338: Installing qt5-qtdeclaraative leaves a dangling
reference to /tmp
Date: Fri, 18 Feb 2022 08:01:25 -0800 (PST)
Just a bit more debug info to show the mount list at the time of the
failure, and the output from fstat (inluding the -f option)
# mount
/dev/wd0a on / type ffs (local)
/dev/wd0e on /var type ffs (local)
/dev/wd0f on /home type ffs (local)
/dev/ld0e on /build type ffs (noatime, local)
kernfs on /kern type kernfs (local)
ptyfs on /dev/pts type ptyfs (local)
procfs on /proc type procfs (local)
tmpfs on /tmp type tmpfs (local)
tmpfs on /var/shm type tmpfs (local)
/build/netbsd-local/src on /build/netbsd-local/src_ro type null (read-only, local)
/build/netbsd-local/xsrc on /build/netbsd-local/xsrc_ro type null (read-only, local)
/build/netbsd-current/src on /build/netbsd-current/src_ro type null (read-only, local)
tmpfs on /build/sandbox/tmp type tmpfs (local)
# fstat -f /build/sandbox/tmp
USER CMD PID FD MOUNT INUM MODE SZ|DV
R/W
#
<Manually added the following, since Emails to gnats-bugs seems not to
be working at the moment>
Some addditional info, collected with enormous help from riastradh@
The mount entry for /build/sandbox/tmp
(gdb) print
*mountlist.tqh_first.me_list.tqe_next->me_list.tqe_next->me_list.tqe_next->me_list.tqe_next->me_list.tqe_next->me_list.tqe_next->me_list.tqe_next->me_list.tqe_next->me_list.tqe_next->me_list.tqe_next->me_list.tqe_next->me_list.tqe_next->me_mount
$15 = {mnt_vnodelock = 0xffff81bc9141ea00, mnt_op = 0xffffffff81234000,
mnt_vnodecovered = 0xffff81bbb2e2a380, mnt_lower = 0x0,
mnt_transinfo = 0xffff81c9289166c0, mnt_data = 0xffff81c14ebef2c0,
mnt_renamelock = 0xffff81bc9141ea40, mnt_flag = 4096, mnt_iflag = 1952,
mnt_fs_bshift = 12, mnt_dev_bshift = 9, mnt_specdataref = {
specdataref_container = 0x0, specdataref_lock = {u = {mtxa_owner = 0, s = {
mtxs_dummy = 0 '\000', mtxs_ipl = {_ipl = 0 '\000'},
mtxs_lock = 0 '\000', mtxs_unused = 0 '\000'}}}},
mnt_updating = 0xffff81bc9141e9c0, mnt_wapbl_op = 0x0, mnt_wapbl = 0x0,
mnt_wapbl_replay = 0x0, mnt_gen = 168, mnt_refcnt = 2,
mnt_synclist_slot = 9, mnt_vnodelist = {tqh_first = 0xffff81bcbbc7fd00,
tqh_last = 0xffff81bcbbc7fe58}, mnt_stat = {f_flag = 0, f_bsize = 4096,
f_frsize = 4096, f_iosize = 4096, f_blocks = 13412631, f_bfree = 13412630,
f_bavail = 13412630, f_bresvd = 0, f_files = 53650527, f_ffree = 53650526,
f_favail = 53650526, f_fresvd = 0, f_syncreads = 0, f_syncwrites = 0,
f_asyncreads = 0, f_asyncwrites = 0, f_fsidx = {__fsid_val = {43921,
27051}}, f_fsid = 43921, f_namemax = 255, f_owner = 0, f_spare = {0,
0, 0, 0}, f_fstypename = "tmpfs", '\000' <repeats 26 times>,
f_mntonname = "/build/sandbox/tmp", '\000' <repeats 1005 times>,
f_mntfromname = "tmpfs", '\000' <repeats 1018 times>,
f_mntfromlabel = '\000' <repeats 1023 times>}}
And the first (and only) vnode for the filesystem:
(gdb) print
*mountlist.tqh_first.me_list.tqe_next->me_list.tqe_next->me_list.tqe_next->m
e_list.tqe_next->me_list.tqe_next->me_list.tqe_next->me_list.tqe_next->me_li
st.tqe_next->me_list.tqe_next->me_list.tqe_next->me_list.tqe_next->me_list.t
qe_next->me_mount->mnt_vnodelist.tqh_first
$18 = {vi_vnode = {v_uobj = {vmobjlock = 0xffff81d46389c280,
pgops = 0xffffffff808b2fe0 <uvm_vnodeops>, uo_npages = 0x0,
uo_refs = 0x1, uo_pages = {t_root = 0x0, t_height = 0x0}, uo_ubc = {
lh_first = 0x0}}, v_size = 0x0, v_writesize = 0x0, v_cv = {
cv_opaque = {0x0, 0xffffffff80945a02}}, v_iflag = 0x0, v_uflag = 0x0,
v_usecount = 0x80000014, v_numoutput = 0x0, v_writecount = 0x0,
v_holdcnt = 0x0, v_cleanblkhd = {lh_first = 0x0}, v_dirtyblkhd = {
lh_first = 0x0}, v_vflag = 0x18, v_interlock = 0xffff81cc540596c0,
v_mount = 0xffff81c2728c8000, v_op = 0xffff81c5d92e4200, v_un = {
vu_mountedhere = 0x0, vu_socket = 0x0, vu_specnode = 0x0,
vu_fifoinfo = 0x0, vu_ractx = 0x0}, v_type = VREG, v_tag = VT_TMPFS,
vu_fifoinfo = 0x0, vu_ractx = 0x0}, v_type = VREG, v_tag = VT_TMPFS,
v_data = 0xffff81d4df8b4ee0, v_klist = {slh_first = 0x0},
v_klist_interest = 0x0, v_segvguard = 0x0}, vi_key = {
vk_mount = 0xffff81c2728c8000, vk_key = 0xffff81bcbbc7fdb0,
vk_key_len = 0x8}, vi_lrulisthd = 0xffffffff80c4efd0 <lru_list+16>,
vi_lrulist = {tqe_next = 0xffff81bcb4fecb00, tqe_prev = 0xffff81c99885b1a0},
vi_synclist_slot = 0x0, vi_lrulisttm = 0x5c3d999, vi_synclist = {
tqe_next = 0x0, tqe_prev = 0x0}, vi_hash = {sle_next = 0x0},
vi_state = VS_LOADED, vi_mntvnodes = {tqe_next = 0x0,
tqe_prev = 0xffff81c2728c8088}, vi_nc_tree = {rbt_root = 0x0,
rbt_ops = 0xffffffff808bb8a0 <cache_rbtree_ops>, rbt_minmax = {0x0, 0x0}},
vi_nc_list = {tqh_first = 0x0, tqh_last = 0xffff81bcbbc7fea0},
vi_nc_mode = 0xffffffff, vi_nc_uid = 0xffffffff, vi_nc_gid = 0xffffffff,
vi_nc_spare = 0x0, vi_lock = {rw_owner = 0x0}, vi_nc_lock = {
rw_owner = 0x0}, vi_nc_listlock = {rw_owner = 0x0}}
pstat -v for this vnode reports
...skipping...
*** MOUNT tmpfs tmpfs on /build/sandbox/tmp (local)
ADDR TYP VFLAG USE HOLD TAG NPAGE
ffff81bcbbc7fd00 reg M 21 0 25 0
Of particular interest is the ref-count of 0x14 (plus VUSECOUNT_GATE)
and the VFLAG
From: "Juergen Hannken-Illjes" <hannken@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/56338 CVS commit: src/sys/uvm
Date: Sun, 27 Mar 2022 20:18:05 +0000
Module Name: src
Committed By: hannken
Date: Sun Mar 27 20:18:05 UTC 2022
Modified Files:
src/sys/uvm: uvm_mmap.c
Log Message:
Make mmap() with "len == 0" an error if not MAP_ANON. We should return
an error for MAP_ANON too but unfortunately our /libexec/ld.elf_so
sometimes creates an empty anon mapping for the bss of a shared library.
At least FreeBSD and Solaris return this error too and according to POSIX
"If len is zero, mmap() shall fail and no mapping shall be established".
Fixes PR pkg/56338 Installing qt5-qtdeclarative leaves a dangling reference
The dangling reference here originates from vn_mmap() taking a vnode
reference for this empty mapping that will never be released.
To generate a diff of this commit:
cvs rdiff -u -r1.176 -r1.177 src/sys/uvm/uvm_mmap.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 21 May 2022 00:10:10 +0000
State-Changed-Why:
Is this fixed?
State-Changed-From-To: feedback->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 21 May 2022 01:14:39 +0000
State-Changed-Why:
yes it is
From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@netbsd.org
Cc: pkg-manager@netbsd.org, pkgsrc-bugs@netbsd.org, gnats-admin@netbsd.org,
dholland@NetBSD.org
Subject: Re: pkg/56338 (Installing qt5-qtdeclarative leaves a dangling
reference to something in /tmp)
Date: Fri, 20 May 2022 18:13:18 -0700 (PDT)
It's fixed
On Sat, 21 May 2022, dholland@NetBSD.org wrote:
> Synopsis: Installing qt5-qtdeclarative leaves a dangling reference to something in /tmp
>
> State-Changed-From-To: open->feedback
> State-Changed-By: dholland@NetBSD.org
> State-Changed-When: Sat, 21 May 2022 00:10:10 +0000
> State-Changed-Why:
> Is this fixed?
>
>
>
>
> !DSPAM:62882e0771266810159776!
>
>
+--------------------+--------------------------+----------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org |
| & Network Engineer | | pgoyette99@gmail.com |
+--------------------+--------------------------+----------------------+
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.