All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Zimmerman <pauldzim@gmail.com>
To: Joe Perches <joe@perches.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	David Miller <davem@davemloft.net>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] r8169: Avoid pointer aliasing
Date: Tue, 5 Feb 2019 19:27:33 -0700	[thread overview]
Message-ID: <20190205192733.b4bd98988d1e4695f740d445@gmail.com> (raw)

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.

-- Paul

             reply	other threads:[~2019-02-06  2:27 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-06  2:27 Paul Zimmerman [this message]
2019-02-06  2:52 ` [PATCH v2 2/2] r8169: Avoid pointer aliasing Joe Perches
2019-02-06  3:25   ` Paul Zimmerman
2019-02-06  3:49     ` Joe Perches
  -- strict thread matches above, loose matches on Subject: below --
2019-02-04 16:42 [PATCH v2 1/2] r8169: Load MAC address from device tree if present Thierry Reding
2019-02-04 16:42 ` [PATCH v2 2/2] r8169: Avoid pointer aliasing Thierry Reding
2019-02-04 16:59   ` Andrew Lunn
2019-02-04 18:44   ` Heiner Kallweit
2019-02-05  3:20   ` David Miller
2019-02-05 18:42     ` Joe Perches
2019-02-05 19:14       ` David Miller
2019-02-05 19:19         ` Joe Perches
2019-02-06  7:25           ` Michal Kubecek
2019-02-05 20:04       ` Eric Dumazet
2019-02-05 20:18         ` Joe Perches
2019-02-05 20:23           ` Eric Dumazet
2019-02-05 20:23           ` Heiner Kallweit

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=20190205192733.b4bd98988d1e4695f740d445@gmail.com \
    --to=pauldzim@gmail.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=hkallweit1@gmail.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 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.