From nobody Tue May 20 16:20:52 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b20D66JmQz5wbtp for ; Tue, 20 May 2025 16:21:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-54.consmr.mail.gq1.yahoo.com (sonic315-54.consmr.mail.gq1.yahoo.com [98.137.65.30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4b20D61w2dz3tF7 for ; Tue, 20 May 2025 16:21:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1747758067; bh=2wB91wCKzMjvy23uGRNahhTiAduTbqU6OSDHSvIvJ78=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=A7Yf7OlQjmvarygs5iFXCQbSmAbkJF5a07HJcHX8XNgdVkBjmjQCcVTxTrNoEE35gOmkfZPSzZRwefUSJXL7Sn3SdcABhGF+wAa3vUVjHdZO8GLbb6rYc3N3LPA7vcZybJhpavqkRCN08d3Hre/yZXx+pO15Zh/0X70B57y2C37ssmJJ2hQrQCUXa5G102OQdbnumMKAlQ8dzT8NFSVNMjNhvvqmraxb38/b+bd/ndECstAaw+Wya+TxQQcos+CTR4GoDyU3G5jOnkA6z2nRPVwKN0bCDRAlmcyU1MrjSg5Xmj/KHj1O6x3tv4DqNfX724IRQHSNvzh8OEAC/rHsKA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1747758067; bh=PuXpsqZur5uVqcRovsf1yTybi3w0FbJ1CV5rwZz4mS2=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=jaBrXtsswk2u3qlsqgUtUX7j2AIOndR+TvHsl73Shh9w1sUzz1r31uhEw4pqTDTWx41uMzeIQRlc8tdjzeSvQgLlLYQ5v0mrXKyQJcFGxzRuhzbHjswYmoWfijfKUvi6F/qai0wv0bIGPct8rxbs3im+qge2ab4jRRIW7U7IS2awAS5yvM5iuivGOe66B6x/ZZpqryFTT/gteB1CMcdPfOfS6vlMxtCANwy9XvG7HNJfRKy2lUpXQZixT/T0S4bju0mxsunsIrpYZUOTtfk5/FSVHFGnTUUTDnOh12fBkaNOg1JKTdhRq+N0CGGkvDybn0VCdc61XL0DD95lBKqchw== X-YMail-OSG: HTibfMMVM1k_QX2kcseU.JuWJQPX5WyFMeojkwwW7DvfARIyGm_UAu1CjGUThed 5.2W94ncgy.tPQ4I4bLaFgefmEZWhENucmNU6YoPh.TyCEZet_2_Vbp4PMzDq2jM.X1V6s3vt71w B6PtNeza2bUAt0G86349D4Am.j018C1VLWRd49tiNeo32cPhIBpVM_W2XAE6HlQcXM2Agfc_CbNY 7dwzynea1y0hQsU8deafE7fPXAB7TwOJeSwjOv..HPnMIFxrcG3p9fuCA1EvvWYwKgqMLaKyxEKp zTKIT8KVhPWxlW6b2f7vUblRzxZDsbz7yU8NHjC9hgHbGFICrp73EmDtwtuVR8yAxDHUZyVRnMQX 1wqtKUuxyuzaQDz3TGB4fFKkHquHm5CSYSJSDdVXp7D9dWRR1Fk_1vM6eAIqPKpj.cDf8CJGLAOQ fFsnI2PuwjxD6GJawo.s6CS7ziFzKr1wfGHgchg6tNwqK8v78_QWwhBnAKs1h0Sb8tI.OCmGDTHW g5900ksuPdjbGn4hYFAscrNwhFBUTrAAF7MNXh7itVmN8ompghre44K.zpTA5QHbvMI3IhyWxXFI u2_Po3vZmxUFL1uDZ2EYtSjkrsOcXNDpgDW7i_1G7Xpr1IH3G0MaEGHKHhirGfFw3jEIJ8Kmd5j0 zigprg4m0FA5inaq4uAYd6ClBsnzbdVEfaiPxOhaxPOLXrwqA5eUmRBmX9UXjmlChDjwdGe2NARj vwYIynxEwTaesaMU.EUIRWA2pRjSq4YIlyk1wecgsklTNwKXC5Lhv._YrYhq9LutITR4AtpVpt60 q7ZVIIcWHSznZKlBxgAV0lfPpdRn4W7_z4TvxZjzbzmkeLGDFk9GhsW59fAipWmxOObNCeN3rk31 nPU0aS3ECFe99e7QCiEnhxWR6Dyn4NuKJ1M6aVrcEXyMgiXe5j2G32nTaS1MxsmOiLPOxKe.StQU h6L1G.z68qr_LC3PAjaiFmaszYpbDtDb_UAl_0w.aJjJzQxN.CP0oi7WfGU4FMhfQSPvSz.ISv.i OciUZyAba4bT3NiGLoHvgKmhjOCBKwiAVOk1qVwxv2pdcXZR8RJ6Uqk.oTomgEDjr6LJqf50ihSq TpCErs0jJxjh7Taopo.I7jCFXHUpSq6o3CQengyaJpFPm6rgEYoEklPLYf_ZPVbKsw517R.JzKOE UQwURQUmzeose5wNiKlIlR1P6eMl12bwZ9NzEesLtoBn61t7Ld2BkQ51GRqhtCV0RI_S8p6vsQQR EU5nnWfTZxXZI_xB68ssgM.1Y32CPhq1rIozF1N.jNYKr9Q790DJ5GaIRgHNLn9qrtrNoNIZh183 egdHdMD8WdefZWziA4JTQSxiWc6BkdLYL_BNQoV.hLzat8zO8WAB0WQlKCAiENff33Qs6hkSk4A7 GR9w0VA_2TZ2QkrNwcQ4Q2JutCFqMN.0RS6CWFZbNQP_Yl99PZVnosJvyuTrWut_rs7yEj82XZta rcotOurYP2pNrr5Hwq0Z.YsKvXnAKrY4OjorrWS.1NopQoXgbni85cnxDAfLF9_1q7DlqcBg8ogz 4GXWiSC53GS.lbwDpmCRvzMOmtslytL3s8cJAODmiDm_NnaIYxSJnmgtQdjwBXH34o1WF3LBvS.L ui01HozPZCL3To7H2X1f2nq2iNS401OKibObTSP32brtJC4pTCN9_EvjpWWsmHAgWwc2ht_nUL.F joS_t.Nv11W8567nX83l6h1p4NCsFGeQYJiaTdx5XidySDtCNj4RCPO3F4d_GuzMbUFOPHD3Kwtl 7ba7GI8pN_1vTWtBrtH37MPGalGDJ_oS8pB2PdhHw4QyHsAW4mm40kLgDdlkTwTbObr0yIOwkqqS bfw.SC1wr8.ZewKJ6GlU3HOfroiR_l_4qv278.VfrxquoTdDMR4YF3NLCz1Rx36uuhzSZS.zzkoF SkgMaFkSpMLnaFIHH4hA0zjlPzd0BtxneeQdc2hfhX1R8aXC1fl.4T2sFh.wgMajgeo88FDr3yGm fM30BFTuu0c9WyC8kAMM49o0BSMv2blTNPPlas7s1nN3dR2KFfhtEy8jcVtjBNPsNyvP4X3CAPgK B_Nda4YhO_tMYlot_GCrBmzig1KJu7qLPCHkSGYH.Mr01.6BpNubcEh9jSz28qOk1y8O.PMTudVj 3vmTxEr3STh.Cz_VQTXV_ltUjzIRqtxjQGx31TdlIvmmAU6FkdAVYDPLFSStp3GurMsU2QScTjzd kax_94Lrax75EkNWpNIT3hSVkqYYYE92DIY1kbCQ_9uCY_nfF4HOz4wBScpJPWtbKiTnY16OyPJZ w X-Sonic-MF: X-Sonic-ID: 476c2806-3fb4-49f5-b7e9-6a8dc20f0a50 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Tue, 20 May 2025 16:21:07 +0000 Received: by hermes--production-gq1-74d64bb7d7-grhph (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID daac92813d25fb7bcf7599d73e8bfac1; Tue, 20 May 2025 16:21:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\)) Subject: Re: Just a question about sys/kern/subr_witness.c where witness_watch may be flipped to -1 From: Mark Millard In-Reply-To: <04528a6d-438f-4b40-86fe-3fc83d372b26@blastwave.org> Date: Tue, 20 May 2025 09:20:52 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: References: <2950BB1C-6672-4110-8485-3CB9ED0DAEC8.ref@yahoo.com> <2950BB1C-6672-4110-8485-3CB9ED0DAEC8@yahoo.com> <04528a6d-438f-4b40-86fe-3fc83d372b26@blastwave.org> To: Dennis Clarke X-Mailer: Apple Mail (2.3826.600.51.1.1) X-Rspamd-Queue-Id: 4b20D61w2dz3tF7 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Spamd-Bar: ---- On May 20, 2025, at 08:34, Dennis Clarke wrote: > On 5/20/25 01:51, Mark Millard wrote: >> Dennis Clarke wrote on >> Date: Tue, 20 May 2025 02:33:58 UTC: >>> Just an odd message to see on the console : >>> >>> # witness_lock_list_get: witness exhausted >>> >>> Looking at https://cgit.freebsd.org/src/tree/sys/kern/subr_witness.c it >>> seems that the comment at line 370 is very clear : >>> >>> /* >>> * If set to 0, lock order checking is disabled. If set to -1, >>> * witness is completely disabled. Otherwise witness performs full >>> * lock order checking for all locks. At runtime, lock order checking >>> * may be toggled. However, witness cannot be reenabled once it is >>> * completely disabled. >>> */ >>> static int witness_watch = 1; >>> >>> So I wonder how I managed to get that message "witness exhausted" ? >>> >>> At line 2203 I see : >>> >>> static struct lock_list_entry * >>> witness_lock_list_get(void) >>> { >>> struct lock_list_entry *lle; >>> >>> if (witness_watch == -1) >>> return (NULL); >>> mtx_lock_spin(&w_mtx); >>> lle = w_lock_list_free; >>> if (lle == NULL) { >> Looks to me like "out of required resources, cannot >> continue with the mode of use" code: an empty free >> list so no node is available to put to use to >> continue with the witness handling. > > Seems like a strange feature that simply gives up and goes away if the > system gets a bit busy. This system was running a poudriere build of > kde when the message appeared on the console. There was still plenty of > memory available so there must be some hard coded limit in there that > needs to be adjusted. I doubt that the kernel would take the point of view that it should be willing to take arbitrary amounts of the overall address space (RAM+SWAP) for itself. There is also the problem of needing to use the same facilities being monitored in order to do arbitrary memory management, risking deadlocks and such, for example. I normally do not use debug kernels for doing poudriere(-devel) bulk runs: it takes longer. And I got the witness notices historically unless the builds were small enough, indicating limiting of the checking. On the official package builders for main-* (So: that use a debug kernel) the builds are taking a lot longer than for the 134* and 142* builds that (apparently) use non-debug kernels. As of pkg 2.1.0+ , ampere2's main-arm64 went from taking about a week for pkg 2.0.6 to do a "bulk -c -a" to about 3 weeks for pkg 2.1.0+ being in use. (bapt is working n such issues.) The scale factor is not as large for 134* and 142* but is still notable. >>> witness_watch = -1; >>> mtx_unlock_spin(&w_mtx); >>> printf("%s: witness exhausted\n", __func__); >>> return (NULL); >>> } >>> w_lock_list_free = lle->ll_next; >>> mtx_unlock_spin(&w_mtx); >>> bzero(lle, sizeof(*lle)); >>> return (lle); >>> } >>> >>> Where it seems that indeed witness_watch has been flipped to -1 and that >>> functionality is now gone? >> Until the next boot, anyway. > > A fairly stange feature that is implemented by default if one merely > does a buildworld/buildkernel sequence with no adjustments. Witness is part of just debug kernels and main has the debug kernel by default. (I have both kernels but normally use the non-debug one.) main has a different kernel config available for building non-debug kernels. PkgBase actually supplies official kernel-NODEBUG kernels for main, not just debug ones, a first for FreeBSD to my knowledge. Again main's default is to use the debug kernel. But building from source is no longer required for using a non-debug main kernel. === Mark Millard marklmi at yahoo.com