Subject: Re: VONWORKLST problems with cached ubc mappings
To: YAMAMOTO Takashi <email@example.com>
From: Darrin B.Jewell <firstname.lastname@example.org>
Date: 09/27/2006 22:28:52
email@example.com (YAMAMOTO Takashi) writes:
> > A vnode gets written with msdofs_write, this faults pages in to
> > a ubc_alloc mapping and the mapping gets cached. The fault marks
> > the vnode VONWORKLST. When these pages are eventually cleaned, the
> > VONWORKLST flag gets appropriately cleared.
> > Later, a second msdosfs_write to the same pages calls ubc_alloc
> > and gets the previously cached mapping. Since it finds the
> > cached mapping and UBC_FAULTBUSY is not used, there is no
> > getpages call, and the pages are dirtied without the vnode
> > being tagged with VONWORKLST.
> > Now the vnode has dirty pages without being marked VONWORKLST.
> > If it does eventually get flushed, this results in the DEBUG panic.
> genfs_putpages makes pages read-only by calling pmap_page_protect
> so that further attempts of making pages dirty, including ubc, will
> involve getpages. (at least it was my intention.)
> YAMAMOTO Takashi
Ah, thanks for pointing this out. With this in mind, I've tested even
more and determined that the vnode never gets on the VONWORKLST or has
a VM_PROT_WRITE getpages call at all. I'm now thinking that the page
gets mapped writable for the purposes of reading in its original data,
and never gets write protected. Since its never gets VONWORKLST at
all, subsequent putpages calls don't write protect it (cleanall == 0)
I will continue to investigate how the pages are getting mapped
writable and will send more information tomorrow.