]> git.baikalelectronics.ru Git - kernel.git/commit
net, neigh: Extend neigh->flags to 32 bit to allow for extensions
authorRoopa Prabhu <roopa@nvidia.com>
Mon, 11 Oct 2021 12:12:37 +0000 (14:12 +0200)
committerDavid S. Miller <davem@davemloft.net>
Tue, 12 Oct 2021 10:27:47 +0000 (11:27 +0100)
commit2c611ad97a82b51221bb0920cc6cac0b1d4c0e52
tree448e0188773ea9e764a1fa625890e8edaf77b652
parent3dc20f4762c62d3b3f0940644881ed818aa7b2f5
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>
include/net/neighbour.h
include/uapi/linux/neighbour.h
net/core/neighbour.c