From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 05:57:15 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D4871065672; Thu, 3 Nov 2011 05:57:15 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh7.mail.rice.edu (mh7.mail.rice.edu [128.42.199.46]) by mx1.freebsd.org (Postfix) with ESMTP id 534738FC0C; Thu, 3 Nov 2011 05:57:15 +0000 (UTC) Received: from mh7.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh7.mail.rice.edu (Postfix) with ESMTP id 9447F291D87; Thu, 3 Nov 2011 00:40:10 -0500 (CDT) Received: from mh7.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh7.mail.rice.edu (Postfix) with ESMTP id 5FEA4291DD6; Thu, 3 Nov 2011 00:40:10 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh7.mail.rice.edu, auth channel Received: from mh7.mail.rice.edu ([127.0.0.1]) by mh7.mail.rice.edu (mh7.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id KqLcmE+4i8xX; Thu, 3 Nov 2011 00:40:10 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh7.mail.rice.edu (Postfix) with ESMTPSA id 4F80A291DDD; Thu, 3 Nov 2011 00:40:09 -0500 (CDT) Message-ID: <4EB22938.4050803@rice.edu> Date: Thu, 03 Nov 2011 00:40:08 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110620 Thunderbird/3.1.10 MIME-Version: 1.0 To: Andriy Gapon References: <4EB11C32.80106@FreeBSD.org> In-Reply-To: <4EB11C32.80106@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Penta Upa , freebsd-current@FreeBSD.org, Benjamin Kaduk , "K. Macy" Subject: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 05:57:15 -0000 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