From: Gustavo Padovan <gustavo@padovan.org>
To: Andre Guedes <andre.guedes@openbossa.org>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH 5/5] Bluetooth: Reduce critical section in sco_conn_ready
Date: Wed, 30 Jan 2013 17:31:46 -0200 [thread overview]
Message-ID: <20130130193146.GA31386@joana> (raw)
In-Reply-To: <1359500396-8184-5-git-send-email-andre.guedes@openbossa.org>
Hi Andre,
* Andre Guedes <andre.guedes@openbossa.org> [2013-01-29 19:59:56 -0300]:
> This patch reduces the critical section protected by sco_conn_lock in
> sco_conn_ready function. The lock is acquired only when it is really
> needed.
>
> This patch fixes the following lockdep warning which is generated
> when the host terminates a SCO connection.
>
> Today, this warning is a false positive. There is no way those
> two threads reported by lockdep are running at the same time since
> hdev->workqueue (where rx_work is queued) is single-thread. However,
> if somehow this behavior is changed in future, we will have a
> potential deadlock.
>
> ======================================================
> [ INFO: possible circular locking dependency detected ]
> 3.8.0-rc1+ #7 Not tainted
> -------------------------------------------------------
> kworker/u:1H/1018 is trying to acquire lock:
> (&(&conn->lock)->rlock){+.+...}, at: [<ffffffffa0033ba6>] sco_chan_del+0x66/0x190 [bluetooth]
>
> but task is already holding lock:
> (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}, at: [<ffffffffa0033d5a>] sco_conn_del+0x8a/0xe0 [bluetooth]
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}:
> [<ffffffff81083011>] lock_acquire+0xb1/0xe0
> [<ffffffff813efd01>] _raw_spin_lock+0x41/0x80
> [<ffffffffa003436e>] sco_connect_cfm+0xbe/0x350 [bluetooth]
> [<ffffffffa0015d6c>] hci_event_packet+0xd3c/0x29b0 [bluetooth]
> [<ffffffffa0004583>] hci_rx_work+0x133/0x870 [bluetooth]
> [<ffffffff8104d65f>] process_one_work+0x2bf/0x4f0
> [<ffffffff81050022>] worker_thread+0x2b2/0x3e0
> [<ffffffff81056021>] kthread+0xd1/0xe0
> [<ffffffff813f14bc>] ret_from_fork+0x7c/0xb0
>
> -> #0 (&(&conn->lock)->rlock){+.+...}:
> [<ffffffff81082215>] __lock_acquire+0x1465/0x1c70
> [<ffffffff81083011>] lock_acquire+0xb1/0xe0
> [<ffffffff813efd01>] _raw_spin_lock+0x41/0x80
> [<ffffffffa0033ba6>] sco_chan_del+0x66/0x190 [bluetooth]
> [<ffffffffa0033d6d>] sco_conn_del+0x9d/0xe0 [bluetooth]
> [<ffffffffa0034653>] sco_disconn_cfm+0x53/0x60 [bluetooth]
> [<ffffffffa000fef3>] hci_disconn_complete_evt.isra.54+0x363/0x3c0 [bluetooth]
> [<ffffffffa00150f7>] hci_event_packet+0xc7/0x29b0 [bluetooth]
> [<ffffffffa0004583>] hci_rx_work+0x133/0x870 [bluetooth]
> [<ffffffff8104d65f>] process_one_work+0x2bf/0x4f0
> [<ffffffff81050022>] worker_thread+0x2b2/0x3e0
> [<ffffffff81056021>] kthread+0xd1/0xe0
> [<ffffffff813f14bc>] ret_from_fork+0x7c/0xb0
>
> other info that might help us debug this:
>
> Possible unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> lock(slock-AF_BLUETOOTH-BTPROTO_SCO);
> lock(&(&conn->lock)->rlock);
> lock(slock-AF_BLUETOOTH-BTPROTO_SCO);
> lock(&(&conn->lock)->rlock);
>
> *** DEADLOCK ***
>
> 4 locks held by kworker/u:1H/1018:
> #0: (hdev->name#2){.+.+.+}, at: [<ffffffff8104d5f8>] process_one_work+0x258/0x4f0
> #1: ((&hdev->rx_work)){+.+.+.}, at: [<ffffffff8104d5f8>] process_one_work+0x258/0x4f0
> #2: (&hdev->lock){+.+.+.}, at: [<ffffffffa000fbe9>] hci_disconn_complete_evt.isra.54+0x59/0x3c0 [bluetooth]
> #3: (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}, at: [<ffffffffa0033d5a>] sco_conn_del+0x8a/0xe0 [bluetooth]
>
> stack backtrace:
> Pid: 1018, comm: kworker/u:1H Not tainted 3.8.0-rc1+ #7
> Call Trace:
> [<ffffffff813e92f9>] print_circular_bug+0x1fb/0x20c
> [<ffffffff81082215>] __lock_acquire+0x1465/0x1c70
> [<ffffffff81083011>] lock_acquire+0xb1/0xe0
> [<ffffffffa0033ba6>] ? sco_chan_del+0x66/0x190 [bluetooth]
> [<ffffffff813efd01>] _raw_spin_lock+0x41/0x80
> [<ffffffffa0033ba6>] ? sco_chan_del+0x66/0x190 [bluetooth]
> [<ffffffffa0033ba6>] sco_chan_del+0x66/0x190 [bluetooth]
> [<ffffffffa0033d6d>] sco_conn_del+0x9d/0xe0 [bluetooth]
> [<ffffffffa0034653>] sco_disconn_cfm+0x53/0x60 [bluetooth]
> [<ffffffffa000fef3>] hci_disconn_complete_evt.isra.54+0x363/0x3c0 [bluetooth]
> [<ffffffffa000fbd0>] ? hci_disconn_complete_evt.isra.54+0x40/0x3c0 [bluetooth]
> [<ffffffffa00150f7>] hci_event_packet+0xc7/0x29b0 [bluetooth]
> [<ffffffff81202e90>] ? __dynamic_pr_debug+0x80/0x90
> [<ffffffff8133ff7d>] ? kfree_skb+0x2d/0x40
> [<ffffffffa0021644>] ? hci_send_to_monitor+0x1a4/0x1c0 [bluetooth]
> [<ffffffffa0004583>] hci_rx_work+0x133/0x870 [bluetooth]
> [<ffffffff8104d5f8>] ? process_one_work+0x258/0x4f0
> [<ffffffff8104d65f>] process_one_work+0x2bf/0x4f0
> [<ffffffff8104d5f8>] ? process_one_work+0x258/0x4f0
> [<ffffffff8104fdc1>] ? worker_thread+0x51/0x3e0
> [<ffffffffa0004450>] ? hci_tx_work+0x800/0x800 [bluetooth]
> [<ffffffff81050022>] worker_thread+0x2b2/0x3e0
> [<ffffffff8104fd70>] ? busy_worker_rebind_fn+0x100/0x100
> [<ffffffff81056021>] kthread+0xd1/0xe0
> [<ffffffff81055f50>] ? flush_kthread_worker+0xc0/0xc0
> [<ffffffff813f14bc>] ret_from_fork+0x7c/0xb0
> [<ffffffff81055f50>] ? flush_kthread_worker+0xc0/0xc0
>
> Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
> ---
>
> This lockdep warning has been around for a long time. I could test
> until Linux 3.4, but it seems it is older than that. However, in
> current bluetooth-next, this warning has been masked by commit
> 53502d69be49e3dd5bc95ab0f2deeaea260bd617 which introduced a bug in
> SCO socket shutdown routine.
>
> The bug in SCO socket shutdown routine has been fixed by patch 02/05
> from this patchset.
>
> net/bluetooth/sco.c | 18 ++++++++++--------
> 1 file changed, 10 insertions(+), 8 deletions(-)
Patch has been applied to bluetooth-next. Thanks.
Gustavo
prev parent reply other threads:[~2013-01-30 19:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-29 22:59 [PATCH 1/5] Bluetooth: Fix L2CAP socket shutdown for LE connections Andre Guedes
2013-01-29 22:59 ` [PATCH 2/5] Bluetooth: Fix SCO socket shutdown Andre Guedes
2013-01-29 22:59 ` [PATCH 3/5] Bluetooth: Refactor hci_conn_disconnect Andre Guedes
2013-01-30 8:01 ` Marcel Holtmann
2013-01-29 22:59 ` [PATCH 4/5] Bluetooth: Rename hci_acl_disconn Andre Guedes
2013-01-29 22:59 ` [PATCH 5/5] Bluetooth: Reduce critical section in sco_conn_ready Andre Guedes
2013-01-30 19:31 ` Gustavo Padovan [this message]
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=20130130193146.GA31386@joana \
--to=gustavo@padovan.org \
--cc=andre.guedes@openbossa.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.