panic at vm_page_wire with FreeBSD 9.0 Beta 3

Benjamin Kaduk kaduk at MIT.EDU
Wed Nov 2 06:10:22 UTC 2011

On Tue, 1 Nov 2011, Penta Upa wrote:

> Yes that seems to be the problem. It will is for out of tree modules.
> . I have to verify if
> moving the module to /usr/src/ tree fixes the problem.
> Thanks,
> Penta
> On Tue, Nov 1, 2011 at 2:04 AM, K. Macy <kmacy at> wrote:
>> Someone was seeing the same issue with the vmtools kmod. The only
>> thing that might make sense is that the page lock array is defined as
>> being a different size in your kmod as in the kernel itself so the
>> lock corresponding to the page you're locking differs between the two
>> files.

Quoting from the PR,
Andriy Gapon <avg at> wrote:
> A standalone module build doesn't get some important definitions from 
> kernel config (e.g. via opt_global.h) and can be in a serious 
> disagreement with the kernel. In particular, if a kernel is built with 
> SMP option, but a module build doesn't have SMP defined, then they will 
> have different definitions of PA_LOCK_COUNT and thus would work on 
> different actual locks when manipulating the same page.

I am perhaps confused.  Last I checked, caused '-include 
opt_global.h' to be passed on the command line.  Is the issue just that 
the opt_global.h used for the kmod could be different from the actual 
kernel's opt_global.h, because KERNCONF was not specified and the header 
is generated at module-build time?  In this case, clearly the onus is on 
the user to pass KERNCONF at module build time.

(I have gotten my laptop to panic in vm_page_free() with the page lock not 
owned, in OpenAFS' vop_getpages implementation, but I had previously 
attributed this to having an old -current snapshot on my laptop and 
openafs sources that were using freebsd major version for API decisions 
(we're not converted to __FreeBSD_version, yet).  If there is a real 
problem here, I will need to care much more.)


Ben Kaduk

More information about the freebsd-current mailing list