Bug 161887 - [vm] [panic] panic at vm_page_wire with FreeBSD 9.0 Beta 3 [regression]
Summary: [vm] [panic] panic at vm_page_wire with FreeBSD 9.0 Beta 3 [regression]
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-21 19:10 UTC by Penta Upa
Modified: 2019-07-18 11:29 UTC (History)
0 users

See Also:


Attachments
file.txt (1.03 KB, text/plain)
2011-10-21 19:10 UTC, Penta Upa
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Penta Upa 2011-10-21 19:10:10 UTC
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>
Comment 1 Andriy Gapon freebsd_committer 2011-10-30 10:31:25 UTC
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
Comment 2 Penta Upa 2011-10-30 16:17:48 UTC
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
Comment 3 Andriy Gapon freebsd_committer 2011-10-30 17:00:28 UTC
> 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
Comment 4 Penta Upa 2011-10-30 17:11:46 UTC
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
Comment 5 Andriy Gapon freebsd_committer 2011-11-02 09:42:59 UTC
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
Comment 6 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:18 UTC
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
Comment 7 Andriy Gapon freebsd_committer 2019-07-18 11:29:11 UTC
There has been a lot of work to provide consistent ABI for kernel modules.
Assume fixed.