]> 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)
commit68c6f2d503d17e00f4f6ef57e9d741d6623091ef
tree448e0188773ea9e764a1fa625890e8edaf77b652
parentc03bb6fd00929f3cabe5a48b5572dac38bcbded0
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 91aa354ae577 ("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