Hello,
Brent W. Baccala, on Wed 17 Aug 2016 10:58:41 -1000, wrote:
> OK, I seem to have gotten a handle on this thing now.
Cool :)
> First, there's a missing mutex unlock in mach_defpager. I'm attaching two
> patches. One fixes the debug printfs in mach_defpager/default_pager.c, which
> obviously haven't been compiled for a while. Use %p and %lx instead of %x to
> silence compiler warnings, and access pthread_mutex_t's internal structure
> member __held instead of held when printing mutex state. The second patch
> actual fixes the problem.
Applied, thanks!
> Second, the sysvinit scripts are killing mach_defpager during the shutdown
> sequence,
> The big culprit is /sbin/killall5, a C program in the sysvinit-utils
> package.
Oh, that's no good indeed.
> killall5's internal logic is just too Linux specific, IMHO. What's the
> Hurdish
> way to do it? I'm thinking killall5 should check that 'important' flag on the
> process and skip processes for which that flag is set. Yet, I don't
> understand
> what that flag is really intended for. Does this make sense?
You can check the changelog of the commit that introduced it:
git show 5f536bc5
It was specifically meant for dealing with killall5. See the
proc_is_important use in procfs:
proc_is_important (p, &essential);
if (essential)
start_code = end_code = 0; /* To make killall5.c consider it a
kernel process that is to be
left alone. */
i.e. we rely on killall5 considering that start/end code being 0 means
it's a kernel thingy, which is true here from the point of view of a
posix program.
So the real fix indeed is to mark mach-defpager as important. Could you
have a look at submitting a tested patch for this?
> Also, what should the kernel do if it has problems with the default pager?
Get errors, probably :)
> After I fixed the mutex bug, I started getting a bunch of
> memory_object_data_request failed messages on console. Still mysterious, but
> I
> guess that's better than nothing! The error code prints in hex, and when I
> looked it up it was MACH_SEND_INVALID_DEST. Is that what you get when you
> send
> to a dead port?
IIRC yes.
> Also, there's this proxy-defpager. Is that the actual default pager, acting
> as
> front end to mach-defpager?
See git grep proxy-defpager in the source:
“
The new proxy-defpager translator grants unprivileged users access to
the default pager.
”
It'd be good if someone could document it in the right places (hurd
documentation, hurd wiki pages about the translators, etc.)
> Yet killall5 seems to be able to kill
> proxy-defpager without consequence. I don't understand.
the proxy-defpager is used by non-root applications, probably at the
killall5 point there are not supposed to be any one of them any more.
> For me, though, I now have a qemu VM that can cleanly start up, use swap, and
> shutdown, so I have real sense of accomplishment!
And it'll definitely be helpful for others, thanks!
Samuel
