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/