Subject: Re: kern/34959
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: netbsd-bugs
Date: 11/02/2006 03:55:02
The following reply was made to PR kern/34959; it has been noted by GNATS.

From: yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi)
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, jmmv@NetBSD.org
Subject: Re: kern/34959
Date: Thu,  2 Nov 2006 11:41:17 +0900 (JST)

 >  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?
 
 >  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.
 
 YAMAMOTO Takashi