Skip to content
  • Herbert Xu's avatar
    cls_cgroup: Store classid in struct sock · f8451725
    Herbert Xu authored
    
    
    Up until now cls_cgroup has relied on fetching the classid out of
    the current executing thread.  This runs into trouble when a packet
    processing is delayed in which case it may execute out of another
    thread's context.
    
    Furthermore, even when a packet is not delayed we may fail to
    classify it if soft IRQs have been disabled, because this scenario
    is indistinguishable from one where a packet unrelated to the
    current thread is processed by a real soft IRQ.
    
    In fact, the current semantics is inherently broken, as a single
    skb may be constructed out of the writes of two different tasks.
    A different manifestation of this problem is when the TCP stack
    transmits in response of an incoming ACK.  This is currently
    unclassified.
    
    As we already have a concept of packet ownership for accounting
    purposes in the skb->sk pointer, this is a natural place to store
    the classid in a persistent manner.
    
    This patch adds the cls_cgroup classid in struct sock, filling up
    an existing hole on 64-bit :)
    
    The value is set at socket creation time.  So all sockets created
    via socket(2) automatically gains the ID of the thread creating it.
    Whenever another process touches the socket by either reading or
    writing to it, we will change the socket classid to that of the
    process if it has a valid (non-zero) classid.
    
    For sockets created on inbound connections through accept(2), we
    inherit the classid of the original listening socket through
    sk_clone, possibly preceding the actual accept(2) call.
    
    In order to minimise risks, I have not made this the authoritative
    classid.  For now it is only used as a backup when we execute
    with soft IRQs disabled.  Once we're completely happy with its
    semantics we can use it as the sole classid.
    
    Footnote: I have rearranged the error path on cls_group module
    creation.  If we didn't do this, then there is a window where
    someone could create a tc rule using cls_group before the cgroup
    subsystem has been registered.
    
    Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    f8451725