linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Du, Changbin" <changbin.du@intel.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: changbin.du@intel.com, jolsa@redhat.com, peterz@infradead.org,
	mingo@redhat.com, alexander.shishkin@linux.intel.com,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org
Subject: Re: [PATCH 3/3] tracing: don't set parser->cont if it has reached the end of input buffer
Date: Wed, 10 Jan 2018 11:18:23 +0800	[thread overview]
Message-ID: <20180110031823.kewjaztlecxgrhad@intel.com> (raw)
In-Reply-To: <20180109181241.6b3f5ffb@vmware.local.home>

On Tue, Jan 09, 2018 at 06:12:41PM -0500, Steven Rostedt wrote:
> On Tue,  9 Jan 2018 17:55:48 +0800
> changbin.du@intel.com wrote:
> 
> > From: Changbin Du <changbin.du@intel.com>
> > 
> > We should not set parser->cont if it has reached the end of input buffer.
> > And since some callers (like ftrace_graph_write()) treat it as an error
> > condition if trace_parser_cont() returns true.
> 
> This will break existing use cases. In fact you are removing the entire
> point of this code. It NEEDS to continue if it reached the end of the
> input buffer.
> 
> I do things like:
> 
>  # cat file > set_ftrace_filter
> 
> where the file has a list of function names. It writes in blocks, and
> it could very well have a function name split between two writes where
> the write is at the end of the buffer but not finished writing the
> function name.
>
> > 
> > For example, if userspace set 'set_ftrace_filter' by writing:
> > write(3, "abcdefg", 7)
> 
> From my point of view, the above isn't done writing the function name
> yet and we SHOULD continue waiting for more input.
> 
hmm, thanks for the background. Your above case is a postive use case. So by
this design, instead of write(3, "abcdefg", 7), it should be
write(3, "abcdefg\0", 8), right?

If true, it means kernel expect userspace write every string terminated with
'\0'. So to fix this issue:
open("/sys/kernel/debug/tracing//set_ftrace_pid", O_WRONLY|O_TRUNC) = 3
write(3, " \0", 2)                      = -1 EINVAL (Invalid argument)

Fix would be:
write(3, "\0", 1)?

So far, I am still confused. Some of the tracing debugfs entry accept '\0'
while some not. AFIK, 'echo xxx > <path to tracing file>' always has a '\0'
terminated.

> BIG NACK on this patch. Sorry.
> 
> I'm guessing you have some program that writes only the strlen() of
> these strings. That's wrong, you need to write "strlen()+1". Write some
> real white space between calls, it will work. Add a "write(fd, " ", 1)"
> between calls if you need to. Please don't change the kernel to fix
> some bad use case. Especially when your fix will break existing use
> cases.
> 
> -- Steve
> 
> > 
> > Then in the kernel function ftrace_regex_write(), ftrace_process_regex()
> > will not be executed. The result is that the given filter will not be
> > applied at all.
> > 
> > ftrace_regex_write() {
> > 	...
> > 	read = trace_get_user(parser, ubuf, cnt, ppos);
> > 	if (read >= 0 && trace_parser_loaded(parser) &&
> > 	    !trace_parser_cont(parser)) {
> > 		ret = ftrace_process_regex(iter, parser->buffer,
> > 					   parser->idx, enable);
> > 		...
> > 	}
> > 	...
> > }
> > 
> > Signed-off-by: Changbin Du <changbin.du@intel.com>

-- 
Thanks,
Changbin Du

  reply	other threads:[~2018-01-10  3:26 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-09  9:55 [PATCH 0/3] tracing: Fix the parser when processing strings w/ or w/o terminated '\0' changbin.du
2018-01-09  9:55 ` [PATCH 1/3] tracing: detect the string termination character when parsing user input string changbin.du
2018-01-09 22:54   ` Steven Rostedt
2018-01-10  3:01     ` Du, Changbin
2018-01-10  4:09       ` Steven Rostedt
2018-01-09  9:55 ` [PATCH 2/3] tracing: make sure the parsed string always terminates with '\0' changbin.du
2018-01-09 23:02   ` Steven Rostedt
2018-01-10  3:02     ` Du, Changbin
2018-01-10  4:10       ` Steven Rostedt
2018-01-15 10:49         ` Du, Changbin
2018-01-09  9:55 ` [PATCH 3/3] tracing: don't set parser->cont if it has reached the end of input buffer changbin.du
2018-01-09 23:12   ` Steven Rostedt
2018-01-10  3:18     ` Du, Changbin [this message]
2018-01-10  4:19       ` Steven Rostedt
2018-01-12  4:05         ` Du, Changbin
2018-01-12 15:31           ` Steven Rostedt
2018-01-14  5:43             ` Du, Changbin

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=20180110031823.kewjaztlecxgrhad@intel.com \
    --to=changbin.du@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.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).