From owner-svn-src-all@freebsd.org Sat Sep 26 18:54:54 2020 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6D7EA426280 for ; Sat, 26 Sep 2020 18:54:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BzHyj2bwLz3gsP for ; Sat, 26 Sep 2020 18:54:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x829.google.com with SMTP id 19so5151242qtp.1 for ; Sat, 26 Sep 2020 11:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1WQD1dMqcvLe8+ErshELEq83g5E+OHJ8h/Qk2C8H5Gw=; b=gLPYZqvBvvsDW28hLqbXFOTzLApj68lv49mbp+KUI8E2PduT+/N6Zb4lVCH/MJbh02 dwG9aXiZ0TrPWHzShtW6bnhjTVg4R9s9SSR5XpC5ysUHKSO0in8ssFrfQdzDm0fEPH2j Lmn1u5mIh3gM/zDdx2yLvTqERs1OEIlqhcTS80H4Xs9wBXoW9r0XT4MEKmbEzAZgNorf +fpX46pRmXUg9uCqsqOzNNkAYfcyq5KCiNVo5t5thIp4/0m04M02+dZ/sJkNQA55cblp Xm+rn5PCwwSDTzsOazyDqTc8a/ZHoo5nmnolayyYkF4IKCduHpPS/aRk19cj1sfD9p2F bTgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1WQD1dMqcvLe8+ErshELEq83g5E+OHJ8h/Qk2C8H5Gw=; b=Xxnd5/92Q3FiCwzbovpbxjuUklmB4HUIPHXeHiIUsX7L7xRMEdYUt0l24RHEGaY+lN j8vD03LbzBlZxAqshP3RoP7VeVj5tn8cBzc5OS2oDkhOQ4Fxy7zRoBvubWEKETDe+uB8 HR4RK2SheoH0gnvlgrUYxQn8bGfmDXEXaUyxo/xLfFjDnsoK3M76c1Xj0YAP5hRW1jnl kxafQL1yS8AOej8t5uKSMEErtV8NVGyYeqTm4TG4QnZHBSvmkQg1E50Sd0dcVuAAYoYS IGiRmh0oixZDejvelgsMbvEGwqrSmncv479gSXeeporVMIrzpx1Fop0zMtQgELd4NigH PcKA== X-Gm-Message-State: AOAM532KOiIBawyzzrRTcwMdWihUGg0E7jHN6isWkuVlMcAOl5dxhzyA gaZ9j1Q2hlqe4rbv/ysckmFLX/iNXuWBECVTPAJVLw== X-Google-Smtp-Source: ABdhPJwcj6X2ueOCRYDqTSpsJucuSZkVnyg4N8tythS7AlGkuJXoq/8cOgp3dcQZvUB6R+isZ+2iPxSIRtk7iDQ3ht0= X-Received: by 2002:ac8:3261:: with SMTP id y30mr5721674qta.242.1601146492172; Sat, 26 Sep 2020 11:54:52 -0700 (PDT) MIME-Version: 1.0 References: <202009261702.08QH2AQ1055654@gndrsh.dnsmgr.net> In-Reply-To: <202009261702.08QH2AQ1055654@gndrsh.dnsmgr.net> From: Warner Losh Date: Sat, 26 Sep 2020 12:54:41 -0600 Message-ID: Subject: Re: svn commit: r365643 - head/bin/cp To: "Rodney W. Grimes" Cc: Ian Lepore , src-committers , svn-src-all , svn-src-head X-Rspamd-Queue-Id: 4BzHyj2bwLz3gsP X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=gLPYZqvB; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::829) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.29 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.92)[-0.921]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-all@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.38)[-0.379]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::829:from]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[svn-src-all]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2020 18:54:54 -0000 On Sat, Sep 26, 2020 at 11:02 AM Rodney W. Grimes wrote: > > > On Fri, 2020-09-25 at 10:55 -0700, Rodney W. Grimes wrote: > > > > I was under the impression from previous reading and kib's response > > > > that this is a complete non-issue, there's no way you can go > > > > multi-user without a mounted /dev and we go to somewhat great > > > > lengths to make sure we're good. > > > > > > Though kib can assert that, it does not change the fact that I > > > frequently find /dev/null FILES on unmounted root file systems. > > > > > > But lets not mix the 2 separate things of boot time /dev dependency > > > and build time /dev dependency. > > > > If you look in sys/kern/vfs_mountroot.c you can see that the code to > > mount /dev is invoked unconditionally as the first step of mounting > > root, and that all the calls it makes to get devfs mounted have their > > results checked with KASSERTs. > > > > That's pretty strong evidence that devfs is mounted before rc scripts > > run. That creates a situation where you are making an extraordinary > > claim, so you need to provide extraordinary evidence to support it. A > > sequence of actions that allows others to recreate the situation would > > do the trick. > > I have provided ways one can look for this file in > other messages of the threads. A dump of a UFS root > can show it up, and iirc you can find it in a > zfs send of a boot dataset. > You've not provided a step-by-step way to recreate the issue leading to the /dev/null file, however. Absent that, it's going to be really hard to fix it. > (A question that occurs to me: could it be that the files you've seen > > got created at shutdown after devfs was unmounted, rather than at > > startup? I don't know enough about the shutdown sequence to know > > whether that's possible.) > > Its not "the files" it is "a file, /dev/null". And yes, it could > be very possible that it is during shutdown. Sadly the files is > usually of 0 length so leave little clue as to what is creating them. > And there's the rub: how did this file come to exist? I'm certain it isn't booting or shutting down the system based on when devfs is mounted (before init) and unmounted (it's not done by the shutdown scripts). Now, it's always possible there's a hole in my understanding of the sequence of events. But given the examination of code, it's crazy to think this could be created by anything but some weird bug. That's why a step-by-step from scratch guide is needed. Im happy to look into it, but I need a bit more to go on. Warner