An error occurred fetching the project authors.
  1. 19 Nov, 2014 1 commit
  2. 18 Nov, 2014 2 commits
    • Johan Hedberg's avatar
      Bluetooth: Call drain_workqueue() before resetting state · 76727c02
      Johan Hedberg authored
      Doing things like hci_conn_hash_flush() while holding the hdev lock is
      risky since its synchronous pending work cancellation could cause the
      L2CAP layer to try to reacquire the hdev lock. Right now there doesn't
      seem to be any obvious places where this would for certain happen but
      it's already enough to cause lockdep to start warning against the hdev
      and the work struct locks being taken in the "wrong" order:
      
      [  +0.000373] mgmt-tester/1603 is trying to acquire lock:
      [  +0.000292]  ((&conn->pending_rx_work)){+.+.+.}, at: [<c104266d>] flush_work+0x0/0x181
      [  +0.000270]
      but task is already holding lock:
      [  +0.000000]  (&hdev->lock){+.+.+.}, at: [<c13b9a80>] hci_dev_do_close+0x166/0x359
      [  +0.000000]
      which lock already depends on the new lock.
      
      [  +0.000000]
      the existing dependency chain (in reverse order) is:
      [  +0.000000]
      -> #1 (&hdev->lock){+.+.+.}:
      [  +0.000000]        [<c105ea8f>] lock_acquire+0xe3/0x156
      [  +0.000000]        [<c140c663>] mutex_lock_nested+0x54/0x375
      [  +0.000000]        [<c13d644b>] l2cap_recv_frame+0x293/0x1a9c
      [  +0.000000]        [<c13d7ca4>] process_pending_rx+0x50/0x5e
      [  +0.000000]        [<c1041a3f>] process_one_work+0x21c/0x436
      [  +0.000000]        [<c1041e3d>] worker_thread+0x1be/0x251
      [  +0.000000]        [<c1045a22>] kthread+0x94/0x99
      [  +0.000000]        [<c140f801>] ret_from_kernel_thread+0x21/0x30
      [  +0.000000]
      -> #0 ((&conn->pending_rx_work)){+.+.+.}:
      [  +0.000000]        [<c105e158>] __lock_acquire+0xa07/0xc89
      [  +0.000000]        [<c105ea8f>] lock_acquire+0xe3/0x156
      [  +0.000000]        [<c1042696>] flush_work+0x29/0x181
      [  +0.000000]        [<c1042864>] __cancel_work_timer+0x76/0x8f
      [  +0.000000]        [<c104288c>] cancel_work_sync+0xf/0x11
      [  +0.000000]        [<c13d4c18>] l2cap_conn_del+0x72/0x183
      [  +0.000000]        [<c13d8953>] l2cap_disconn_cfm+0x49/0x55
      [  +0.000000]        [<c13be37a>] hci_conn_hash_flush+0x7a/0xc3
      [  +0.000000]        [<c13b9af6>] hci_dev_do_close+0x1dc/0x359
      [  +0.012038]        [<c13bbe38>] hci_unregister_dev+0x6e/0x1a3
      [  +0.000000]        [<c12d33c1>] vhci_release+0x28/0x47
      [  +0.000000]        [<c10dd6a9>] __fput+0xd6/0x154
      [  +0.000000]        [<c10dd757>] ____fput+0xd/0xf
      [  +0.000000]        [<c1044bb2>] task_work_run+0x6b/0x8d
      [  +0.000000]        [<c1001bd2>] do_notify_resume+0x3c/0x3f
      [  +0.000000]        [<c140fa70>] work_notifysig+0x29/0x31
      [  +0.000000]
      other info that might help us debug this:
      
      [  +0.000000]  Possible unsafe locking scenario:
      
      [  +0.000000]        CPU0                    CPU1
      [  +0.000000]        ----                    ----
      [  +0.000000]   lock(&hdev->lock);
      [  +0.000000]                                lock((&conn->pending_rx_work));
      [  +0.000000]                                lock(&hdev->lock);
      [  +0.000000]   lock((&conn->pending_rx_work));
      [  +0.000000]
       *** DEADLOCK ***
      
      Fully fixing this would require some quite heavy refactoring to change
      how the hdev lock and hci_conn instances are handled together. A simpler
      solution for now which this patch takes is to try ensure that the hdev
      workqueue is empty before proceeding with the various cleanup calls,
      including hci_conn_hash_flush().
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      76727c02
    • Johan Hedberg's avatar
      Bluetooth: Use shorter "rand" name for "randomizer" · 38da1703
      Johan Hedberg authored
      The common short form of "randomizer" is "rand" in many places
      (including the Bluetooth specification). The shorter version also makes
      for easier to read code with less forced line breaks. This patch renames
      all occurences of "randomizer" to "rand" in the Bluetooth subsystem
      code.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      38da1703
  3. 15 Nov, 2014 2 commits
  4. 03 Nov, 2014 1 commit
  5. 02 Nov, 2014 1 commit
  6. 01 Nov, 2014 1 commit
  7. 29 Oct, 2014 1 commit
  8. 28 Oct, 2014 1 commit
  9. 17 Sep, 2014 1 commit
  10. 15 Sep, 2014 1 commit
  11. 12 Sep, 2014 1 commit
  12. 08 Sep, 2014 2 commits
  13. 20 Aug, 2014 1 commit
    • Johan Hedberg's avatar
      Bluetooth: Fix hci_conn reference counting for auto-connections · f161dd41
      Johan Hedberg authored
      Recently the LE passive scanning and auto-connections feature was
      introduced. It uses the hci_connect_le() API which returns a hci_conn
      along with a reference count to that object. All previous users would
      tie this returned reference to some existing object, such as an L2CAP
      channel, and there'd be no leaked references this way. For
      auto-connections however the reference was returned but not stored
      anywhere, leaving established connections with one higher reference
      count than they should have.
      
      Instead of playing special tricks with hci_conn_hold/drop this patch
      associates the returned reference from hci_connect_le() with the object
      that in practice does own this reference, i.e. the hci_conn_params
      struct that caused us to initiate a connection in the first place. Once
      the connection is established or fails to establish this reference is
      removed appropriately.
      
      One extra thing needed is to call hci_pend_le_actions_clear() before
      calling hci_conn_hash_flush() so that the reference is cleared before
      the hci_conn objects are fully removed.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      f161dd41
  14. 14 Aug, 2014 8 commits
  15. 30 Jul, 2014 1 commit
  16. 27 Jul, 2014 1 commit
  17. 26 Jul, 2014 4 commits
  18. 23 Jul, 2014 3 commits
  19. 21 Jul, 2014 1 commit
  20. 20 Jul, 2014 1 commit
    • Johan Hedberg's avatar
      Bluetooth: Disable HCI_CONNECTABLE based passive scanning for now · d1d588c1
      Johan Hedberg authored
      When HCI_CONNECTABLE is set the code has been enabling passive scanning
      in order to be consistent with BR/EDR and accept connections from any
      device doing directed advertising to us. However, some hardware
      (particularly CSR) can get very noisy even when doing duplicates
      filtering, making this feature waste resources.
      
      Considering that the feature is for fairly corner-case use (devices
      who'd use directed advertising would likely be in the whitelist anyway)
      it's better to disable it for now. It may still be brought back later,
      possibly with a better implementation (e.g. through improved scan
      parameters).
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      d1d588c1
  21. 16 Jul, 2014 2 commits
    • NeilBrown's avatar
      sched: Remove proliferation of wait_on_bit() action functions · 74316201
      NeilBrown authored
      The current "wait_on_bit" interface requires an 'action'
      function to be provided which does the actual waiting.
      There are over 20 such functions, many of them identical.
      Most cases can be satisfied by one of just two functions, one
      which uses io_schedule() and one which just uses schedule().
      
      So:
       Rename wait_on_bit and        wait_on_bit_lock to
              wait_on_bit_action and wait_on_bit_lock_action
       to make it explicit that they need an action function.
      
       Introduce new wait_on_bit{,_lock} and wait_on_bit{,_lock}_io
       which are *not* given an action function but implicitly use
       a standard one.
       The decision to error-out if a signal is pending is now made
       based on the 'mode' argument rather than being encoded in the action
       function.
      
       All instances of the old wait_on_bit and wait_on_bit_lock which
       can use the new version have been changed accordingly and their
       action functions have been discarded.
       wait_on_bit{_lock} does not return any specific error code in the
       event of a signal so the caller must check for non-zero and
       interpolate their own error code as appropriate.
      
      The wait_on_bit() call in __fscache_wait_on_invalidate() was
      ambiguous as it specified TASK_UNINTERRUPTIBLE but used
      fscache_wait_bit_interruptible as an action function.
      David Howells confirms this should be uniformly
      "uninterruptible"
      
      The main remaining user of wait_on_bit{,_lock}_action is NFS
      which needs to use a freezer-aware schedule() call.
      
      A comment in fs/gfs2/glock.c notes that having multiple 'action'
      functions is useful as they display differently in the 'wchan'
      field of 'ps'. (and /proc/$PID/wchan).
      As the new bit_wait{,_io} functions are tagged "__sched", they
      will not show up at all, but something higher in the stack.  So
      the distinction will still be visible, only with different
      function names (gds2_glock_wait versus gfs2_glock_dq_wait in the
      gfs2/glock.c case).
      
      Since first version of this patch (against 3.15) two new action
      functions appeared, on in NFS and one in CIFS.  CIFS also now
      uses an action function that makes the same freezer aware
      schedule call as NFS.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Acked-by: David Howells <dhowells@redhat.com> (fscache, keys)
      Acked-by: Steven Whitehouse <swhiteho@redhat.com> (gfs2)
      Acked-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Steve French <sfrench@samba.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/20140707051603.28027.72349.stgit@notabene.brownSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      74316201
    • Johan Hedberg's avatar
      Bluetooth: Use explicit role instead of a bool in function parameters · e804d25d
      Johan Hedberg authored
      To make the code more understandable it makes sense to use the new HCI
      defines for connection role instead of a "bool master" parameter. This
      makes it immediately clear when looking at the function calls what the
      last parameter is describing.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      e804d25d
  22. 13 Jul, 2014 3 commits