linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Kauer <florian.kauer@linutronix.de>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Donglin Peng <pengdonglin@sangfor.com.cn>,
	mhiramat@kernel.org, linux@armlinux.org.uk, mark.rutland@arm.com,
	will@kernel.org, catalin.marinas@arm.com, palmer@dabbelt.com,
	paul.walmsley@sifive.com, tglx@linutronix.de,
	dave.hansen@linux.intel.com, x86@kernel.org, mingo@redhat.com,
	xiehuan09@gmail.com, dinghui@sangfor.com.cn,
	huangcun@sangfor.com.cn, dolinux.peng@gmail.com,
	linux-trace-kernel@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 1/2] function_graph: Support recording and printing the return value of function
Date: Tue, 21 Mar 2023 16:11:07 +0100	[thread overview]
Message-ID: <ac95f1f7-2af3-1461-2ea2-3608d081de3f@linutronix.de> (raw)
In-Reply-To: <20230321104413.43a81ffb@gandalf.local.home>

On 21.03.23 15:44, Steven Rostedt wrote:
> On Tue, 21 Mar 2023 15:09:40 +0100
> Florian Kauer <florian.kauer@linutronix.de> wrote:
> 
>> On 20.03.23 14:16, Donglin Peng wrote:
>>> When using the function_graph tracer to analyze system call failures,
>>> it can be time-consuming to analyze the trace logs and locate the kernel
>>> function that first returns an error. This change aims to simplify the
>>> process by recording the function return value to the 'retval' member of
>>> 'ftrace_graph_ent' and printing it when outputing the trace log.  
>>
>> I just came across your patch by pure luck and it helped me a lot
>> to trace down a problem I had, thanks!
>>
>> So you can have my
>> Tested-by: Florian Kauer <florian.kauer@linutronix.de>
>>  
>>> New trace options are introduced: funcgraph-retval and graph_retval_hex.  
>>
>> I would personally prefer to have the second option scoped better, so for example
>> "funcgraph-retval-hex".
> 
> That could be an ftrace option.

What do you mean? In the current implementation both funcgraph-retval and graph_retval_hex
are options for the function_graph tracer, but one is prefixed with "funcgraph-" as nearly
all other options for the function_graph tracer and one is not (and is even snake_case, while
the others are kebab-case). So it just looks inconsistent for me, but there might be a reason?

By the way: The documentation patch also references "function-retval" instead of
"funcgraph-retval" in the documentation of the graph_retval_hex option.

> Anyway, could you tell us your use case, and that could go into the change
> log of this patch as "one use case that this helped with".

Nothing spectacular. I just wanted to find out why ICMP port unreachable messages
sporadically lead to -111 (Connection Refused) for __sys_sendto() when IP_RECVERR is set
and the call never fails if IP_RECVERR is not set. (I am still unsure if this is
REALLY intended behavior, but at least it makes sense why this occurs when reading
the sources).

And with this patch, the -111 is directly popping up in the trace, but I do not think
that my missing knowledge about details of the kernel network stack
really qualifies as a good argument ;-)

Greetings,
Florian

  reply	other threads:[~2023-03-21 15:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-20 13:16 [PATCH v5 0/2] function_graph: Support recording and printing the return value of function Donglin Peng
2023-03-20 13:16 ` [PATCH v5 1/2] " Donglin Peng
2023-03-21 14:09   ` Florian Kauer
2023-03-21 14:44     ` Steven Rostedt
2023-03-21 15:11       ` Florian Kauer [this message]
2023-03-22  5:01         ` Donglin Peng
2023-03-21 14:24   ` Mark Rutland
2023-03-22  8:47     ` Donglin Peng
2023-03-21 17:31   ` Russell King (Oracle)
2023-03-22  9:01     ` Donglin Peng
2023-03-20 13:16 ` [PATCH v5 2/2] tracing: Add documentation for funcgraph-retval and graph_retval_hex Donglin Peng
2023-03-21  2:31   ` Ding Hui
2023-03-21  3:24     ` Donglin Peng

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=ac95f1f7-2af3-1461-2ea2-3608d081de3f@linutronix.de \
    --to=florian.kauer@linutronix.de \
    --cc=catalin.marinas@arm.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dinghui@sangfor.com.cn \
    --cc=dolinux.peng@gmail.com \
    --cc=huangcun@sangfor.com.cn \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=pengdonglin@sangfor.com.cn \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=xiehuan09@gmail.com \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).