public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Joe Perches <joe@perches.com>
Cc: Eric Paris <eparis@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: [REGRESSION PATCH] vsprintf: increase sizeof precision in printf_spec
Date: Wed, 14 Apr 2010 17:00:10 +0200	[thread overview]
Message-ID: <20100414150007.GD5142@nowhere> (raw)
In-Reply-To: <1271214102.1555.27.camel@Joe-Laptop.home>

On Tue, Apr 13, 2010 at 08:01:42PM -0700, Joe Perches wrote:
> On Tue, 2010-04-13 at 22:44 -0400, Eric Paris wrote:
> > On Tue, 2010-04-13 at 18:33 -0700, Joe Perches wrote:
> > > On Tue, 2010-04-13 at 21:13 -0400, Eric Paris wrote:
> > > > Patch ef0658f3de484bf9b173639cd47544584e01efa5 changed the precision field
> > > > from and int to an s8.  Problem is that we have code which uses a much larger
> > > > precision in the kernel.  An example would in the audit code where we have:
> > > > 
> > > > vsnprintf(...,..., " msg='%.1024s'", (char *)data);
> > > > 
> > > > which causes precision to be too large and end up truncating to nothing.
> > > > Raising the size of the precision fixes the audit system issue.  It also does
> > > > not affect the alignment of the struct according to pahole and is still
> > > > approprietely packed.
> > > 
> > > I don't see how it could be appropriately packed.
> > 
> > I was just saying there was no padding inside the struct, although you
> > are right about it now being longer than 64.
> 
> Which is bad.
> 
> > But what does __attribute__((packed)) buy us?
> 
> It could force the size to be 64 bits on more platforms.
> 
> > I'll gladly resend with u8 type and s16 precision if that's the best
> > solution.
> 
> Reordering struct members to keep width and precision
> together seems appropriate.  The attribute may not be.
> 
> struct printf_spec {
> 	u8 type;
> 	u8 flags;		/* flags to number() */
> 	u8 base;
> 	u8 qualifier;
> 	s16 field_width;	/* width of output field */
> 	s16 precision;		/* # of digits/chars */
> };


Yeah, we should avoid the attribute. Packing struct should be
done for pretty special cases, not to fix padding holes, because
the hole problem would be turned into an alignment access unefficiency.


  parent reply	other threads:[~2010-04-14 15:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-14  1:13 [REGRESSION PATCH] vsprintf: increase sizeof precision in printf_spec Eric Paris
2010-04-14  1:33 ` Joe Perches
2010-04-14  2:44   ` Eric Paris
2010-04-14  3:01     ` Joe Perches
2010-04-14 14:40       ` Justin P. mattock
2010-04-14 15:00       ` Frederic Weisbecker [this message]
2010-04-14 16:27 ` [REGRESSION PATCH V2] vsprintf: Change struct printf_spec.precision from s8 to s16 Joe Perches
2010-04-14 16:47   ` Justin P. mattock
2010-04-14 18:50   ` Eric Paris

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=20100414150007.GD5142@nowhere \
    --to=fweisbec@gmail.com \
    --cc=eparis@redhat.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.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