From: Will Deacon <will@kernel.org> To: Changbin Du <changbin.du@gmail.com> Cc: rostedt@goodmis.org, mingo@redhat.com, corbet@lwn.net, linux@armlinux.org.uk, catalin.marinas@arm.com, tglx@linutronix.de, bp@alien8.de, hpa@zytor.com, x86@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] tracing/fgraph: support recording function return values Date: Mon, 15 Jul 2019 09:29:30 +0100 [thread overview] Message-ID: <20190715082930.uyxn2kklgw4yri5l@willie-the-truck> (raw) In-Reply-To: <20190713121026.11030-1-changbin.du@gmail.com> On Sat, Jul 13, 2019 at 08:10:26PM +0800, Changbin Du wrote: > This patch adds a new trace option 'funcgraph-retval' and is disabled by > default. When this option is enabled, fgraph tracer will show the return > value of each function. This is useful to find/analyze a original error > source in a call graph. > > One limitation is that the kernel doesn't know the prototype of functions. > So fgraph assumes all functions have a retvalue of type int. You must ignore > the value of *void* function. And if the retvalue looks like an error code > then both hexadecimal and decimal number are displayed. This seems like quite a significant drawback and I think it could be pretty confusing if you have to filter out bogus return values from the trace. For example, in your snippet: > 3) | kvm_vm_ioctl() { > 3) | mutex_lock() { > 3) | _cond_resched() { > 3) 0.234 us | rcu_all_qs(); /* ret=0x80000000 */ > 3) 0.704 us | } /* ret=0x0 */ > 3) 1.226 us | } /* ret=0x0 */ > 3) 0.247 us | mutex_unlock(); /* ret=0xffff8880738ed040 */ mutex_unlock() is wrongly listed as returning something. How much of this could be achieved from userspace by placing kretprobes on non-void functions instead? Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org> To: Changbin Du <changbin.du@gmail.com> Cc: corbet@lwn.net, catalin.marinas@arm.com, x86@kernel.org, linux-doc@vger.kernel.org, linux@armlinux.org.uk, rostedt@goodmis.org, linux-kernel@vger.kernel.org, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, tglx@linutronix.de, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] tracing/fgraph: support recording function return values Date: Mon, 15 Jul 2019 09:29:30 +0100 [thread overview] Message-ID: <20190715082930.uyxn2kklgw4yri5l@willie-the-truck> (raw) In-Reply-To: <20190713121026.11030-1-changbin.du@gmail.com> On Sat, Jul 13, 2019 at 08:10:26PM +0800, Changbin Du wrote: > This patch adds a new trace option 'funcgraph-retval' and is disabled by > default. When this option is enabled, fgraph tracer will show the return > value of each function. This is useful to find/analyze a original error > source in a call graph. > > One limitation is that the kernel doesn't know the prototype of functions. > So fgraph assumes all functions have a retvalue of type int. You must ignore > the value of *void* function. And if the retvalue looks like an error code > then both hexadecimal and decimal number are displayed. This seems like quite a significant drawback and I think it could be pretty confusing if you have to filter out bogus return values from the trace. For example, in your snippet: > 3) | kvm_vm_ioctl() { > 3) | mutex_lock() { > 3) | _cond_resched() { > 3) 0.234 us | rcu_all_qs(); /* ret=0x80000000 */ > 3) 0.704 us | } /* ret=0x0 */ > 3) 1.226 us | } /* ret=0x0 */ > 3) 0.247 us | mutex_unlock(); /* ret=0xffff8880738ed040 */ mutex_unlock() is wrongly listed as returning something. How much of this could be achieved from userspace by placing kretprobes on non-void functions instead? Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-07-15 8:29 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-07-13 12:10 [PATCH] tracing/fgraph: support recording function return values Changbin Du 2019-07-13 12:10 ` Changbin Du 2019-07-15 8:29 ` Will Deacon [this message] 2019-07-15 8:29 ` Will Deacon 2019-07-15 10:12 ` Peter Zijlstra 2019-07-15 10:12 ` Peter Zijlstra 2019-07-16 14:08 ` Changbin Du 2019-07-16 14:08 ` Changbin Du 2019-07-16 14:20 ` Peter Zijlstra 2019-07-16 14:20 ` Peter Zijlstra 2019-07-16 15:24 ` Steven Rostedt 2019-07-16 15:24 ` Steven Rostedt
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190715082930.uyxn2kklgw4yri5l@willie-the-truck \ --to=will@kernel.org \ --cc=bp@alien8.de \ --cc=catalin.marinas@arm.com \ --cc=changbin.du@gmail.com \ --cc=corbet@lwn.net \ --cc=hpa@zytor.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=mingo@redhat.com \ --cc=rostedt@goodmis.org \ --cc=tglx@linutronix.de \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.