diff options
author | Roopa Prabhu <roopa@nvidia.com> | 2021-10-11 14:12:37 +0200 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2021-10-12 11:27:47 +0100 |
commit | 2c611ad97a82b51221bb0920cc6cac0b1d4c0e52 (patch) | |
tree | 448e0188773ea9e764a1fa625890e8edaf77b652 /mm | |
parent | 3dc20f4762c62d3b3f0940644881ed818aa7b2f5 (diff) | |
download | linux-2c611ad97a82b51221bb0920cc6cac0b1d4c0e52.tar.gz linux-2c611ad97a82b51221bb0920cc6cac0b1d4c0e52.tar.bz2 linux-2c611ad97a82b51221bb0920cc6cac0b1d4c0e52.zip |
net, neigh: Extend neigh->flags to 32 bit to allow for extensions
Currently, all bits in struct ndmsg's ndm_flags are used up with the most
recent addition of 435f2e7cc0b7 ("net: bridge: add support for sticky fdb
entries"). This makes it impossible to extend the neighboring subsystem
with new NTF_* flags:
struct ndmsg {
__u8 ndm_family;
__u8 ndm_pad1;
__u16 ndm_pad2;
__s32 ndm_ifindex;
__u16 ndm_state;
__u8 ndm_flags;
__u8 ndm_type;
};
There are ndm_pad{1,2} attributes which are not used. However, due to
uncareful design, the kernel does not enforce them to be zero upon new
neighbor entry addition, and given they've been around forever, it is
not possible to reuse them today due to risk of breakage. One option to
overcome this limitation is to add a new NDA_FLAGS_EXT attribute for
extended flags.
In struct neighbour, there is a 3 byte hole between protocol and ha_lock,
which allows neigh->flags to be extended from 8 to 32 bits while still
being on the same cacheline as before. This also allows for all future
NTF_* flags being in neigh->flags rather than yet another flags field.
Unknown flags in NDA_FLAGS_EXT will be rejected by the kernel.
Co-developed-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'mm')
0 files changed, 0 insertions, 0 deletions