External modules calling vm_page_wire() even after calling vm_page_lock() results in the following assertion failure in vm_page.c panic: mutex page lock not owned at /usr/src/sys/vm/vm_page:1845 Interestingly check for vm page locked is also done in the external module but there is no assertion there. More clearly within the external module vm_page_lock(pp); vm_page_lock_assert(pp, MA_OWNED); /* No panic here */ vm_page_wire(pp); /* Panic here for the same assertion as above, strange */ vm_page_unlock(pp); The machine in use is a fresh install of FreeBSD 9 Beta 3. No changes to the kernel were made. Problem however exists ever after a kernel recompile. I have also sent a mail to the mailing list on this. http://lists.freebsd.org/pipermail/freebsd-current/2011-October/028550.html I dont have a backtrace of the crash as i'm unable to configure kernel dumps yet. Will post them once i have it. Fix: Patch attached with submission follows: How-To-Repeat: Try the attached vmtest.c Makefile contents are KMOD = vmtest SRCS = vmtest.c .include <bsd.kmod.mk>
Do you build your test module as a part of a kernel+modules build or do you build it in isolation? If the latter, then this could be a known obscure problem. 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. -- Andriy Gapon
On Sun, Oct 30, 2011 at 4:01 PM, Andriy Gapon <avg@freebsd.org> wrote: > > Do you build your test module as a part of a kernel+modules build or do you > build it in isolation? If the latter, then this could be a known obscure > problem. > > External. For example built in /home/penta/vmtest > 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. > > Ok and it seems like they are operating on different locks then. vm_page_assert() succeeds in the module but immediately fails in vm_page_wire(). But then isn't vm_page_wire/unwire() and exported kernel api (i assumed it is since there is a man page entry), so shouldn't it succeed irrespective of the kernel config and irrespective of the location of the build. Regards, Penta
> Ok and it seems like they are operating on different locks then. > vm_page_assert() succeeds in the module but immediately fails in vm_page_wire(). > But then isn't vm_page_wire/unwire() and exported kernel api (i assumed it is > since there is a man page entry), so shouldn't it succeed irrespective of the > kernel config and irrespective of the location of the build. You described how things should be and I described how they are at the moment. -- Andriy Gapon
On Sun, Oct 30, 2011 at 10:30 PM, Andriy Gapon <avg@freebsd.org> wrote: > You described how things should be and I described how they are at the > moment. > > > Ok :-) Would including any specific header, tweaks to the Makefile make it work it for me. My target environment will be release version of FreeBSD on amd64. For example 9.0 release and it would never be a custom built kernel. Or moving the module to /usr/src/sys/modules and building from there be the safest way. Thanks, Penta
on 30/10/2011 19:11 Penta Upa said the following: > Ok :-) Would including any specific header, tweaks to the Makefile make it work > it for me. My target environment will be release version of FreeBSD on amd64. > For example 9.0 release and it would never be a custom built kernel. > > Or moving the module to /usr/src/sys/modules and building from there be the > safest way. Unfortunately I do not have a good answer for you. Ideally, this issue should be fixed somewhere on vm_page.h side. Merely moving your module sources into /usr/src/sys/modules won't change anything. The only workaround I know at the moment is to build the module as a part of kernel build (make buildkernel). -- Andriy Gapon
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
There has been a lot of work to provide consistent ABI for kernel modules. Assume fixed.