* [PATCH] Bluetooth: Fix locking in bt_accept_enqueue() for BH context
@ 2018-10-15 22:39 Matthias Kaehlcke
2018-11-12 21:40 ` Matthias Kaehlcke
2018-12-14 23:01 ` Doug Anderson
0 siblings, 2 replies; 3+ messages in thread
From: Matthias Kaehlcke @ 2018-10-15 22:39 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, David S . Miller, Dean Jenkins
Cc: linux-bluetooth, netdev, linux-kernel, Konstantin Khlebnikov,
Balakrishna Godavarthi, Douglas Anderson, Dmitry Grinberg,
Matthias Kaehlcke
With commit e16337622016 ("Bluetooth: Handle bt_accept_enqueue() socket
atomically") lock_sock[_nested]() is used to acquire the socket lock
before manipulating the socket. lock_sock[_nested]() may block, which
is problematic since bt_accept_enqueue() can be called in bottom half
context (e.g. from rfcomm_connect_ind()).
The socket API provides bh_lock_sock[_nested]() to acquire the socket
lock in bottom half context. Check the context in bt_accept_enqueue()
and use the appropriate locking mechanism for the context.
Fixes: e16337622016 ("Bluetooth: Handle bt_accept_enqueue() socket atomically")
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
Not sure if this is the correct solution, it's certainly not elegant and
checkpatch.pl complains that in_atomic() shouldn't be used outside of
core kernel code. I'm open to other suggestions :)
net/bluetooth/af_bluetooth.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
index deacc52d7ff1..0f0540dbb44a 100644
--- a/net/bluetooth/af_bluetooth.c
+++ b/net/bluetooth/af_bluetooth.c
@@ -159,10 +159,20 @@ void bt_accept_enqueue(struct sock *parent, struct sock *sk)
BT_DBG("parent %p, sk %p", parent, sk);
sock_hold(sk);
- lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
+
+ if (in_atomic())
+ bh_lock_sock_nested(sk);
+ else
+ lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
+
list_add_tail(&bt_sk(sk)->accept_q, &bt_sk(parent)->accept_q);
bt_sk(sk)->parent = parent;
- release_sock(sk);
+
+ if (in_atomic())
+ bh_unlock_sock(sk);
+ else
+ release_sock(sk);
+
parent->sk_ack_backlog++;
}
EXPORT_SYMBOL(bt_accept_enqueue);
--
2.19.1.331.ge82ca0e54c-goog
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] Bluetooth: Fix locking in bt_accept_enqueue() for BH context
2018-10-15 22:39 [PATCH] Bluetooth: Fix locking in bt_accept_enqueue() for BH context Matthias Kaehlcke
@ 2018-11-12 21:40 ` Matthias Kaehlcke
2018-12-14 23:01 ` Doug Anderson
1 sibling, 0 replies; 3+ messages in thread
From: Matthias Kaehlcke @ 2018-11-12 21:40 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, David S . Miller, Dean Jenkins
Cc: linux-bluetooth, netdev, linux-kernel, Konstantin Khlebnikov,
Balakrishna Godavarthi, Douglas Anderson, Dmitry Grinberg
On Mon, Oct 15, 2018 at 03:39:10PM -0700, Matthias Kaehlcke wrote:
> With commit e16337622016 ("Bluetooth: Handle bt_accept_enqueue() socket
> atomically") lock_sock[_nested]() is used to acquire the socket lock
> before manipulating the socket. lock_sock[_nested]() may block, which
> is problematic since bt_accept_enqueue() can be called in bottom half
> context (e.g. from rfcomm_connect_ind()).
>
> The socket API provides bh_lock_sock[_nested]() to acquire the socket
> lock in bottom half context. Check the context in bt_accept_enqueue()
> and use the appropriate locking mechanism for the context.
>
> Fixes: e16337622016 ("Bluetooth: Handle bt_accept_enqueue() socket atomically")
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> Not sure if this is the correct solution, it's certainly not elegant and
> checkpatch.pl complains that in_atomic() shouldn't be used outside of
> core kernel code. I'm open to other suggestions :)
>
> net/bluetooth/af_bluetooth.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
> index deacc52d7ff1..0f0540dbb44a 100644
> --- a/net/bluetooth/af_bluetooth.c
> +++ b/net/bluetooth/af_bluetooth.c
> @@ -159,10 +159,20 @@ void bt_accept_enqueue(struct sock *parent, struct sock *sk)
> BT_DBG("parent %p, sk %p", parent, sk);
>
> sock_hold(sk);
> - lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
> +
> + if (in_atomic())
> + bh_lock_sock_nested(sk);
> + else
> + lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
> +
> list_add_tail(&bt_sk(sk)->accept_q, &bt_sk(parent)->accept_q);
> bt_sk(sk)->parent = parent;
> - release_sock(sk);
> +
> + if (in_atomic())
> + bh_unlock_sock(sk);
> + else
> + release_sock(sk);
> +
> parent->sk_ack_backlog++;
> }
> EXPORT_SYMBOL(bt_accept_enqueue);
Any comments or ideas for a better solutions?
Thanks
Matthias
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] Bluetooth: Fix locking in bt_accept_enqueue() for BH context
2018-10-15 22:39 [PATCH] Bluetooth: Fix locking in bt_accept_enqueue() for BH context Matthias Kaehlcke
2018-11-12 21:40 ` Matthias Kaehlcke
@ 2018-12-14 23:01 ` Doug Anderson
1 sibling, 0 replies; 3+ messages in thread
From: Doug Anderson @ 2018-12-14 23:01 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: marcel, johan.hedberg, David Miller, Dean_Jenkins,
linux-bluetooth, netdev, LKML, khlebnikov,
Balakrishna Godavarthi, Dmitry Grinberg
Hi,
On Mon, Oct 15, 2018 at 3:39 PM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> With commit e16337622016 ("Bluetooth: Handle bt_accept_enqueue() socket
> atomically") lock_sock[_nested]() is used to acquire the socket lock
> before manipulating the socket. lock_sock[_nested]() may block, which
> is problematic since bt_accept_enqueue() can be called in bottom half
> context (e.g. from rfcomm_connect_ind()).
>
> The socket API provides bh_lock_sock[_nested]() to acquire the socket
> lock in bottom half context. Check the context in bt_accept_enqueue()
> and use the appropriate locking mechanism for the context.
I wonder if it would help to put the stack crawl in the commit message
too? I think this is what the BUG was reporting (though the stack
seems a bet shorter than I'd expect due to compiler inlining)
__might_sleep+0x4c/0x80
lock_sock_nested+0x24/0x58
bt_accept_enqueue+0x48/0xd4 [bluetooth]
rfcomm_connect_ind+0x190/0x218 [rfcomm]
rfcomm_run+0xe3c/0x163c [rfcomm]
> Fixes: e16337622016 ("Bluetooth: Handle bt_accept_enqueue() socket atomically")
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> Not sure if this is the correct solution, it's certainly not elegant and
> checkpatch.pl complains that in_atomic() shouldn't be used outside of
> core kernel code. I'm open to other suggestions :)
I'm a total noob when it comes to Bluetooth, so I guess I'll try to
understand the callchains here. As far as I can tell there are only 3
calls to bt_accept_enqueue, right? I guess we can look at each of
them:
--
1. net/bluetooth/l2cap_sock.c:
Parent is locked with lock_sock().
--
2. net/bluetooth/rfcomm/sock.c:
Parent is locked with bh_lock_sock(). This is the case you were seeing.
--
3. net/bluetooth/sco.c
sco_conn_ready() => __sco_chan_add => bt_accept_enqueue()
...parent is locked with bh_lock_sock().
sco_connect() => sco_chan_add() => __sco_chan_add
...parent is NULL so we actually never call bt_accept_enqueue() in
this callchain.
So the net result is that the parent is locked with bh_lock_sock().
--
From looking at the above I guess it's pretty simple--if our parent
was locked with bh_lock_sock() then the child should be locked with
bh_lock_sock_nested(). If the parent was locked with lock_sock() then
the child should be locked with lock_sock_nested().
I wonder if a less controversial solution here (and one that wouldn't
upset checkpatch) is to just add a parameter to bt_accept_enqueue()
like "bh". Then you'd pass true for "bh" in
"net/bluetooth/rfcomm/sock.c" and "net/bluetooth/sco.c" and false from
"net/bluetooth/l2cap_sock.c"
--
In any case the problem seems serious enough that I'd propose a Revert
of commit e16337622016 ("Bluetooth: Handle bt_accept_enqueue() socket
atomically") unless we can come up with an acceptable solution.
-Doug
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-12-14 23:02 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-15 22:39 [PATCH] Bluetooth: Fix locking in bt_accept_enqueue() for BH context Matthias Kaehlcke
2018-11-12 21:40 ` Matthias Kaehlcke
2018-12-14 23:01 ` Doug Anderson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).