kern/161887: [vm] [panic] panic at vm_page_wire with FreeBSD 9.0 Beta 3 [regression]

[Penta Upa]

The following reply was made to PR kern/161887; it has been noted by GNATS.

From: Penta Upa <bsdboot at gmail.com>
To: Andriy Gapon <avg at freebsd.org>
Cc: bug-followup at freebsd.org
Subject: Re: kern/161887: [vm] [panic] panic at vm_page_wire with FreeBSD 9.0
 Beta 3 [regression]
Date: Sun, 30 Oct 2011 21:47:48 +0530

 --90e6ba6e834292b19904b0867651
 Content-Type: text/plain; charset=ISO-8859-1
 
 On Sun, Oct 30, 2011 at 4:01 PM, Andriy Gapon <avg at 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
 
 --90e6ba6e834292b19904b0867651
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 <br><br><div class=3D"gmail_quote">On Sun, Oct 30, 2011 at 4:01 PM, Andriy =
 Gapon <span dir=3D"ltr">&lt;<a href=3D"mailto:avg at freebsd.org">avg at freebsd.=
 org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
 gin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-=
 left: 1ex;">
 <br>
 Do you build your test module as a part of a kernel+modules build or do you=
 <br>
 build it in isolation? =A0If the latter, then this could be a known obscure=
  problem.<br>
 <br></blockquote><div>External. For example built in /home/penta/vmtest<br>=
 <br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt=
  0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
 A standalone module build doesn&#39;t get some important definitions from k=
 ernel<br>
 config (e.g. via =A0opt_global.h) and can be in a serious disagreement with=
  the<br>
 kernel. =A0In particular, if a kernel is built with SMP option, but a modul=
 e build<br>
 doesn&#39;t have SMP defined, then they will have different definitions of<=
 br>
 PA_LOCK_COUNT and thus would work on different actual locks when manipulati=
 ng<br>
 the same page.<br>
 <font color=3D"#888888"><br></font></blockquote><div>Ok and it seems like t=
 hey are operating on different locks then. vm_page_assert() succeeds in the=
  module but immediately fails in vm_page_wire(). But then isn&#39;t vm_page=
 _wire/unwire() and exported kernel api (i assumed it is since there is a ma=
 n page entry), so shouldn&#39;t it succeed irrespective of the kernel confi=
 g and irrespective of the location of the build. <br>
 <br>Regards,<br>Penta<br></div></div>
 
 --90e6ba6e834292b19904b0867651--