> Just for the case of responding to CONN_MANAGER messages, testing > socket owner is safe. But the solution seems unsafe when > TIPC_ERR_OVERLOAD message is sent. > > While TIPC_ERR_OVERLOAD is sent out under BH context, socket's owner is set.
Where? There are two locations where tipc_sk_respond() may be sent under BH, in tipc_sk_enqueue() and filter_rcv(), but it is either-or: either we are under BH, and socket is not owned, or it is owned, and we are not under BH. I don't see at all what you are referring to. [Ying] let's look at the following code again: ================= static void tipc_sk_enqueue(struct sk_buff_head *inputq, struct sock *sk, u32 dport) { unsigned int lim; atomic_t *dcnt; struct sk_buff *skb; unsigned long time_limit = jiffies + 2; while (skb_queue_len(inputq)) { if (unlikely(time_after_eq(jiffies, time_limit))) return; skb = tipc_skb_dequeue(inputq, dport); if (unlikely(!skb)) return; /* Add message directly to receive queue if possible */ if (!sock_owned_by_user(sk)) {---------------------------------------------->(*1) filter_rcv(sk, skb); continue; } /* Try backlog, compensating for double-counted bytes */ dcnt = &tipc_sk(sk)->dupl_rcvcnt; if (!sk->sk_backlog.len) atomic_set(dcnt, 0); lim = rcvbuf_limit(sk, skb) + atomic_read(dcnt); if (likely(!sk_add_backlog(sk, skb, lim))) continue; /* Overload => reject message back to sender */ tipc_sk_respond(sk, skb, TIPC_ERR_OVERLOAD);-------------------------(*2) break; } } =================== Firstly we assume that tipc_sk_enqueue() is called under BH now. At place (*1), all skb messages will be fed to filter_rcv() if socket's owner is not set. When code is executed to place (*2), socket's owner is absolutely set, and now we still stay BH context. That's why I say we still face deadlock risk in this scenario when tipc_sk_respond(sk, skb, TIPC_ERR_OVERLOAD) is invoked. Regards, Ying ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381 _______________________________________________ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion