May 2012 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

Re: [RFC]Read kernel stack with trace-cmd
by harryxiyou May 9, 2012

May 9, 2012

On Tue, May 8, 2012 at 11:06 PM, Steven Rostedt <rostedt(a)goodmis.org> wrote: > On Tue, 2012-05-08 at 22:34 +0800, harryxiyou wrote: > >> > [...] >> => i915_add_request (f850cef4) >> => i915_gem_do_execbuffer (f8510adc) >> Xorg-1104 [001] 3106.003258: irq_handler_exit: > > Isn't this what you asked for? Hmmm.., this is what i wanna see ;-) Actually, i don't know how to analyse these datas got by trace-cmd. Cloud you please give me some descriptions for following ones? #./trace-cmd report | less version = 6 cpus=2 trace-cmd-1666 [000] 66.206448: sys_exit: NR 4 = 1 Xorg-977 [001] 66.206449: sys_exit: NR 265 = 0 trace-cmd-1666 [000] 66.206450: kernel_stack: <stack trace> => syscall_exit_work (c010352a) Xorg-977 [001] 66.206450: kernel_stack: <stack trace> => syscall_exit_work (c010352a) Xorg-977 [001] 66.206455: sys_enter: NR 54 (9, c00c6466, bfcfccb0, 9f42bf0, 863b7b4, bfcfccd8) Xorg-977 [001] 66.206455: kernel_stack: <stack trace> => syscall_trace_entry (c01034ff) trace-cmd-1666 [000] 66.206456: mm_page_alloc: page=0xc13c65a0 pfn=3241960864 order=0 migratetype=2 gfp_flags=GFP_HIGHUSER_MOVABLE trace-cmd-1666 [000] 66.206457: kernel_stack: <stack trace> => do_wp_page (c01e5659) => handle_mm_fault (c01e641c) => do_page_fault (c058da8d) => error_code (c058b983) Xorg-977 [001] 66.206463: sys_exit: NR 54 = 0 Xorg-977 [001] 66.206463: kernel_stack: <stack trace> => syscall_exit_work (c010352a) trace-cmd-1666 [000] 66.206467: sys_enter: NR 4 (1, b782f000, 1d, 1d, b782f000, bf91b918) Xorg-977 [001] 66.206467: sys_enter: NR 54 (9, c00c6466, bfcfcd20, 9e767a8, 863b7b4, bfcfcd48) trace-cmd-1666 [000] 66.206467: kernel_stack: <stack trace> => syscall_trace_entry (c01034ff) Xorg-977 [001] 66.206467: kernel_stack: <stack trace> => syscall_trace_entry (c01034ff) Xorg-977 [001] 66.206470: sys_exit: NR 54 = 0 Xorg-977 [001] 66.206470: kernel_stack: <stack trace> => syscall_exit_work (c010352a) Xorg-977 [001] 66.206473: sys_enter: NR 54 (9, c00c6466, bfcfcd90, 9f42620, 863b7b4, bfcfcdb8) Xorg-977 [001] 66.206473: kernel_stack: <stack trace> => syscall_trace_entry (c01034ff) trace-cmd-1666 [000] 66.206475: timer_start: timer 0xef0be8c8: func delayed_work_timer_fn, expires 53251, timeout 1 trace-cmd-1666 [000] 66.206475: kernel_stack: <stack trace> => add_timer (c015be36) => queue_delayed_work_on (c01642df) => queue_delayed_work (c0164370) => schedule_delayed_work (c01643a6) => tty_flip_buffer_push (c03ba7c3) => pty_write (c03bb7ca) => process_output_block (c03b5992) => n_tty_write (c03b669b) Xorg-977 [001] 66.206476: sys_exit: NR 54 = 0 Xorg-977 [001] 66.206476: kernel_stack: <stack trace> => syscall_exit_work (c010352a) Xorg-977 [001] 66.206478: sys_enter: NR 54 (9, c00c6466, bfcfcd90, 9f546d0, 863b7d8, bfcfcdb8) Xorg-977 [001] 66.206479: kernel_stack: <stack trace> => syscall_trace_entry (c01034ff) trace-cmd-1666 [000] 66.206481: sched_wakeup: task trace-cmd:1666 [120] success=0 [000] trace-cmd-1666 [000] 66.206481: kernel_stack: <stack trace> [...] > >> irq=29 return=handled >> Xorg-1104 [001] 3106.003259: kernel_stack: <stack trace> [...] >> => hrtimer_wakeup (c016acad) >> => __run_hrtimer (c016b14a)^Ctrace-cmd: Received SIGINT >> Xorg-1104 [001] 3106.003348: kernel_stack: <stack trace> >> [...] >> >> >> Note: i can't stop the cmd './trace-cmd report' after >> './trace-cmd record -e all -O stacktrace' but enter 'CTRC+C'. >> >> If it is a bug here? Any comments? > > It should stop, but perhaps not immediately. Best to pipe it through > less: > > trace-cmd report |less Yup, it works for me, thanks ;-) > > I may, in the future, make trace-cmd report do its own paging, like git > does. But for now, I just use less. > > The reason for the special ctrl-c is because of the python plugin. It > has some strange side effects. One is that it overrides ctrl-c, so I add > a handler to explicitly kill trace-cmd. But that still causes a delay > before the kill happens. > Hmm.., It sounds well, thanks ;-) -- Thanks Harry Wei

1 0

user virtual address to physical address
by Fredrick May 9, 2012

May 9, 2012

Hi, I need to convert a user virtual address to its corresponding physical address. I know that if the virtual address is from kernel, we could use virt_to_phys. Is there a similar helper function to convert user virtual address.? Thanks, Fredrick

2 1

Re: [RFC]Read kernel stack with trace-cmd
by harryxiyou May 8, 2012

May 8, 2012

On Mon, May 7, 2012 at 10:12 PM, Steven Rostedt <rostedt(a)goodmis.org> wrote: > On Sun, 2012-05-06 at 21:25 +0800, harryxiyou wrote: >> Hi Steven, >> >> Maybe this is not the right place for asking a trace-cmd matter. If true, >> please ignore this mail. Thanks. >> I wanna to read stack contents with our trace-cmd. But i can only get >> something about function information like following. I can not get kernel >> stack infos with trace-cmd. How should i run trace-cmd for kernel stack >> ones. Cloud anyone give me some suggestions? >> >> My Environments: >> # uname -r >> 2.6.32-21-generic > > Wow that's an old kernel. Yup ;-) > >> # lsb_release -a >> No LSB modules are available. >> Distributor ID: Ubuntu > > Note, I don't use Ubuntu. I use Debian or Fedora. > >> Description: Ubuntu 10.04.4 LTS >> Release: 10.04 >> Codename: lucid >> gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) >> >> Following are my test code and logs after running trace-cmd. >> >> /* >> * linux_os/sys_call.c >> * >> * Harry Wei (C) 2012 5 6 >> */ >> #include <syscall.h> >> #include <unistd.h> >> #include <stdio.h> >> #include <sys/types.h> >> >> int main(int argc, char **argv) { >> long ID1 = 0L; >> long ID2 = 0L; >> >> ID1 = syscall(SYS_getpid); >> printf("syscall(SYS_getpid) = %ld\n", ID1); >> ID2 = getpid(); >> printf("getpid() = %ld\n", ID2); >> return 0; >> } >> >> $ gcc sys_call.c >> >> # ./trace-cmd record -e all ../../workshop1/homeworkxy/linux_os/a.out > > > Have you tried it with -O stacktrace ? > > trace-cmd record -e all -O stacktrace > After this cmd, i get following ones. [...] => handle_IRQ_event (c019fc34) => handle_edge_irq (c01a1b84) => handle_irq (c01059ed) => do_IRQ (c058fa1c) => common_interrupt (c0103a30) => mod_timer (c015bd42) => i915_add_request (f850cef4) => i915_gem_do_execbuffer (f8510adc) Xorg-1104 [001] 3106.003258: irq_handler_exit: irq=29 return=handled Xorg-1104 [001] 3106.003259: kernel_stack: <stack trace> => handle_edge_irq (c01a1b84) => handle_irq (c01059ed) => do_IRQ (c058fa1c) => common_interrupt (c0103a30) => mod_timer (c015bd42) => i915_add_request (f850cef4) => i915_gem_do_execbuffer (f8510adc) => i915_gem_execbuffer (f851123b) Xorg-1104 [001] 3106.003272: kfree: call_site=f8510958 ptr=0xf5ab9380 Xorg-1104 [001] 3106.003273: kernel_stack: <stack trace> => i915_gem_do_execbuffer (f8510958) => i915_gem_execbuffer (f851123b) => drm_ioctl (f81d57cd) => vfs_ioctl (c0216231) => do_vfs_ioctl (c0216519) => sys_ioctl (c0216817) [...] Xorg-1104 [001] 3106.003348: sched_wakeup: task trace-cmd:3028 [120] success=1 [001] Xorg-1104 [001] 3106.003348: kernel_stack: <stack trace> => wake_up_process (c0142bd4) => hrtimer_wakeup (c016acad) => __run_hrtimer (c016b14a)^Ctrace-cmd: Received SIGINT Xorg-1104 [001] 3106.003348: kernel_stack: <stack trace> => wake_up_process (c0142bd4) => hrtimer_wakeup (c016acad) => __run_hrtimer (c016b14a) => hrtimer_interrupt (c016b4e0) => smp_apic_timer_interrupt (c058fae7) => apic_timer_interrupt (c0103df1) => __module_text_address (c017cdf0) [...] => wake_up_process (c0142bd4) => hrtimer_wakeup (c016acad) => __run_hrtimer (c016b14a)^Ctrace-cmd: Received SIGINT Xorg-1104 [001] 3106.003348: kernel_stack: <stack trace> [...] Note: i can't stop the cmd './trace-cmd report' after './trace-cmd record -e all -O stacktrace' but enter 'CTRC+C'. If it is a bug here? Any comments? -- Thanks Harry Wei

1 0

standard way to extract kernel headers
by Jung-joon Kim May 8, 2012

May 8, 2012

I want to extract kernel header files from our kernel sources for kernel module developers. Currently, I copy following files manually. kernel_sources/Makefile kernel_sources/arch/[our-arch]/* kernel_sources/include/* kernel_sources/scripts/* (optional) kernel_sources/.config kernel_sources/Module.symvers Is there any standard/automatic/easy way to do this? Expecting some scripts exist to make packages like linux-headers-....deb/rpm in linux distributions, but cannot find yet. Best regards, Jung-joon Kim

3 2

rootfile system porting for FPGA [/bin/sh: can't access tty; job control turned off]
by pcuser p May 8, 2012

May 8, 2012

Hi, I am newbie to linux kernel,doing kernel porting on a arm926ej-s FPGA board (only timer & uart hardware is available in the board) I'm using busybox for rootfs(busy box binary is built with "static" option enabled) After file system is mounted,I can see the below message, "VFS: Mounted root (cramfs filesystem) readonly on device 1:0." "Freeing init memory: 80K" I am expecting to get to shell prompt and give some commands (ls,clear) after file system gets mounted. *I am ending up in the shell prompt with the message as below:* "entered linuxrc script" "/bin/sh: can't access tty; job control turned off / $" I am getting no response from terminal for any commands entered in the shel lafter this. I went through this FAQ in http://www.busybox.net/FAQ.html#job_control I could not follow this exactly. my kernel commad line is "mem=32M console=ttySAC0,115200 root=/dev/ram0 init=/linuxrc initrd=0x80800000,8M user_debug=31" *I could see 2 issues here:* 1. I am using shell on /dev/console which is not correct as mentioned in busybox FAQ 2. linuxrc and /etc/inittab files may not be correct. I think the problem could be in both above 2 cases. Below are my /linuxrc and /etc/inittab file contents *linuxrc: *#!/bin/sh /bin/echo "entered linuxrc script" /bin/sh exec /sbin/init * /etc/inittab:* id:3:initdefault: # System initialization. si::sysinit:/etc/rc.d/rc. sysinit l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 l3:3:wait:/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6 # Trap CTRL-ALT-DELETE ca::ctrlaltdel:/sbin/shutdown -t3 -r now # When our UPS tells us power has failed, assume we have a few minutes # of power left. Schedule a shutdown for 2 minutes from now. # This does, of course, assume you have powerd installed and your # UPS connected and working correctly. pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down" # If power was restored before the shutdown kicked in, cancel it. pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled" # Run gettys in standard runlevels 3:2345:respawn:/sbin/getty 115200 ttySAC0 Can some experts suggest how to fix this two problems and get a shell prompt working?

4 5

Some questions in v6_copy_user_highpage_aliasing
by Gavin Guo May 8, 2012

May 8, 2012

Hi all, I have traced v6_copy_user_highpage_aliasing in arch/arm/mm/copypage-v6.c and found some questions. 72 /* 73 * Copy the page, taking account of the cache colour. 74 */ 75 static void v6_copy_user_highpage_aliasing(struct page *to, 76 struct page *from, unsigned long vaddr) 77 { 78 unsigned int offset = CACHE_COLOUR(vaddr); 79 unsigned long kfrom, kto; 80 I think the following statement is to solve aliasing problem that kernel & user address map to the same physical frame. When the kernel mapping is dirty, writing back is needed before the copy_page() is used. Because the color bit of user space address & kernel one may be difference which cause inconsistency. Now, the problem is what is the scenario of dirty cache. When does the PG_dcache_dirty set ? In normal copy-on-write case, I think the if clause will be false. 81 if (test_and_clear_bit(PG_dcache_dirty, &from->flags)) 82 __flush_dcache_page(page_mapping(from), from); 83 The problem is similar with before. Two virtual address map to "to", in order to avoid the problem that when "kto" is copied with data "kfrom". The cache data belong to kernel address mapping to "to" will not match with the user one. Thus, invalidation of cache mapped by kernel address is needed. But I don't know what will happen if invalidating cache is removed. Where is the place that the problem will happen ? 84 /* FIXME: not highmem safe */ 85 discard_old_kernel_data(page_address(to)); 86 87 /* 88 * Now copy the page using the same cache colour as the 89 * pages ultimate destination. 90 */ 91 spin_lock(&v6_lock); 92 93 set_pte_ext(TOP_PTE(from_address) + offset, pfn_pte(page_to_pfn(from), PAGE_KERNEL), 0); 94 set_pte_ext(TOP_PTE(to_address) + offset, pfn_pte(page_to_pfn(to), PAGE_KERNEL), 0); 95 96 kfrom = from_address + (offset << PAGE_SHIFT); 97 kto = to_address + (offset << PAGE_SHIFT); 98 99 flush_tlb_kernel_page(kfrom); 100 flush_tlb_kernel_page(kto); 101 102 copy_page((void *)kto, (void *)kfrom); 103 104 spin_unlock(&v6_lock); 105 } Thanks for your help, any comment is appreciated. Regards, Gavin

1 0

usbserial != serial
by Peter Senna Tschudin May 7, 2012

May 7, 2012

Dear list, To read and write to serial ports from Kernel space I would take a look at /proc/ioports to find out the address range of the port I want to use. # cat ioports |grep serial 03f8-03ff : serial Then I would use inb() functions outb() to read and write from I/O registers. But how can I figure it out the address range for usb-serial /dev/ttyUSB0? There is nothing at /proc/ioports. My device uses cypress_m8 and usbserial modules. How bad is using filp_open() to open /dev/ttyUSB0? Thanks, Peter -- Peter Senna Tschudin peter.senna(a)gmail.com gpg id: 48274C36

1 0

Regarding xfs tests.
by karunakar merugu May 7, 2012

May 7, 2012

Hi I am trying to learn about the xfstests .I am searching for good article on that. Can anyone please share the links with me to know more about the xfstests please. Thanks, Karunakar.

1 0

[RFC]Read kernel stack with trace-cmd
by harryxiyou May 6, 2012

May 6, 2012

Hi Steven, Maybe this is not the right place for asking a trace-cmd matter. If true, please ignore this mail. Thanks. I wanna to read stack contents with our trace-cmd. But i can only get something about function information like following. I can not get kernel stack infos with trace-cmd. How should i run trace-cmd for kernel stack ones. Cloud anyone give me some suggestions? My Environments: # uname -r 2.6.32-21-generic # lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 10.04.4 LTS Release: 10.04 Codename: lucid gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) Following are my test code and logs after running trace-cmd. /* * linux_os/sys_call.c * * Harry Wei (C) 2012 5 6 */ #include <syscall.h> #include <unistd.h> #include <stdio.h> #include <sys/types.h> int main(int argc, char **argv) { long ID1 = 0L; long ID2 = 0L; ID1 = syscall(SYS_getpid); printf("syscall(SYS_getpid) = %ld\n", ID1); ID2 = getpid(); printf("getpid() = %ld\n", ID2); return 0; } $ gcc sys_call.c # ./trace-cmd record -e all ../../workshop1/homeworkxy/linux_os/a.out /sys/kernel/debug/tracing/events/*/filter syscall(SYS_getpid) = 3497 getpid() = 3497 Kernel buffer statistics: Note: "entries" are the entries left in the kernel ring buffer and are not recorded in the trace data. They should all be zero. CPU: 0 entries: 0 overrun: 0 commit overrun: 0 CPU: 1 entries: 0 overrun: 0 commit overrun: 0 CPU0 data recorded at offset=0x1fc000 53248 bytes in size CPU1 data recorded at offset=0x209000 12288 bytes in size # ./trace-cmd report # ./trace-cmd report > 1 trace-cmd: No such file or directory unknown op '{' failed to read event print fmt for hrtimer_start unknown op '{' failed to read event print fmt for hrtimer_expire_entry function jbd2_dev_to_name not defined failed to read event print fmt for jbd2_submit_inode_data function jbd2_dev_to_name not defined ... version = 6 cpus=2 a.out-3497 [001] 417.636333: sys_exit: NR 4 = 1 a.out-3497 [001] 417.636345: sys_enter: NR 11 (bf911946, bf910a44, bf910a4c, bf910a44, c47ff4, bf910874) a.out-3497 [001] 417.636346: kmem_cache_alloc: call_site=c021113a ptr=0xd2d61000 bytes_req=4096 bytes_alloc=4096 gfp_flags=GFP_KERNEL a.out-3497 [001] 417.636347: kmem_cache_alloc: call_site=c020e906 ptr=0xe3f6e800 bytes_req=256 bytes_alloc=256 gfp_flags=GFP_KERNEL|GFP_ZERO a.out-3497 [001] 417.636347: kmalloc: call_site=c020e8f8 ptr=0xe3f6e800 bytes_req=196 bytes_alloc=256 gfp_flags=GFP_KERNEL|GFP_ZERO a.out-3497 [001] 417.636348: kmem_cache_alloc: call_site=c016df13 ptr=0xf4124900 bytes_req=32 bytes_alloc=32 gfp_flags=GFP_KERNEL a.out-3497 [001] 417.636348: kmalloc: call_site=c016def0 ptr=0xf4124900 bytes_req=28 bytes_alloc=32 gfp_flags=GFP_KERNEL a.out-3497 [001] 417.636349: kmem_cache_alloc: call_site=c016db9c ptr=0xd2c6f780 bytes_req=128 bytes_alloc=128 gfp_flags=GFP_KERNEL ... # cat 1 | tail -10 <idle>-0 [001] 417.652875: hrtimer_start: [FAILED TO PARSE] timer=0xc1e03d80 function=0xc0176db0 expires=2759989000000 softexpires=2759989000000 <idle>-0 [001] 417.652877: sched_stat_wait: task: trace-cmd:3494 wait: 22002 [ns] <idle>-0 [001] 417.652878: sched_switch: task swapper:0 [120] (R) ==> trace-cmd:3494 [120] trace-cmd-3494 [001] 417.652880: mm_page_free_direct: page=0xc174d980 pfn=3245660544 order=0 trace-cmd-3494 [001] 417.652880: mm_page_free_direct: page=0xc174d980 pfn=3245660544 order=0 trace-cmd-3494 [001] 417.652881: kmem_cache_free: call_site=c014a6c7 ptr=0xf6b84fc0 trace-cmd-3494 [001] 417.652889: kmem_cache_free: call_site=c0149bf4 ptr=0xf6b1da40 trace-cmd-3494 [001] 417.652890: kmem_cache_free: call_site=c0149ce2 ptr=0xe3fba900 trace-cmd-3494 [001] 417.652891: sys_exit: NR 7 = 3497 trace-cmd-3494 [001] 417.652896: sys_enter: NR 4 (3, 806fb9a, 1, 0, 0, bf910898) -- Thanks Harry Wei

1 0

Linux sys_call_table RIP relative addressing
by Alexander Samilovskih May 6, 2012

May 6, 2012

Hello! I am trying to get offset of sys_call_table on Linux x86_64. First of all i read pointer to system_call entry by reading it from MSR_LSTAR and it's correct static unsigned long read_msr(unsigned int msr) { unsigned low, high; asm volatile("rdmsr" : "=a" (low), "=d" (high) : "c" (msr)); return ((low) | ((u64)(high) << 32)); } Then i parse it to find opcode of call instruction and it is also correct #define CALL_OP 0xFF #define CALL_MODRM 0x14 static unsigned long find_syscall_table(unsigned char *ptr) { //parse correct for (; (*ptr != CALL_OP) || (*(ptr+1) != CALL_MODRM); ptr++); //calculation not correct ptr += *(unsigned int*)(ptr + 3); pr_info("%lx", (unsigned long)ptr); return ptr; } But i failed to get address after call opcode. First byte of ptr is opcode, then ModRM byte, then SIB and then 32bit displacement, so i add 3 to ptr and dereferenced it as integer value and then add it to ptr, because it is %RIP, and address is RIP relative. But the result value is wrong, it dont coincide with value i see in gdb, so where am i wrong? Thank you

1 0