lsof has been broken for me since upgrading to 12.2-RELEASE. The symptom is for it to go cpu bound and never output any results. This appears to be fallout resulting from the reordering of the namecache struct in kern/vfs_cache.c: r363891 | mjg | 2020-08-05 02:24:38 -0700 (Wed, 05 Aug 2020) | 9 lines [..] While here reorder struct namecache so that most commonly used fields are closer. Since the namecache struct is not public lsof defines it's own copy which needs to be different for 12.2 and newer. I've tested the patch on 12.2-RELEASE and 13.0-CURRENT (r367338).
Created attachment 219405 [details] patch
Created attachment 219408 [details] revised patch Key changes off of __FreeBSD_version instead of FREEBSDV and avoid breaking 12.1 as suggested by @ler. Tested on 12.1 and 12.2.
Created attachment 219410 [details] revised patch As per @ler 13-CURRENT did not reorder the namecache struct until 1300105; adjust patch to handle this as well. Tested on 12.1, 12.2, and 13.0 (r367338).
A commit references this bug: Author: leres Date: Wed Nov 11 22:11:46 UTC 2020 New revision: 554915 URL: https://svnweb.freebsd.org/changeset/ports/554915 Log: sysutils/lsof: Unbreak for 12.2-RELEASE and newer 13.0-CURRENT The the order of fields in the namecache struct changed in stable/12 (r363891) and head (r367338); this definition is not public so lsof has it's own copy that needs to be conditionally adjusted accordingly. PR: 250916 Approved by: ler (maintainer) Changes: head/sysutils/lsof/Makefile head/sysutils/lsof/files/patch-dialects-freebsd-dlsof.h
Committed (with offline email approval from @ler).
I am not sure that this is fixed. 250929 appears to be a symptom of the same root cause: lsof opens /dev/kmem and then keeps trying to walk a data structure that is not the shape that it expects. Looking at the things it's reading, it seems to be grabbing random pages from the buffer cache. I suspect that it sees some null bytes and stops on some systems but on others it just keeps going until it runs out of memory.