[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().

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>, Don Slutz <dslutz@xxxxxxxxxxx>
From: Don Slutz <dslutz@xxxxxxxxxxx>
Date: Tue, 01 Apr 2014 17:33:23 -0400
Cc: George Dunlap <george.dunlap@xxxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, xen-devel@xxxxxxxxxxxxx
Delivery-date: Tue, 01 Apr 2014 21:34:05 +0000
List-id: Xen developer discussion <xen-devel.lists.xen.org>

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.

(TBH, I'd suggest that this new functionality be left out for now, this
series has gone on for long enough as it is)


I will drop the module stuff.  (basically back to v5).

ffff88003b759dc0:  [<ffffffffa005f19d>]
ffff88003b759e50:  [<ffffffffa005f1e8>]
ffff88003b759ee0:  [<ffffffffa005f1e8>]
ffff88003b759f70:  [<ffffffffa005f1e8>]

This shows that a kernel module is using a lot of stack.

Does it? All I see is the four additional entries at the base, consuming
about 0.5k which I suppose is a lot. I suppose those are stack frames
corresponding to some module? Perhaps mark them as such with "unknown
module function"?



Here is maybe a better output:


dcs-xen-54:~/xen>sudo tools/xentrace/xenctx -s 
/boot/System.map-2.6.32-279.2.1.el6.mpbios5.x86_64 3 1 -n 3
rip: ffffffff81346898 io_serial_out+0x18
flags: 00000002 nz
rsp: ffff880032bb1308
rax: 0000000000000074   rcx: 0000000000000000   rdx: 00000000000003f8
rbx: ffffffff81ff8f00   rsi: 0000000000000000   rdi: ffffffff81ff8f00
rbp: ffff880032bb1308    r8: ffffffff81c03a10    r9: 0000000000000080
r10: 0000000000000004   r11: 0000000000000000   r12: 0000000000000074
r13: 0000000000000064   r14: 000000000000001b   r15: ffffffff81346f20
 cs: 0010        ss: 0018        ds: 0000        es: 0000
 fs: 0000 @ 00007f41d1061700
 gs: 0000 @ ffff88000b420000/0000000000000000/
Code (instr addr ffffffff81346898)
e5 0f 1f 44 00 00 0f b6 4f 41 89 d0 0f b7 57 08 d3 e6 01 f2 ee <c9> c3 66 0f 1f 
44 00 00 55 48 89


Stack:
 ffff880032bb1328 ffffffff81346f51 ffffffff81e361c1 ffffffff81ff8f00
 ffff880032bb1368 ffffffff813428de ffffffff8100bc0e 0000000000000000
 ffffffff81ff8f00 0000000000000001 0000000000000064 ffffffff81e361a7
 ffff880032bb13b8 ffffffff813472ad 0000000032bb14f8 0000000000000006
 ffff880032bb1428 ffffffff81affa00 ffffffff81c03800 000000000000e707

Call Trace:
                   [<ffffffff81346898>] io_serial_out+0x18 <--
ffff880032bb1310:   [<ffffffff81346f51>] serial8250_console_putchar+0x31
ffff880032bb1330:   [<ffffffff813428de>] uart_console_write+0x3e
ffff880032bb1338:   [<ffffffff8100bc0e>] apic_timer_interrupt+0xe
ffff880032bb1370:   [<ffffffff813472ad>] serial8250_console_write+0xbd
ffff880032bb13c0:   [<ffffffff8106b8f5>] __call_console_drivers+0x75
ffff880032bb13f0:   [<ffffffff8106b95a>] _call_console_drivers+0x4a
ffff880032bb1410:   [<ffffffff8106be6e>] release_console_sem+0x4e
ffff880032bb1450:   [<ffffffff8106c628>] vprintk+0x248
ffff880032bb14f0:   [<ffffffff814fd363>] printk+0x41
ffff880032bb1550:   [<ffffffffa005119d>]
ffff880032bb15e0:   [<ffffffffa00511e8>]
ffff880032bb1670:   [<ffffffffa00511e8>]
ffff880032bb1700:   [<ffffffffa00511e8>]
ffff880032bb1790:   [<ffffffffa00511e8>]
ffff880032bb1820:   [<ffffffffa00511e8>]
ffff880032bb18b0:   [<ffffffffa00511e8>]
ffff880032bb1940:   [<ffffffffa00511e8>]
ffff880032bb19d0:   [<ffffffffa00511e8>]
ffff880032bb1a60:   [<ffffffffa00511e8>]
ffff880032bb1af0:   [<ffffffffa00511e8>]
ffff880032bb1b80:   [<ffffffffa00511e8>]
ffff880032bb1c10:   [<ffffffffa00511e8>]
ffff880032bb1ca0:   [<ffffffffa00511e8>]
ffff880032bb1d30:   [<ffffffffa00511e8>]
ffff880032bb1dc0:   [<ffffffffa00511e8>]
ffff880032bb1e50:   [<ffffffffa00511e8>]
ffff880032bb1ee0:   [<ffffffffa00511e8>]
ffff880032bb1f70:   [<ffffffffa00511e8>]
ffff880032bb2000:   [<ffffffffa00511e8>]
ffff880032bb2090:   [<ffffffffa00511e8>]
ffff880032bb2120:   [<ffffffffa00511e8>]
ffff880032bb21b0:   [<ffffffffa00511e8>]
ffff880032bb2240:   [<ffffffffa00511e8>]
ffff880032bb22d0:   [<ffffffffa00511e8>]
ffff880032bb2360:   [<ffffffffa00511e8>]
ffff880032bb23f0:   [<ffffffffa00511e8>]
ffff880032bb2480:   [<ffffffffa00511e8>]
ffff880032bb2510:   [<ffffffffa00511e8>]
ffff880032bb25a0:   [<ffffffffa00511e8>]
ffff880032bb2630:   [<ffffffffa00511e8>]
ffff880032bb26c0:   [<ffffffffa00511e8>]
ffff880032bb2750:   [<ffffffffa00511e8>]
ffff880032bb27e0:   [<ffffffffa00511e8>]
ffff880032bb2870:   [<ffffffffa00511e8>]
ffff880032bb2900:   [<ffffffffa00511e8>]
ffff880032bb2990:   [<ffffffffa00511e8>]
ffff880032bb2a20:   [<ffffffffa00511e8>]
ffff880032bb2ab0:   [<ffffffffa00511e8>]
ffff880032bb2b40:   [<ffffffffa00511e8>]
ffff880032bb2bd0:   [<ffffffffa00511e8>]
ffff880032bb2c60:   [<ffffffffa00511e8>]
ffff880032bb2cf0:   [<ffffffffa00511e8>]
ffff880032bb2d80:   [<ffffffffa00511e8>]
ffff880032bb2e10:   [<ffffffffa00511e8>]
ffff880032bb2ea0:   [<ffffffffa00511e8>]
ffff880032bb2f30:   [<ffffffffa00511e8>]
ffff880032bb2fc0:   [<ffffffffa00511e8>]
ffff880032bb3050:   [<ffffffffa00511e8>]
ffff880032bb30e0:   [<ffffffffa00511e8>]
ffff880032bb3170:   [<ffffffffa00511e8>]
ffff880032bb3200:   [<ffffffffa00511e8>]
ffff880032bb3290:   [<ffffffffa00511e8>]
ffff880032bb3320:   [<ffffffffa00511e8>]
ffff880032bb33b0:   [<ffffffffa00511e8>]
ffff880032bb3440:   [<ffffffffa00511e8>]
ffff880032bb34d0:   [<ffffffffa00511e8>]
ffff880032bb3560:   [<ffffffffa00511e8>]
ffff880032bb35f0:   [<ffffffffa00511e8>]
ffff880032bb3680:   [<ffffffffa00511e8>]
ffff880032bb3710:   [<ffffffffa00511e8>]
ffff880032bb37a0:   [<ffffffffa00511e8>]
ffff880032bb3830:   [<ffffffffa00511e8>]
ffff880032bb38c0:   [<ffffffffa00511e8>]
ffff880032bb3950:   [<ffffffffa00511e8>]
ffff880032bb39e0:   [<ffffffffa00511e8>]
ffff880032bb3a70:   [<ffffffffa00511e8>]
ffff880032bb3b00:   [<ffffffffa00511e8>]
ffff880032bb3b90:   [<ffffffffa00511e8>]
ffff880032bb3c20:   [<ffffffffa00511e8>]
ffff880032bb3cb0:   [<ffffffffa00511e8>]
ffff880032bb3d40:   [<ffffffffa00511e8>]
ffff880032bb3dd0:   [<ffffffffa00511e8>]
ffff880032bb3e60:   [<ffffffffa00511e8>]
ffff880032bb3ee0:   [<ffffffffa0051210>]
ffff880032bb3ef0:   [<ffffffffa0051241>]
ffff880032bb3f20:   [<ffffffff8100204c>] do_one_initcall+0x3c
ffff880032bb3f30:   [<ffffffffa0055740>]
ffff880032bb3f50:   [<ffffffff810b0eb1>] sys_init_module+0xe1
ffff880032bb3f80:   [<ffffffff8100b0f2>] system_call_fastpath+0x16
dcs-xen-54:~/xen>


I could, but that looks to be a task for later.

Signed-off-by: Don Slutz <dslutz@xxxxxxxxxxx>
---
v8:
   Added more to commit message.
   Added some basic linux kernel module reporting.
   Moved kernel_end into define tree in case no symbol found.

kernel_start is overridable on the command line, so kernel_end probably
should be too.


Ok, but at this time I think I will defer adding "kernel_end command
option" to later.


In old 32bit linux virtual addresses were split at kernel start. Kernel end
was the same as end of memory.  With 64bit linux adding vsyscall32
(/proc/sys/abi/vsyscall32)  These are no longer kernel addresses.

   At some point __bss_stop was added and _end was dropped. Both
   mean end of named kernel data.

Hrm I suppose we already encode a bunch of Linux kernel specific symbols
in this tool so a couple more don't hurt.

[...]

+        return KERNEL_TEXT_ADDR;
+    if ( xenctx.kernel_start_set )
+    {
+        if ( addr >= kernel_start )

Has this logic changed since last time? Why no check of kernel_end?


No.  No check because the user requested a particular split.

Previously we only used kernel_start if no symbol table was provided.
That seemed logical enough to me, is there a reason to change that?


This is what to do when both are specified.  What I went with is that
if both are specified and we know this is a kernel symbol, then say so.
if the user said anything above KADDR is a kernel address, also accept
that.

Here is output of the same 3 stack pages in use guest that is paused:


dcs-xen-54:~/xen>sudo tools/xentrace/xenctx -s 
/boot/System.map-2.6.32-279.2.1.el6.mpbios5.x86_64 3 1 -n 3 -k 0xffffffff80000000
rip: ffffffff81346898 io_serial_out+0x18
flags: 00000002 nz
rsp: ffff880032bb1308
rax: 0000000000000074   rcx: 0000000000000000   rdx: 00000000000003f8
rbx: ffffffff81ff8f00   rsi: 0000000000000000   rdi: ffffffff81ff8f00
rbp: ffff880032bb1308    r8: ffffffff81c03a10    r9: 0000000000000080
r10: 0000000000000004   r11: 0000000000000000   r12: 0000000000000074
r13: 0000000000000064   r14: 000000000000001b   r15: ffffffff81346f20
 cs: 0010        ss: 0018        ds: 0000        es: 0000
 fs: 0000 @ 00007f41d1061700
 gs: 0000 @ ffff88000b420000/0000000000000000/
Code (instr addr ffffffff81346898)
e5 0f 1f 44 00 00 0f b6 4f 41 89 d0 0f b7 57 08 d3 e6 01 f2 ee <c9> c3 66 0f 1f 
44 00 00 55 48 89


Stack:
 ffff880032bb1328 ffffffff81346f51 ffffffff81e361c1 ffffffff81ff8f00
 ffff880032bb1368 ffffffff813428de ffffffff8100bc0e 0000000000000000
 ffffffff81ff8f00 0000000000000001 0000000000000064 ffffffff81e361a7
 ffff880032bb13b8 ffffffff813472ad 0000000032bb14f8 0000000000000006
 ffff880032bb1428 ffffffff81affa00 ffffffff81c03800 000000000000e707

Call Trace:
                    [<ffffffff81346898>] io_serial_out+0x18 <--
ffff880032bb1310:   [<ffffffff81346f51>] serial8250_console_putchar+0x31
ffff880032bb1318:   [<ffffffff81e361c1>] __log_buf+0xe721
ffff880032bb1320:   [<ffffffff81ff8f00>] serial8250_ports
ffff880032bb1330:   [<ffffffff813428de>] uart_console_write+0x3e
ffff880032bb1338:   [<ffffffff8100bc0e>] apic_timer_interrupt+0xe
ffff880032bb1348:   [<ffffffff81ff8f00>] serial8250_ports
ffff880032bb1360:   [<ffffffff81e361a7>] __log_buf+0xe707
ffff880032bb1370:   [<ffffffff813472ad>] serial8250_console_write+0xbd
ffff880032bb1390:   [<ffffffff81affa00>] serial8250_console
ffff880032bb1398:   [<ffffffff81c03800>] cpu_online_bits
ffff880032bb13c0:   [<ffffffff8106b8f5>] __call_console_drivers+0x75
ffff880032bb13d0:   [<ffffffff81e2797c>] logbuf_lock
ffff880032bb13f0:   [<ffffffff8106b95a>] _call_console_drivers+0x4a
ffff880032bb1410:   [<ffffffff8106be6e>] release_console_sem+0x4e
ffff880032bb1428:   [<ffffffff81ea7b24>] printk_buf+0x64
ffff880032bb1450:   [<ffffffff8106c628>] vprintk+0x248
ffff880032bb14a8:   [<ffffffff81c03a10>] cpu_present_bits+0x10
ffff880032bb14f0:   [<ffffffff814fd363>] printk+0x41
ffff880032bb1538:   [<ffffffff81c03a10>] cpu_present_bits+0x10
ffff880032bb1550:   [<ffffffffa005119d>] __brk_limit+0x1e01c19d
ffff880032bb15e0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1670:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1700:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1790:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1820:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb18b0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1940:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb19d0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1a60:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1af0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1b80:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1c10:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1ca0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1d30:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1dc0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1e50:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1ee0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb1f70:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2000:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2090:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2120:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb21b0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2240:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb22d0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2360:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb23f0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2480:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2510:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb25a0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2630:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb26c0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2750:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb27e0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2870:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2900:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2990:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2a20:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2ab0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2b40:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2bd0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2c60:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2cf0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2d80:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2e10:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2ea0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2f30:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb2fc0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3050:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb30e0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3170:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3200:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3290:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3320:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb33b0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3440:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb34d0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3560:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb35f0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3680:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3710:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb37a0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3830:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb38c0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3950:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb39e0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3a70:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3b00:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3b90:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3c20:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3cb0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3d40:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3dd0:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3e60:   [<ffffffffa00511e8>] __brk_limit+0x1e01c1e8
ffff880032bb3ee0:   [<ffffffffa0051210>] __brk_limit+0x1e01c210
ffff880032bb3ef0:   [<ffffffffa0051241>] __brk_limit+0x1e01c241
ffff880032bb3f20:   [<ffffffff8100204c>] do_one_initcall+0x3c
ffff880032bb3f30:   [<ffffffffa0055740>] __brk_limit+0x1e020740
ffff880032bb3f50:   [<ffffffff810b0eb1>] sys_init_module+0xe1
ffff880032bb3f80:   [<ffffffff8100b0f2>] system_call_fastpath+0x16

+            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.  But that symbol may also be too far also:

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


   -Don Slutz

+        printf(" %s+%#llx", s->name, offset);
+    }
  }
static void read_symbol_table(const char *symtab)
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

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

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

Prev by Date: [Xen-devel] [linux-3.10 test] 25710: tolerable FAIL - PUSHED
Next by Date: Re: [Xen-devel] [PATCH v2 1/2] xentrace: Add emacs local variables
Previous by thread: Re: [Xen-devel] [PATCH v8 13/20] xenctx: change is_kernel_text() into kernel_addr().
Next by thread: Re: [Xen-devel] [PATCH v8 13/20] xenctx: change is_kernel_text() into kernel_addr().
Index(es):
- Date
- Thread

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.