>> > Its not enough to just look at the paths where outq_tail is called, because > the outq_tail function is checking a state variable that can update > asynchronously in the side effect processing queue. Look at any one of the > timer functions. Those all fire asynchronous to the outq list, but they all Fortunately, sctp_do_sm is protected by lock_sock. I just checked all the sctp_do_sm calling in timer functions. ------------ bh_lock_sock(sk); if (sock_owned_by_user(sk)) { <----------- [1] pr_debug("%s: sock is busy\n", __func__); /* Try again later. */ mod_timer() goto out_unlock; } error = sctp_do_sm(net, SCTP_EVENT_T_TIMEOUT, out_unlock: bh_unlock_sock(sk); which means sctp_do_sm is *non-reenterable* because of sock lock's protection. even if it's interrupted by something like timers, they have to delay their real process until sock lock is released. So It's still safe here. pls double-check. -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html