• Petr Machata's avatar
    mlxsw: spectrum_router: Link CRIFs to RIFs · aa21242b
    Petr Machata authored
    When a RIF is about to be created, the registration of the netdevice that
    it should be associated with must have been seen in the past, and a CRIF
    created. Therefore make this a hard requirement by looking up the CRIF
    during RIF creation, and complaining loudly when there isn't one.
    
    This then allows to keep a link between a RIF and its corresponding
    CRIF (and back, as the relationship is one-to-at-most-one), which do.
    
    The CRIF will later be useful as the objects tracked there will be
    offloaded lazily as a result of RIF creation.
    
    CRIFs are created when an "interesting" netdevice is registered, and
    destroyed after such device is unregistered. CRIFs are supposed to already
    exist when a RIF creation request arises, and exist at least as long as
    that RIF exists. This makes for a simple invariant: it is always safe to
    dereference CRIF pointer from "its" RIF.
    
    To guarantee this, CRIFs cannot be removed immediately when the UNREGISTER
    event is delivered. The reason is that if a RIF's netdevices has an IPv6
    address, removal of this address is notified in an atomic block. To remove
    the RIF, the IPv6 removal handler schedules a work item. It must be safe
    for this work item to access the associated CRIF as well.
    
    Thus when a netdevice that backs the CRIF is removed, if it still has a
    RIF, do not actually free the CRIF, only toggle its can_destroy flag, which
    this patch adds. Later on, mlxsw_sp_rif_destroy() collects the CRIF.
    Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
    Reviewed-by: default avatarDanielle Ratson <danieller@nvidia.com>
    Link: https://lore.kernel.org/r/68c8e33afa6b8c03c431b435e1685ffdff752e63.1687438411.git.petrm@nvidia.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
    aa21242b
spectrum_router.c 296 KB