• J
    tipc: resolve race problem at unicast message reception · c637c103
    Jon Paul Maloy 提交于
    TIPC handles message cardinality and sequencing at the link layer,
    before passing messages upwards to the destination sockets. During the
    upcall from link to socket no locks are held. It is therefore possible,
    and we see it happen occasionally, that messages arriving in different
    threads and delivered in sequence still bypass each other before they
    reach the destination socket. This must not happen, since it violates
    the sequentiality guarantee.
    
    We solve this by adding a new input buffer queue to the link structure.
    Arriving messages are added safely to the tail of that queue by the
    link, while the head of the queue is consumed, also safely, by the
    receiving socket. Sequentiality is secured per socket by only allowing
    buffers to be dequeued inside the socket lock. Since there may be multiple
    simultaneous readers of the queue, we use a 'filter' parameter to reduce
    the risk that they peek the same buffer from the queue, hence also
    reducing the risk of contention on the receiving socket locks.
    
    This solves the sequentiality problem, and seems to cause no measurable
    performance degradation.
    
    A nice side effect of this change is that lock handling in the functions
    tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
    will enable future simplifications of those functions.
    Reviewed-by: NYing Xue <ying.xue@windriver.com>
    Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
    Signed-off-by: NDavid S. Miller <davem@davemloft.net>
    c637c103
name_distr.c 11.6 KB