bug-hurd
[Top][All Lists]
Advanced

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

Re: default pager using legacy interfaces


From: Marcus Brinkmann
Subject: Re: default pager using legacy interfaces
Date: Mon, 15 Oct 2001 03:16:39 +0200
User-agent: Mutt/1.3.22i

On Thu, Sep 27, 2001 at 06:00:03PM -0700, Thomas Bushnell, BSG wrote:
> Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> 
> > the default pager in serverboot (also used by mach-defpager) is still using
> > the legacy interfaces memory_object_set_attributes() and
> > memory_object_data_write() to set the ready attribute and receive data from
> > the kernel.  The newer documentation suggests that memory_object_ready()
> > and memory_object_data_return() should be used.
> 
> In general I have no problem with this.  Switching to
> memory_object_ready means that you have to commit to using the new
> interface entirely, and IIRC there are several changes to worry
> about.  I don't think any of them affect the default pager.

It would be nice if you could elaborate on what things there are to worry
about.
 
> But I would feel happier if you compiled this and did some major
> stress-testing of it first.

Excellent instinct.  I tried a small test program that is just malloc'ing
pages and touches them in a rapid succession.  In GNU Mach as it is now, it
will consume all RAM and swap and the crash failing on page requests (as
expected).  With my patch, it will consume all RAM, and then die a horrible
death:

/hurd/mach-defpager: panic: (default pager): data_writepanic: thread_invoke:
thread 802935 has invalid state 14

(the thread address was different, and the text might be *slightly*
different wording as well).  Is this something you would have suspected as
easily being possible?  Note that I saw occasional (once every 50 hours)
panics in thread_invoke (and other thread handling code) before, with state
14 (see earlier postings).  I don't know how to debug this (maybe with
oskit-mach over serial line, I will do a better job in examining the kernel
state at the time of the crash).

Maybe I was lucky and found a good way to reproduce the thread state 14 bug
in a fast way.  Maybe I was just a bit lucky and found a different bug. 
Maybe I was unlucky and just wrote a wrong patch ;)  What should in general
happen if the default pager misbehave?  I guess it should not provoke a
panic in the thread code like this.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de



reply via email to

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