[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1403545094.4418.32.camel@jlt4.sipsolutions.net>
Date: Mon, 23 Jun 2014 19:38:14 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...nel.org>, Jiri Kosina <jkosina@...e.cz>,
Michal Hocko <mhocko@...e.cz>, Jan Kara <jack@...e.cz>,
Frederic Weisbecker <fweisbec@...il.com>,
Dave Anderson <anderson@...hat.com>,
Petr Mladek <pmladek@...e.cz>
Subject: Re: [RFC][PATCH 1/3] trace_seq: Move the trace_seq code to lib/
On Mon, 2014-06-23 at 12:08 -0400, Steven Rostedt wrote:
> On Sun, 22 Jun 2014 09:38:05 +0200
> Johannes Berg <johannes@...solutions.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists