Skip to content

L
linux
Switch branch/tag
  1. 02 Oct, 2014 4 commits
    • Jukka Rissanen's avatar
      Bluetooth: 6lowpan: Return EAGAIN error also for multicast packets · d7b6b0a5
      Jukka Rissanen authored 
      Make sure that we are able to return EAGAIN from l2cap_chan_send()
even for multicast packets. The error code was ignored unncessarily.
Signed-off-by: default avatarJukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      d7b6b0a5
    • Jukka Rissanen's avatar
      Bluetooth: 6lowpan: Avoid memory leak if memory allocation fails · a7807d73
      Jukka Rissanen authored 
      If skb_unshare() returns NULL, then we leak the original skb.
Solution is to use temp variable to hold the new skb.
Signed-off-by: default avatarJukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      a7807d73
    • Jukka Rissanen's avatar
      Bluetooth: 6lowpan: Memory leak as the skb is not freed · fc12518a
      Jukka Rissanen authored 
      The earlier multicast commit 36b3dd25 ("Bluetooth: 6lowpan:
Ensure header compression does not corrupt IPv6 header") lost one
skb free which then caused memory leak.
Signed-off-by: default avatarJukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      fc12518a
    • Johan Hedberg's avatar
      Bluetooth: Fix lockdep warning with l2cap_chan_connect · 02e246ae
      Johan Hedberg authored 
      The L2CAP connection's channel list lock (conn->chan_lock) must never be
taken while already holding a channel lock (chan->lock) in order to
avoid lock-inversion and lockdep warnings. So far the l2cap_chan_connect
function has acquired the chan->lock early in the function and then
later called l2cap_chan_add(conn, chan) which will try to take the
conn->chan_lock. This violates the correct order of taking the locks and
may lead to the following type of lockdep warnings:

-> #1 (&conn->chan_lock){+.+...}:
       [<c109324d>] lock_acquire+0x9d/0x140
       [<c188459c>] mutex_lock_nested+0x6c/0x420
       [<d0aab48e>] l2cap_chan_add+0x1e/0x40 [bluetooth]
       [<d0aac618>] l2cap_chan_connect+0x348/0x8f0 [bluetooth]
       [<d0cc9a91>] lowpan_control_write+0x221/0x2d0 [bluetooth_6lowpan]
-> #0 (&chan->lock){+.+.+.}:
       [<c10928d8>] __lock_acquire+0x1a18/0x1d20
       [<c109324d>] lock_acquire+0x9d/0x140
       [<c188459c>] mutex_lock_nested+0x6c/0x420
       [<d0ab05fd>] l2cap_connect_cfm+0x1dd/0x3f0 [bluetooth]
       [<d0a909c4>] hci_le_meta_evt+0x11a4/0x1260 [bluetooth]
       [<d0a910eb>] hci_event_packet+0x3ab/0x3120 [bluetooth]
       [<d0a7cb08>] hci_rx_work+0x208/0x4a0 [bluetooth]

       CPU0                    CPU1
       ----                    ----
  lock(&conn->chan_lock);
                               lock(&chan->lock);
                               lock(&conn->chan_lock);
  lock(&chan->lock);

Before calling l2cap_chan_add() the channel is not part of the
conn->chan_l list, and can therefore only be accessed by the L2CAP user
(such as l2cap_sock.c). We can therefore assume that it is the
responsibility of the user to handle mutual exclusion until this point
(which we can see is already true in l2cap_sock.c by it in many places
touching chan members without holding chan->lock).

Since the hci_conn and by exctension l2cap_conn creation in the
l2cap_chan_connect() function depend on chan details we cannot simply
add a mutex_lock(&conn->chan_lock) in the beginning of the function
(since the conn object doesn't yet exist there). What we can do however
is move the chan->lock taking later into the function where we already
have the conn object and can that way take conn->chan_lock first.

This patch implements the above strategy and does some other necessary
changes such as using __l2cap_chan_add() which assumes conn->chan_lock
is held, as well as adding a second needed label so the unlocking
happens as it should.
Reported-by: default avatarJukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
Tested-by: default avatarJukka Rissanen <jukka.rissanen@linux.intel.com>
Acked-by: default avatarJukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      02e246ae
  3. 30 Sep, 2014 3 commits
  5. 29 Sep, 2014 3 commits
  7. 25 Sep, 2014 1 commit
  9. 24 Sep, 2014 7 commits
  11. 23 Sep, 2014 1 commit
  13. 18 Sep, 2014 1 commit
    • Johan Hedberg's avatar
      Bluetooth: Fix setting correct security level when initiating SMP · 5eb596f5
      Johan Hedberg authored 
      We can only determine the final security level when both pairing request
and response have been exchanged. When initiating pairing the starting
target security level is set to MEDIUM unless explicitly specified to be
HIGH, so that we can still perform pairing even if the remote doesn't
have MITM capabilities. However, once we've received the pairing
response we should re-consult the remote and local IO capabilities and
upgrade the target security level if necessary.

Without this patch the resulting Long Term Key will occasionally be
reported to be unauthenticated when it in reality is an authenticated
one.
Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
      5eb596f5
  15. 17 Sep, 2014 1 commit
  17. 16 Sep, 2014 3 commits
  19. 15 Sep, 2014 3 commits
  21. 14 Sep, 2014 2 commits
  23. 12 Sep, 2014 1 commit
  25. 11 Sep, 2014 8 commits
  27. 09 Sep, 2014 2 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7