Re: WITNESS not always working

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]