From nobody Tue May 20 15:34:00 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 4b1z9n668sz5wYR3 for ; Tue, 20 May 2025 15:34:05 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (prime256v1) client-digest SHA256) (Client CN "mail.oetec.com", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b1z9n4BNMz3nwQ for ; Tue, 20 May 2025 15:34:05 +0000 (UTC) (envelope-from dclarke@blastwave.org) Authentication-Results: mx1.freebsd.org; none Received: from [172.16.35.3] (pool-99-253-118-250.cpe.net.cable.rogers.com [99.253.118.250]) (authenticated bits=0) by mail.oetec.com (8.17.1/8.17.1) with ESMTPSA id 54KFY0s7072664 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT); Tue, 20 May 2025 11:34:02 -0400 (EDT) (envelope-from dclarke@blastwave.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=blastwave.org; s=default; t=1747755242; bh=1tfhgd8OJSzqL40j1QtqPQP5lQeI3S5myOKfQq8P6j8=; h=Date:Subject:To:References:From:In-Reply-To; b=hPYL5cQgFrE6qo9lCu4sHWJ+GN+V/OQBetdO19VTZHu/AeGHgfnC+iYtVbP4aewPO T71Gv4f8ET36FsXXc9UdVRlezUZJAayuzkHQo/qSk2BIEQ60ce5ZfCFYzQfD3vcc6y N5A/1+cacw9lrTmRQZXcMbak2BB0W8L2tAjYIQRvF0wHkMTGgZ8DESc8gljErT/Fff t2Ne4893daRUYo78/UAd1hNU8t+KH0ZQ+TitXu0GSGIFNNKJhTpWTAzCUxOjoOkPbL eLmImf1U89a/hzMX7dpw1RX1MJ/XFaqAJ2nrmE3e8Hls0rQLpX5fI9Jxp/yqMNJtL9 /E+o8cCLn+JSA== Message-ID: <04528a6d-438f-4b40-86fe-3fc83d372b26@blastwave.org> Date: Tue, 20 May 2025 11:34:00 -0400 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 User-Agent: Mozilla Thunderbird Subject: Re: Just a question about sys/kern/subr_witness.c where witness_watch may be flipped to -1 Content-Language: en-CA To: Mark Millard , FreeBSD Current References: <2950BB1C-6672-4110-8485-3CB9ED0DAEC8.ref@yahoo.com> <2950BB1C-6672-4110-8485-3CB9ED0DAEC8@yahoo.com> From: Dennis Clarke Organization: GENUNIX In-Reply-To: <2950BB1C-6672-4110-8485-3CB9ED0DAEC8@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-oetec-MailScanner-Information: Please contact the ISP for more information X-oetec-MailScanner-ID: 54KFY0s7072664 X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-From: dclarke@blastwave.org X-Spam-Status: No X-Rspamd-Queue-Id: 4b1z9n4BNMz3nwQ 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:812, ipnet:108.160.240.0/20, country:CA] X-Spamd-Bar: ---- 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. >> 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. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken