All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Joe Perches <joe@perches.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Andrew Morton <akpm@linux-foundation.org>,
	Kees Cook <keescook@chromium.org>,
	Martin Kletzander <mkletzan@redhat.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
	Maurizio Lombardi <mlombard@redhat.com>,
	Tejun Heo <tj@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 04/14] lib/vsprintf.c: expand field_width to 24 bits
Date: Thu, 03 Dec 2015 23:28:58 +0200	[thread overview]
Message-ID: <1449178138.15393.161.camel@linux.intel.com> (raw)
In-Reply-To: <1449176047.17296.4.camel@perches.com>

On Thu, 2015-12-03 at 12:54 -0800, Joe Perches wrote:
> On Thu, 2015-12-03 at 21:51 +0100, Rasmus Villemoes wrote:
> > Maurizio Lombardi reported a problem [1] with the %pb extension: It
> > doesn't work for sufficiently large bitmaps, since the size is
> > stashed
> > in the field_width field of the struct printf_spec, which is
> > currently
> > an s16. Concretely, this manifested itself in
> > /sys/bus/pseudo/drivers/scsi_debug/map being empty, since the
> > bitmap
> > printer got a size of 0, which is the 16 bit truncation of the
> > actual
> > bitmap size.
> > 
> > We do want to keep struct printf_spec at 8 bytes so that it can
> > cheaply be passed by value. The qualifier field is only used for
> > internal bookkeeping in format_decode, so we might as well use a
> > local
> > variable for that. This gives us an additional 8 bits, which we can
> > then use for the field width.
> > 
> > To stay in 8 bytes, we need to do a little rearranging and make the
> > type member a bitfield as well. For consistency, change all the
> > members to bit fields. gcc doesn't generate much worse code with
> > these
> > changes (in fact, bloat-o-meter says we save 300 bytes - which I
> > think
> > is a little surprising).
> > 
> > I didn't find a BUILD_BUG/compiletime_assertion/... which would
> > work
> > outside function context, so for now I just open-coded it.
> > 
> > [1] http://thread.gmane.org/gmane.linux.kernel/2034835
> 
> Thanks for keeping at this Rasmus.
> This seems quite reasonable.

I like most of the stuff here, though, Joe, can we avoid open-coded
BUILD_BUG_ON()?


-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy


  reply	other threads:[~2015-12-03 21:30 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-03 20:50 [PATCH v3 00/14] printf stuff for 4.5 Rasmus Villemoes
2015-12-03 20:51 ` [PATCH v3 01/14] lib/vsprintf.c: pull out padding code from dentry_name() Rasmus Villemoes
2015-12-03 20:51 ` [PATCH v3 02/14] lib/vsprintf.c: move string() below widen_string() Rasmus Villemoes
2015-12-03 20:51 ` [PATCH v3 03/14] lib/vsprintf.c: eliminate potential race in string() Rasmus Villemoes
2015-12-03 20:51 ` [PATCH v3 04/14] lib/vsprintf.c: expand field_width to 24 bits Rasmus Villemoes
2015-12-03 20:54   ` Joe Perches
2015-12-03 21:28     ` Andy Shevchenko [this message]
2015-12-03 23:34       ` Andrew Morton
2015-12-04  0:03         ` Joe Perches
2015-12-04  8:59           ` Rasmus Villemoes
2015-12-04  9:02         ` Rasmus Villemoes
2015-12-03 23:41       ` Joe Perches
2015-12-03 20:51 ` [PATCH v3 05/14] lib/vsprintf.c: help gcc make number() smaller Rasmus Villemoes
2015-12-03 20:51 ` [PATCH v3 06/14] lib/vsprintf.c: warn about too large precisions and field widths Rasmus Villemoes
2015-12-03 20:51 ` [PATCH v3 07/14] lib/kasprintf.c: add sanity check to kvasprintf Rasmus Villemoes
2015-12-03 20:51 ` [PATCH v3 08/14] lib/test_printf.c: don't BUG Rasmus Villemoes
2015-12-03 20:51 ` [PATCH v3 09/14] lib/test_printf.c: check for out-of-bound writes Rasmus Villemoes
2015-12-03 20:51 ` [PATCH v3 10/14] lib/test_printf.c: test precision quirks Rasmus Villemoes
2015-12-03 20:51 ` [PATCH v3 11/14] lib/test_printf.c: add a few number() tests Rasmus Villemoes
2015-12-03 20:51 ` [PATCH v3 12/14] lib/test_printf.c: account for kvasprintf tests Rasmus Villemoes
2015-12-03 20:51 ` [PATCH v3 13/14] lib/test_printf.c: add test for large bitmaps Rasmus Villemoes
2015-12-03 20:51 ` [PATCH v3 14/14] lib/test_printf.c: test dentry printing Rasmus Villemoes
2015-12-04  0:19   ` Andrew Morton
2015-12-04  8:16     ` Rasmus Villemoes
2015-12-04  8:46       ` Andrew Morton

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=1449178138.15393.161.camel@linux.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=joe@perches.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=mkletzan@redhat.com \
    --cc=mlombard@redhat.com \
    --cc=tj@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.