2010-05-07 14:31:04 -07:00
|
|
|
|
/*
|
2014-10-08 22:13:31 -07:00
|
|
|
|
* Copyright (c) 2010, 2011, 2014 Nicira, Inc.
|
2010-05-07 14:31:04 -07:00
|
|
|
|
*
|
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
|
* You may obtain a copy of the License at:
|
|
|
|
|
*
|
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
|
*
|
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
|
* limitations under the License.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef UNALIGNED_H
|
|
|
|
|
#define UNALIGNED_H 1
|
|
|
|
|
|
|
|
|
|
#include <stdint.h>
|
2010-10-28 17:13:18 -07:00
|
|
|
|
#include "byte-order.h"
|
2010-11-15 15:53:00 -08:00
|
|
|
|
#include "openvswitch/types.h"
|
2016-04-04 21:32:08 -04:00
|
|
|
|
#include "openvswitch/type-props.h"
|
dpif-linux: Fix build with certain 64-bit kernel/userspace combinations.
Unix 64-bit ABIs have two 64-bit types: "long" and "long long". Either of
these is a reasonable choice for uint64_t (the userspace type) and for
__u64 (the kernel type). Unfortunately, kernel and userspace don't
necessarily agree on the choice, and in fact the choice varies across
kernel versions and architectures.
Now that OVS is actually using kernel types in its kernel header, this
can make a difference: when __u64 and uint64_t differ, passing a pointer
to __u64 to OVS function get_unaligned_u64() yields a compiler warning
or error.
This commit fixes up the problems of this type found in OVS, by making
get_unaligned_u64() accept all 64-bit unsigned integer types, not just
whichever one happens to be uint64_t. I didn't do the same thing for
put_unaligned_u64() because it is less likely to be a problem in
practice: usually, when userspace writes to kernel data structures it
does so with copies that it knows to be aligned, so that it's not
necessary to use put_unaligned_u64().
This problem won't occur for uint8_t, uint16_t, or uint32_t, since there is
only one reasonable choice of type for each. It won't occur for ovs_be<N>
because OVS always defines those as aliases for the kernel's __be<N> types
when those are available.
This compiled cleanly for me in Scientific Linux 6.0 x86-64.
Reported-by: Pravin Shelar <pshelar@nicira.com>
2011-10-14 09:39:48 -07:00
|
|
|
|
#include "util.h"
|
2010-05-07 14:31:04 -07:00
|
|
|
|
|
|
|
|
|
/* Public API. */
|
|
|
|
|
static inline uint16_t get_unaligned_u16(const uint16_t *);
|
|
|
|
|
static inline uint32_t get_unaligned_u32(const uint32_t *);
|
|
|
|
|
static inline void put_unaligned_u16(uint16_t *, uint16_t);
|
|
|
|
|
static inline void put_unaligned_u32(uint32_t *, uint32_t);
|
|
|
|
|
static inline void put_unaligned_u64(uint64_t *, uint64_t);
|
|
|
|
|
|
2010-11-15 15:53:00 -08:00
|
|
|
|
static inline ovs_be16 get_unaligned_be16(const ovs_be16 *);
|
|
|
|
|
static inline ovs_be32 get_unaligned_be32(const ovs_be32 *);
|
|
|
|
|
static inline ovs_be64 get_unaligned_be64(const ovs_be64 *);
|
|
|
|
|
static inline void put_unaligned_be16(ovs_be16 *, ovs_be16);
|
|
|
|
|
static inline void put_unaligned_be32(ovs_be32 *, ovs_be32);
|
|
|
|
|
static inline void put_unaligned_be64(ovs_be64 *, ovs_be64);
|
|
|
|
|
|
2014-10-08 22:13:31 -07:00
|
|
|
|
/* uint64_t get_unaligned_u64(uint64_t *p);
|
|
|
|
|
*
|
|
|
|
|
* Returns the value of the possibly misaligned uint64_t at 'p'. 'p' may
|
|
|
|
|
* actually be any type that points to a 64-bit integer. That is, on Unix-like
|
|
|
|
|
* 32-bit ABIs, it may point to an "unsigned long long int", and on Unix-like
|
|
|
|
|
* 64-bit ABIs, it may point to an "unsigned long int" or an "unsigned long
|
|
|
|
|
* long int".
|
|
|
|
|
*
|
|
|
|
|
* This is special-cased because on some Linux targets, the kernel __u64 is
|
|
|
|
|
* unsigned long long int and the userspace uint64_t is unsigned long int, so
|
|
|
|
|
* that any single function prototype would fail to accept one or the other.
|
|
|
|
|
*
|
|
|
|
|
* Below, "sizeof (*(P) % 1)" verifies that *P has an integer type, since
|
|
|
|
|
* operands to % must be integers.
|
|
|
|
|
*/
|
|
|
|
|
#define get_unaligned_u64(P) \
|
|
|
|
|
(BUILD_ASSERT(sizeof *(P) == 8), \
|
|
|
|
|
BUILD_ASSERT_GCCONLY(!TYPE_IS_SIGNED(typeof(*(P)))), \
|
|
|
|
|
(void) sizeof (*(P) % 1), \
|
|
|
|
|
get_unaligned_u64__((const uint64_t *) (P)))
|
|
|
|
|
|
2010-05-07 14:31:04 -07:00
|
|
|
|
#ifdef __GNUC__
|
|
|
|
|
/* GCC implementations. */
|
2010-11-15 15:53:00 -08:00
|
|
|
|
#define GCC_UNALIGNED_ACCESSORS(TYPE, ABBREV) \
|
|
|
|
|
struct unaligned_##ABBREV { \
|
|
|
|
|
TYPE x __attribute__((__packed__)); \
|
|
|
|
|
}; \
|
|
|
|
|
static inline struct unaligned_##ABBREV * \
|
|
|
|
|
unaligned_##ABBREV(const TYPE *p) \
|
|
|
|
|
{ \
|
|
|
|
|
return (struct unaligned_##ABBREV *) p; \
|
|
|
|
|
} \
|
|
|
|
|
\
|
|
|
|
|
static inline TYPE \
|
|
|
|
|
get_unaligned_##ABBREV(const TYPE *p) \
|
|
|
|
|
{ \
|
|
|
|
|
return unaligned_##ABBREV(p)->x; \
|
|
|
|
|
} \
|
|
|
|
|
\
|
|
|
|
|
static inline void \
|
|
|
|
|
put_unaligned_##ABBREV(TYPE *p, TYPE x) \
|
|
|
|
|
{ \
|
|
|
|
|
unaligned_##ABBREV(p)->x = x; \
|
2010-05-07 14:31:04 -07:00
|
|
|
|
}
|
|
|
|
|
|
2010-11-15 15:53:00 -08:00
|
|
|
|
GCC_UNALIGNED_ACCESSORS(uint16_t, u16);
|
|
|
|
|
GCC_UNALIGNED_ACCESSORS(uint32_t, u32);
|
dpif-linux: Fix build with certain 64-bit kernel/userspace combinations.
Unix 64-bit ABIs have two 64-bit types: "long" and "long long". Either of
these is a reasonable choice for uint64_t (the userspace type) and for
__u64 (the kernel type). Unfortunately, kernel and userspace don't
necessarily agree on the choice, and in fact the choice varies across
kernel versions and architectures.
Now that OVS is actually using kernel types in its kernel header, this
can make a difference: when __u64 and uint64_t differ, passing a pointer
to __u64 to OVS function get_unaligned_u64() yields a compiler warning
or error.
This commit fixes up the problems of this type found in OVS, by making
get_unaligned_u64() accept all 64-bit unsigned integer types, not just
whichever one happens to be uint64_t. I didn't do the same thing for
put_unaligned_u64() because it is less likely to be a problem in
practice: usually, when userspace writes to kernel data structures it
does so with copies that it knows to be aligned, so that it's not
necessary to use put_unaligned_u64().
This problem won't occur for uint8_t, uint16_t, or uint32_t, since there is
only one reasonable choice of type for each. It won't occur for ovs_be<N>
because OVS always defines those as aliases for the kernel's __be<N> types
when those are available.
This compiled cleanly for me in Scientific Linux 6.0 x86-64.
Reported-by: Pravin Shelar <pshelar@nicira.com>
2011-10-14 09:39:48 -07:00
|
|
|
|
GCC_UNALIGNED_ACCESSORS(uint64_t, u64__); /* Special case: see below. */
|
2010-11-15 15:53:00 -08:00
|
|
|
|
|
|
|
|
|
GCC_UNALIGNED_ACCESSORS(ovs_be16, be16);
|
|
|
|
|
GCC_UNALIGNED_ACCESSORS(ovs_be32, be32);
|
|
|
|
|
GCC_UNALIGNED_ACCESSORS(ovs_be64, be64);
|
2010-05-07 14:31:04 -07:00
|
|
|
|
#else
|
|
|
|
|
/* Generic implementations. */
|
|
|
|
|
|
|
|
|
|
static inline uint16_t get_unaligned_u16(const uint16_t *p_)
|
|
|
|
|
{
|
|
|
|
|
const uint8_t *p = (const uint8_t *) p_;
|
|
|
|
|
return ntohs((p[0] << 8) | p[1]);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void put_unaligned_u16(uint16_t *p_, uint16_t x_)
|
|
|
|
|
{
|
|
|
|
|
uint8_t *p = (uint8_t *) p_;
|
|
|
|
|
uint16_t x = ntohs(x_);
|
|
|
|
|
|
|
|
|
|
p[0] = x >> 8;
|
|
|
|
|
p[1] = x;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline uint32_t get_unaligned_u32(const uint32_t *p_)
|
|
|
|
|
{
|
|
|
|
|
const uint8_t *p = (const uint8_t *) p_;
|
|
|
|
|
return ntohl((p[0] << 24) | (p[1] << 16) | (p[2] << 8) | p[3]);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void put_unaligned_u32(uint32_t *p_, uint32_t x_)
|
|
|
|
|
{
|
|
|
|
|
uint8_t *p = (uint8_t *) p_;
|
|
|
|
|
uint32_t x = ntohl(x_);
|
|
|
|
|
|
|
|
|
|
p[0] = x >> 24;
|
|
|
|
|
p[1] = x >> 16;
|
|
|
|
|
p[2] = x >> 8;
|
|
|
|
|
p[3] = x;
|
|
|
|
|
}
|
|
|
|
|
|
dpif-linux: Fix build with certain 64-bit kernel/userspace combinations.
Unix 64-bit ABIs have two 64-bit types: "long" and "long long". Either of
these is a reasonable choice for uint64_t (the userspace type) and for
__u64 (the kernel type). Unfortunately, kernel and userspace don't
necessarily agree on the choice, and in fact the choice varies across
kernel versions and architectures.
Now that OVS is actually using kernel types in its kernel header, this
can make a difference: when __u64 and uint64_t differ, passing a pointer
to __u64 to OVS function get_unaligned_u64() yields a compiler warning
or error.
This commit fixes up the problems of this type found in OVS, by making
get_unaligned_u64() accept all 64-bit unsigned integer types, not just
whichever one happens to be uint64_t. I didn't do the same thing for
put_unaligned_u64() because it is less likely to be a problem in
practice: usually, when userspace writes to kernel data structures it
does so with copies that it knows to be aligned, so that it's not
necessary to use put_unaligned_u64().
This problem won't occur for uint8_t, uint16_t, or uint32_t, since there is
only one reasonable choice of type for each. It won't occur for ovs_be<N>
because OVS always defines those as aliases for the kernel's __be<N> types
when those are available.
This compiled cleanly for me in Scientific Linux 6.0 x86-64.
Reported-by: Pravin Shelar <pshelar@nicira.com>
2011-10-14 09:39:48 -07:00
|
|
|
|
static inline uint64_t get_unaligned_u64__(const uint64_t *p_)
|
2010-05-07 14:31:04 -07:00
|
|
|
|
{
|
|
|
|
|
const uint8_t *p = (const uint8_t *) p_;
|
|
|
|
|
return ntohll(((uint64_t) p[0] << 56)
|
|
|
|
|
| ((uint64_t) p[1] << 48)
|
|
|
|
|
| ((uint64_t) p[2] << 40)
|
|
|
|
|
| ((uint64_t) p[3] << 32)
|
|
|
|
|
| (p[4] << 24)
|
|
|
|
|
| (p[5] << 16)
|
|
|
|
|
| (p[6] << 8)
|
|
|
|
|
| p[7]);
|
|
|
|
|
}
|
|
|
|
|
|
dpif-linux: Fix build with certain 64-bit kernel/userspace combinations.
Unix 64-bit ABIs have two 64-bit types: "long" and "long long". Either of
these is a reasonable choice for uint64_t (the userspace type) and for
__u64 (the kernel type). Unfortunately, kernel and userspace don't
necessarily agree on the choice, and in fact the choice varies across
kernel versions and architectures.
Now that OVS is actually using kernel types in its kernel header, this
can make a difference: when __u64 and uint64_t differ, passing a pointer
to __u64 to OVS function get_unaligned_u64() yields a compiler warning
or error.
This commit fixes up the problems of this type found in OVS, by making
get_unaligned_u64() accept all 64-bit unsigned integer types, not just
whichever one happens to be uint64_t. I didn't do the same thing for
put_unaligned_u64() because it is less likely to be a problem in
practice: usually, when userspace writes to kernel data structures it
does so with copies that it knows to be aligned, so that it's not
necessary to use put_unaligned_u64().
This problem won't occur for uint8_t, uint16_t, or uint32_t, since there is
only one reasonable choice of type for each. It won't occur for ovs_be<N>
because OVS always defines those as aliases for the kernel's __be<N> types
when those are available.
This compiled cleanly for me in Scientific Linux 6.0 x86-64.
Reported-by: Pravin Shelar <pshelar@nicira.com>
2011-10-14 09:39:48 -07:00
|
|
|
|
static inline void put_unaligned_u64__(uint64_t *p_, uint64_t x_)
|
2010-05-07 14:31:04 -07:00
|
|
|
|
{
|
|
|
|
|
uint8_t *p = (uint8_t *) p_;
|
|
|
|
|
uint64_t x = ntohll(x_);
|
|
|
|
|
|
|
|
|
|
p[0] = x >> 56;
|
|
|
|
|
p[1] = x >> 48;
|
|
|
|
|
p[2] = x >> 40;
|
|
|
|
|
p[3] = x >> 32;
|
|
|
|
|
p[4] = x >> 24;
|
|
|
|
|
p[5] = x >> 16;
|
|
|
|
|
p[6] = x >> 8;
|
|
|
|
|
p[7] = x;
|
|
|
|
|
}
|
2010-11-15 15:53:00 -08:00
|
|
|
|
|
|
|
|
|
/* Only sparse cares about the difference between uint<N>_t and ovs_be<N>, and
|
|
|
|
|
* that takes the GCC branch, so there's no point in working too hard on these
|
|
|
|
|
* accessors. */
|
|
|
|
|
#define get_unaligned_be16 get_unaligned_u16
|
|
|
|
|
#define get_unaligned_be32 get_unaligned_u32
|
|
|
|
|
#define put_unaligned_be16 put_unaligned_u16
|
|
|
|
|
#define put_unaligned_be32 put_unaligned_u32
|
|
|
|
|
#define put_unaligned_be64 put_unaligned_u64
|
dpif-linux: Fix build with certain 64-bit kernel/userspace combinations.
Unix 64-bit ABIs have two 64-bit types: "long" and "long long". Either of
these is a reasonable choice for uint64_t (the userspace type) and for
__u64 (the kernel type). Unfortunately, kernel and userspace don't
necessarily agree on the choice, and in fact the choice varies across
kernel versions and architectures.
Now that OVS is actually using kernel types in its kernel header, this
can make a difference: when __u64 and uint64_t differ, passing a pointer
to __u64 to OVS function get_unaligned_u64() yields a compiler warning
or error.
This commit fixes up the problems of this type found in OVS, by making
get_unaligned_u64() accept all 64-bit unsigned integer types, not just
whichever one happens to be uint64_t. I didn't do the same thing for
put_unaligned_u64() because it is less likely to be a problem in
practice: usually, when userspace writes to kernel data structures it
does so with copies that it knows to be aligned, so that it's not
necessary to use put_unaligned_u64().
This problem won't occur for uint8_t, uint16_t, or uint32_t, since there is
only one reasonable choice of type for each. It won't occur for ovs_be<N>
because OVS always defines those as aliases for the kernel's __be<N> types
when those are available.
This compiled cleanly for me in Scientific Linux 6.0 x86-64.
Reported-by: Pravin Shelar <pshelar@nicira.com>
2011-10-14 09:39:48 -07:00
|
|
|
|
|
2014-10-08 22:13:31 -07:00
|
|
|
|
/* We do not #define get_unaligned_be64 as for the other be<N> functions above,
|
|
|
|
|
* because such a definition would mean that get_unaligned_be64() would have a
|
|
|
|
|
* different interface in each branch of the #if: with GCC it would take a
|
|
|
|
|
* "ovs_be64 *", with other compilers any pointer-to-64-bit-type (but not void
|
|
|
|
|
* *). The latter means code like "get_unaligned_be64(ofpbuf_data(b))" would
|
|
|
|
|
* work with GCC but not with other compilers, which is surprising and
|
|
|
|
|
* undesirable. Hence this wrapper function. */
|
|
|
|
|
static inline ovs_be64
|
|
|
|
|
get_unaligned_be64(const ovs_be64 *p)
|
|
|
|
|
{
|
|
|
|
|
return get_unaligned_u64(p);
|
|
|
|
|
}
|
|
|
|
|
#endif
|
dpif-linux: Fix build with certain 64-bit kernel/userspace combinations.
Unix 64-bit ABIs have two 64-bit types: "long" and "long long". Either of
these is a reasonable choice for uint64_t (the userspace type) and for
__u64 (the kernel type). Unfortunately, kernel and userspace don't
necessarily agree on the choice, and in fact the choice varies across
kernel versions and architectures.
Now that OVS is actually using kernel types in its kernel header, this
can make a difference: when __u64 and uint64_t differ, passing a pointer
to __u64 to OVS function get_unaligned_u64() yields a compiler warning
or error.
This commit fixes up the problems of this type found in OVS, by making
get_unaligned_u64() accept all 64-bit unsigned integer types, not just
whichever one happens to be uint64_t. I didn't do the same thing for
put_unaligned_u64() because it is less likely to be a problem in
practice: usually, when userspace writes to kernel data structures it
does so with copies that it knows to be aligned, so that it's not
necessary to use put_unaligned_u64().
This problem won't occur for uint8_t, uint16_t, or uint32_t, since there is
only one reasonable choice of type for each. It won't occur for ovs_be<N>
because OVS always defines those as aliases for the kernel's __be<N> types
when those are available.
This compiled cleanly for me in Scientific Linux 6.0 x86-64.
Reported-by: Pravin Shelar <pshelar@nicira.com>
2011-10-14 09:39:48 -07:00
|
|
|
|
|
|
|
|
|
/* Stores 'x' at possibly misaligned address 'p'.
|
|
|
|
|
*
|
|
|
|
|
* put_unaligned_u64() could be overloaded in the same way as
|
|
|
|
|
* get_unaligned_u64(), but so far it has not proven necessary.
|
|
|
|
|
*/
|
|
|
|
|
static inline void
|
|
|
|
|
put_unaligned_u64(uint64_t *p, uint64_t x)
|
|
|
|
|
{
|
|
|
|
|
put_unaligned_u64__(p, x);
|
|
|
|
|
}
|
2011-02-05 13:14:47 -08:00
|
|
|
|
|
packets: Do not assume that IPv4, TCP, or ARP headers are 32-bit aligned.
Ethernet headers are 14 bytes long, so when the beginning of such a header
is 32-bit aligned, the following data is misaligned. The usual trick to
fix that is to start the Ethernet header on an odd-numbered 16-bit
boundary. That trick works OK for Open vSwitch, but there are two
problems:
- OVS doesn't use that trick everywhere. Maybe it should, but it's
difficult to make sure that it does consistently because the CPUs
most commonly used with OVS don't care about misalignment, so we
only find problems when porting.
- Some protocols (GRE, VXLAN) don't use that trick, so in such a case
one can properly align the inner or outer L3/L4/L7 but not both. (OVS
userspace doesn't directly deal with such protocols yet, so this is
just future-proofing.)
- OpenFlow uses the alignment trick in a few places but not all of them.
This commit starts the adoption of what I hope will be a more robust way
to avoid misalignment problems and the resulting bus errors on RISC
architectures. Instead of trying to ensure that 32-bit quantities are
always aligned, we always read them as if they were misaligned. To ensure
that they are read this way, we change their types from 32-bit types to
pairs of 16-bit types. (I don't know of any protocols that offset the
next header by an odd number of bytes, so a 16-bit alignment assumption
seems OK.)
The same would be necessary for 64-bit types in protocol headers, but we
don't yet have any protocol definitions with 64-bit types.
IPv6 protocol headers need the same treatment, but for those we rely on
structs provided by system headers, so I'll leave them for an upcoming
patch.
Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-08-15 10:47:39 -07:00
|
|
|
|
/* Returns the value in 'x'. */
|
|
|
|
|
static inline uint32_t
|
|
|
|
|
get_16aligned_u32(const ovs_16aligned_u32 *x)
|
|
|
|
|
{
|
|
|
|
|
return ((uint32_t) x->hi << 16) | x->lo;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Stores 'value' in 'x'. */
|
|
|
|
|
static inline void
|
|
|
|
|
put_16aligned_u32(ovs_16aligned_u32 *x, uint32_t value)
|
|
|
|
|
{
|
|
|
|
|
x->hi = value >> 16;
|
|
|
|
|
x->lo = value;
|
|
|
|
|
}
|
|
|
|
|
|
2011-02-05 13:14:47 -08:00
|
|
|
|
/* Returns the value in 'x'. */
|
|
|
|
|
static inline uint64_t
|
|
|
|
|
get_32aligned_u64(const ovs_32aligned_u64 *x)
|
|
|
|
|
{
|
2012-03-23 11:43:54 -07:00
|
|
|
|
return ((uint64_t) x->hi << 32) | x->lo;
|
2011-02-05 13:14:47 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Stores 'value' in 'x'. */
|
|
|
|
|
static inline void
|
|
|
|
|
put_32aligned_u64(ovs_32aligned_u64 *x, uint64_t value)
|
|
|
|
|
{
|
2012-03-23 11:43:54 -07:00
|
|
|
|
x->hi = value >> 32;
|
|
|
|
|
x->lo = value;
|
2011-02-05 13:14:47 -08:00
|
|
|
|
}
|
|
|
|
|
|
2017-06-14 08:46:32 -07:00
|
|
|
|
/* Returns the value in 'x'. */
|
|
|
|
|
static inline ovs_u128
|
|
|
|
|
get_32aligned_u128(const ovs_32aligned_u128 *x)
|
|
|
|
|
{
|
2017-12-15 16:58:59 -08:00
|
|
|
|
ovs_u128 u;
|
|
|
|
|
u.u32[0] = x->u32[0];
|
|
|
|
|
u.u32[1] = x->u32[1];
|
|
|
|
|
u.u32[2] = x->u32[2];
|
|
|
|
|
u.u32[3] = x->u32[3];
|
2017-06-14 08:46:32 -07:00
|
|
|
|
return u;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Stores 'value' in 'x'. */
|
|
|
|
|
static inline void
|
|
|
|
|
put_32aligned_u128(ovs_32aligned_u128 *x, ovs_u128 value)
|
|
|
|
|
{
|
|
|
|
|
x->u32[0] = value.u32[0];
|
|
|
|
|
x->u32[1] = value.u32[1];
|
|
|
|
|
x->u32[2] = value.u32[2];
|
|
|
|
|
x->u32[3] = value.u32[3];
|
|
|
|
|
}
|
|
|
|
|
|
2011-05-06 12:59:51 -07:00
|
|
|
|
#ifndef __CHECKER__
|
packets: Do not assume that IPv4, TCP, or ARP headers are 32-bit aligned.
Ethernet headers are 14 bytes long, so when the beginning of such a header
is 32-bit aligned, the following data is misaligned. The usual trick to
fix that is to start the Ethernet header on an odd-numbered 16-bit
boundary. That trick works OK for Open vSwitch, but there are two
problems:
- OVS doesn't use that trick everywhere. Maybe it should, but it's
difficult to make sure that it does consistently because the CPUs
most commonly used with OVS don't care about misalignment, so we
only find problems when porting.
- Some protocols (GRE, VXLAN) don't use that trick, so in such a case
one can properly align the inner or outer L3/L4/L7 but not both. (OVS
userspace doesn't directly deal with such protocols yet, so this is
just future-proofing.)
- OpenFlow uses the alignment trick in a few places but not all of them.
This commit starts the adoption of what I hope will be a more robust way
to avoid misalignment problems and the resulting bus errors on RISC
architectures. Instead of trying to ensure that 32-bit quantities are
always aligned, we always read them as if they were misaligned. To ensure
that they are read this way, we change their types from 32-bit types to
pairs of 16-bit types. (I don't know of any protocols that offset the
next header by an odd number of bytes, so a 16-bit alignment assumption
seems OK.)
The same would be necessary for 64-bit types in protocol headers, but we
don't yet have any protocol definitions with 64-bit types.
IPv6 protocol headers need the same treatment, but for those we rely on
structs provided by system headers, so I'll leave them for an upcoming
patch.
Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-08-15 10:47:39 -07:00
|
|
|
|
/* Returns the value of 'x'. */
|
|
|
|
|
static inline ovs_be32
|
|
|
|
|
get_16aligned_be32(const ovs_16aligned_be32 *x)
|
|
|
|
|
{
|
|
|
|
|
#ifdef WORDS_BIGENDIAN
|
|
|
|
|
return ((ovs_be32) x->hi << 16) | x->lo;
|
|
|
|
|
#else
|
|
|
|
|
return ((ovs_be32) x->lo << 16) | x->hi;
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Stores network byte order 'value' into 'x'. */
|
|
|
|
|
static inline void
|
|
|
|
|
put_16aligned_be32(ovs_16aligned_be32 *x, ovs_be32 value)
|
|
|
|
|
{
|
|
|
|
|
#if WORDS_BIGENDIAN
|
|
|
|
|
x->hi = value >> 16;
|
|
|
|
|
x->lo = value;
|
|
|
|
|
#else
|
|
|
|
|
x->hi = value;
|
|
|
|
|
x->lo = value >> 16;
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
2011-02-05 13:14:47 -08:00
|
|
|
|
/* Returns the value of 'x'. */
|
|
|
|
|
static inline ovs_be64
|
|
|
|
|
get_32aligned_be64(const ovs_32aligned_be64 *x)
|
|
|
|
|
{
|
|
|
|
|
#ifdef WORDS_BIGENDIAN
|
2012-03-23 11:43:54 -07:00
|
|
|
|
return ((ovs_be64) x->hi << 32) | x->lo;
|
2011-02-05 13:14:47 -08:00
|
|
|
|
#else
|
2012-03-23 11:43:54 -07:00
|
|
|
|
return ((ovs_be64) x->lo << 32) | x->hi;
|
2011-02-05 13:14:47 -08:00
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Stores network byte order 'value' into 'x'. */
|
|
|
|
|
static inline void
|
|
|
|
|
put_32aligned_be64(ovs_32aligned_be64 *x, ovs_be64 value)
|
|
|
|
|
{
|
|
|
|
|
#if WORDS_BIGENDIAN
|
2012-03-23 11:43:54 -07:00
|
|
|
|
x->hi = value >> 32;
|
|
|
|
|
x->lo = value;
|
2011-02-05 13:14:47 -08:00
|
|
|
|
#else
|
|
|
|
|
x->hi = value;
|
|
|
|
|
x->lo = value >> 32;
|
|
|
|
|
#endif
|
|
|
|
|
}
|
2017-06-14 08:46:32 -07:00
|
|
|
|
|
|
|
|
|
/* Returns the value of 'x'. */
|
|
|
|
|
static inline ovs_be128
|
|
|
|
|
get_32aligned_be128(const ovs_32aligned_be128 *x)
|
|
|
|
|
{
|
2017-12-15 16:58:59 -08:00
|
|
|
|
ovs_be128 u;
|
|
|
|
|
u.be32[0] = x->be32[0];
|
|
|
|
|
u.be32[1] = x->be32[1];
|
|
|
|
|
u.be32[2] = x->be32[2];
|
|
|
|
|
u.be32[3] = x->be32[3];
|
2017-06-14 08:46:32 -07:00
|
|
|
|
return u;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Stores network byte order 'value' into 'x'. */
|
|
|
|
|
static inline void
|
|
|
|
|
put_32aligned_be128(ovs_32aligned_be128 *x, ovs_be128 value)
|
|
|
|
|
{
|
|
|
|
|
x->be32[0] = value.be32[0];
|
|
|
|
|
x->be32[1] = value.be32[1];
|
|
|
|
|
x->be32[2] = value.be32[2];
|
|
|
|
|
x->be32[3] = value.be32[3];
|
|
|
|
|
}
|
2011-05-06 12:59:51 -07:00
|
|
|
|
#else /* __CHECKER__ */
|
|
|
|
|
/* Making sparse happy with these functions also makes them unreadable, so
|
|
|
|
|
* don't bother to show it their implementations. */
|
packets: Do not assume that IPv4, TCP, or ARP headers are 32-bit aligned.
Ethernet headers are 14 bytes long, so when the beginning of such a header
is 32-bit aligned, the following data is misaligned. The usual trick to
fix that is to start the Ethernet header on an odd-numbered 16-bit
boundary. That trick works OK for Open vSwitch, but there are two
problems:
- OVS doesn't use that trick everywhere. Maybe it should, but it's
difficult to make sure that it does consistently because the CPUs
most commonly used with OVS don't care about misalignment, so we
only find problems when porting.
- Some protocols (GRE, VXLAN) don't use that trick, so in such a case
one can properly align the inner or outer L3/L4/L7 but not both. (OVS
userspace doesn't directly deal with such protocols yet, so this is
just future-proofing.)
- OpenFlow uses the alignment trick in a few places but not all of them.
This commit starts the adoption of what I hope will be a more robust way
to avoid misalignment problems and the resulting bus errors on RISC
architectures. Instead of trying to ensure that 32-bit quantities are
always aligned, we always read them as if they were misaligned. To ensure
that they are read this way, we change their types from 32-bit types to
pairs of 16-bit types. (I don't know of any protocols that offset the
next header by an odd number of bytes, so a 16-bit alignment assumption
seems OK.)
The same would be necessary for 64-bit types in protocol headers, but we
don't yet have any protocol definitions with 64-bit types.
IPv6 protocol headers need the same treatment, but for those we rely on
structs provided by system headers, so I'll leave them for an upcoming
patch.
Signed-off-by: Ben Pfaff <blp@nicira.com>
2013-08-15 10:47:39 -07:00
|
|
|
|
ovs_be32 get_16aligned_be32(const ovs_16aligned_be32 *);
|
|
|
|
|
void put_16aligned_be32(ovs_16aligned_be32 *, ovs_be32);
|
2011-05-06 12:59:51 -07:00
|
|
|
|
ovs_be64 get_32aligned_be64(const ovs_32aligned_be64 *);
|
|
|
|
|
void put_32aligned_be64(ovs_32aligned_be64 *, ovs_be64);
|
2017-06-14 08:46:32 -07:00
|
|
|
|
ovs_be128 get_32aligned_be128(const ovs_32aligned_be128 *);
|
|
|
|
|
void put_32aligned_be128(ovs_32aligned_be128 *, ovs_be128);
|
2011-05-06 12:59:51 -07:00
|
|
|
|
#endif
|
2010-05-07 14:31:04 -07:00
|
|
|
|
|
|
|
|
|
#endif /* unaligned.h */
|