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:

NetBSD Home
NetBSD PR Database Search

(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.