On Sun, 13 Sep 2026, Bjoern A. Zeeb wrote: Hi,
[for the archives]
I have a problem with lock assertions and apparently it's been ongoing for a while. I am working on Linux derived drivers with lock assertions and we have users hitting them. Yet I have not hit them in months of using the drivers.
So the reason for users hitting them was specific set of kernel config with options disabling WITNESS but having INVARIANTS.
This time it was even more curious: I've done a rebase and a full rebuilt of my work branch, booted the kernel, loaded the driver (manually) and it went kaboom on a lock assertion right away. I reset from ddb and bootes the same kernel and (manually) loaded the driver again and nothing happened. I unloaded the driver which is a current PR and nothing, so I checked again and;
I ended up writing a small kernel module just for testing to rule out any possible other oddities like the above which I cannot repro at the moment.
I use the GENERIC-MMCCAM kernel config which includes GENERIC which includes std.debug so this is alright: # sysctl kern.features.witness kern.features.invariants kern.features.witness: 1 kern.features.invariants: 1 Does anyone have any idea as to why witness may not do its job (sometimes)?
The answer is -include odering; for LinuxKPI the LinuxKPI kconfig.h comes (came) before opt_global.h and thus various options were not set correctly which should have pevented XX_NOWITNESS on a debug kernel (D59231). I have a patch to put up for review hopefully later today which fixes LINUXKPI_INCLUDES ... need to sort out conflicts related to USB in my tree and want to write linuxkpi.9 first. /bz -- For there shall arise false Christs, and false prophets, and shall shew great signs and wonders; insomuch that, if it were possible, they shall deceive the very elect. Behold, I have told you before. [Mat. 24:24-25]
