linux-trace-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Dan Carpenter <dan.carpenter@linaro.org>,
	linux-trace-kernel@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3] tracing/probes: Fix return value when "(fault)" is injected
Date: Fri, 7 Jul 2023 11:02:10 +0900	[thread overview]
Message-ID: <20230707110210.06e81e182c775454ce86280d@kernel.org> (raw)
In-Reply-To: <20230706095039.1cb9c9d1@gandalf.local.home>

On Thu, 6 Jul 2023 09:50:39 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Thu, 6 Jul 2023 13:40:36 +0900
> Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
> 
> > On Wed, 5 Jul 2023 22:49:56 -0400
> > Steven Rostedt <rostedt@goodmis.org> wrote:
> > 
> > > On Sun,  2 Jul 2023 23:47:35 +0900
> > > "Masami Hiramatsu (Google)" <mhiramat@kernel.org> wrote:
> > >   
> > > > From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> > > > 
> > > > When the "(fault)" is injected, the return value of fetch_store_string*()
> > > > should be the length of the "(fault)", but an error code is returned.
> > > > Fix it to return the correct length and update the data_loc according the
> > > > updated length.
> > > > This needs to update a ftracetest test case, which expects trace output
> > > > to appear as '(fault)' instead of '"(fault)"'.
> > > >   
> > > 
> > > Ah, because of patch 2, the ret < 0 makes it return without printing the
> > > "fault"?  
> > 
> > No, actually set_data_loc() updates the 'ret' argument, but it is just
> > disposed... (not returned to the caller)
> 
> That's not what I was talking about.
> 
> We have:
> 
> process_fetch_insn_bottom() {
> 	[..]
> 	case FETCH_OP_ST_STRING:
> 		loc = *(u32 *)dest;
> 		ret = fetch_store_string(val + code->offset, dest, base);
> 		break;
> 	[..]
> 
> // And from patch 2 we have:
> 
> @@ -193,6 +193,8 @@ process_fetch_insn_bottom(struct fetch_insn *code, unsigned long val,
>  	default:
>  		return -EILSEQ;
>  	}
> +	if (ret < 0)
> +		return ret;
>  	code++;
> 
> And now that the return value of fetch_store_string() is being checked, and
> if it returns negative, it ends the function before being processed
> further. And if there's a fault, it happens to return negative!
> 
> This patch now changes fetch_store_string() and fetch_store_string_user()
> to not return negative if there's a fault. As this patch has:
> 
> @@ -107,9 +106,7 @@ fetch_store_string(unsigned long addr, void *dest, void *base)
>  	 * probing.
>  	 */
>  	ret = strncpy_from_kernel_nofault(__dest, (void *)addr, maxlen);
> -	set_data_loc(ret, dest, __dest, base, maxlen);
> -
> -	return ret;
> +	return set_data_loc(ret, dest, __dest, base, maxlen);
>  }
> 
> But to do that, you needed to update set_data_loc() to return a value.
> 
> *that's* what I meant by 
> 
> 'Ah, because of patch 2, the ret < 0 makes it return without printing the "fault"?'

Yes, that's correct. Actually, the data ("(fault)") is stored, but ignored
because data_loc is not updated.

But wait, it seems that the print function shows (fault), so commit 2e9906f84fc7
("tracing: Add "(fault)" name injection to kernel probes") may not needed?

----
/* Print type function for string type */
int PRINT_TYPE_FUNC_NAME(string)(struct trace_seq *s, void *data, void *ent)
{
        int len = *(u32 *)data >> 16;

        if (!len)
                trace_seq_puts(s, "(fault)");
        else
----

In this case, what we need is to set data_loc length = 0 if ret < 0.

Do you really need to get '"(fault)"' (with double quotation) or
just '(fault)' (no double quotation) is OK?

Thank you,
> 
> 
> -- Steve
> 
> > 
> > -static nokprobe_inline void set_data_loc(int ret, void *dest, void *__dest, void *base, int len)
> > +static nokprobe_inline int set_data_loc(int ret, void *dest, void *__dest, void *base, int len)
> >  {
> > -	if (ret >= 0) {
> > -		*(u32 *)dest = make_data_loc(ret, __dest - base);
> > -	} else {
> > +	if (ret < 0) {
> >  		strscpy(__dest, FAULT_STRING, len);
> >  		ret = strlen(__dest) + 1;
> >  	}
> > +
> > +	*(u32 *)dest = make_data_loc(ret, __dest - base);
> > +	return ret;
> >  }
> > 
> > So this returns updated 'ret', and also update data_loc to use the
> > updated 'ret' value (which is the length of the stored data).
> > 
> > > 
> > > Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>  
> > 
> > Thank you!
> > 
> > > 
> > > -- Steve
> > > 
> > >   
> > > > Fixes: 2e9906f84fc7 ("tracing: Add "(fault)" name injection to kernel probes")
> > > > Cc: stable@vger.kernel.org
> > > > Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> > > > ---  
> > 
> > 
> 


-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>

  reply	other threads:[~2023-07-07  2:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-02 14:47 [PATCH 0/3] tracing/probes: Fix bugs in process_fetch_insn Masami Hiramatsu (Google)
2023-07-02 14:47 ` [PATCH 1/3] tracing/probes: Fix to avoid double count of the string length on the array Masami Hiramatsu (Google)
     [not found]   ` <25bd757c-f929-0153-4c94-f0502c5d1005@web.de>
2023-07-03  8:21     ` Masami Hiramatsu
2023-07-02 14:47 ` [PATCH 2/3] tracing/probes: Fix to exit fetching if an error is detected Masami Hiramatsu (Google)
2023-07-07  7:07   ` Masami Hiramatsu
2023-07-02 14:47 ` [PATCH 3/3] tracing/probes: Fix return value when "(fault)" is injected Masami Hiramatsu (Google)
2023-07-06  2:49   ` Steven Rostedt
2023-07-06  4:40     ` Masami Hiramatsu
2023-07-06 13:50       ` Steven Rostedt
2023-07-07  2:02         ` Masami Hiramatsu [this message]
2023-07-07  2:20           ` Steven Rostedt
2023-07-07  2:51             ` Masami Hiramatsu
2023-07-07  3:06               ` Steven Rostedt
2023-07-07  6:54                 ` Masami Hiramatsu

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=20230707110210.06e81e182c775454ce86280d@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=dan.carpenter@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.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: 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).