On May 20, 2025, at 08:34, Dennis Clarke <dcla...@blastwave.org> wrote:
> On 5/20/25 01:51, Mark Millard wrote: >> Dennis Clarke <dclarke_at_blastwave.org> 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
