Skip to content
  • Tuong Lien's avatar
    tipc: add trace_events for tipc socket · 01e661eb
    Tuong Lien authored
    
    
    The commit adds the new trace_events for TIPC socket object:
    
    trace_tipc_sk_create()
    trace_tipc_sk_poll()
    trace_tipc_sk_sendmsg()
    trace_tipc_sk_sendmcast()
    trace_tipc_sk_sendstream()
    trace_tipc_sk_filter_rcv()
    trace_tipc_sk_advance_rx()
    trace_tipc_sk_rej_msg()
    trace_tipc_sk_drop_msg()
    trace_tipc_sk_release()
    trace_tipc_sk_shutdown()
    trace_tipc_sk_overlimit1()
    trace_tipc_sk_overlimit2()
    
    Also, enables the traces for the following cases:
    - When user creates a TIPC socket;
    - When user calls poll() on TIPC socket;
    - When user sends a dgram/mcast/stream message.
    - When a message is put into the socket 'sk_receive_queue';
    - When a message is released from the socket 'sk_receive_queue';
    - When a message is rejected (e.g. due to no port, invalid, etc.);
    - When a message is dropped (e.g. due to wrong message type);
    - When socket is released;
    - When socket is shutdown;
    - When socket rcvq's allocation is overlimit (> 90%);
    - When socket rcvq + bklq's allocation is overlimit (> 90%);
    - When the 'TIPC_ERR_OVERLOAD/2' issue happens;
    
    Note:
    a) All the socket traces are designed to be able to trace on a specific
    socket by either using the 'event filtering' feature on a known socket
    'portid' value or the sysctl file:
    
    /proc/sys/net/tipc/sk_filter
    
    The file determines a 'tuple' for what socket should be traced:
    
    (portid, sock type, name type, name lower, name upper)
    
    where:
    + 'portid' is the socket portid generated at socket creating, can be
    found in the trace outputs or the 'tipc socket list' command printouts;
    + 'sock type' is the socket type (1 = SOCK_TREAM, ...);
    + 'name type', 'name lower' and 'name upper' are the service name being
    connected to or published by the socket.
    
    Value '0' means 'ANY', the default tuple value is (0, 0, 0, 0, 0) i.e.
    the traces happen for every sockets with no filter.
    
    b) The 'tipc_sk_overlimit1/2' event is also a conditional trace_event
    which happens when the socket receive queue (and backlog queue) is
    about to be overloaded, when the queue allocation is > 90%. Then, when
    the trace is enabled, the last skbs leading to the TIPC_ERR_OVERLOAD/2
    issue can be traced.
    
    The trace event is designed as an 'upper watermark' notification that
    the other traces (e.g. 'tipc_sk_advance_rx' vs 'tipc_sk_filter_rcv') or
    actions can be triggerred in the meanwhile to see what is going on with
    the socket queue.
    
    In addition, the 'trace_tipc_sk_dump()' is also placed at the
    'TIPC_ERR_OVERLOAD/2' case, so the socket and last skb can be dumped
    for post-analysis.
    
    Acked-by: default avatarYing Xue <ying.xue@windriver.com>
    Tested-by: default avatarYing Xue <ying.xue@windriver.com>
    Acked-by: default avatarJon Maloy <jon.maloy@ericsson.com>
    Signed-off-by: default avatarTuong Lien <tuong.t.lien@dektech.com.au>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    01e661eb