Re: [RFC][PATCH 1/3] trace_seq: Move the trace_seq code to lib/

From: Johannes Berg <johannes@sipsolutions.net>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@kernel.org>, Jiri Kosina <jkosina@suse.cz>,
	Michal Hocko <mhocko@suse.cz>, Jan Kara <jack@suse.cz>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Dave Anderson <anderson@redhat.com>,
	Petr Mladek <pmladek@suse.cz>
Subject: Re: [RFC][PATCH 1/3] trace_seq: Move the trace_seq code to lib/
Date: Mon, 23 Jun 2014 19:38:14 +0200	[thread overview]
Message-ID: <1403545094.4418.32.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <20140623120805.1624e1db@gandalf.local.home>

On Mon, 2014-06-23 at 12:08 -0400, Steven Rostedt wrote:
> On Sun, 22 Jun 2014 09:38:05 +0200
> Johannes Berg <johannes@sipsolutions.net> wrote:
> 
> 
> > Looking at the code though, I'm not sure it's a pure optimisation - if
> > you do say putc() after a failed puts(), without this code the putc()
> > would succeed? I can't tell right now if that's really a problem, but it
> > seems you could get some odd behaviour out of it.
> 
> How would putc() still succeed? We're just talking about the "full"
> field. It would still do the length check:
> 
> 	if (s->len >= (PAGE_SIZE - 1))
> 		return 0;

Right, but the puts() could fail if not all of the string fits, and a
subsequent putc() might fit.

johannes