Re: [Xen-devel] [PATCH v8 13/20] xenctx: change is_kernel_text() into kernel_addr().

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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