[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48685019.90706@cn.fujitsu.com>
Date: Mon, 30 Jun 2008 11:16:41 +0800
From: Gui Jianfeng <guijianfeng@...fujitsu.com>
To: David Miller <davem@...emloft.net>
CC: netdev@...r.kernel.org
Subject: Re: [PATCH] Prevent from potential dead lock for inet_listen_lock
David Miller wrote:
> From: Gui Jianfeng <guijianfeng@...fujitsu.com>
> Date: Fri, 20 Jun 2008 17:08:20 +0800
>
>> hashinfo->lhash_lock might be acquired by write_lock() in softirq,
>
> How?
How about the following call trace.
dccp_v4_rcv
-> sk_receive_skb(sk, skb, 1);
-> sk->sk_backlog_rcv(sk, skb);(dccp_v4_do_rcv)
-> dccp_rcv_state_process()
-> dccp_rcv_request_sent_state_process(sk, skb, dh, len);
-> icsk->icsk_af_ops->rebuild_header(sk); (inet_sk_rebuild_header)
-> inet_sk_reselect_saddr(sk))
-> __sk_prot_rehash(sk);
-> sk->sk_prot->hash(sk);
-> inet_hash(struct sock *sk)
-> __inet_hash(struct sock *sk)
-> inet_listen_wlock(hashinfo);
-> write_lock(&hashinfo->lhash_lock);
>
>> so using read_lock() here isn't safe, just substitudes by read_lock_bh().
>>
>> Signed-off-by: Gui Jianfeng <guijianfeng@...fujitsu.com>
>
> I don't think this is necessary.
>
> The only place the write lock is obtained, is via
> the ->hash() and ->unhash() sk_prot operation methods.
>
> And for listening sockets that only occurs in normal base
> context. Never from softirqs.
>
> If there is a patch from softirqs where this can occur,
> that is a bug and must be fixed.
>
>
>
--
Regards
Gui Jianfeng
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists