I have now got a patch that drains down the queue, and it does successfully stop sblock from being dereferenced etc when we actually reload. However, sometimes thread 5 (the same one that would dereference sblock) seems to get stuck in vm_fault_continue (at least according to the kernel debugger), so I need to do some more debugging to see why.
James > On 19 Jul 2015, at 15:00, Richard Braun <rbr...@sceen.net> wrote: > >> On Sun, Jul 19, 2015 at 02:25:14PM +0100, James Clarke wrote: >> Yeah, I tried inhibiting both buckets, but the paging RPCs still got >> through, so my guess was that libports's inhibit/resume methods weren't able >> to deal with libpager's own threads. The thing is I don't think we currently >> keep track of any reference to the main/worker threads, as >> pager_start_workers just takes a bucket and returns void. Is there a way we >> can instead make the main thread and/or workers able to block >> ports_inhibit_X_rpcs like normal RPC handlers and be cancelled etc? If >> possible I think that would be a cleaner solution. > > To continue our discussion on IRC: > > No, it would definitely not be a cleaner solution, just an ugly hack. > Since paging doesn't occur as part of an RPC, you just can't use RPC > stuff to manage it. I suggest building rwlock-based synrchonization > functions specific to the pager workers. > > -- > Richard Braun