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 [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
