[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Re: Hurd shutdown problems

From: Samuel Thibault
Subject: Re: [PATCH] Re: Hurd shutdown problems
Date: Sat, 20 Aug 2016 14:29:56 +0200
User-agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)


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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]