Prev: [PATCH v2] Add comment in alloc_pages_exact_node
Next: [PATCH v2] change alloc function in __vmalloc_area_node
From: Frederic Weisbecker on 14 Apr 2010 11:10 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |