Re: providing memory objects to users

[Marcus Brinkmann]

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?

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