All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chan-yeol Park <chanyeol.park@gmail.com>
To: Gustavo Padovan <gustavo@padovan.org>
Cc: linux-bluetooth <linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH] Bluetooth: Fix possible deadlock in SCO code
Date: Wed, 28 Nov 2012 23:35:33 +0900	[thread overview]
Message-ID: <50B62135.7080507@gmail.com> (raw)
In-Reply-To: <1339738863-6407-1-git-send-email-gustavo@padovan.org>

Hi Gustavo

If we use the below patch, we face crash or circular locking dependency 
detected.
*It's very easily reproduced(about 100%)

I guess once sco_sock_shutdown() is called,"sk" would be destructed.
but due to response from remote side, sco_disconn_cfm(),sco_conn_del() 
would be called in order.
and finally in sco_conn_del() crash or circular locking dependency is 
happened.
because it access "sk" that is already destructed.

I think in sco_chan_del(), based on conn info, the relation between sk 
and conn should be cleaned
like the original code before you commit.

[  104.889622] Bluetooth: [sco_sock_shutdown] sock e8856000, sk eb695000
[  104.894666] Bluetooth: [sco_sock_clear_timer] sock eb695000 state 1
[  104.900869] Bluetooth: [__sco_sock_close] sk eb695000 state 1 socket 
e8856000
[  104.907976] Bluetooth: [sco_sock_set_timer] sock eb695000 state 8 
timeout 400
[  104.915106] Bluetooth: [sco_sock_release] sock e8856000, sk eb695000
[  104.921439] Bluetooth: [sco_sock_clear_timer] sock eb695000 state 8
[  104.927875] Bluetooth: [__sco_sock_close] sk eb695000 state 8 socket 
e8856000
[  104.938762] Bluetooth: [sco_chan_del] sk eb695000, conn ed38da60, err 104
[  104.956861] Bluetooth: [sco_sock_kill] sk eb695000 state 9
[  104.962321] Bluetooth: [sco_sock_destruct] sk eb695000
[  105.071125] Bluetooth: [sco_disconn_cfm] hcon ed376000 reason 22
[  105.075875] Bluetooth: [sco_conn_del] hcon ed376000 conn ed38da60, 
err 103
[  105.082848] Bluetooth: [sco_conn_del] before bh_lock_sock () sk eb695000

Could you give me your opinion?

regards
chanyeol

On 06/15/2012 02:41 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>
> sco_chan_del() only has conn != NULL when called from sco_conn_del() so
> just move the code from it that deal with conn to sco_conn_del().
>
> [  120.765529]
> [  120.765529] ======================================================
> [  120.766529] [ INFO: possible circular locking dependency detected ]
> [  120.766529] 3.5.0-rc1-10292-g3701f94-dirty #70 Tainted: G        W
> [  120.766529] -------------------------------------------------------
> [  120.766529] kworker/u:3/1497 is trying to acquire lock:
> [  120.766529]  (&(&conn->lock)->rlock#2){+.+...}, at:
> [<ffffffffa00b7ecc>] sco_chan_del+0x4c/0x170 [bluetooth]
> [  120.766529]
> [  120.766529] but task is already holding lock:
> [  120.766529]  (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}, at:
> [<ffffffffa00b8401>] sco_conn_del+0x61/0xe0 [bluetooth]
> [  120.766529]
> [  120.766529] which lock already depends on the new lock.
> [  120.766529]
> [  120.766529]
> [  120.766529] the existing dependency chain (in reverse order) is:
> [  120.766529]
> [  120.766529] -> #1 (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}:
> [  120.766529]        [<ffffffff8107980e>] lock_acquire+0x8e/0xb0
> [  120.766529]        [<ffffffff813c19e0>] _raw_spin_lock+0x40/0x80
> [  120.766529]        [<ffffffffa00b85e9>] sco_connect_cfm+0x79/0x300
> [bluetooth]
> [  120.766529]        [<ffffffffa0094b13>]
> hci_sync_conn_complete_evt.isra.90+0x343/0x400 [bluetooth]
> [  120.766529]        [<ffffffffa009d447>] hci_event_packet+0x317/0xfb0
> [bluetooth]
> [  120.766529]        [<ffffffffa008aa68>] hci_rx_work+0x2c8/0x890
> [bluetooth]
> [  120.766529]        [<ffffffff81047db7>] process_one_work+0x197/0x460
> [  120.766529]        [<ffffffff810489d6>] worker_thread+0x126/0x2d0
> [  120.766529]        [<ffffffff8104ee4d>] kthread+0x9d/0xb0
> [  120.766529]        [<ffffffff813c4294>] kernel_thread_helper+0x4/0x10
> [  120.766529]
> [  120.766529] -> #0 (&(&conn->lock)->rlock#2){+.+...}:
> [  120.766529]        [<ffffffff81078a8a>] __lock_acquire+0x154a/0x1d30
> [  120.766529]        [<ffffffff8107980e>] lock_acquire+0x8e/0xb0
> [  120.766529]        [<ffffffff813c19e0>] _raw_spin_lock+0x40/0x80
> [  120.766529]        [<ffffffffa00b7ecc>] sco_chan_del+0x4c/0x170
> [bluetooth]
> [  120.766529]        [<ffffffffa00b8414>] sco_conn_del+0x74/0xe0
> [bluetooth]
> [  120.766529]        [<ffffffffa00b88a2>] sco_disconn_cfm+0x32/0x60
> [bluetooth]
> [  120.766529]        [<ffffffffa0093a82>]
> hci_disconn_complete_evt.isra.53+0x242/0x390 [bluetooth]
> [  120.766529]        [<ffffffffa009d747>] hci_event_packet+0x617/0xfb0
> [bluetooth]
> [  120.766529]        [<ffffffffa008aa68>] hci_rx_work+0x2c8/0x890
> [bluetooth]
> [  120.766529]        [<ffffffff81047db7>] process_one_work+0x197/0x460
> [  120.766529]        [<ffffffff810489d6>] worker_thread+0x126/0x2d0
> [  120.766529]        [<ffffffff8104ee4d>] kthread+0x9d/0xb0
> [  120.766529]        [<ffffffff813c4294>] kernel_thread_helper+0x4/0x10
> [  120.766529]
> [  120.766529] other info that might help us debug this:
> [  120.766529]
> [  120.766529]  Possible unsafe locking scenario:
> [  120.766529]
> [  120.766529]        CPU0                    CPU1
> [  120.766529]        ----                    ----
> [  120.766529]   lock(slock-AF_BLUETOOTH-BTPROTO_SCO);
> [  120.766529]
> lock(&(&conn->lock)->rlock#2);
> [  120.766529]
> lock(slock-AF_BLUETOOTH-BTPROTO_SCO);
> [  120.766529]   lock(&(&conn->lock)->rlock#2);
> [  120.766529]
> [  120.766529]  *** DEADLOCK ***
>
> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> ---
>   net/bluetooth/sco.c |   19 +++++++++----------
>   1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
> index cbdd313..596fdc8 100644
> --- a/net/bluetooth/sco.c
> +++ b/net/bluetooth/sco.c
> @@ -149,6 +149,15 @@ static int sco_conn_del(struct hci_conn *hcon, int err)
>   		sco_sock_clear_timer(sk);
>   		sco_chan_del(sk, err);
>   		bh_unlock_sock(sk);
> +
> +		sco_conn_lock(conn);
> +		conn->sk = NULL;
> +		sco_pi(sk)->conn = NULL;
> +		sco_conn_unlock(conn);
> +
> +		if (conn->hcon)
> +			hci_conn_put(conn->hcon);
> +
>   		sco_sock_kill(sk);
>   	}
>   
> @@ -838,16 +847,6 @@ static void sco_chan_del(struct sock *sk, int err)
>   
>   	BT_DBG("sk %p, conn %p, err %d", sk, conn, err);
>   
> -	if (conn) {
> -		sco_conn_lock(conn);
> -		conn->sk = NULL;
> -		sco_pi(sk)->conn = NULL;
> -		sco_conn_unlock(conn);
> -
> -		if (conn->hcon)
> -			hci_conn_put(conn->hcon);
> -	}
> -
>   	sk->sk_state = BT_CLOSED;
>   	sk->sk_err   = err;
>   	sk->sk_state_change(sk);


  reply	other threads:[~2012-11-28 14:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-15  5:41 [PATCH] Bluetooth: Fix possible deadlock in SCO code Gustavo Padovan
2012-11-28 14:35 ` Chan-yeol Park [this message]
2012-12-03 17:40   ` Gustavo Padovan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50B62135.7080507@gmail.com \
    --to=chanyeol.park@gmail.com \
    --cc=gustavo@padovan.org \
    --cc=linux-bluetooth@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.