diff options
| author | Szymon Janc <szymon.janc@gmail.com> | 2014-02-18 20:48:34 +0100 |
|---|---|---|
| committer | Marcel Holtmann <marcel@holtmann.org> | 2014-02-18 12:11:47 -0800 |
| commit | 2c96e03def3b1ba47a5d0ec0c8ef7935a9bfb3a0 (patch) | |
| tree | b36d7547a68fea536feaead43a72a6919d97a1f8 | |
| parent | 5cedbb8d7aee79a8bbfc8e5b91bc1353ffb0f7b0 (diff) | |
| download | linux-2c96e03def3b1ba47a5d0ec0c8ef7935a9bfb3a0.tar.bz2 | |
Bluetooth: Print error when dropping L2CAP data
Silently dropping L2CAP data (i.e. due to remote device not obeying
negotiated MTU) is confusing and makes debugging harder.
Signed-off-by: Szymon Janc <szymon.janc@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| -rw-r--r-- | net/bluetooth/l2cap_core.c | 4 |
1 files changed, 3 insertions, 1 deletions
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c index c3bda6445f3d..6ace116f3b39 100644 --- a/net/bluetooth/l2cap_core.c +++ b/net/bluetooth/l2cap_core.c @@ -6776,8 +6776,10 @@ static void l2cap_data_channel(struct l2cap_conn *conn, u16 cid, * But we don't have any other choice. L2CAP doesn't * provide flow control mechanism. */ - if (chan->imtu < skb->len) + if (chan->imtu < skb->len) { + BT_ERR("Dropping L2CAP data: receive buffer overflow"); goto drop; + } if (!chan->ops->recv(chan, skb)) goto done; |