From owner-freebsd-current@FreeBSD.ORG Wed Nov 2 06:10:22 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 1DA541065673 for ; Wed, 2 Nov 2011 06:10:22 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by mx1.freebsd.org (Postfix) with ESMTP id B05908FC0A for ; Wed, 2 Nov 2011 06:10:21 +0000 (UTC) X-AuditID: 1209190c-b7f806d0000008d6-cf-4eb0deccc923 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 51.D5.02262.CCED0BE4; Wed, 2 Nov 2011 02:10:20 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id pA26AJ8O022328; Wed, 2 Nov 2011 02:10:20 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pA26AIsk002275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Nov 2011 02:10:19 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id pA26AH7l024806; Wed, 2 Nov 2011 02:10:17 -0400 (EDT) Date: Wed, 2 Nov 2011 02:10:17 -0400 (EDT) From: Benjamin Kaduk To: "K. Macy" In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrHvm3gY/g9YDAhaTXnWyW8x584HJ 4vHeLWwOzB4zPs1nCWCM4rJJSc3JLEst0rdL4MromXyWtWA/f8WrL8vZGhjX8XQxcnJICJhI tD56xghhi0lcuLeerYuRi0NIYB+jxJEP+1ggnPWMEicPv4Ny9jNJnH3+nA2kRUigXqJ9+VYw m0VAS2La2m0sIDabgIrEzDcbweIiAooSJ/6uYAexmQUMJH7e2cQKYgsLWEn8ndoIFOfg4BQI lFg5H6yVV8BeYv3RJ1BX3GKUuLF0HVivqICOxOr9U6CKBCVOznzCAjHTUuLcn+tsExgFZyFJ zUKSWsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXUC83s0QvNaV0EyM4VCV5djC+Oah0iFGA g1GJh9dZa4OfEGtiWXFl7iFGSQ4mJVFeDWCgC/El5adUZiQWZ8QXleakFh9ilOBgVhLhLVwG lONNSaysSi3Kh0lJc7AoifMe3OHgJySQnliSmp2aWpBaBJOV4eBQkuDVAhkqWJSanlqRlplT gpBm4uAEGc4DNHz6XZDhxQWJucWZ6RD5U4yKUuK8LSAJAZBERmkeXC8slbxiFAd6RZhXFmQF DzANwXW/AhrMBDR45qX1IINLEhFSUg2MLaYxr6yPCe63q3wTwnn0U83T7TOc56hrvvHYfJDx A0vH9FmvdS7vE7i5/PDpXe/2lN2L/7jOa1fbjDc+JzYJbr/SIFfMqvfV3OdRwpWYGrEJMuqr NS2/Mf6/ydbhsPSP/JZpWzctCprqkXOm6bDxVQnjbPvopVFugX6x1bW3DmwsX9LgpOkQq8RS nJFoqMVcVJwIADVBRQAAAwAA Cc: freebsd-current@freebsd.org, avg@freebsd.org 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: Wed, 02 Nov 2011 06:10:22 -0000 On Tue, 1 Nov 2011, Penta Upa wrote: > Yes that seems to be the problem. It will is for out of tree modules. > http://www.freebsd.org/cgi/query-pr.cgi?pr=161887 . 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 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 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, 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. (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.) Thanks, Ben Kaduk