Re: [PATCH 3/3] tracing: don't set parser->cont if it has reached the end of input buffer

[Steven Rostedt]

On Wed, 10 Jan 2018 11:18:23 +0800
"Du, Changbin" <changbin.du@xxxxxxxxx> wrote:

> 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?

BTW, gcc would translate the above string to 'abcdefg\0\0'. When
defining strings with "", gcc (and all C compilers) append a '\0' to
the end.

But I replied to the first patch, saying that allowing \0 as whitespace
may be OK, given the usecase I showed.

> 
> 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.

I don't believe that's true.

 $ echo -n abc > /tmp/abc
 $ wc /tmp/abc
 0 1 3 /tmp/abc

Echo writes only the characters you put on the line, nothing more.

Note, when the file descriptor is closed, the code also executes on
what was written but not terminated. That is:

	write(fd, "abc", 3);
	close(fd);

Will keep the "abc" in the continue buffer, but the closing of the file
descriptor will flush it, and execute it.

-- Steve