Thank you for your reply, but still have one more. (i think i forgot to reply to the mailing list with the previous email, so, i'm attaching the text)
On 9/28/05, Jeff Dike <[EMAIL PROTECTED]> wrote: > On Tue, Sep 27, 2005 at 08:56:51PM -0400, Young Koh wrote: > > 1) if the address is fine, shouldn't the access that causes a segfault > > be regarded as a page fault? that is, shouldn't it be handled by UML > > kernel and UML proceeds normally instead of returning an error to the > > application? (because the app gave the proper address) > > No. > > It's akin to a piece of memory all of a sudden going bad. You allocated the > memory and thought you could use it, but when you try, it turns out not > to be there. yes, i think memory can go bad if 1) it cannot be allocated because of filesystem full or similar reasons as Jeff described, or 2) it was allocated once but could have been swapped. in case of 1) it should be more like kernel panic rather than just a system call error, i think? because kernel cannot allocate any more memory, which kernel is supposed to use. in case of 2) this is a real fault, so, the seg fault handler of UML kernel is supposed to load the swapped page and UML kernel proceeds normally? (as Blaisorblade described in the other mail, by calling handle_page_fault()?) Thank you, -Young > > > 2) i thought that the file used for UML memory is created when a UML > > process is initialized. > > then, the memory file is not created for the fixed size at first, but > > it changes the size according to the UML memory usage? > > It's not fully allocated. It starts off sparse and gets allocated on > the host as the guest's memory usage increases. > > > 3) is it the only case sigsetjmp() protected from? > > I believe so, but am not positive. > > Jeff > ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ User-mode-linux-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
