panic at vm_page_wire with FreeBSD 9.0 Beta 3

Alan Cox alc at
Thu Nov 3 05:57:15 UTC 2011

On 11/02/2011 05:32, Andriy Gapon wrote:
> [restored cc: to the original poster]
> on 02/11/2011 08:10 Benjamin Kaduk said the following:
>> 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.
> To be precise, this is what is actually passed to a compiler:
> sys/conf/
> .if defined(KERNBUILDDIR)
> .endif
> where KERNBUILDDIR can be passed via environment from a kernel build:
> sys/conf/
> KERNCONF does not have any meaning in a module build.
> To make sure that a module build sees exactly the same kernel options as a
> kernel with which the module should work, one has to either build the module
> together with the kernel (within the kernel build; search for MODULES in
> make.conf(5)) or to manually specify KERNBUILDDIR to point to a correct kernel
> build directory.  (Which to a certain degree implies impossibility to build a
> "perfect" module for a pre-built binary kernel or to provide a "perfect"
> universal pre-built module for any custom kernel)
> Of course, the real problem is that modules should not care about any (or at
> least some) kernel options, they should be isolated from the options via a
> proper KPI/KBI (perhaps DDI or "module-to-kernel interface" or whatever).  A
> module should be able to work correctly with kernels built with different options.
> As Bruce Evans has pointed to me privately [I am not sure why privately], there
> is already an example in i386 and amd64 atomic.h, where operations are inlined
> for a kernel build, but presented as real (external) functions for a module
> build.  You can search e.g. sys/amd64/include/atomic.h for KLD_MODULE.
> I think that the same treatment could/should be applied to vm_page_*lock*
> operations defined in sys/vm/vm_page.h.

Yes, it should be.  There are without question legitimate reasons for a 
module to acquire a page lock.


More information about the freebsd-current mailing list