mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@kernel.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 03/14] lib/vsprintf.c: eliminate potential race in string()
Date: Thu, 26 Nov 2015 22:31:43 +0100	[thread overview]
Message-ID: <87wpt4curk.fsf@rasmusvillemoes.dk> (raw)
In-Reply-To: <CAHp75VePn-1kge9NEJHjyAkVJ8xhKutjGqjfB_iUMjZx-Kk0OA@mail.gmail.com> (Andy Shevchenko's message of "Tue, 24 Nov 2015 00:51:44 +0200")

On Mon, Nov 23 2015, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Mon, Nov 23, 2015 at 11:29 PM, Rasmus Villemoes
> <linux@rasmusvillemoes.dk> wrote:
>> If the string corresponding to a %s specifier can change under us, we
>> might end up copying a \0 byte to the output buffer. There might be
>> callers who expect the output buffer to contain a genuine C string
>> whose length is exactly the snprintf return value (assuming truncation
>> hasn't happened or has been checked for).
>>
>> We can avoid this by only passing over the source string once,
>> stopping the first time we meet a nul byte (or when we reach the given
>> precision), and then letting widen_string() handle left/right space
>> padding. As a small bonus, this code reuse also makes the generated
>> code slightly smaller.
>>
>
> Could it be pair of patches: a) re-use, b) optimize for fuzzy strings?

I'm afraid I have no idea what you mean. The patch is already broken
into three (pull out from dentry(), move helper, do the actual thing to
string()). What's a 'fuzzy string', and what optimization do you think of?

This patch already gives us the bonus of only passing over the source
once instead of twice. (Well, at the expense of a little complicated
logic in case we have a larger field width and not the LEFT flag set,
but these are so extremely rare compared to plain %s that it's not worth
caring about. And in any case, the logic already existed.)

>> Cc: Ingo Molnar <mingo@kernel.org>
>> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
>> ---
>>  lib/vsprintf.c | 28 +++++++++-------------------
>>  1 file changed, 9 insertions(+), 19 deletions(-)
>>
>> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
>> index a021e6380404..63ca52366049 100644
>> --- a/lib/vsprintf.c
>> +++ b/lib/vsprintf.c
>> @@ -557,32 +557,22 @@ char *widen_string(char *buf, int n, char *end, struct printf_spec spec)
>>  static noinline_for_stack
>>  char *string(char *buf, char *end, const char *s, struct printf_spec spec)
>>  {
>> -       int len, i;
>> +       int len = 0;
>> +       size_t lim = spec.precision;
>
> Just a nitpick: maybe longer first?

Why?

Rasmus

  reply	other threads:[~2015-11-26 21:31 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-23 21:29 [PATCH 00/14] printf stuff for 4.5 Rasmus Villemoes
2015-11-23 21:29 ` [PATCH 01/14] lib/vsprintf.c: pull out padding code from dentry_name() Rasmus Villemoes
2015-11-23 22:56   ` Andy Shevchenko
2015-11-26 21:41     ` Rasmus Villemoes
2015-11-23 21:29 ` [PATCH 02/14] lib/vsprintf.c: move string() below widen_string() Rasmus Villemoes
2015-11-23 21:29 ` [PATCH 03/14] lib/vsprintf.c: eliminate potential race in string() Rasmus Villemoes
2015-11-23 22:51   ` Andy Shevchenko
2015-11-26 21:31     ` Rasmus Villemoes [this message]
2015-11-23 21:29 ` [PATCH 04/14] lib/vsprintf.c: expand field_width to 24 bits Rasmus Villemoes
2015-11-23 23:05   ` Andy Shevchenko
2015-11-26 21:47     ` Rasmus Villemoes
2015-11-23 23:19   ` Tejun Heo
2015-11-23 21:29 ` [PATCH 05/14] lib/vsprintf.c: help gcc make number() smaller Rasmus Villemoes
2015-11-23 22:17   ` Andy Shevchenko
2015-11-23 21:29 ` [PATCH 06/14] lib/vsprintf.c: warn about too large precisions and field widths Rasmus Villemoes
2015-11-23 22:34   ` Andy Shevchenko
2015-11-26 21:10     ` Rasmus Villemoes
2015-11-23 21:29 ` [PATCH 07/14] lib/vsprintf.c: slightly refactor vscnprintf() Rasmus Villemoes
2015-11-23 22:39   ` Andy Shevchenko
2015-11-26 21:23     ` Rasmus Villemoes
2015-11-23 21:29 ` [PATCH 08/14] lib/kasprintf.c: add sanity check to kvasprintf Rasmus Villemoes
2015-11-23 23:10   ` Andy Shevchenko
2015-11-23 21:29 ` [PATCH 09/14] lib/test_printf.c: don't BUG Rasmus Villemoes
2015-11-23 21:29 ` [PATCH 10/14] lib/test_printf.c: check for out-of-bound writes Rasmus Villemoes
2015-11-23 21:29 ` [PATCH 11/14] lib/test_printf.c: test precision quirks Rasmus Villemoes
2015-11-23 21:29 ` [PATCH 12/14] lib/test_printf.c: account for kvasprintf tests Rasmus Villemoes
2015-11-23 21:29 ` [PATCH 13/14] lib/test_printf.c: add test for large bitmaps Rasmus Villemoes
2015-11-23 21:29 ` [PATCH 14/14] lib/test_printf.c: test dentry printing Rasmus Villemoes

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=87wpt4curk.fsf@rasmusvillemoes.dk \
    --to=linux@rasmusvillemoes.dk \
    --cc=akpm@linux-foundation.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.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

Powered by JetHome