[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v8 13/20] xenctx: change is_kernel_text() into kernel_addr().
On Tue, 2014-04-01 at 17:33 -0400, Don Slutz wrote: > On 04/01/14 10:10, Ian Campbell wrote: > > On Thu, 2014-03-27 at 15:05 -0400, Don Slutz wrote: > >> A new enum has been added to allow the caller to determine if this > >> kernel address is a text, data, or module address. This can help > >> understand what is going on. > >> > >> Kernel modules are only found when they are more then 1MiB after > > s/then/than/ > > > > But where does this magic assumption come from? Where does 1MiB come > > from? > > I just picked it. I did base it on the theory that a given routine > should not be too large. I do feel that any routine that has more > then 1MiB of code bytes is too large. > > >> kernel_end or the symbol "__brk_limit". The symbol "vgettimeofday" > >> is used to mark the end of where modules can be loaded. > > I can just about see from the vmlinux.lds.S why __brk_limit might be > > somewhat relevant, but where does the use of vgettimeofday come from? > > > > The 3.2 kernel on my desktop doesn't list vgettimeofday in System.map > > for example and in any case you can't rely on it not being moved around. > > (you can't really rely on __brk_limit either, but it seems less likely > > to move). > > I would guess you are running a 32 bit desktop. No. 3.13-1-amd64 and I looked in System.map-3.13-1-amd64 System.map-3.2.0-4-amd64 and System.map-3.9-1-amd64 which happened to be present in /boot. > Here is output of the same 3 stack pages in use guest that is paused: You keep dropping in these massive output dumps without explaining what they are supposed to illustrate. I have no idea what you think this is telling me. > >> + return KERNEL_TEXT_ADDR; > >> + } > >> + else > >> + { > >> + if ( kernel_text && > >> + (addr >= kernel_text && > >> + addr <= kernel_end) ) > >> + return KERNEL_DATA_ADDR; > >> + if ( kernel_mod_start && > >> + (addr >= kernel_mod_start && > >> + addr <= kernel_mod_end) ) > >> + return KERNEL_MOD_ADDR; > >> + } > >> + return NOT_KERNEL_ADDR; > >> } > >> > >> @@ -180,7 +223,14 @@ static void print_symbol(guest_word_t addr) > >> if (addr==s->address) > >> printf(" %s", s->name); > >> else > >> - printf(" %s+%#x", s->name, (unsigned int)(addr - s->address)); > >> + { > >> + unsigned long long offset = addr - s->address; > >> + > >> + if ( addr_type == KERNEL_MOD_ADDR && > >> + offset > MAX_MOD_OFFSET ) > >> + return; > > Shouldn't kernel_addr have not returned KERNEL_MOD_ADDR in that case? > > > > I did. You did what? > But that symbol may also be too far also: If it is too far then why is addr_type == KERNEL_MOD_ADDR in the first place. Isn't it kernel_addr()s job to return the right answer? > > Like this is: > > ffff880032bb3950: [<ffffffffa08711e8>] offline::checkit+0x41c1e8 > > > This was an attempt to allow a more complete map to be used. > Like a copy of /proc/kallsyms from the guest. This would add > lines like: > > ffffffffa000a510 t rpc_destroy_wait_queue [sunrpc] > ffffffffa002d140 b rpciod_workqueue [sunrpc] > ffffffffa00128c0 t auth_domain_put [sunrpc] > ffffffffa002cd00 d __tracepoint_rpc_task_sleep [sunrpc] > ffffffffa002cd40 d __tracepoint_rpc_task_complete [sunrpc] > ffffffffa0017100 t xdr_shift_buf [sunrpc] > ffffffffa000c9e0 t rpcauth_register [sunrpc] > > I.E doing this gives: > > ... > ffff880032bb3c20: [<ffffffffa00511e8>] init_module [offline]+0x1e8 > ffff880032bb3cb0: [<ffffffffa00511e8>] init_module [offline]+0x1e8 > ffff880032bb3d40: [<ffffffffa00511e8>] init_module [offline]+0x1e8 > ffff880032bb3dd0: [<ffffffffa00511e8>] init_module [offline]+0x1e8 > ffff880032bb3e60: [<ffffffffa00511e8>] init_module [offline]+0x1e8 > ffff880032bb3ee0: [<ffffffffa0051210>] init_module [offline]+0x210 > ffff880032bb3ef0: [<ffffffffa0051241>] init_module [offline]+0x241 > ffff880032bb3f20: [<ffffffff8100204c>] do_one_initcall+0x3c > ffff880032bb3f30: [<ffffffffa0055740>] init_module [offline]+0x4740 > ffff880032bb3f50: [<ffffffff810b0eb1>] sys_init_module+0xe1 > ffff880032bb3f80: [<ffffffff8100b0f2>] system_call_fastpath+0x16 I have no clue what you think this is telling me. Apparently a bunch of "[offline]" and "offline::" prefixes have appeared out of thin air though. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |