* Why dump_stack results different so much? @ 2005-07-29 20:27 Xin Zhao 2005-07-29 20:34 ` bert hubert 0 siblings, 1 reply; 6+ messages in thread From: Xin Zhao @ 2005-07-29 20:27 UTC (permalink / raw) To: linux-kernel I tried to use dump_stack to dump the calling trace in the kernel. What I did is adding a dump_stack() call in the sys_open function. Below is the dump out result: Jul 28 17:33:31 normal kernel: [<c0151601>] sys_open+0xa6/0xb7 Jul 28 17:33:31 normal kernel: [<c0108e2c>] syscall_call+0x7/0xb However, if I insert a new kernel module which does nothing but pointing the orignal sys_open to our_sys_open(), and in our_system_open(), I simply do return sys_open(); I supprisely noticed that the dump_stack results are quite different! Why did I get the calling traces below our_ssy_open() and above syscall_call()? Any thought on this? Many thanks! Jul 28 17:33:42 normal kernel: [<c0151601>] sys_open+0xa6/0xb7 Jul 28 17:33:42 normal kernel: [<d080f02c>] our_sys_open+0x2c/0x33 [trace] Jul 28 17:33:42 normal kernel: [<c0114984>] __wake_up+0x41/0x81 Jul 28 17:33:42 normal kernel: [<c02c5e44>] sbf_read+0x5a/0x6f Jul 28 17:33:42 normal kernel: [<c01c4e12>] journal_stop+0x159/0x279 Jul 28 17:33:42 normal kernel: [<c01b7aff>] ext3_mark_iloc_dirty+0x25/0x2f Jul 28 17:33:42 normal kernel: [<c02c5e44>] sbf_read+0x5a/0x6f Jul 28 17:33:42 normal kernel: [<c01b7bef>] ext3_mark_inode_dirty+0x3d/0x44 Jul 28 17:33:42 normal kernel: [<c02c5e44>] sbf_read+0x5a/0x6f Jul 28 17:33:42 normal kernel: [<c01c583a>] __journal_file_buffer+0xbb/0x282 Jul 28 17:33:42 normal kernel: [<c01546ed>] bh_lru_install+0xc3/0xdf Jul 28 17:33:42 normal kernel: [<c01c4169>] do_get_write_access+0x36f/0x5ea Jul 28 17:33:42 normal kernel: [<c01c583a>] __journal_file_buffer+0xbb/0x282 Jul 28 17:33:42 normal kernel: [<c01c4a39>] journal_dirty_metadata+0xf4/0x16d Jul 28 17:33:42 normal kernel: [<c0114984>] __wake_up+0x41/0x81 Jul 28 17:33:42 normal kernel: [<c01c4e12>] journal_stop+0x159/0x279 Jul 28 17:33:42 normal kernel: [<c01b7aff>] ext3_mark_iloc_dirty+0x25/0x2f Jul 28 17:33:42 normal kernel: [<c01b7bef>] ext3_mark_inode_dirty+0x3d/0x44 Jul 28 17:33:42 normal kernel: [<c01bc111>] __ext3_journal_stop+0x1e/0x44 Jul 28 17:33:42 normal kernel: [<c01b7c5c>] ext3_dirty_inode+0x66/0x7b Jul 28 17:33:42 normal kernel: [<c01736fc>] __mark_inode_dirty+0xec/0x1ce Jul 28 17:33:42 normal kernel: [<c011cbd4>] current_fs_time+0x4d/0x5b Jul 28 17:33:42 normal kernel: [<c0107606>] __switch_to+0x2a/0x365 Jul 28 17:33:42 normal kernel: [<c0107606>] __switch_to+0x2a/0x365 Jul 28 17:33:42 normal kernel: [<c0132c3d>] find_get_page+0x30/0x6a Jul 28 17:33:42 normal kernel: [<c015f35b>] do_lookup+0x24/0x89 Jul 28 17:33:42 normal kernel: [<c01686fc>] dput+0x95/0x252 Jul 28 17:33:42 normal kernel: [<c015ff9d>] link_path_walk+0xbdd/0xe86 Jul 28 17:33:42 normal kernel: [<c0121778>] free_uid+0x1c/0x6d Jul 28 17:33:42 normal kernel: [<c01e63de>] copy_to_user+0x3c/0x4a Jul 28 17:33:42 normal kernel: [<c015b519>] cp_new_stat64+0xf5/0x105 Jul 28 17:33:42 normal kernel: [<c015b55a>] sys_stat64+0x31/0x36 Jul 28 17:33:42 normal kernel: [<c0108e2c>] syscall_call+0x7/0xb ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why dump_stack results different so much? 2005-07-29 20:27 Why dump_stack results different so much? Xin Zhao @ 2005-07-29 20:34 ` bert hubert 2005-07-29 21:00 ` Xin Zhao 0 siblings, 1 reply; 6+ messages in thread From: bert hubert @ 2005-07-29 20:34 UTC (permalink / raw) To: Xin Zhao; +Cc: linux-kernel On Fri, Jul 29, 2005 at 04:27:16PM -0400, Xin Zhao wrote: > I supprisely noticed that the dump_stack results are quite different! > Why did I get the calling traces below our_ssy_open() and above > syscall_call()? Any thought on this? Many thanks! This might depend on compiling with frame pointers, or not. I recall that at one point, the kernel did a basic scan of addresses that looked like likely candidates to have been pointers, and printed those. Frame pointers are hailed as improving backtraces. They are in the 'kernel hacking' section of the kernel configuration. Sorry that I can't be more precise, but try turning on frame pointers. Good luck! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why dump_stack results different so much? 2005-07-29 20:34 ` bert hubert @ 2005-07-29 21:00 ` Xin Zhao 2005-07-29 21:22 ` bert hubert 0 siblings, 1 reply; 6+ messages in thread From: Xin Zhao @ 2005-07-29 21:00 UTC (permalink / raw) To: bert hubert, Xin Zhao, linux-kernel Thanks for your reply. Below is the code that print the kernel calling trace: /**********************************************************************************/ void show_trace(struct task_struct *task, unsigned long * stack) { unsigned long ebp; if (!task) task = current; if (task == current) { /* Grab ebp right from our regs */ asm ("movl %%ebp, %0" : "=r" (ebp) : ); } else { /* ebp is the last reg pushed by switch_to */ ebp = *(unsigned long *) task->thread.esp; } while (1) { struct thread_info *context; context = (struct thread_info *) ((unsigned long)stack & (~(THREAD_SIZE - 1))); ebp = print_context_stack(context, stack, ebp); stack = (unsigned long*)context->previous_esp; if (!stack) break; printk(" =======================\n"); } } /**********************************************************************************/ >From this code, I can see that the show_trace does not scan and guess the pointers. Instead, it use "previous_esp" to extract the esp and thus the returning eip. Am I right? Cheers, xin On 7/29/05, bert hubert <bert.hubert@netherlabs.nl> wrote: > On Fri, Jul 29, 2005 at 04:27:16PM -0400, Xin Zhao wrote: > > I supprisely noticed that the dump_stack results are quite different! > > Why did I get the calling traces below our_ssy_open() and above > > syscall_call()? Any thought on this? Many thanks! > > This might depend on compiling with frame pointers, or not. I recall that at > one point, the kernel did a basic scan of addresses that looked like likely > candidates to have been pointers, and printed those. > > Frame pointers are hailed as improving backtraces. They are in the 'kernel > hacking' section of the kernel configuration. > > Sorry that I can't be more precise, but try turning on frame pointers. > > Good luck! > > -- > http://www.PowerDNS.com Open source, database driven DNS Software > http://netherlabs.nl Open and Closed source services > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why dump_stack results different so much? 2005-07-29 21:00 ` Xin Zhao @ 2005-07-29 21:22 ` bert hubert 2005-07-30 0:10 ` Xin Zhao 0 siblings, 1 reply; 6+ messages in thread From: bert hubert @ 2005-07-29 21:22 UTC (permalink / raw) To: Xin Zhao; +Cc: linux-kernel On Fri, Jul 29, 2005 at 05:00:20PM -0400, Xin Zhao wrote: > Thanks for your reply. > > Below is the code that print the kernel calling trace: Can I suggest just turning on frame pointers like I suggested? If you say Y here the resulting kernel image will be slightly larger and slower, but it will give very useful debugging information. If you don't debug the kernel, you can say N, but we may not be able to solve problems without frame pointers. Good luck! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why dump_stack results different so much? 2005-07-29 21:22 ` bert hubert @ 2005-07-30 0:10 ` Xin Zhao 2005-07-30 11:52 ` bert hubert 0 siblings, 1 reply; 6+ messages in thread From: Xin Zhao @ 2005-07-30 0:10 UTC (permalink / raw) To: bert hubert, Xin Zhao, linux-kernel Thanks. I will try. The only problem I have right now is I am using Xenolinux instead of standard Linux kernel, I cannot see the option to enable the frame pointer. But I will figure out how to enable that. Again, thank you for your help! Xin an 7/29/05, bert hubert <bert.hubert@netherlabs.nl> wrote: > On Fri, Jul 29, 2005 at 05:00:20PM -0400, Xin Zhao wrote: > > Thanks for your reply. > > > > Below is the code that print the kernel calling trace: > > Can I suggest just turning on frame pointers like I suggested? > > If you say Y here the resulting kernel image will be slightly larger > and slower, but it will give very useful debugging information. > If you don't debug the kernel, you can say N, but we may not be able > to solve problems without frame pointers. > > Good luck! > > -- > http://www.PowerDNS.com Open source, database driven DNS Software > http://netherlabs.nl Open and Closed source services > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Why dump_stack results different so much? 2005-07-30 0:10 ` Xin Zhao @ 2005-07-30 11:52 ` bert hubert 0 siblings, 0 replies; 6+ messages in thread From: bert hubert @ 2005-07-30 11:52 UTC (permalink / raw) To: Xin Zhao; +Cc: linux-kernel On Fri, Jul 29, 2005 at 08:10:32PM -0400, Xin Zhao wrote: > Thanks. I will try. The only problem I have right now is I am using > Xenolinux instead of standard Linux kernel, I cannot see the option to > enable the frame pointer. But I will figure out how to enable that. If you ever report something odd again, remember to inform the readers here of any odd patches you are running with; they might be the *cause* of what you are seeing! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-07-30 11:55 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-07-29 20:27 Why dump_stack results different so much? Xin Zhao 2005-07-29 20:34 ` bert hubert 2005-07-29 21:00 ` Xin Zhao 2005-07-29 21:22 ` bert hubert 2005-07-30 0:10 ` Xin Zhao 2005-07-30 11:52 ` bert hubert
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox