Re: [PATCH] Prevent from potential dead lock for inet_listen_lock

[Gui Jianfeng <guijianfeng@cn.fujitsu.com>]

David Miller wrote:
> From: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
> Date: Mon, 30 Jun 2008 11:16:41 +0800
> 
>>   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);
> 
> You're not answering my question.
> 
> I'll ask my question one more time.
> 
> How can this happen for a LISTENING SOCKET?  Ie. with
> sk_state == TCP_LISTEN.
> 
> Only listening sockets go into inet_listen_wlock().
> 
> This DCCP call trace you're showing sets the sk_state to DCCP_PARTOPEN
> right before that ->rebuild_header() call. (DCCP_PARTOPEN is defined
> to be equal to TCP_MAX_STATES in include/linux/dccp.h)
> 
> So this call chain is absolutely impossible.
> 
> We specifically forbid listening sockets from calling hash or unhash
> in BH context.  And this is exactly what makes the locking legal.
> 
> You had to have a reason for writing this patch.  You saw something,
> either a deadlock or a lockdep trace.  My theory is that you saw
> lockdep triggered erroneously because it can't see what prevents BH
> contexts from invoking inet_listen_wlock().
> 
> Or did you just write this patch in response to pure code reading?

  I think you are right. I read the code, and thought it might have
  deadlock problem. I'm very sorry for my mistake. 
  Please ignore this patch.