Re: [PATCH] Re: Hurd shutdown problems

[Samuel Thibault]

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