Subject: Re: Solved, in part: Re: pool problems, TAILQ, and more...
To: None <>
From: Chuck Silvers <>
List: tech-kern
Date: 04/07/2000 01:45:35
On Fri, Apr 07, 2000 at 12:23:33AM -0500, Brian C. Grayson wrote:
>   So I finally figured out my main problem.  Between rev 1.31 and
> 1.32 of uvm_swap.c, Someone removed the call to brelvp(), in
> order to disassociate the soon-to-be-freed buf from the vnode.
> Contrary to the comment in r1.31, b_vp is NOT set to NULLVP -- it
> is initialized to NULLVP, but then twiddled by the bgetvp() call.
> So, we end up with a freed buf that is still on the vnode's list
> of busy buffers.
>   Next time we do I/O to this swap file, we add the new buf to
> the list of bufs associated with the vnode, which means
> changing the previous head (i.e., the freed buf)'s prev
> pointers.  Corruption of buf on the free list, and panic
> ensues at the next pool_get, if we're lucky, or at the second
> pool_get if we are unlucky.
>   Note that only the brelvp() in the swap-to-file routine
> sw_reg_iodone() was removed.  Thus, ordinary swapping to a
> device was not broken.
>   So uvm_swap.c should be modified.  Chuck and Chuck?

I just checked in the fix.  good catch.
that was my fault, sorry about that.

>   HOWEVER, once I add back the call to brelvp(), the system does
> fine for a while, but eventually panics with:
> pmap_change_attrs: found pager VA on pv_listpmap_change_attrs: found pager VA on pv_listpmap_change_attrs: found pager VA on pv_listpmap_change_attrs: found pager VA on pv_listpagedaemon:
> deadlock detected!
> panic: pagedaemon deadlock
>   I don't know if this is related or independent.
>   Brian

I've seen the "pmap_change_attrs: found pager VA on pv_list" message before,
I don't think it's related.  this message seems kinda bad to me,
but it doesn't actually seem to cause any problems, so I haven't
bothered to track it down yet.

the "panic: pagedaemon deadlock" issue with swapping to files
is actually present in the normal device swap code too
(and in fact all of the pageout code), but the swap-to-files code
is more likely to trip over it since it potentially allocates much
more memory in the process of writing data to the file.
this is one of several known problems with the current pagedaemon
design, and I'll be looking at these once UBC is integrated into -current.