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