Bluetooth: Fix race condition on l2cap_ertm_send()
authorGustavo F. Padovan <padovan@profusion.mobi>
Sat, 1 May 2010 19:15:45 +0000 (16:15 -0300)
committerMarcel Holtmann <marcel@holtmann.org>
Mon, 10 May 2010 07:28:53 +0000 (09:28 +0200)
commitdfc909befbfe967bd7f46ef33b6969c1b7f3cf42
treecec8545cce920fe194a2d167467a1ca500c2616d
parent6161c0382bbab883a634d284f7367a88bbe88534
Bluetooth: Fix race condition on l2cap_ertm_send()

l2cap_ertm_send() can be called both from user context and bottom half
context. The socket locks for that contexts are different, the user
context uses a mutex(which can sleep) and the second one uses a
spinlock_bh. That creates a race condition when we have interruptions on
both contexts at the same time.

The better way to solve this is to add a new spinlock to lock
l2cap_ertm_send() and the vars it access. The other solution was to defer
l2cap_ertm_send() with a workqueue, but we the sending process already
has one defer on the hci layer. It's not a good idea add another one.

The patch refactor the code to create l2cap_retransmit_frames(), then we
encapulate the lock of l2cap_ertm_send() for some call. It also changes
l2cap_retransmit_frame() to l2cap_retransmit_one_frame() to avoid
confusion

Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Reviewed-by: João Paulo Rechi Vita <jprvita@profusion.mobi>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
include/net/bluetooth/l2cap.h
net/bluetooth/l2cap.c