Le mercredi 22 septembre 2010 Ã 17:58 +0900, Tetsuo Handa a Ãcrit : > > Updated and booted/tested patch : > > The warning by test.sh disappeared by your patch. > But the warning which I encounter upon reboot still appears. > FYI, > > # cat /etc/exports > /usr/src/ *(rw,no_root_squash,async) > > # grep nfs /proc/mounts > 127.0.0.1:/usr/src/ /mnt nfs rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=udp,port=65535,timeo=7,retrans=3,sec=sys,addr=127.0.0.1 0 0 > > test.sh does not trigger this warning on 2.6.34.7 and > triggers this warning on 2.6.35.5 . > Thanks ! We have for each socket : One spinlock (sk_slock.slock) One rwlock (sk_callback_lock) It is legal to use : A) (this is used in net/sunrpc/xprtsock.c) read_lock(&sk->sk_callback_lock) (without blocking BH) <BH> spin_lock(&sk->sk_slock.slock); ... read_lock(&sk->sk_callback_lock); ... Its also legal to do B) write_lock_bh(&sk->sk_callback_lock) stuff write_unlock_bh(&sk->sk_callback_lock) But if we have a path that : C) spin_lock_bh(&sk->sk_slock) ... write_lock_bh(&sk->sk_callback_lock) stuff write_unlock_bh(&sk->sk_callback_lock) Then we can have a deadlock with A) CPU1 [A] CPU2 [C] read_lock(&sk->sk_callback_lock) <BH> spin_lock_bh(&sk->sk_slock) <wait to spin_lock(slock)> <wait to write_lock_bh(callback_lock)> We have one such path C) in inet_csk_listen_stop() : local_bh_disable(); bh_lock_sock(child); // spin_lock_bh(&sk->sk_slock) WARN_ON(sock_owned_by_user(child)); ... sock_orphan(child); // write_lock_bh(&sk->sk_callback_lock) This is a false positive because its not possible that this particular deadlock can occur, since inet_csk_listen_stop() manipulates half sockets (not yet given to a listener) Give me a moment to think about it and write a fix. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
