> 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
