Re: [PATCH v2 2/2] r8169: Avoid pointer aliasing

[Joe Perches <joe@perches.com>]

On Tue, 2019-02-05 at 19:27 -0700, Paul Zimmerman wrote:
> On Tue, 2019-02-05, Joe Perches wrote:
> > On Tue, 2019-02-05 at 12:04 -0800, Eric Dumazet wrote:
> > > On 02/05/2019 10:42 AM, Joe Perches wrote:
> > > > It's declared after a pointer so it is already is 2 byte aligned.
> > > > 
> > > > A lot of drivers wouldn't work otherwise.
> > > 
> > > Maybe these drivers are only used on arches where this does not matter.
> > 
> > Possible.
> > 
> > I had only grepped through the sources looking for
> > declarations using:
> > 
> > $ git grep -B1 '\[ETH_ALEN\];' -- '*.c' | grep -A1 '\*'
> > 
> > It's quite a few files in net/ too btw.
> > 
> > I still think adding __align(<even#>) is unnecessary here unless
> > it follows something like a bool or a u8.
> 
> Um, guys, this is practically C-101.
> 
> From C99, 6.7.2.1:
> 
> > 13/ Within a structure object, the non-bit-field members and the units in
> > which bit-fields reside have addresses that increase in the order in which
> > they are declared. A pointer to a structure object, suitably converted,
> > points to its initial member (or if that member is a bit-field, then to the
> > unit in which it resides), and vice versa. There may be unnamed padding
> > within a structure object, but not at its beginning.
> 
> AFAIK there is no such language in the spec regarding variable layout on
> the stack. So Joe, you are totally off-base here.

We're not talking about the spec, see the void * arithmetic
bit, we're talking about what gcc and clang actually do.

This spec regarding variable layout structure members could
also apply to any of the unpacked protocol headers like in
include/uapi/linux/ip.h (struct iphdr for instance)

So, it's not me that's off here.
I do understand the c90 spec pretty well.

Eric's comment about stack layout randomization certainly applies.

Perhaps it's reasonable to add some __aligned(<even#>) to the
appropriate [ETH_ALEN] declarations.