Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3

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, bsd.kmod.mk 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/kmod.mk:
> .if defined(KERNBUILDDIR)
> CFLAGS+=     -DHAVE_KERNEL_OPTION_HEADERS -include ${KERNBUILDDIR}/opt_global.h
> .endif
>
> where KERNBUILDDIR can be passed via environment from a kernel build:
> sys/conf/kern.post.mk:
> MKMODULESENV+=  KERNBUILDDIR="${.CURDIR}" SYSDIR="${SYSDIR}"
>
> 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.
*snip*

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

Alan