netdev - Re: [2.6.36-rc5] INET?: possible irq lock inversion dependency

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1285176935.2639.453.camel@edumazet-laptop>
Date:	Wed, 22 Sep 2010 19:35:35 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:	linux-fsdevel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [2.6.36-rc5] INET?: possible irq lock inversion dependency

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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html