[Top][All Lists]

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

Re: providing memory objects to users

From: Marcus Brinkmann
Subject: Re: providing memory objects to users
Date: Wed, 12 Jun 2002 12:41:51 +0200
User-agent: Mutt/1.3.28i

On Tue, Jun 11, 2002 at 08:21:59PM -0700, Thomas Bushnell, BSG wrote:
> pager_read_page provides a newly-allocated page to the caller, but the
> caller completely consumes that page.  Once you return, you must
> regard the page as deallocated.  Why?

Ah, ok.  I will do it more like libdiskfs then (using a mapping of the
object internally, too).  I hope I don't get lost in the jungle of objects
and references to them :)

> On to the next:
> > Furthermore, I noticed that this version would deadlock
> > when there were no callers and the kernel tried to swap out the page and
> > return it to the console server.  I didn't try hard to find out what
> > went wrong, but I still have the debugging output if you want it.
> This has to be some kind of locking bug.  No clue what it is, but if
> your code acquires pager locks...that's where to look.

I include the backtrace of the three interesting threads below.  It looks
very strange to me.
> And the next:
> > And as I don't use libdiskfs, I
> > don't need to link to libpager at all.  However, this version now
> > doesn't work at all.  I tried to map in the memory via vm_map, but when
> > I access it the server just hangs interruptible (it hangs in a similar
> > way my first version hanged when I didn't have the pager RPCs served).
> By "the server" you mean which program exactly?  The default pager,
> the program that does the map, or the server that hands out the memory
> object? 

Actually, the memory object comes from the default pager.  But the console
server which requested this object, and which tries to do a mapping for
internal use, hung when trying to write to the mapped area after vm_map.

> If it's the program that does the map, then it's hanging because you
> probably didn't give it a real valid memory object.

Yeah, that would match my past experience.
> > And, btw, why is getting pages from the default server a privileged
> > operation?  
> Because memory object ports are not well-protected in Mach.

Yes, I remember now, thank you.

> > Here the meat of what I did:
> > 
> >   err = default_pager_object_create (default_pager, &display->memobj,
> >                                        display->allocsize);
> >   err = vm_map (mach_task_self (), (vm_address_t *) &user,
> >                 display->allocsize,
> >             0, 1, display->memobj, 0, 0,
> >             VM_PROT_READ | VM_PROT_WRITE,
> >             VM_PROT_READ | VM_PROT_WRITE,
> >             VM_INHERIT_NONE);
> Well, what's the error return from the first call?

I omitted the error checking from my mail.  There was no error.

The line following that code, "user->magic = CONS_MAGIC;", hung the server.

BTW, Thomas, while we are chatting about pagers.  I remember Roland told me
the thread explosion in the server is a known problem with the Mach virtual
memory management.  Can you briefly wrap up an example for a typical behaviour
that can cause it?  I have seen > 2000 threads in ext2fs, and I am at a loss
how this can happen.  Does it happen at page-out time?


`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org

reply via email to

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