From: Florian Weimer <fw@deneb.enyo.de>
To: "Cufi, Carles" <Carles.Cufi@nordicsemi.no>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"jukka.rissanen@linux.intel.com" <jukka.rissanen@linux.intel.com>,
"johan.hedberg@intel.com" <johan.hedberg@intel.com>,
"Lubos, Robert" <Robert.Lubos@nordicsemi.no>,
"Bursztyka, Tomasz" <tomasz.bursztyka@intel.com>,
"linux-toolchains@vger.kernel.org"
<linux-toolchains@vger.kernel.org>
Subject: Re: Non-packed structures in IP headers
Date: Sat, 09 Oct 2021 08:56:03 +0200 [thread overview]
Message-ID: <875yu6bsak.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <DB9PR05MB7898339C06B9317EBAB13437E7AE9@DB9PR05MB7898.eurprd05.prod.outlook.com> (Carles Cufi's message of "Mon, 4 Oct 2021 10:30:34 +0000")
* Carles Cufi:
>> * Carles Cufi:
>>
>> > I was looking through the structures for IPv{4,6} packet headers and
>> > noticed that several of those that seem to be used to parse a packet
>> > directly from the wire are not declared as packed. This surprised me
>> > because, although I did find that provisions are made so that the
>> > alignment of the structure, it is still technically possible for the
>> > compiler to inject padding bytes inside those structures, since AFAIK
>> > the C standard makes no guarantees about padding unless it's
>> > instructed to pack the structure.
>>
>> The C standards do not make such guarantees, but the platform ABI
>> standards describe struct layout and ensure that there is no padding.
>> Linux relies on that not just for networking, but also for the userspace
>> ABI, support for separately compiled kernel modules, and in other places.
>
> That makes sense, but aren't ABI standards different for every
> architecture? For example, I checked the Arm AAPCS[1] and it states:
>
> "The size of an aggregate shall be the smallest multiple of its
> alignment that is sufficient to hold all of its members."
>
> Which, unless I am reading this wrong, means that the compiler would
> indeed insert padding if the size of the IP headers structs was not
> a multiple of 4. In this particular case, the struct sizes for the
> IP headers are 20 and 40 bytes respectively, so there will be no
> padding inserted. But I only checked a single architecture's ABI (or
> Procedure Call Standard) documentation, is this true for all archs?
For structure layout in memory, there is a large overlap between ABIs.
There is divergence around long long (which is easily avoided by
adding padding manually), and potentially bit fileds (but I haven't
looked at that).
Things only get weird for pass-by-value structs and unions and return
types.
prev parent reply other threads:[~2021-10-09 7:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-30 12:30 Non-packed structures in IP headers Cufi, Carles
2021-10-01 20:10 ` Florian Weimer
2021-10-02 15:54 ` David Laight
2021-10-04 10:41 ` Cufi, Carles
2021-10-04 12:18 ` David Laight
2021-10-04 10:30 ` Cufi, Carles
2021-10-09 6:56 ` Florian Weimer [this message]
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=875yu6bsak.fsf@mid.deneb.enyo.de \
--to=fw@deneb.enyo.de \
--cc=Carles.Cufi@nordicsemi.no \
--cc=Robert.Lubos@nordicsemi.no \
--cc=johan.hedberg@intel.com \
--cc=jukka.rissanen@linux.intel.com \
--cc=linux-toolchains@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=tomasz.bursztyka@intel.com \
/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.