Re: kernel panic in gsync_wait

[Kalle Olavi Niemitalo]

"Brent W. Baccala" <cosine@freesoft.org> writes:

> My new and improved rpctrace is generating kernel panics when run on
> ext2fs.  This happens when rpctrace calls gsync_wait, with ext2fs as the
> 'task' argument.

Could gsync_wait be removed from gnumach.defs and replaced with
only a trap that does not take a task_t parameter and cannot be
intercepted by rpctrace?
(If the gsync code is not deleted altogether because of the
license conflict.)

> Even if I'm right about the nature of this bug, I don't understand gnumach
> well enough to know how a task should access another task's memory.

vm_copy apparently supports such access; code from there could be
reused.  But if rpctrace uses gsync_wait on the address space of
another task and the page has been paged out, then the call could
end up blocking for the pager, and I don't think you want that.