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

From: "Julio M. Merino Vidal" <jmmv84@gmail.com>
To: "YAMAMOTO Takashi" <yamt@mwd.biglobe.ne.jp>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/34959
Date: Thu, 2 Nov 2006 09:02:44 +0100

 On 11/2/06, YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp> wrote:
 > >  I'm not sure at all, but this feels incorrect.  The code is passing
 > >  the m_ext.ext_pgs to the uvm_loanuobjpages function, yet it seems to be
 > >  uninitialized; at least, M_EXT_PAGES is not set in m->m_flags and
 > >  ext_pgs[0] is always 0x30000000.  This supposedly-bogus value is later
 > >  handed off to auo_get, which, seeing that the page pointer is not NULL,
 > >  assumes it is valid and does not fetch it (see uvm_aobj.c 1.81 around
 > >  line 1022).  As a result, the rest of the uvm_loanuobjpages handles
 > >  this invalid pointer and ends up crashing.  Is this a bug?  Note that
 > >  it will be exposed whenever that NFS code path ends up calling
 > >  auo_get without PGO_LOCKED (because it will enter step 2).
 >
 > uao_get, you mean?
 
 Oh, yes.  I made that typo quite a few times...
 
 > >  For now I've been able to workaround the problem by making the
 > >  nfsrv_read function initialize the mbuf's ext_pgs field to NULL
 > >  pointers and later passing PGO_ALLPAGES to the pgo_get call in
 > >  uvm_loanuobjpages.  The former may be fine, but the latter is most
 > >  likely not.
 >
 > see PR/32166.
 
 It looks like
 
         2. for !PGO_LOCKED requests, always ignore PGO_DONTCARE.
            (ie. make "pps" output only, and remove memset() in callers.)
 
 could fix the tmpfs problem without changes to the tmpfs code itself.
 I can try doing this later today and see what happens.
 
 Any reason why that PR hasn't been looked at for almost a year (except ENOTIME)?
 
 Thanks!
 
 -- 
 Julio M. Merino Vidal <jmmv84@gmail.com>
 The Julipedia - http://julipedia.blogspot.com/