Subject: Re: poolifying fileassoc
To: None <blymn@baesystems.com.au>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: tech-kern
Date: 01/07/2007 20:27:28
>  /*
> - * uvm_aio_aiodone: do iodone processing for async i/os.
> - * this should be called in thread context, not interrupt context.
> + *
> + * uvm_io_done: Set page flag status when an i/o (synch or asynch) has
> + * completed or an async i/o is started.
> + *
> + * pgs - array of pages to handle
> + * npages - number of pages in request
> + * write - TRUE if a write request
> + * swap - TRUE if a swap request
> + * aio_complete - TRUE if called from aio completion
> + * overwrite - TRUE if overwriting pages
> + * ext_error - error status from caller
> + * ext_slock - ignored iff swap otherwise is uobj lock held
> + * swslot - swap slot (used iff swap == TRUE)
> + * ridx - ?? extra pages to round to fs block size transaction?
> + *         (set to npages if no rounding done)
> + * orignpages - original transaction size before rounding.
> + * aio_initiate - TRUE if pages are being brought in asynchronously.
> + * vn - pointer to vnode for object.
> + *
> + * pageqlock must be held if swap is FALSE.  The locks will be released
> + * before return.
>   */

at a glance, it seems far more complicated than it should be...

> Unfortunately, it seems like my original problem still exists though -
> I think that the fileassoc code needs to use pools because the
> veriexec check is done with locks held so I get panics of the
> "vmem_alloc with simple_lock held" kind if fileassoc is not using
> pools for it's working storage.

again, can you explain why it needs to be done with simple_locks held?
i really don't see any reason why it should.

poolify merely hides the bug, unless you know a strict number of
necessary reservations.

YAMAMOTO Takashi