From owner-freebsd-arch@freebsd.org Sun May 15 13:42:51 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0D37B3B7BC; Sun, 15 May 2016 13:42:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 73E7E1099; Sun, 15 May 2016 13:42:46 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA04848; Sun, 15 May 2016 16:38:02 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1b1wF8-000GHJ-8t; Sun, 15 May 2016 16:38:02 +0300 To: freebsd-arch@FreeBSD.org, freebsd-fs From: Andriy Gapon Subject: mount / unmount and mountcheckdirs() Message-ID: <5c01bf62-b7b2-2e1d-bca5-859e6bf1f0e5@FreeBSD.org> Date: Sun, 15 May 2016 16:37:05 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 13:42:51 -0000 I am curious about the purpose of mountcheckdirs() called when mounting and unmounting a filesystem. The function is described as such: /* * Scan all active processes and prisons to see if any of them have a current * or root directory of `olddp'. If so, replace them with the new mount point. */ and it seems to be used to "lift" processes and jails to a root of a new filesystem when it is mounted and to "lower" them onto a covered vnode (if any) when a filesystem is unmounted. What's the purpose of those actions? It's strange that the machinations are done at all, but it is stranger that they are applied only to processes and jails at exactly a covered vnode and a root vnode. Anything below in a filesystem's tree is left alone. Is there anything so very special about being at exactly those points? IMO, the machinations can have unexpected security consequences. A little bit of history. mountcheckdirs() was first added in r22521 (circa 1997) as checkdirs with a rather non-specific commit message. Initially it was used only when a filesystem was mounted. Then, in r73241 (circa 2002) the function was added to dounmount(): The checkdirs() function is called at mount time to find any process fd_cdir or fd_rdir pointers referencing the covered mountpoint vnode. It transfers these to point at the root of the new filesystem. However, this process was not reversed at unmount time, so processes with a cwd/root at a mount point would unexpectedly lose their cwd/root following a mount-unmount cycle at that mountpoint. ... Dounmount() now undoes the actions taken by checkdirs() at mount time; any process cdir/rdir pointers that reference the root vnode of the unmounted filesystem are transferred to the now-uncovered vnode. -- Andriy Gapon From owner-freebsd-arch@freebsd.org Sun May 15 16:53:37 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D384CB3C990; Sun, 15 May 2016 16:53:37 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7DEA9120F; Sun, 15 May 2016 16:53:37 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wm0-x244.google.com with SMTP id e201so13358314wme.2; Sun, 15 May 2016 09:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Y1hB2QtQw86g5Esi718zi9W2Rdhm8nQI48Gzl+oxQLo=; b=fXlhRU7dtzRsrz0aQqMjrJsYvzPVwaMBFS7+rbJgQjGr2ckEKqn6bZF6XcdC9abSIl OJYE+NvQkHc2C80ziEdPrOHABDXweIN7oCMgKrTGufI/emJ4Qe2Tk64vb+KmjqqS2JDG I4eREXCsZP3kvcPbIspl5+F4fx2cdX4E1NnLAi1mKmiCvb++mkpv4WUAAiuVOlnoOh7j 15mXgYkSmCbwz43F9RvfOJFznvSSSZycGZhrO+WbCEZkVdwPE6X7BdfBoQVMititnuZR /mffZVtKvCMzaaUJ7aakyzC3AL+9yllMeshI4w2TQMasoQRxJCCaoSKJ48WoIHQMKKxW EVJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Y1hB2QtQw86g5Esi718zi9W2Rdhm8nQI48Gzl+oxQLo=; b=EPMHiYsTPvh0DqxUHK+GNfKGps0OOVSfjjXDbj5Kza9LPBhGBLzxAWCa7pI2WtEJuH HO/THMTsBJB2KFfqLitdCZyXiufpmtpRWZmoXrIOJXqH2XwPqH7EC8/xpNihABPfUosZ itfN3bdhwdrEvDdV6+z3DKizDdcB9ISoXZBmRVglyJxiPUMpv0c262NlCwuNboIZQrs9 XPr4Kaqs7DiWX7bzO4UgDyEEGUg9ZW323u0SaxcZTbaY+EWnsn9TH5W39SKvi/TYgBHV 6DqWwaYfa7Obttb7MA64PQf2QG4FvRFd2I5fvRiAp3/Z1v2H/S+KUtZhD2QKE97RKhI0 9umg== X-Gm-Message-State: AOPr4FVvul2R3LpF1VutAwX2UMkvpoR32Rpyqxsf02LnkAOkwHQm9YYzEcLL84Pgom9tVQ== X-Received: by 10.194.234.167 with SMTP id uf7mr25495264wjc.122.1463331216058; Sun, 15 May 2016 09:53:36 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by smtp.gmail.com with ESMTPSA id c194sm13990641wme.9.2016.05.15.09.53.34 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sun, 15 May 2016 09:53:34 -0700 (PDT) Date: Sun, 15 May 2016 18:53:32 +0200 From: Mateusz Guzik To: Andriy Gapon Cc: freebsd-arch@FreeBSD.org, freebsd-fs Subject: Re: mount / unmount and mountcheckdirs() Message-ID: <20160515165332.GA27836@dft-labs.eu> References: <5c01bf62-b7b2-2e1d-bca5-859e6bf1f0e5@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5c01bf62-b7b2-2e1d-bca5-859e6bf1f0e5@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 16:53:37 -0000 On Sun, May 15, 2016 at 04:37:05PM +0300, Andriy Gapon wrote: > > I am curious about the purpose of mountcheckdirs() called when mounting and > unmounting a filesystem. > > The function is described as such: > /* > * Scan all active processes and prisons to see if any of them have a current > * or root directory of `olddp'. If so, replace them with the new mount point. > */ > and it seems to be used to "lift" processes and jails to a root of a new > filesystem when it is mounted and to "lower" them onto a covered vnode (if any) > when a filesystem is unmounted. > > What's the purpose of those actions? > It's strange that the machinations are done at all, but it is stranger that they > are applied only to processes and jails at exactly a covered vnode and a root > vnode. Anything below in a filesystem's tree is left alone. Is there anything > so very special about being at exactly those points? > > IMO, the machinations can have unexpected security consequences. > I don't know why this was implemented. It is also being done in NetBSD. It is not done in Solaris nor Linux. Replacement is buggy in at least 2 ways: 1. the process vs jail vnode replacement leaves a time window where these 2 don't match, which screws up with the look up 2. on fork we can have a 'struct filedesc' object copied but not assigned to the new process yet, so it ends up with the old vnode And indeed, interested parties still have access to old vnodes by means of having a file descriptor. That said, this likely needs to be simply changed to /deny/ mount operations which would alter jail roots. -- Mateusz Guzik From owner-freebsd-arch@freebsd.org Sun May 15 23:07:23 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35E17B3C32E for ; Sun, 15 May 2016 23:07:23 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 03AF017B6 for ; Sun, 15 May 2016 23:07:22 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id u4FN7Gtg069070 for ; Sun, 15 May 2016 16:07:20 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201605152307.u4FN7Gtg069070@gw.catspoiler.org> Date: Sun, 15 May 2016 16:07:16 -0700 (PDT) From: Don Lewis Subject: is ut_user[] in struct utmpx NUL terminated? To: freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 23:07:23 -0000 There is a lot of code that expects ut_user[] to be NUL terminated. There is also a lot of code that sets ut_user[] using strncmp(), which will not guarantee NUL termination of this field if the name is sufficiently long. This doesn't matter as long as user names are kept short enough, but there doesn't seem to be any limit enforced by the passwd file format or getpwent(). From owner-freebsd-arch@freebsd.org Mon May 16 07:03:20 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4DAFCB3DED6; Mon, 16 May 2016 07:03:20 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D896E1432; Mon, 16 May 2016 07:03:19 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id a17so120423832wme.0; Mon, 16 May 2016 00:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=JPOvQYSt7RTwNWj5WNCvYQS5JFsuu4sZBydUKZ2z2fA=; b=F1v0eF+z+4Xc49juEOXt0LUUUebPI3Ya2fV7Y/P4aIR6N2F59AXKxdWtzXSWHt/sQb ZOISylbveoDM40XhTOAvQbVoRQ2pLLNncth6pGQiJxLsqOgSPDEQTHehw3iTh+MfsAZJ ENXQcq6/PoBSEOl292WF03K6LRmgzCJxX1y/N/skRQ5zvCno8Y6rZ5FIRxC5vkQ/V2/s Qrp0rft1ITdbD7WvwJfhV3nsA7H+VDeBBfjOASTSQGfK2Zq8MLmR721Dehf1DRyVAhvr K9zFkWMIgqGqAsF9Hu523dLMWiP08Qn8PXDOQFMU576OWymhjxFw/B33r3ebUA00Uh9X 3GqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=JPOvQYSt7RTwNWj5WNCvYQS5JFsuu4sZBydUKZ2z2fA=; b=B6WGRH8RA95o84U63iBaiMdK2LE82x0A/nL7SRgrvpG0Q7VBDkzxNpm/DtFInbmB+R RJcuquh+1PKXRCBiNu9ksnaS+absVYNikieJq4M4KUs7L0bNmv7v3irG5EgcN/m7IxMr ucYWzml8d4ie+ZSnx29s9vhdPrgwK3qCaj8jThTb5JF88EkUDGpJrRKZEvWx2jO2hAhN NVksSUNdw9qboK8uSeVoIL1bGEqzzw8EjuMLkK4+dG9whM9etBxncdfc4lyDau4fYG/B 3JdRZm9iUgjclhsQO0XdfRZjubmwoZE19O/0HXm/sLlcIc5TMjCzA4ZELLfDlk6Fnnme zBqw== X-Gm-Message-State: AOPr4FVli7+0kYXLCNaKsfM4eaOkPc26NVu3FeWtcZVAeshWm36oud2wKa8J8wCWqmJoHg== X-Received: by 10.194.19.197 with SMTP id h5mr27803898wje.139.1463382198098; Mon, 16 May 2016 00:03:18 -0700 (PDT) Received: from brick (acyr99.neoplus.adsl.tpnet.pl. [83.11.201.99]) by smtp.gmail.com with ESMTPSA id u6sm32098595wjh.2.2016.05.16.00.03.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 May 2016 00:03:16 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Mon, 16 May 2016 09:03:14 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Andriy Gapon Cc: freebsd-arch@FreeBSD.org, freebsd-fs Subject: Re: mount / unmount and mountcheckdirs() Message-ID: <20160516070314.GA3029@brick> Mail-Followup-To: Andriy Gapon , freebsd-arch@FreeBSD.org, freebsd-fs References: <5c01bf62-b7b2-2e1d-bca5-859e6bf1f0e5@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5c01bf62-b7b2-2e1d-bca5-859e6bf1f0e5@FreeBSD.org> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 07:03:20 -0000 On 0515T1637, Andriy Gapon wrote: > > I am curious about the purpose of mountcheckdirs() called when mounting and > unmounting a filesystem. [..] Whatever you do, please make sure you don't break autofs, and reroot, esp. firmware(9) loading after reroot. I'll happily test patches, just mail them to me. Thanks :-) From owner-freebsd-arch@freebsd.org Mon May 16 07:43:49 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61BDDB3CFEC; Mon, 16 May 2016 07:43:49 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7997A199B; Mon, 16 May 2016 07:43:48 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA07644; Mon, 16 May 2016 10:43:46 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1b2DBq-000HKc-DV; Mon, 16 May 2016 10:43:46 +0300 Subject: Re: mount / unmount and mountcheckdirs() To: freebsd-arch@FreeBSD.org, freebsd-fs References: <5c01bf62-b7b2-2e1d-bca5-859e6bf1f0e5@FreeBSD.org> <20160516070314.GA3029@brick> From: Andriy Gapon Message-ID: Date: Mon, 16 May 2016 10:43:08 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160516070314.GA3029@brick> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 07:43:49 -0000 On 16/05/2016 10:03, Edward Tomasz Napierała wrote: > On 0515T1637, Andriy Gapon wrote: >> >> I am curious about the purpose of mountcheckdirs() called when mounting and >> unmounting a filesystem. > > [..] > > Whatever you do, please make sure you don't break autofs, and reroot, > esp. firmware(9) loading after reroot. I'll happily test patches, just > mail them to me. Thanks :-) > Well, the only patch I had in mind (besides https://svnweb.freebsd.org/changeset/base/299913) is completely removing mountcheckdirs(). But now that you mentioned autofs and reroot I am not sure that it could be that simple... -- Andriy Gapon From owner-freebsd-arch@freebsd.org Mon May 16 18:10:27 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5BA3FB3D34F for ; Mon, 16 May 2016 18:10:27 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A7971F5A for ; Mon, 16 May 2016 18:10:27 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-yw0-x22c.google.com with SMTP id g133so169817694ywb.2 for ; Mon, 16 May 2016 11:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=1u51LIF7k+Mp0bwuHDv3mklI6nC9v+CZUUtkkhPOGyQ=; b=npAEsmf+pjc0wrC4V61y9OzbvIaj4rIOO1EH460VW536HGQ/6pUow23GSIzgKMeuzF ola+Q2iMtwJmB9epXslx/zHa4pVnPC+y/oNR/jROHVzUQx5ueVufpTqqZgwsulzoVSi8 gGZn3C/2p0jPx/TBo5yLHioDjvlAS3j8zNqOC1/Z7t4GFVDj1+3hn2uKhBVJerYWNKd6 z1quBK4pe2JKCVtsztuD3s5u3Kt0bT+ax304vpJzK+YAzR+lJ54SAZEPDWZWbx/VQBs9 RezKNcM96NEYDpeWNiSiZtzQVafC9DDe83Khk7kON5xKoXlQuZRxsczWdI76IDnhPKSp Ee9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=1u51LIF7k+Mp0bwuHDv3mklI6nC9v+CZUUtkkhPOGyQ=; b=EUqnGsM0xvaLZqojigZOWec4Ks3OjJK2qW14Xo4JGIAfa/tPFM28SthEkAUMJdTGb/ cV63s0nVj1v0qtaanW9V+HT0iguJmHYc3z33df+r0yWBbgu/oK/LhfflmCvT46cvwaCE fEORjUSvsxQh49yJr0q8q6saTS9xyXQZp/EblvSixJ11Ibm5AP8/riEsTWWwgaVqbffJ 10T/4OyRCPbUmQjHdtqqy/qbbPrjlVtgIpOUyMUNBjtp5u3i2MWeMN3541hkBRXF9hbJ F/4bptAaydujlv47fSuuiMLGjSXrPfgF2SeumqsQwJ5KNnSoSooDfNhInAQAVuUWTkWI /+jg== X-Gm-Message-State: AOPr4FW6MbqE0/JbEXoc50/aqTwgqdyZTct2IsLNKpg0JW5SlP1eqx2VeNue8cY81G27lpnrNctoU7g2zzPHnQ== MIME-Version: 1.0 X-Received: by 10.37.195.133 with SMTP id t127mr7772595ybf.149.1463422226214; Mon, 16 May 2016 11:10:26 -0700 (PDT) Received: by 10.13.201.199 with HTTP; Mon, 16 May 2016 11:10:26 -0700 (PDT) In-Reply-To: <201605152307.u4FN7Gtg069070@gw.catspoiler.org> References: <201605152307.u4FN7Gtg069070@gw.catspoiler.org> Date: Mon, 16 May 2016 20:10:26 +0200 Message-ID: Subject: Re: is ut_user[] in struct utmpx NUL terminated? From: Ed Schouten To: Don Lewis Cc: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 18:10:27 -0000 Hi Don, 2016-05-16 1:07 GMT+02:00 Don Lewis : > There is a lot of code that expects ut_user[] to be NUL terminated. Our implementation of utmpx should be pretty friendly to use: - You can call pututxline() with strings that are not null terminated. - The getutx*() functions return entries in which all strings are null terminated. Keep in mind that ut_id is not a string, but a binary identifier, meaning it is not null terminated. Best regards, -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 From owner-freebsd-arch@freebsd.org Thu May 19 10:56:44 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8603DB423AB for ; Thu, 19 May 2016 10:56:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 71AAC147A for ; Thu, 19 May 2016 10:56:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6DA76B423A9; Thu, 19 May 2016 10:56:44 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D328B423A8; Thu, 19 May 2016 10:56:44 +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-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F2C791478; Thu, 19 May 2016 10:56:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u4JAuYfr059664 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 19 May 2016 13:56:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u4JAuYfr059664 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u4JAuYhq059663; Thu, 19 May 2016 13:56:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 19 May 2016 13:56:34 +0300 From: Konstantin Belousov To: geom@freebsd.org Cc: arch@freebsd.org Subject: Removing Giant asserts from geom Message-ID: <20160519105634.GO89104@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) 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 autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 10:56:44 -0000 I propose to remove asserts mtx_assert(&Giant, MA_NOTOWNED); from the geom KPI. The asserts do not serve any purposes, at least not in the current kernel. They might provided some agenda in the 5.x days, but now they only force filesystems to add cruft to satisfy GEOM KPI requirements. As an example, consider DROP_GIANT/PICKUP_GIANT in the ffs code. VFS is currently Giant-free, including the mount and unmount path, UFS/FFS are also Giant-free, but mount and unmount paths have to do the Giant dance to allow root mount to proceed. This is because startup is executed with the Giant owned by the thread0. Giant asserts are even more ridiculous in the geom code since geom cdev geom.ctl is marked as needing Giant. And there are vestiges of Giant around calls to add geom kthreads, which is not need by KPI. Not to note that Giant is already held there due to startup protocol. Any objections ? diff --git a/sys/geom/eli/g_eli.c b/sys/geom/eli/g_eli.c index 403d0b6..422883d 100644 --- a/sys/geom/eli/g_eli.c +++ b/sys/geom/eli/g_eli.c @@ -1229,7 +1229,6 @@ g_eli_shutdown_pre_sync(void *arg, int howto) int error; mp = arg; - DROP_GIANT(); g_topology_lock(); LIST_FOREACH_SAFE(gp, &mp->geom, geom, gp2) { sc = gp->softc; @@ -1245,7 +1244,6 @@ g_eli_shutdown_pre_sync(void *arg, int howto) } } g_topology_unlock(); - PICKUP_GIANT(); } static void diff --git a/sys/geom/geom.h b/sys/geom/geom.h index bf70d0b..7c1d714 100644 --- a/sys/geom/geom.h +++ b/sys/geom/geom.h @@ -369,7 +369,6 @@ g_free(void *ptr) #define g_topology_lock() \ do { \ - mtx_assert(&Giant, MA_NOTOWNED); \ sx_xlock(&topology_lock); \ } while (0) diff --git a/sys/geom/geom_event.c b/sys/geom/geom_event.c index 2ded638..3c2ee49 100644 --- a/sys/geom/geom_event.c +++ b/sys/geom/geom_event.c @@ -83,7 +83,6 @@ g_waitidle(void) { g_topology_assert_not(); - mtx_assert(&Giant, MA_NOTOWNED); mtx_lock(&g_eventlock); while (!TAILQ_EMPTY(&g_events)) diff --git a/sys/geom/geom_kern.c b/sys/geom/geom_kern.c index dbced0f..9f3f120 100644 --- a/sys/geom/geom_kern.c +++ b/sys/geom/geom_kern.c @@ -90,7 +90,6 @@ static void g_up_procbody(void *arg) { - mtx_assert(&Giant, MA_NOTOWNED); thread_lock(g_up_td); sched_prio(g_up_td, PRIBIO); thread_unlock(g_up_td); @@ -103,7 +102,6 @@ static void g_down_procbody(void *arg) { - mtx_assert(&Giant, MA_NOTOWNED); thread_lock(g_down_td); sched_prio(g_down_td, PRIBIO); thread_unlock(g_down_td); @@ -116,7 +114,6 @@ static void g_event_procbody(void *arg) { - mtx_assert(&Giant, MA_NOTOWNED); thread_lock(g_event_td); sched_prio(g_event_td, PRIBIO); thread_unlock(g_event_td); @@ -147,14 +144,12 @@ g_init(void) g_io_init(); g_event_init(); g_ctl_init(); - mtx_lock(&Giant); kproc_kthread_add(g_event_procbody, NULL, &g_proc, &g_event_td, RFHIGHPID, 0, "geom", "g_event"); kproc_kthread_add(g_up_procbody, NULL, &g_proc, &g_up_td, RFHIGHPID, 0, "geom", "g_up"); kproc_kthread_add(g_down_procbody, NULL, &g_proc, &g_down_td, RFHIGHPID, 0, "geom", "g_down"); - mtx_unlock(&Giant); EVENTHANDLER_REGISTER(shutdown_pre_sync, geom_shutdown, NULL, SHUTDOWN_PRI_FIRST); } diff --git a/sys/geom/geom_mbr.c b/sys/geom/geom_mbr.c index 86ee860..a811e35 100644 --- a/sys/geom/geom_mbr.c +++ b/sys/geom/geom_mbr.c @@ -190,7 +190,6 @@ g_mbr_ioctl(struct g_provider *pp, u_long cmd, void *data, int fflag, struct thr case DIOCSMBR: { if (!(fflag & FWRITE)) return (EPERM); - DROP_GIANT(); g_topology_lock(); cp = LIST_FIRST(&gp->consumer); if (cp->acw == 0) { @@ -205,7 +204,6 @@ g_mbr_ioctl(struct g_provider *pp, u_long cmd, void *data, int fflag, struct thr if (opened) g_access(cp, 0, -1 , 0); g_topology_unlock(); - PICKUP_GIANT(); return(error); } default: diff --git a/sys/geom/geom_pc98.c b/sys/geom/geom_pc98.c index 42c9962..f4435cb 100644 --- a/sys/geom/geom_pc98.c +++ b/sys/geom/geom_pc98.c @@ -176,7 +176,6 @@ g_pc98_ioctl(struct g_provider *pp, u_long cmd, void *data, int fflag, struct th case DIOCSPC98: { if (!(fflag & FWRITE)) return (EPERM); - DROP_GIANT(); g_topology_lock(); cp = LIST_FIRST(&gp->consumer); if (cp->acw == 0) { @@ -191,7 +190,6 @@ g_pc98_ioctl(struct g_provider *pp, u_long cmd, void *data, int fflag, struct th if (opened) g_access(cp, 0, -1 , 0); g_topology_unlock(); - PICKUP_GIANT(); return(error); } default: diff --git a/sys/geom/geom_subr.c b/sys/geom/geom_subr.c index 54a99bf..8517991 100644 --- a/sys/geom/geom_subr.c +++ b/sys/geom/geom_subr.c @@ -247,9 +247,7 @@ g_modevent(module_t mod, int type, void *data) break; case MOD_UNLOAD: g_trace(G_T_TOPOLOGY, "g_modevent(%s, UNLOAD)", mp->name); - DROP_GIANT(); error = g_unload_class(mp); - PICKUP_GIANT(); if (error == 0) { KASSERT(LIST_EMPTY(&mp->geom), ("Unloaded class (%s) still has geom", mp->name)); diff --git a/sys/geom/journal/g_journal.c b/sys/geom/journal/g_journal.c index 871bd8e4..0678003 100644 --- a/sys/geom/journal/g_journal.c +++ b/sys/geom/journal/g_journal.c @@ -2697,7 +2697,6 @@ g_journal_shutdown(void *arg, int howto __unused) if (panicstr != NULL) return; mp = arg; - DROP_GIANT(); g_topology_lock(); LIST_FOREACH_SAFE(gp, &mp->geom, geom, gp2) { if (gp->softc == NULL) @@ -2706,7 +2705,6 @@ g_journal_shutdown(void *arg, int howto __unused) g_journal_destroy(gp->softc); } g_topology_unlock(); - PICKUP_GIANT(); } /* @@ -2725,7 +2723,6 @@ g_journal_lowmem(void *arg, int howto __unused) g_journal_stats_low_mem++; mp = arg; - DROP_GIANT(); g_topology_lock(); LIST_FOREACH(gp, &mp->geom, geom) { sc = gp->softc; @@ -2756,7 +2753,6 @@ g_journal_lowmem(void *arg, int howto __unused) break; } g_topology_unlock(); - PICKUP_GIANT(); } static void g_journal_switcher(void *arg); @@ -2871,7 +2867,6 @@ g_journal_do_switch(struct g_class *classp) char *mountpoint; int error, save; - DROP_GIANT(); g_topology_lock(); LIST_FOREACH(gp, &classp->geom, geom) { sc = gp->softc; @@ -2886,7 +2881,6 @@ g_journal_do_switch(struct g_class *classp) mtx_unlock(&sc->sc_mtx); } g_topology_unlock(); - PICKUP_GIANT(); mtx_lock(&mountlist_mtx); TAILQ_FOREACH(mp, &mountlist, mnt_list) { @@ -2901,11 +2895,9 @@ g_journal_do_switch(struct g_class *classp) continue; /* mtx_unlock(&mountlist_mtx) was done inside vfs_busy() */ - DROP_GIANT(); g_topology_lock(); sc = g_journal_find_device(classp, mp->mnt_gjprovider); g_topology_unlock(); - PICKUP_GIANT(); if (sc == NULL) { GJ_DEBUG(0, "Cannot find journal geom for %s.", @@ -2984,7 +2976,6 @@ next: sc = NULL; for (;;) { - DROP_GIANT(); g_topology_lock(); LIST_FOREACH(gp, &g_journal_class.geom, geom) { sc = gp->softc; @@ -3000,7 +2991,6 @@ next: sc = NULL; } g_topology_unlock(); - PICKUP_GIANT(); if (sc == NULL) break; mtx_assert(&sc->sc_mtx, MA_OWNED); diff --git a/sys/geom/mirror/g_mirror.c b/sys/geom/mirror/g_mirror.c index 91f1367..379f615 100644 --- a/sys/geom/mirror/g_mirror.c +++ b/sys/geom/mirror/g_mirror.c @@ -3310,7 +3310,6 @@ g_mirror_shutdown_post_sync(void *arg, int howto) int error; mp = arg; - DROP_GIANT(); g_topology_lock(); g_mirror_shutdown = 1; LIST_FOREACH_SAFE(gp, &mp->geom, geom, gp2) { @@ -3329,7 +3328,6 @@ g_mirror_shutdown_post_sync(void *arg, int howto) g_topology_lock(); } g_topology_unlock(); - PICKUP_GIANT(); } static void diff --git a/sys/geom/mountver/g_mountver.c b/sys/geom/mountver/g_mountver.c index eafccc8..61375ef 100644 --- a/sys/geom/mountver/g_mountver.c +++ b/sys/geom/mountver/g_mountver.c @@ -611,12 +611,10 @@ g_mountver_shutdown_pre_sync(void *arg, int howto) struct g_geom *gp, *gp2; mp = arg; - DROP_GIANT(); g_topology_lock(); LIST_FOREACH_SAFE(gp, &mp->geom, geom, gp2) g_mountver_destroy(gp, 1); g_topology_unlock(); - PICKUP_GIANT(); } static void diff --git a/sys/geom/raid/g_raid.c b/sys/geom/raid/g_raid.c index 4885319..e590e35 100644 --- a/sys/geom/raid/g_raid.c +++ b/sys/geom/raid/g_raid.c @@ -2462,7 +2462,6 @@ g_raid_shutdown_post_sync(void *arg, int howto) struct g_raid_volume *vol; mp = arg; - DROP_GIANT(); g_topology_lock(); g_raid_shutdown = 1; LIST_FOREACH_SAFE(gp, &mp->geom, geom, gp2) { @@ -2477,7 +2476,6 @@ g_raid_shutdown_post_sync(void *arg, int howto) g_topology_lock(); } g_topology_unlock(); - PICKUP_GIANT(); } static void diff --git a/sys/geom/raid3/g_raid3.c b/sys/geom/raid3/g_raid3.c index a2ffe53..9b3c483 100644 --- a/sys/geom/raid3/g_raid3.c +++ b/sys/geom/raid3/g_raid3.c @@ -3543,7 +3543,6 @@ g_raid3_shutdown_post_sync(void *arg, int howto) int error; mp = arg; - DROP_GIANT(); g_topology_lock(); g_raid3_shutdown = 1; LIST_FOREACH_SAFE(gp, &mp->geom, geom, gp2) { @@ -3562,7 +3561,6 @@ g_raid3_shutdown_post_sync(void *arg, int howto) g_topology_lock(); } g_topology_unlock(); - PICKUP_GIANT(); } static void From owner-freebsd-arch@freebsd.org Thu May 19 11:04:30 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 373A5B4277F for ; Thu, 19 May 2016 11:04:30 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 27CCE1E34 for ; Thu, 19 May 2016 11:04:30 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: by mailman.ysv.freebsd.org (Postfix) id 23927B4277D; Thu, 19 May 2016 11:04:30 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23034B4277B; Thu, 19 May 2016 11:04:30 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id E55901E32; Thu, 19 May 2016 11:04:29 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 58CEE4FB1D; Thu, 19 May 2016 11:04:22 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id u4JB4Lx2085765; Thu, 19 May 2016 11:04:21 GMT (envelope-from phk@phk.freebsd.dk) To: Konstantin Belousov cc: geom@freebsd.org, arch@freebsd.org Subject: Re: Removing Giant asserts from geom In-reply-to: <20160519105634.GO89104@kib.kiev.ua> From: "Poul-Henning Kamp" References: <20160519105634.GO89104@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <85763.1463655861.1@critter.freebsd.dk> Date: Thu, 19 May 2016 11:04:21 +0000 Message-ID: <85764.1463655861@critter.freebsd.dk> X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 11:04:30 -0000 -------- In message <20160519105634.GO89104@kib.kiev.ua>, Konstantin Belousov writes: >I propose to remove asserts > mtx_assert(&Giant, MA_NOTOWNED); By all means. They were necessary because GEOM happened in the early days of SMP where things were strange and locks unpredictable. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@freebsd.org Thu May 19 16:31:54 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8840CB427A9 for ; Thu, 19 May 2016 16:31:54 +0000 (UTC) (envelope-from bright@mu.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 793621F27 for ; Thu, 19 May 2016 16:31:54 +0000 (UTC) (envelope-from bright@mu.org) Received: by mailman.ysv.freebsd.org (Postfix) id 74840B427A6; Thu, 19 May 2016 16:31:54 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73D89B427A4; Thu, 19 May 2016 16:31:54 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 644B91F25; Thu, 19 May 2016 16:31:54 +0000 (UTC) (envelope-from bright@mu.org) Received: from AlfredMacbookAir.local (unknown [IPv6:2601:645:8003:a4d6:1000:9833:bf6a:cc6b]) by elvis.mu.org (Postfix) with ESMTPSA id 9F159346DDE2; Thu, 19 May 2016 09:31:48 -0700 (PDT) Subject: Re: Removing Giant asserts from geom To: Konstantin Belousov , geom@freebsd.org References: <20160519105634.GO89104@kib.kiev.ua> Cc: arch@freebsd.org From: Alfred Perlstein Message-ID: <573DEA73.4080408@mu.org> Date: Thu, 19 May 2016 09:31:47 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160519105634.GO89104@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 16:31:54 -0000 It seems like it should be the opposite, the DROP_GIANTs should be turned into mtx_assert(&Giant, MA_NOTOWNED) as giant is removed from the tree. Meaning Giant should be pushed further back until it is eliminated. Doing as this patch proposes hides that we still have callers holding Giant which is not good. -Alfred On 5/19/16 3:56 AM, Konstantin Belousov wrote: > I propose to remove asserts > mtx_assert(&Giant, MA_NOTOWNED); > from the geom KPI. The asserts do not serve any purposes, at least not > in the current kernel. They might provided some agenda in the 5.x days, > but now they only force filesystems to add cruft to satisfy GEOM KPI > requirements. > > As an example, consider DROP_GIANT/PICKUP_GIANT in the ffs code. VFS is > currently Giant-free, including the mount and unmount path, UFS/FFS are > also Giant-free, but mount and unmount paths have to do the Giant dance > to allow root mount to proceed. This is because startup is executed with > the Giant owned by the thread0. > > Giant asserts are even more ridiculous in the geom code since geom cdev > geom.ctl is marked as needing Giant. And there are vestiges of Giant > around calls to add geom kthreads, which is not need by KPI. Not to note > that Giant is already held there due to startup protocol. > > Any objections ? > > diff --git a/sys/geom/eli/g_eli.c b/sys/geom/eli/g_eli.c > index 403d0b6..422883d 100644 > --- a/sys/geom/eli/g_eli.c > +++ b/sys/geom/eli/g_eli.c > @@ -1229,7 +1229,6 @@ g_eli_shutdown_pre_sync(void *arg, int howto) > int error; > > mp = arg; > - DROP_GIANT(); > g_topology_lock(); > LIST_FOREACH_SAFE(gp, &mp->geom, geom, gp2) { > sc = gp->softc; > @@ -1245,7 +1244,6 @@ g_eli_shutdown_pre_sync(void *arg, int howto) > } > } > g_topology_unlock(); > - PICKUP_GIANT(); > } > > static void > diff --git a/sys/geom/geom.h b/sys/geom/geom.h > index bf70d0b..7c1d714 100644 > --- a/sys/geom/geom.h > +++ b/sys/geom/geom.h > @@ -369,7 +369,6 @@ g_free(void *ptr) > > #define g_topology_lock() \ > do { \ > - mtx_assert(&Giant, MA_NOTOWNED); \ > sx_xlock(&topology_lock); \ > } while (0) > > diff --git a/sys/geom/geom_event.c b/sys/geom/geom_event.c > index 2ded638..3c2ee49 100644 > --- a/sys/geom/geom_event.c > +++ b/sys/geom/geom_event.c > @@ -83,7 +83,6 @@ g_waitidle(void) > { > > g_topology_assert_not(); > - mtx_assert(&Giant, MA_NOTOWNED); > > mtx_lock(&g_eventlock); > while (!TAILQ_EMPTY(&g_events)) > diff --git a/sys/geom/geom_kern.c b/sys/geom/geom_kern.c > index dbced0f..9f3f120 100644 > --- a/sys/geom/geom_kern.c > +++ b/sys/geom/geom_kern.c > @@ -90,7 +90,6 @@ static void > g_up_procbody(void *arg) > { > > - mtx_assert(&Giant, MA_NOTOWNED); > thread_lock(g_up_td); > sched_prio(g_up_td, PRIBIO); > thread_unlock(g_up_td); > @@ -103,7 +102,6 @@ static void > g_down_procbody(void *arg) > { > > - mtx_assert(&Giant, MA_NOTOWNED); > thread_lock(g_down_td); > sched_prio(g_down_td, PRIBIO); > thread_unlock(g_down_td); > @@ -116,7 +114,6 @@ static void > g_event_procbody(void *arg) > { > > - mtx_assert(&Giant, MA_NOTOWNED); > thread_lock(g_event_td); > sched_prio(g_event_td, PRIBIO); > thread_unlock(g_event_td); > @@ -147,14 +144,12 @@ g_init(void) > g_io_init(); > g_event_init(); > g_ctl_init(); > - mtx_lock(&Giant); > kproc_kthread_add(g_event_procbody, NULL, &g_proc, &g_event_td, > RFHIGHPID, 0, "geom", "g_event"); > kproc_kthread_add(g_up_procbody, NULL, &g_proc, &g_up_td, > RFHIGHPID, 0, "geom", "g_up"); > kproc_kthread_add(g_down_procbody, NULL, &g_proc, &g_down_td, > RFHIGHPID, 0, "geom", "g_down"); > - mtx_unlock(&Giant); > EVENTHANDLER_REGISTER(shutdown_pre_sync, geom_shutdown, NULL, > SHUTDOWN_PRI_FIRST); > } > diff --git a/sys/geom/geom_mbr.c b/sys/geom/geom_mbr.c > index 86ee860..a811e35 100644 > --- a/sys/geom/geom_mbr.c > +++ b/sys/geom/geom_mbr.c > @@ -190,7 +190,6 @@ g_mbr_ioctl(struct g_provider *pp, u_long cmd, void *data, int fflag, struct thr > case DIOCSMBR: { > if (!(fflag & FWRITE)) > return (EPERM); > - DROP_GIANT(); > g_topology_lock(); > cp = LIST_FIRST(&gp->consumer); > if (cp->acw == 0) { > @@ -205,7 +204,6 @@ g_mbr_ioctl(struct g_provider *pp, u_long cmd, void *data, int fflag, struct thr > if (opened) > g_access(cp, 0, -1 , 0); > g_topology_unlock(); > - PICKUP_GIANT(); > return(error); > } > default: > diff --git a/sys/geom/geom_pc98.c b/sys/geom/geom_pc98.c > index 42c9962..f4435cb 100644 > --- a/sys/geom/geom_pc98.c > +++ b/sys/geom/geom_pc98.c > @@ -176,7 +176,6 @@ g_pc98_ioctl(struct g_provider *pp, u_long cmd, void *data, int fflag, struct th > case DIOCSPC98: { > if (!(fflag & FWRITE)) > return (EPERM); > - DROP_GIANT(); > g_topology_lock(); > cp = LIST_FIRST(&gp->consumer); > if (cp->acw == 0) { > @@ -191,7 +190,6 @@ g_pc98_ioctl(struct g_provider *pp, u_long cmd, void *data, int fflag, struct th > if (opened) > g_access(cp, 0, -1 , 0); > g_topology_unlock(); > - PICKUP_GIANT(); > return(error); > } > default: > diff --git a/sys/geom/geom_subr.c b/sys/geom/geom_subr.c > index 54a99bf..8517991 100644 > --- a/sys/geom/geom_subr.c > +++ b/sys/geom/geom_subr.c > @@ -247,9 +247,7 @@ g_modevent(module_t mod, int type, void *data) > break; > case MOD_UNLOAD: > g_trace(G_T_TOPOLOGY, "g_modevent(%s, UNLOAD)", mp->name); > - DROP_GIANT(); > error = g_unload_class(mp); > - PICKUP_GIANT(); > if (error == 0) { > KASSERT(LIST_EMPTY(&mp->geom), > ("Unloaded class (%s) still has geom", mp->name)); > diff --git a/sys/geom/journal/g_journal.c b/sys/geom/journal/g_journal.c > index 871bd8e4..0678003 100644 > --- a/sys/geom/journal/g_journal.c > +++ b/sys/geom/journal/g_journal.c > @@ -2697,7 +2697,6 @@ g_journal_shutdown(void *arg, int howto __unused) > if (panicstr != NULL) > return; > mp = arg; > - DROP_GIANT(); > g_topology_lock(); > LIST_FOREACH_SAFE(gp, &mp->geom, geom, gp2) { > if (gp->softc == NULL) > @@ -2706,7 +2705,6 @@ g_journal_shutdown(void *arg, int howto __unused) > g_journal_destroy(gp->softc); > } > g_topology_unlock(); > - PICKUP_GIANT(); > } > > /* > @@ -2725,7 +2723,6 @@ g_journal_lowmem(void *arg, int howto __unused) > > g_journal_stats_low_mem++; > mp = arg; > - DROP_GIANT(); > g_topology_lock(); > LIST_FOREACH(gp, &mp->geom, geom) { > sc = gp->softc; > @@ -2756,7 +2753,6 @@ g_journal_lowmem(void *arg, int howto __unused) > break; > } > g_topology_unlock(); > - PICKUP_GIANT(); > } > > static void g_journal_switcher(void *arg); > @@ -2871,7 +2867,6 @@ g_journal_do_switch(struct g_class *classp) > char *mountpoint; > int error, save; > > - DROP_GIANT(); > g_topology_lock(); > LIST_FOREACH(gp, &classp->geom, geom) { > sc = gp->softc; > @@ -2886,7 +2881,6 @@ g_journal_do_switch(struct g_class *classp) > mtx_unlock(&sc->sc_mtx); > } > g_topology_unlock(); > - PICKUP_GIANT(); > > mtx_lock(&mountlist_mtx); > TAILQ_FOREACH(mp, &mountlist, mnt_list) { > @@ -2901,11 +2895,9 @@ g_journal_do_switch(struct g_class *classp) > continue; > /* mtx_unlock(&mountlist_mtx) was done inside vfs_busy() */ > > - DROP_GIANT(); > g_topology_lock(); > sc = g_journal_find_device(classp, mp->mnt_gjprovider); > g_topology_unlock(); > - PICKUP_GIANT(); > > if (sc == NULL) { > GJ_DEBUG(0, "Cannot find journal geom for %s.", > @@ -2984,7 +2976,6 @@ next: > > sc = NULL; > for (;;) { > - DROP_GIANT(); > g_topology_lock(); > LIST_FOREACH(gp, &g_journal_class.geom, geom) { > sc = gp->softc; > @@ -3000,7 +2991,6 @@ next: > sc = NULL; > } > g_topology_unlock(); > - PICKUP_GIANT(); > if (sc == NULL) > break; > mtx_assert(&sc->sc_mtx, MA_OWNED); > diff --git a/sys/geom/mirror/g_mirror.c b/sys/geom/mirror/g_mirror.c > index 91f1367..379f615 100644 > --- a/sys/geom/mirror/g_mirror.c > +++ b/sys/geom/mirror/g_mirror.c > @@ -3310,7 +3310,6 @@ g_mirror_shutdown_post_sync(void *arg, int howto) > int error; > > mp = arg; > - DROP_GIANT(); > g_topology_lock(); > g_mirror_shutdown = 1; > LIST_FOREACH_SAFE(gp, &mp->geom, geom, gp2) { > @@ -3329,7 +3328,6 @@ g_mirror_shutdown_post_sync(void *arg, int howto) > g_topology_lock(); > } > g_topology_unlock(); > - PICKUP_GIANT(); > } > > static void > diff --git a/sys/geom/mountver/g_mountver.c b/sys/geom/mountver/g_mountver.c > index eafccc8..61375ef 100644 > --- a/sys/geom/mountver/g_mountver.c > +++ b/sys/geom/mountver/g_mountver.c > @@ -611,12 +611,10 @@ g_mountver_shutdown_pre_sync(void *arg, int howto) > struct g_geom *gp, *gp2; > > mp = arg; > - DROP_GIANT(); > g_topology_lock(); > LIST_FOREACH_SAFE(gp, &mp->geom, geom, gp2) > g_mountver_destroy(gp, 1); > g_topology_unlock(); > - PICKUP_GIANT(); > } > > static void > diff --git a/sys/geom/raid/g_raid.c b/sys/geom/raid/g_raid.c > index 4885319..e590e35 100644 > --- a/sys/geom/raid/g_raid.c > +++ b/sys/geom/raid/g_raid.c > @@ -2462,7 +2462,6 @@ g_raid_shutdown_post_sync(void *arg, int howto) > struct g_raid_volume *vol; > > mp = arg; > - DROP_GIANT(); > g_topology_lock(); > g_raid_shutdown = 1; > LIST_FOREACH_SAFE(gp, &mp->geom, geom, gp2) { > @@ -2477,7 +2476,6 @@ g_raid_shutdown_post_sync(void *arg, int howto) > g_topology_lock(); > } > g_topology_unlock(); > - PICKUP_GIANT(); > } > > static void > diff --git a/sys/geom/raid3/g_raid3.c b/sys/geom/raid3/g_raid3.c > index a2ffe53..9b3c483 100644 > --- a/sys/geom/raid3/g_raid3.c > +++ b/sys/geom/raid3/g_raid3.c > @@ -3543,7 +3543,6 @@ g_raid3_shutdown_post_sync(void *arg, int howto) > int error; > > mp = arg; > - DROP_GIANT(); > g_topology_lock(); > g_raid3_shutdown = 1; > LIST_FOREACH_SAFE(gp, &mp->geom, geom, gp2) { > @@ -3562,7 +3561,6 @@ g_raid3_shutdown_post_sync(void *arg, int howto) > g_topology_lock(); > } > g_topology_unlock(); > - PICKUP_GIANT(); > } > > static void > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@freebsd.org Thu May 19 19:12:56 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01994B3F40F for ; Thu, 19 May 2016 19:12:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id E06F21123 for ; Thu, 19 May 2016 19:12:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id DF930B3F40D; Thu, 19 May 2016 19:12:55 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DCDB6B3F40C; Thu, 19 May 2016 19:12:55 +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-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6EF4E1122; Thu, 19 May 2016 19:12:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u4JJClL9084388 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 19 May 2016 22:12:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u4JJClL9084388 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u4JJCliR084387; Thu, 19 May 2016 22:12:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 19 May 2016 22:12:47 +0300 From: Konstantin Belousov To: Alfred Perlstein Cc: geom@freebsd.org, arch@freebsd.org Subject: Re: Removing Giant asserts from geom Message-ID: <20160519191247.GQ89104@kib.kiev.ua> References: <20160519105634.GO89104@kib.kiev.ua> <573DEA73.4080408@mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <573DEA73.4080408@mu.org> User-Agent: Mutt/1.6.1 (2016-04-27) 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 autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 19:12:56 -0000 On Thu, May 19, 2016 at 09:31:47AM -0700, Alfred Perlstein wrote: > It seems like it should be the opposite, the DROP_GIANTs should be > turned into mtx_assert(&Giant, MA_NOTOWNED) as giant is removed from the > tree. > > Meaning Giant should be pushed further back until it is eliminated. > Doing as this patch proposes hides that we still have callers holding > Giant which is not good. Did you read the third paragraph of my email ? FWIW, the assumed model of the kernel locking which must be in somebody mind when talking about 'pushing back Giant' is not true for last 5-6 years for our kernel in general, and for the VFS in particular. > > -Alfred > > > On 5/19/16 3:56 AM, Konstantin Belousov wrote: > > I propose to remove asserts > > mtx_assert(&Giant, MA_NOTOWNED); > > from the geom KPI. The asserts do not serve any purposes, at least not > > in the current kernel. They might provided some agenda in the 5.x days, > > but now they only force filesystems to add cruft to satisfy GEOM KPI > > requirements. > > > > As an example, consider DROP_GIANT/PICKUP_GIANT in the ffs code. VFS is > > currently Giant-free, including the mount and unmount path, UFS/FFS are > > also Giant-free, but mount and unmount paths have to do the Giant dance > > to allow root mount to proceed. This is because startup is executed with > > the Giant owned by the thread0. ^^^^ > > > > Giant asserts are even more ridiculous in the geom code since geom cdev > > geom.ctl is marked as needing Giant. And there are vestiges of Giant > > around calls to add geom kthreads, which is not need by KPI. Not to note > > that Giant is already held there due to startup protocol. > > > > Any objections ? > > > > diff --git a/sys/geom/eli/g_eli.c b/sys/geom/eli/g_eli.c > > index 403d0b6..422883d 100644 > > --- a/sys/geom/eli/g_eli.c > > +++ b/sys/geom/eli/g_eli.c > > @@ -1229,7 +1229,6 @@ g_eli_shutdown_pre_sync(void *arg, int howto) > > int error; > > > > mp = arg; > > - DROP_GIANT(); > > g_topology_lock(); > > LIST_FOREACH_SAFE(gp, &mp->geom, geom, gp2) { > > sc = gp->softc; > > @@ -1245,7 +1244,6 @@ g_eli_shutdown_pre_sync(void *arg, int howto) > > } > > } > > g_topology_unlock(); > > - PICKUP_GIANT(); > > } > > > > static void > > diff --git a/sys/geom/geom.h b/sys/geom/geom.h > > index bf70d0b..7c1d714 100644 > > --- a/sys/geom/geom.h > > +++ b/sys/geom/geom.h > > @@ -369,7 +369,6 @@ g_free(void *ptr) > > > > #define g_topology_lock() \ > > do { \ > > - mtx_assert(&Giant, MA_NOTOWNED); \ > > sx_xlock(&topology_lock); \ > > } while (0) > > > > diff --git a/sys/geom/geom_event.c b/sys/geom/geom_event.c > > index 2ded638..3c2ee49 100644 > > --- a/sys/geom/geom_event.c > > +++ b/sys/geom/geom_event.c > > @@ -83,7 +83,6 @@ g_waitidle(void) > > { > > > > g_topology_assert_not(); > > - mtx_assert(&Giant, MA_NOTOWNED); > > > > mtx_lock(&g_eventlock); > > while (!TAILQ_EMPTY(&g_events)) > > diff --git a/sys/geom/geom_kern.c b/sys/geom/geom_kern.c > > index dbced0f..9f3f120 100644 > > --- a/sys/geom/geom_kern.c > > +++ b/sys/geom/geom_kern.c > > @@ -90,7 +90,6 @@ static void > > g_up_procbody(void *arg) > > { > > > > - mtx_assert(&Giant, MA_NOTOWNED); > > thread_lock(g_up_td); > > sched_prio(g_up_td, PRIBIO); > > thread_unlock(g_up_td); > > @@ -103,7 +102,6 @@ static void > > g_down_procbody(void *arg) > > { > > > > - mtx_assert(&Giant, MA_NOTOWNED); > > thread_lock(g_down_td); > > sched_prio(g_down_td, PRIBIO); > > thread_unlock(g_down_td); > > @@ -116,7 +114,6 @@ static void > > g_event_procbody(void *arg) > > { > > > > - mtx_assert(&Giant, MA_NOTOWNED); > > thread_lock(g_event_td); > > sched_prio(g_event_td, PRIBIO); > > thread_unlock(g_event_td); > > @@ -147,14 +144,12 @@ g_init(void) > > g_io_init(); > > g_event_init(); > > g_ctl_init(); > > - mtx_lock(&Giant); > > kproc_kthread_add(g_event_procbody, NULL, &g_proc, &g_event_td, > > RFHIGHPID, 0, "geom", "g_event"); > > kproc_kthread_add(g_up_procbody, NULL, &g_proc, &g_up_td, > > RFHIGHPID, 0, "geom", "g_up"); > > kproc_kthread_add(g_down_procbody, NULL, &g_proc, &g_down_td, > > RFHIGHPID, 0, "geom", "g_down"); > > - mtx_unlock(&Giant); > > EVENTHANDLER_REGISTER(shutdown_pre_sync, geom_shutdown, NULL, > > SHUTDOWN_PRI_FIRST); > > } > > diff --git a/sys/geom/geom_mbr.c b/sys/geom/geom_mbr.c > > index 86ee860..a811e35 100644 > > --- a/sys/geom/geom_mbr.c > > +++ b/sys/geom/geom_mbr.c > > @@ -190,7 +190,6 @@ g_mbr_ioctl(struct g_provider *pp, u_long cmd, void *data, int fflag, struct thr > > case DIOCSMBR: { > > if (!(fflag & FWRITE)) > > return (EPERM); > > - DROP_GIANT(); > > g_topology_lock(); > > cp = LIST_FIRST(&gp->consumer); > > if (cp->acw == 0) { > > @@ -205,7 +204,6 @@ g_mbr_ioctl(struct g_provider *pp, u_long cmd, void *data, int fflag, struct thr > > if (opened) > > g_access(cp, 0, -1 , 0); > > g_topology_unlock(); > > - PICKUP_GIANT(); > > return(error); > > } > > default: > > diff --git a/sys/geom/geom_pc98.c b/sys/geom/geom_pc98.c > > index 42c9962..f4435cb 100644 > > --- a/sys/geom/geom_pc98.c > > +++ b/sys/geom/geom_pc98.c > > @@ -176,7 +176,6 @@ g_pc98_ioctl(struct g_provider *pp, u_long cmd, void *data, int fflag, struct th > > case DIOCSPC98: { > > if (!(fflag & FWRITE)) > > return (EPERM); > > - DROP_GIANT(); > > g_topology_lock(); > > cp = LIST_FIRST(&gp->consumer); > > if (cp->acw == 0) { > > @@ -191,7 +190,6 @@ g_pc98_ioctl(struct g_provider *pp, u_long cmd, void *data, int fflag, struct th > > if (opened) > > g_access(cp, 0, -1 , 0); > > g_topology_unlock(); > > - PICKUP_GIANT(); > > return(error); > > } > > default: > > diff --git a/sys/geom/geom_subr.c b/sys/geom/geom_subr.c > > index 54a99bf..8517991 100644 > > --- a/sys/geom/geom_subr.c > > +++ b/sys/geom/geom_subr.c > > @@ -247,9 +247,7 @@ g_modevent(module_t mod, int type, void *data) > > break; > > case MOD_UNLOAD: > > g_trace(G_T_TOPOLOGY, "g_modevent(%s, UNLOAD)", mp->name); > > - DROP_GIANT(); > > error = g_unload_class(mp); > > - PICKUP_GIANT(); > > if (error == 0) { > > KASSERT(LIST_EMPTY(&mp->geom), > > ("Unloaded class (%s) still has geom", mp->name)); > > diff --git a/sys/geom/journal/g_journal.c b/sys/geom/journal/g_journal.c > > index 871bd8e4..0678003 100644 > > --- a/sys/geom/journal/g_journal.c > > +++ b/sys/geom/journal/g_journal.c > > @@ -2697,7 +2697,6 @@ g_journal_shutdown(void *arg, int howto __unused) > > if (panicstr != NULL) > > return; > > mp = arg; > > - DROP_GIANT(); > > g_topology_lock(); > > LIST_FOREACH_SAFE(gp, &mp->geom, geom, gp2) { > > if (gp->softc == NULL) > > @@ -2706,7 +2705,6 @@ g_journal_shutdown(void *arg, int howto __unused) > > g_journal_destroy(gp->softc); > > } > > g_topology_unlock(); > > - PICKUP_GIANT(); > > } > > > > /* > > @@ -2725,7 +2723,6 @@ g_journal_lowmem(void *arg, int howto __unused) > > > > g_journal_stats_low_mem++; > > mp = arg; > > - DROP_GIANT(); > > g_topology_lock(); > > LIST_FOREACH(gp, &mp->geom, geom) { > > sc = gp->softc; > > @@ -2756,7 +2753,6 @@ g_journal_lowmem(void *arg, int howto __unused) > > break; > > } > > g_topology_unlock(); > > - PICKUP_GIANT(); > > } > > > > static void g_journal_switcher(void *arg); > > @@ -2871,7 +2867,6 @@ g_journal_do_switch(struct g_class *classp) > > char *mountpoint; > > int error, save; > > > > - DROP_GIANT(); > > g_topology_lock(); > > LIST_FOREACH(gp, &classp->geom, geom) { > > sc = gp->softc; > > @@ -2886,7 +2881,6 @@ g_journal_do_switch(struct g_class *classp) > > mtx_unlock(&sc->sc_mtx); > > } > > g_topology_unlock(); > > - PICKUP_GIANT(); > > > > mtx_lock(&mountlist_mtx); > > TAILQ_FOREACH(mp, &mountlist, mnt_list) { > > @@ -2901,11 +2895,9 @@ g_journal_do_switch(struct g_class *classp) > > continue; > > /* mtx_unlock(&mountlist_mtx) was done inside vfs_busy() */ > > > > - DROP_GIANT(); > > g_topology_lock(); > > sc = g_journal_find_device(classp, mp->mnt_gjprovider); > > g_topology_unlock(); > > - PICKUP_GIANT(); > > > > if (sc == NULL) { > > GJ_DEBUG(0, "Cannot find journal geom for %s.", > > @@ -2984,7 +2976,6 @@ next: > > > > sc = NULL; > > for (;;) { > > - DROP_GIANT(); > > g_topology_lock(); > > LIST_FOREACH(gp, &g_journal_class.geom, geom) { > > sc = gp->softc; > > @@ -3000,7 +2991,6 @@ next: > > sc = NULL; > > } > > g_topology_unlock(); > > - PICKUP_GIANT(); > > if (sc == NULL) > > break; > > mtx_assert(&sc->sc_mtx, MA_OWNED); > > diff --git a/sys/geom/mirror/g_mirror.c b/sys/geom/mirror/g_mirror.c > > index 91f1367..379f615 100644 > > --- a/sys/geom/mirror/g_mirror.c > > +++ b/sys/geom/mirror/g_mirror.c > > @@ -3310,7 +3310,6 @@ g_mirror_shutdown_post_sync(void *arg, int howto) > > int error; > > > > mp = arg; > > - DROP_GIANT(); > > g_topology_lock(); > > g_mirror_shutdown = 1; > > LIST_FOREACH_SAFE(gp, &mp->geom, geom, gp2) { > > @@ -3329,7 +3328,6 @@ g_mirror_shutdown_post_sync(void *arg, int howto) > > g_topology_lock(); > > } > > g_topology_unlock(); > > - PICKUP_GIANT(); > > } > > > > static void > > diff --git a/sys/geom/mountver/g_mountver.c b/sys/geom/mountver/g_mountver.c > > index eafccc8..61375ef 100644 > > --- a/sys/geom/mountver/g_mountver.c > > +++ b/sys/geom/mountver/g_mountver.c > > @@ -611,12 +611,10 @@ g_mountver_shutdown_pre_sync(void *arg, int howto) > > struct g_geom *gp, *gp2; > > > > mp = arg; > > - DROP_GIANT(); > > g_topology_lock(); > > LIST_FOREACH_SAFE(gp, &mp->geom, geom, gp2) > > g_mountver_destroy(gp, 1); > > g_topology_unlock(); > > - PICKUP_GIANT(); > > } > > > > static void > > diff --git a/sys/geom/raid/g_raid.c b/sys/geom/raid/g_raid.c > > index 4885319..e590e35 100644 > > --- a/sys/geom/raid/g_raid.c > > +++ b/sys/geom/raid/g_raid.c > > @@ -2462,7 +2462,6 @@ g_raid_shutdown_post_sync(void *arg, int howto) > > struct g_raid_volume *vol; > > > > mp = arg; > > - DROP_GIANT(); > > g_topology_lock(); > > g_raid_shutdown = 1; > > LIST_FOREACH_SAFE(gp, &mp->geom, geom, gp2) { > > @@ -2477,7 +2476,6 @@ g_raid_shutdown_post_sync(void *arg, int howto) > > g_topology_lock(); > > } > > g_topology_unlock(); > > - PICKUP_GIANT(); > > } > > > > static void > > diff --git a/sys/geom/raid3/g_raid3.c b/sys/geom/raid3/g_raid3.c > > index a2ffe53..9b3c483 100644 > > --- a/sys/geom/raid3/g_raid3.c > > +++ b/sys/geom/raid3/g_raid3.c > > @@ -3543,7 +3543,6 @@ g_raid3_shutdown_post_sync(void *arg, int howto) > > int error; > > > > mp = arg; > > - DROP_GIANT(); > > g_topology_lock(); > > g_raid3_shutdown = 1; > > LIST_FOREACH_SAFE(gp, &mp->geom, geom, gp2) { > > @@ -3562,7 +3561,6 @@ g_raid3_shutdown_post_sync(void *arg, int howto) > > g_topology_lock(); > > } > > g_topology_unlock(); > > - PICKUP_GIANT(); > > } > > > > static void > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > From owner-freebsd-arch@freebsd.org Thu May 19 19:58:56 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E5A7B42021 for ; Thu, 19 May 2016 19:58:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 808E61A4D for ; Thu, 19 May 2016 19:58:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 7927FB4201F; Thu, 19 May 2016 19:58:56 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78D88B4201D for ; Thu, 19 May 2016 19:58:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4E6821A4B for ; Thu, 19 May 2016 19:58:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x232.google.com with SMTP id z123so82398itg.0 for ; Thu, 19 May 2016 12:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=ni3XQ2Fv3KiXMKEwYiQC0scsA+fc4g2ZSpxyNEfEYew=; b=is5fWV3f7CF88CMLN7O0TRptLkJJ6TMdjj2OVPiaSSrqVRc9AwFSAWv/etQhIR3bH1 /aTzKk3e6r2sptOMjxnkocY+C7QlIab9aFl7UIaKU0Mm9a3T31j+xVFTI+ZtinRgtT/L QFZQlKhqIpAes3JMbv1ObXPqOwJs5CLouAu5g1xkQY+Z3/de/cz9uZ0apA5p18ylPkvo 8uzl3mTx4wBH/aeYTTvdjlw+BDJvEuxkRJPslEiX3SqLyYMZishd2T7kFRCSYhelHaih 0fQw1ElMFKXfTcFHe9yMRhe8u4V7oLB1sFx1fhj4pZ+fEA2M7a8j7P2FmJkoUG+uBne2 3hxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ni3XQ2Fv3KiXMKEwYiQC0scsA+fc4g2ZSpxyNEfEYew=; b=Oln6rHhQk9tsi+8vopmMAE5M2uc0ORjBRnXjTZFVXvhEL9Y2qrt8m2waKn+DWnoDpK i0/V1ZV8yJU2oekpV6jwjgftJjh461Zzd+Ln/pRvwl8OyVGgrOw6VK9bm/0P6dtSu5ol J31fH/4i+udHNpab1Jjlg0nlbwFFJFsXtwUe1/TfkVJLD2GYo0JMhZ1wKHP12CPMyzRW qOBASxQyIzF8KKxcQGtPsjfTio5bWJGUzE/secBy8ZLpwTcZmqNmWQ4p04N2/+x6I7TP GSCmqABf8z4mIq3AevGSMRR4PINln8ffy/U2uVeUCSdYd0zPJazz9dOrfliGvKdiQN5N kGSQ== X-Gm-Message-State: AOPr4FUQqeNqn8+kkepwYoNRwtTD3IuCkxNog+WnDVxKlyAUfyAvQKWmfijl++k4cnSD2yOwLCyHSnw3Vntd3Q== MIME-Version: 1.0 X-Received: by 10.36.78.67 with SMTP id r64mr4519237ita.72.1463687935609; Thu, 19 May 2016 12:58:55 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.79.75.68 with HTTP; Thu, 19 May 2016 12:58:55 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <20160519105634.GO89104@kib.kiev.ua> References: <20160519105634.GO89104@kib.kiev.ua> Date: Thu, 19 May 2016 13:58:55 -0600 X-Google-Sender-Auth: 1rl7IH8SaZS3VPQGythPq5cvSsk Message-ID: Subject: Re: Removing Giant asserts from geom From: Warner Losh To: Konstantin Belousov Cc: geom@freebsd.org, "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 19:58:56 -0000 On Thu, May 19, 2016 at 4:56 AM, Konstantin Belousov wrote: > I propose to remove asserts > mtx_assert(&Giant, MA_NOTOWNED); > from the geom KPI. I can't see any reason for the assertion in today's kernel. I might split out the lock / unlock of giant around thread creation since that's different. Warner From owner-freebsd-arch@freebsd.org Thu May 19 20:56:44 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AFA57B41180 for ; Thu, 19 May 2016 20:56:44 +0000 (UTC) (envelope-from bright@mu.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A01281E8B for ; Thu, 19 May 2016 20:56:44 +0000 (UTC) (envelope-from bright@mu.org) Received: by mailman.ysv.freebsd.org (Postfix) id 9B263B41178; Thu, 19 May 2016 20:56:44 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9AAB6B41176; Thu, 19 May 2016 20:56:44 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 8EEA91E8A; Thu, 19 May 2016 20:56:44 +0000 (UTC) (envelope-from bright@mu.org) Received: from Alfreds-MacBook-Pro-2.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id B15C0346DDE2; Thu, 19 May 2016 13:56:43 -0700 (PDT) Subject: Re: Removing Giant asserts from geom To: Konstantin Belousov References: <20160519105634.GO89104@kib.kiev.ua> <573DEA73.4080408@mu.org> <20160519191247.GQ89104@kib.kiev.ua> Cc: geom@freebsd.org, arch@freebsd.org From: Alfred Perlstein Message-ID: <53397f3f-1056-ceb7-ce3a-5269ac1d29e2@mu.org> Date: Thu, 19 May 2016 13:57:53 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160519191247.GQ89104@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 20:56:44 -0000 On 5/19/16 12:12 PM, Konstantin Belousov wrote: > On Thu, May 19, 2016 at 09:31:47AM -0700, Alfred Perlstein wrote: >> It seems like it should be the opposite, the DROP_GIANTs should be >> turned into mtx_assert(&Giant, MA_NOTOWNED) as giant is removed from the >> tree. >> >> Meaning Giant should be pushed further back until it is eliminated. >> Doing as this patch proposes hides that we still have callers holding >> Giant which is not good. > Did you read the third paragraph of my email ? OK, and why is thread0 needing Giant for so long? > FWIW, the assumed model of the kernel locking which must be in somebody > mind when talking about 'pushing back Giant' is not true for last 5-6 > years for our kernel in general, and for the VFS in particular. OK, makes sense, still would prefer to have assertions that don't allow mistakes to creep in. FreeBSD's assertions on locking and VFS make it much easier to develop under. -Alfred From owner-freebsd-arch@freebsd.org Thu May 19 21:31:34 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A199B41DAE for ; Thu, 19 May 2016 21:31:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 34B001725 for ; Thu, 19 May 2016 21:31:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 3051EB41DAC; Thu, 19 May 2016 21:31:34 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2FD37B41DAA; Thu, 19 May 2016 21:31:34 +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-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A45EB1723; Thu, 19 May 2016 21:31:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u4JLVSL7017475 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 20 May 2016 00:31:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u4JLVSL7017475 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u4JLVSbX017474; Fri, 20 May 2016 00:31:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 20 May 2016 00:31:28 +0300 From: Konstantin Belousov To: Alfred Perlstein Cc: geom@freebsd.org, arch@freebsd.org Subject: Re: Removing Giant asserts from geom Message-ID: <20160519213128.GT89104@kib.kiev.ua> References: <20160519105634.GO89104@kib.kiev.ua> <573DEA73.4080408@mu.org> <20160519191247.GQ89104@kib.kiev.ua> <53397f3f-1056-ceb7-ce3a-5269ac1d29e2@mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53397f3f-1056-ceb7-ce3a-5269ac1d29e2@mu.org> User-Agent: Mutt/1.6.1 (2016-04-27) 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 autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 21:31:34 -0000 On Thu, May 19, 2016 at 01:57:53PM -0700, Alfred Perlstein wrote: > OK, and why is thread0 needing Giant for so long? [Below is my opinion] It does not need Giant per se, it needs a work done to audit and turn it off. Probably most high profile subsystem in the kernel still relying on Giant is the newbus. Easy to see consequence is that handling thread0, that spends most of the time in discovering and configuring devices, actually needs to provide proper locking for the newbus. At least one attempt to do the later failed. Troubles are both in the strange recursiveness of newbus, where device method could call into subr_bus.c, and in potential offloading of some work to other thread, which means that naive surround of the subr_bus.c methods with some global sleepable (and even recursive) lock would not work. Since newbus activity and early startup are rare events, fine-grained locking for them would result in, well, fine grained locking. There would be no break-through performance improvements after really hard work, including handling user reports for long time. So, it is not a priority for most people. From owner-freebsd-arch@freebsd.org Thu May 19 21:35:36 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36B7CB41EEF for ; Thu, 19 May 2016 21:35:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 16FC11A18 for ; Thu, 19 May 2016 21:35:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 12DA4B41EED; Thu, 19 May 2016 21:35:36 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 128EFB41EEC for ; Thu, 19 May 2016 21:35:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D15FB1A16 for ; Thu, 19 May 2016 21:35:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id 190so124559549iow.1 for ; Thu, 19 May 2016 14:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=56NIbtNbLlzDvThqDkhfRCWD+zx79zvQY9sMgH1gmTI=; b=ZhiS6hp5LKRKzgyLEg3G+yuyqXIvPpn9V/u0LWFGslG4LDefGmfvZDY5hk3CqYAIKn faoo8SkMFjGQsjwCn6Hmgd42T4Z4W+QxPXey8eiVOWv+rf3QcKljEl7uhV+n4u0G7ZPJ GPz8W0J1iZhQJoJJAIwoY0hKeW9taPj/E0Gd5lWcYS6jvLo81Fzi5y29+m6pU82VNXIr ejvI7/wAMNjt/NZcx9I2a8KZK5VAy+0gOFJU6GvNrSp0AHMndMktuPAyRD75GzvRgQm3 jYhPXgKaIdltE/FH7PlWWF29UjQxJVf7O9McOoumaRl8Hc2jlG/QvWJFoxscBgAvkK7/ NKew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=56NIbtNbLlzDvThqDkhfRCWD+zx79zvQY9sMgH1gmTI=; b=btlTVe+EStemANWEIFcOKh/9F3a39nvM++Bgpt1xFsSSf7wGUIuP6YjC0ThlfiGFcD 8I1zH29wk+JWPQdcRemojuBPEyYT/V+WspOTiVAry9zTDYYR2s1FEQ+udgMFssNq2po7 bic6HbkEouyNfz0xI6NzPL3vKJWiVdsklVrJNwWoYQsTKrJ7yTCZRprYpoq/qMD1Iinv t3cmDIIXBdwcwu8EiCVVmeANB7AiW6NljSh/mdiH1rE+iwE9f59hBWQHGX1GVD15PHqH XDXMN4A49mahxKl3aMtwlxnbIFus//udXD/qTKkrfvCPCbyPIaeG0CMw2JRIMlhTpNuO jbRA== X-Gm-Message-State: AOPr4FVgQoMyikOsvkFsy419fofLbK3MOep5Ytjy+crS2kRHXzFZWIk+ft7tP7cGIOQYzGuryzdQoKWryK70Wg== MIME-Version: 1.0 X-Received: by 10.36.70.7 with SMTP id j7mr4806886itb.72.1463693735230; Thu, 19 May 2016 14:35:35 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.79.75.68 with HTTP; Thu, 19 May 2016 14:35:35 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <20160519213128.GT89104@kib.kiev.ua> References: <20160519105634.GO89104@kib.kiev.ua> <573DEA73.4080408@mu.org> <20160519191247.GQ89104@kib.kiev.ua> <53397f3f-1056-ceb7-ce3a-5269ac1d29e2@mu.org> <20160519213128.GT89104@kib.kiev.ua> Date: Thu, 19 May 2016 15:35:35 -0600 X-Google-Sender-Auth: O3xZTgY3zSYoqJ9xkwhh0htQZ7U Message-ID: Subject: Re: Removing Giant asserts from geom From: Warner Losh To: Konstantin Belousov Cc: Alfred Perlstein , geom@freebsd.org, "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 21:35:36 -0000 On Thu, May 19, 2016 at 3:31 PM, Konstantin Belousov wrote: > On Thu, May 19, 2016 at 01:57:53PM -0700, Alfred Perlstein wrote: >> OK, and why is thread0 needing Giant for so long? > [Below is my opinion] > > It does not need Giant per se, it needs a work done to audit and turn it > off. Probably most high profile subsystem in the kernel still relying on > Giant is the newbus. Easy to see consequence is that handling thread0, > that spends most of the time in discovering and configuring devices, > actually needs to provide proper locking for the newbus. > > At least one attempt to do the later failed. Troubles are both in the > strange recursiveness of newbus, where device method could call into > subr_bus.c, and in potential offloading of some work to other thread, > which means that naive surround of the subr_bus.c methods with some > global sleepable (and even recursive) lock would not work. > > Since newbus activity and early startup are rare events, fine-grained > locking for them would result in, well, fine grained locking. There > would be no break-through performance improvements after really hard > work, including handling user reports for long time. > > So, it is not a priority for most people. I know of three runs at the newbus locking issue that have failed. It's not easy or trivial because it calls into so many different subsystems, many in odd ways that aren't done elsewhere. Warner From owner-freebsd-arch@freebsd.org Thu May 19 21:42:22 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CA52B42250 for ; Thu, 19 May 2016 21:42:22 +0000 (UTC) (envelope-from bright@mu.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id F06A21045 for ; Thu, 19 May 2016 21:42:21 +0000 (UTC) (envelope-from bright@mu.org) Received: by mailman.ysv.freebsd.org (Postfix) id EFCFDB4224B; Thu, 19 May 2016 21:42:21 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EF579B42249; Thu, 19 May 2016 21:42:21 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id E25311043; Thu, 19 May 2016 21:42:21 +0000 (UTC) (envelope-from bright@mu.org) Received: from Alfreds-MacBook-Pro-2.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 98943346DE2F; Thu, 19 May 2016 14:42:21 -0700 (PDT) Subject: Re: Removing Giant asserts from geom To: Konstantin Belousov References: <20160519105634.GO89104@kib.kiev.ua> <573DEA73.4080408@mu.org> <20160519191247.GQ89104@kib.kiev.ua> <53397f3f-1056-ceb7-ce3a-5269ac1d29e2@mu.org> <20160519213128.GT89104@kib.kiev.ua> Cc: geom@freebsd.org, arch@freebsd.org From: Alfred Perlstein Message-ID: Date: Thu, 19 May 2016 14:43:31 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160519213128.GT89104@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 21:42:22 -0000 On 5/19/16 2:31 PM, Konstantin Belousov wrote: > On Thu, May 19, 2016 at 01:57:53PM -0700, Alfred Perlstein wrote: >> OK, and why is thread0 needing Giant for so long? > [Below is my opinion] > > It does not need Giant per se, it needs a work done to audit and turn it > off. Probably most high profile subsystem in the kernel still relying on > Giant is the newbus. Easy to see consequence is that handling thread0, > that spends most of the time in discovering and configuring devices, > actually needs to provide proper locking for the newbus. > > At least one attempt to do the later failed. Troubles are both in the > strange recursiveness of newbus, where device method could call into > subr_bus.c, and in potential offloading of some work to other thread, > which means that naive surround of the subr_bus.c methods with some > global sleepable (and even recursive) lock would not work. > > Since newbus activity and early startup are rare events, fine-grained > locking for them would result in, well, fine grained locking. There > would be no break-through performance improvements after really hard > work, including handling user reports for long time. > > So, it is not a priority for most people. > Thank you Konstantin, makes sense. -Alfred From owner-freebsd-arch@freebsd.org Sat May 21 02:29:45 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E4DEB43B20 for ; Sat, 21 May 2016 02:29:45 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6A6881981 for ; Sat, 21 May 2016 02:29:45 +0000 (UTC) (envelope-from ian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 66246B43B1F; Sat, 21 May 2016 02:29:45 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65D3AB43B1E for ; Sat, 21 May 2016 02:29:45 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2FB95197F for ; Sat, 21 May 2016 02:29:44 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: ef50173d-1efb-11e6-a09e-4d61a6885157 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Sat, 21 May 2016 02:30:07 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u4L2TaYO059460; Fri, 20 May 2016 20:29:36 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1463797776.1180.357.camel@freebsd.org> Subject: Re: Build -j target tags and command output From: Ian Lepore To: "Simon J. Gerraty" , Bryan Drewery Cc: arch@freebsd.org Date: Fri, 20 May 2016 20:29:36 -0600 In-Reply-To: <77472.1456528808@kaos.jnpr.net> References: <56D0CD68.606@FreeBSD.org> <77472.1456528808@kaos.jnpr.net> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 02:29:45 -0000 On Fri, 2016-02-26 at 15:20 -0800, Simon J. Gerraty wrote: > Bryan Drewery wrote: > > I'm looking for opinions on whether we should keep or remove the -- > > Keep. > > Without them it is virtually impossible to identify which job > produced > certain output. > > Even with them, the log from a parallel hirerarchical build can get > confusing - especially when multiple makes are writing at the same > time. > But you are still better off with some clues. > > > Removing them would yield potentially hard-to-debug failures since > > the > > Yes, pls don't do that. > > > failed command could be anywhere. At least the 'make stopped' > > error > > that follows would print the directory. There is an interesting > > feature > > Yes, but generally the exciting stuff that caused the stoppage is > earlier in the log. > The --- lines allow use of scripts to demux the output. > Are any such scripts available? -- Ian (catching up on really old mail) From owner-freebsd-arch@freebsd.org Sat May 21 18:53:07 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D17D9B44624 for ; Sat, 21 May 2016 18:53:07 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 99AD11BC2 for ; Sat, 21 May 2016 18:53:07 +0000 (UTC) (envelope-from sjg@juniper.net) Received: by mailman.ysv.freebsd.org (Postfix) id 95A1AB44623; Sat, 21 May 2016 18:53:07 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93008B44622 for ; Sat, 21 May 2016 18:53:07 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0116.outbound.protection.outlook.com [157.56.110.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE0081BBF; Sat, 21 May 2016 18:53:06 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RpOWwxxhKnhyWtAphXZWZ7/q8tzKwctu80hSKslWAyU=; b=KXrk+1RsltPqlzESnr6wcXpVgCa3YUq8zs3a7YNILt4GKFgq9yZyL6D9LU2tTTd+DAzgR8hghoNOQ+Txlu0rui8Oekh7ZQvNwDGfdSKXQZw3MzMGugavEJnQUhFNw50VaawJg8wEFKuEFGd/0exNUC0GyCe7b6B50L7OCClBTQ8= Received: from CO2PR05CA032.namprd05.prod.outlook.com (10.141.241.160) by DM2PR0501MB811.namprd05.prod.outlook.com (10.242.115.141) with Microsoft SMTP Server (TLS) id 15.1.497.12; Sat, 21 May 2016 18:52:58 +0000 Received: from BN1BFFO11FD014.protection.gbl (2a01:111:f400:7c10::1:156) by CO2PR05CA032.outlook.office365.com (2a01:111:e400:1429::32) with Microsoft SMTP Server (TLS) id 15.1.497.12 via Frontend Transport; Sat, 21 May 2016 18:52:58 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1BFFO11FD014.mail.protection.outlook.com (10.58.144.77) with Microsoft SMTP Server (TLS) id 15.1.497.8 via Frontend Transport; Sat, 21 May 2016 18:52:57 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 21 May 2016 11:52:55 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.16.84]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id u4LIqtJ48592; Sat, 21 May 2016 11:52:55 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 658C6385508; Sat, 21 May 2016 11:52:55 -0700 (PDT) To: Ian Lepore CC: Bryan Drewery , , Subject: Re: Build -j target tags and command output In-Reply-To: <1463797776.1180.357.camel@freebsd.org> References: <56D0CD68.606@FreeBSD.org> <77472.1456528808@kaos.jnpr.net> <1463797776.1180.357.camel@freebsd.org> Comments: In-reply-to: Ian Lepore message dated "Fri, 20 May 2016 20:29:36 -0600." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12424.1463856775.1@kaos.jnpr.net> Date: Sat, 21 May 2016 11:52:55 -0700 Message-ID: <12426.1463856775@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(24454002)(189002)(199003)(9170700003)(2906002)(2810700001)(86362001)(5003600100002)(46406003)(450100001)(1220700001)(87936001)(50466002)(110136002)(23726003)(5008740100001)(107886002)(50986999)(4326007)(586003)(19580395003)(53416004)(76506005)(97756001)(19580405001)(77096005)(9686002)(117636001)(8936002)(92566002)(2950100001)(105596002)(4001430100002)(11100500001)(189998001)(50226002)(6806005)(106466001)(81166006)(8676002)(76176999)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB811; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD014; 1:9l7dFMIZjsY8gmSqKGUC7h4ppR+RR4bI6NN7iDZc7VVz8M3Jw2oyMfTexbAnZgzxbcvqob01BRCJBrBy93a4Q3aybakun1SpaYJ1zZJxoAl1CEswBxH2lY5wBS2uoL8U2Z68SQ4uz3pSeapHzaKhtOZDNEzaQSy6g8SRxM5N9xf36jINmeJHz1iyOMzFhy+ysOT7bfrPp8yPgclP7MnS1RPHA6qCa+bbHGYmIQ280RjJwQZb+DnC3EdsDTYEVwZV5s7pnDsM2EaLtkEKUSC7cv+vvyO/D+2ShBopDiiBDK5hqzDidizVcNtvuBFJutUixIh7vNKvyV7eMN1HdmkKCLQSi0CHMOw8HJHl9MTBbVPAB/F324IOgJrR16hSGctBodhbpZCqp5fleJ1WeEp4EyY7bU9RYDPT1eWpbueSyHopHm+iqdW8fE6d6BMKWyBZQSB60XRTNYB5Tgx9bCjKFhyWQmGR2uro3yXNvmgVmHU= X-MS-Office365-Filtering-Correlation-Id: 8f61e458-c11f-4dac-7cf7-08d381a91fe2 X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB811; 2:hf2VWMvUiXKN7lyBUNS4tUTxpP4fkEI7wleTG5D3fXWLPCwvnHKvyY1VVC8c4mZfWsD40lVZdUNTJHu5hqAGWJziqDkKoTuUCxm6t2L5LBnMpRROFG7GnNHr9QG7fbVasbq8o9qNhtJluTIkyaB8A14Zu4K4DeoAm6MsH/T8FZu54qvYXcIU59+y+NNlbKUE; 3:Eya59IfeUAn8D94RqX+lXRhNTqHPahW3yPj0mAKof1P5UaIoYXC7+kyP3kU3w8AAz7CyHC7B8wUvmPw4CuMf3aaAZuQV8GdQ6OUeW138h19pw0y5J4z+OdwQB+ct8ytAfjFhg649UBprisJ8hHV/LzXtlaMH7OPWZtS8QJ7usq3omxZejH/rMfJBym7ncjFC1BhA1QYJ8S+sA0ZGXcMKfJICofA7pg2wiyaUHuaV0M8=; 25:ftfR3TZmE3D+jhsCH3vt9T2BWQpOVXs8Ey5knKR+L9jdVP1/SEgQjzlhYCaShO6BZw9b4R+rOvc1cKLXpXnZ+3N8IRRiah+Yk2hMduiEBLW7iV0pDNxRQqbZ9QXLlnMvKnjtJYm8PIRbhs/6S+6i0OhtjpWDKvN6PoDkvgc3i1FJW3y4hjRR0aGcvnHzTpgvR2uUb8S2ce0k8wiikwbYC2olmX+66QJowz+nHUak/FNb4ILBxdIEFK8D3LHfQHPiWir4vklB/+c8xuNnnMD8NblgIScfzaDnpcnBcFv1emDxBpyZ9s2mBsVEoVcyd60jMQ4lXPTrOuFpbQ0XVUahbgYmKFD3fq0qJKXgCQC/m7R6d+J0O80MVfnxzN/MFkU6+7M7l/aQLpi0lAJfBRuJ/coyrzmEZOUxhuNo+iknhvQ= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB811; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB811; 20:e3OSMhQhjZQbeKUHGHBw9yc7g4fUyd5UiTasTlA8Y7uBnhuDlBwNO9D7E2AhwbirvRgMmou/rOx2Fo3+g5gDZlDqIfO9Nv3WxAYwtxI9DZRwImxIsbWzsnn3+aOExoabu5KENKhVyHOrVTfEKId7Gqb7B/b1VRR80hBl0BXGN6uDm5vDTbg5UMIWUpRangOBPYcKuXpEcdLs42efe8QVp1RmLyQ4sCdGPKII/Gvx4VeLXoV2Rkt2sw9+8wRwCc5qx/M0gMb2wXGIvqRL9/K3WAUbmzSpXRJLdJfAFDkFwef6cW8q5ZcBvj0bLSt2hUEzWxwseH5V4RYTGok0SkweMEEvu48h/ACwi8QC8ROZV4WnpxRsKgZdp2e+f2OAJZ7o+VqbEsq5bbEgK6VGu3ALxaFfmxjAizjmngUWRrGQvcWFqhO3CovgaiKW7z2KTZya0JtHr1wg3kUPpPQtr4huMcKA+/NFC9+RnLM8jcsLJoxnH+kv25Q1fFL2WhkINFH1 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13024025)(13018025)(13017025)(13015025)(13023025)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:DM2PR0501MB811; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB811; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB811; 4:7ryz3Ywf8rkSNFzTq9Y0tskbYvhH1D6f9HHGtEJl2HQ0MUMlOEyQjehq8JS946Wq7JUEENx1ME+WAsQ3mShNfxgFSgMmhlK4js1qLStvVBMjwc0RbXxHN4KMsDFnrG18gyqy9PW0/KVLSR9u5RNH1REBXi16hlZSLjcp2mbPjac+j3SB+YuO6w7x6Q9C6TqyfHY5lSG8J129qylv9+Ke1erfc2bruCCsbtri36voSzISWOrVjfaTHJ2nayFNqqTkK33PlUW6TFQsK28lELh+qEMY6KO8NIpQo/gAaioI7NyxT/74TCfmtC1K/szHA/xwm737p3Fpaga08dDMN/yFa595fW3Mjs8QMth8smOeyhR9ACyVXWEdqY8q7jWvAs4i76yvdJdfv5RuppX+ydkZjGAySs0X3fY8VW2uFUWlhg7NRhoPievH9JbF2gpgyzFfe5sOeIsaKEF60uxId3DIOPcvaskbvpCg9hQJVsCHuV8= X-Forefront-PRVS: 09497C15EB X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0501MB811; 23:X+lpDFg6i0RuwJ+h9OWMMmcvxlThGgYrmQJ+Apeo?= =?us-ascii?Q?5sIzttXROUekgPPc5u8SNQAiPs4JyGVImLP75whD+2fLmTuZ7scWq0t4uEct?= =?us-ascii?Q?Tv+rg0CV+plt7oJtBKOvr3+X+3ziITj4d1ZLzxV/je52xYtTp/WrQD5uoE/v?= =?us-ascii?Q?AO7nW9QStZsKt3y7sqdwVBFniSAT1V8QpntQtjF3w0Jv7spjKnkEcSiClYMi?= =?us-ascii?Q?1jGQeH5CeaV1FgrC6M0bReHZjFgftBED6Sk779nhvthuk60slZlNjrvqzIA+?= =?us-ascii?Q?s3af++D9B7G/DxVsXd6riZJdBHxLmz1F06ZpYaesOJVFXt8NNuqNx5kzKWw0?= =?us-ascii?Q?wIHZ21WDBSH/r7lxH3w0SeEF7lCvpcqedflBvyNFACRjtwYe7llpLegaM7Ga?= =?us-ascii?Q?h5IPjYX1mvrjnjoA4xm+HtCGOWfk0WjW6FboMYB4ckuqmemPqviYKO5+/7NV?= =?us-ascii?Q?iOJrFydSa+hKSyT/vMDehHDwE0SzVBScwuiUtAKoFuBqMHj44WGI+HRxfOZq?= =?us-ascii?Q?0dDAdVwpL7+8aCD1SJJL4lfsUpWjU4MGEKAS3WXRAVXfgZy3JkzfTn29jGXo?= =?us-ascii?Q?12QFnOB4uMSeodVCv6YPZBRQimkjSGng8SnG/e3OHtcsoixodJDU9C6QbW5a?= =?us-ascii?Q?VHRV60VVWA/Y4emiN4oY74jz5li3zOtTJPVGfMxvfQfa/N8YsVZTvCvi8Y2l?= =?us-ascii?Q?rzi5kkgwy6hX/LAda9T7elazbdZsVsaT2nzL9gaDr4zwQ3joH/XvkOKXZeCE?= =?us-ascii?Q?BxEd8O68LKHoNhdTqHmY42Oito9vf1ol+yvwP6KLw8FBiHjUnVWGtOkEhSIJ?= =?us-ascii?Q?kX+FtbQtn8m8kh0KMeEIRYtxBxS/SDn/dqebbghMWegS0vEnPrywVvwceREs?= =?us-ascii?Q?k6ea6PbY8UqureUS+Q5IF7Aq2NcJpJ4BE0eSFAS0Q0dZ2Qh0NWVIVekMvzJA?= =?us-ascii?Q?wUpst2w1UeYRazUXMQXGMcNUGEKxi9bH7xfnUwhGwqn0KEd5gWsyjNAqok4w?= =?us-ascii?Q?xi9UGpK6BN25pALQz/UwWu+r59BVhjGt8isxw/V4Dd+gt60XpXR2y/SZJwjC?= =?us-ascii?Q?m1qz8mq2CYkh3hIlkmG4gs8QBMUkPh8wBroQkwn+JtYl9MQURXGoZYzqhhoT?= =?us-ascii?Q?QoWJtAsB3Km2pC8esOIWGVEAEXckTvtMcOaytdjNmruopQs4fdhZIQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB811; 5:dLWOGAEzeJ2d4M4B4nw/atZ2AQL3KwiB4qQKtXfE87WwISvadwWcd2XBT5ARu438HH5jt5eBPrwWm5NH7w+6AKr3Zm6Ht/dO6nPmvR4Qcz6O2nrsnCmRZDh3fO7ofN0BzeO0dvYAg46fVuPSIF5Ycw==; 24:ETcHcS9euRS8KFlTeXcNy8uYQtoXLzCchZexKE5dEcDNvw+CUmYlmEdEw5wPUTBZF28xI3G2PwmtPc4mPCeUveLMSUBkti7rcmjQ0k2aJLY=; 7:UsJGlaLlDZtrDEECVG4YaK9BSNT9A5f1JlQ3sXBijRjqG+qkEhoD0+KTe4FE7/h7gIKJ7OTxcb6kYokFBnckoZxBmRsZMPBVHNk/1DXQ937NB1mRRsW5i3dls2V2sTmwaf9/Le6meAJQsqf90+LeW3436I28dYWlMfLHfC0JQfEDTyqmY88/1vkcpZjG3tgf SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2016 18:52:57.0176 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB811 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 18:53:07 -0000 Ian Lepore wrote: > > Yes, but generally the exciting stuff that caused the stoppage is > > earlier in the log. > > The --- lines allow use of scripts to demux the output. > > > > Are any such scripts available? Not right now but I'm sure that can be fixed... the one we used to use was 23 lines of perl not counting comments.