diff options
author | 2019-01-26 21:12:19 +0100 | |
---|---|---|
committer | 2019-01-27 23:11:55 -0800 | |
commit | 50c2936634bcb1db78a8ca63249236810c11a80f (patch) | |
tree | e9e56ffd071a94a61c735de61a42ff749ca06dde /tools/perf/scripts/python/export-to-postgresql.py | |
parent | net: stmmac: dwmac-rk: fix error handling in rk_gmac_powerup() (diff) | |
download | linux-dev-50c2936634bcb1db78a8ca63249236810c11a80f.tar.xz linux-dev-50c2936634bcb1db78a8ca63249236810c11a80f.zip |
decnet: fix DN_IFREQ_SIZE
Digging through the ioctls with Al because of the previous
patches, we found that on 64-bit decnet's dn_dev_ioctl()
is wrong, because struct ifreq::ifr_ifru is actually 24
bytes (not 16 as expected from struct sockaddr) due to the
ifru_map and ifru_settings members.
Clearly, decnet expects the ioctl to be called with a struct
like
struct ifreq_dn {
char ifr_name[IFNAMSIZ];
struct sockaddr_dn ifr_addr;
};
since it does
struct ifreq *ifr = ...;
struct sockaddr_dn *sdn = (struct sockaddr_dn *)&ifr->ifr_addr;
This means that DN_IFREQ_SIZE is too big for what it wants on
64-bit, as it is
sizeof(struct ifreq) - sizeof(struct sockaddr) +
sizeof(struct sockaddr_dn)
This assumes that sizeof(struct sockaddr) is the size of ifr_ifru
but that isn't true.
Fix this to use offsetof(struct ifreq, ifr_ifru).
This indeed doesn't really matter much - the result is that we
copy in/out 8 bytes more than we should on 64-bit platforms. In
case the "struct ifreq_dn" lands just on the end of a page though
it might lead to faults.
As far as I can tell, it has been like this forever, so it seems
very likely that nobody cares.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions