An error occurred fetching the project authors.
  1. 14 Jul, 2014 1 commit
  2. 13 Jul, 2014 2 commits
  3. 11 Jul, 2014 3 commits
  4. 11 Apr, 2014 1 commit
    • David S. Miller's avatar
      net: Fix use after free by removing length arg from sk_data_ready callbacks. · 676d2369
      David S. Miller authored
      Several spots in the kernel perform a sequence like:
      
      	skb_queue_tail(&sk->s_receive_queue, skb);
      	sk->sk_data_ready(sk, skb->len);
      
      But at the moment we place the SKB onto the socket receive queue it
      can be consumed and freed up.  So this skb->len access is potentially
      to freed up memory.
      
      Furthermore, the skb->len can be modified by the consumer so it is
      possible that the value isn't accurate.
      
      And finally, no actual implementation of this callback actually uses
      the length argument.  And since nobody actually cared about it's
      value, lots of call sites pass arbitrary values in such as '0' and
      even '1'.
      
      So just remove the length argument from the callback, that way there
      is no confusion whatsoever and all of these use-after-free cases get
      fixed as a side effect.
      
      Based upon a patch by Eric Dumazet and his suggestion to audit this
      issue tree-wide.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      676d2369
  5. 12 Mar, 2014 1 commit
  6. 21 Nov, 2013 1 commit
    • Hannes Frederic Sowa's avatar
      net: rework recvmsg handler msg_name and msg_namelen logic · f3d33426
      Hannes Frederic Sowa authored
      This patch now always passes msg->msg_namelen as 0. recvmsg handlers must
      set msg_namelen to the proper size <= sizeof(struct sockaddr_storage)
      to return msg_name to the user.
      
      This prevents numerous uninitialized memory leaks we had in the
      recvmsg handlers and makes it harder for new code to accidentally leak
      uninitialized memory.
      
      Optimize for the case recvfrom is called with NULL as address. We don't
      need to copy the address at all, so set it to NULL before invoking the
      recvmsg handler. We can do so, because all the recvmsg handlers must
      cope with the case a plain read() is called on them. read() also sets
      msg_name to NULL.
      
      Also document these changes in include/linux/net.h as suggested by David
      Miller.
      
      Changes since RFC:
      
      Set msg->msg_name = NULL if user specified a NULL in msg_name but had a
      non-null msg_namelen in verify_iovec/verify_compat_iovec. This doesn't
      affect sendto as it would bail out earlier while trying to copy-in the
      address. It also more naturally reflects the logic by the callers of
      verify_iovec.
      
      With this change in place I could remove "
      if (!uaddr || msg_sys->msg_namelen == 0)
      	msg->msg_name = NULL
      ".
      
      This change does not alter the user visible error logic as we ignore
      msg_namelen as long as msg_name is NULL.
      
      Also remove two unnecessary curly brackets in ___sys_recvmsg and change
      comments to netdev style.
      
      Cc: David Miller <davem@davemloft.net>
      Suggested-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f3d33426
  7. 18 Oct, 2013 1 commit
  8. 13 Oct, 2013 2 commits
  9. 21 Aug, 2013 7 commits
  10. 18 Apr, 2013 1 commit
  11. 11 Apr, 2013 3 commits
  12. 09 Apr, 2013 1 commit
  13. 07 Apr, 2013 1 commit
  14. 14 Mar, 2013 1 commit
    • Vinicius Costa Gomes's avatar
      Bluetooth: Fix not closing SCO sockets in the BT_CONNECT2 state · eb20ff9c
      Vinicius Costa Gomes authored
      With deferred setup for SCO, it is possible that userspace closes the
      socket when it is in the BT_CONNECT2 state, after the Connect Request is
      received but before the Accept Synchonous Connection is sent.
      
      If this happens the following crash was observed, when the connection is
      terminated:
      
      [  +0.000003] hci_sync_conn_complete_evt: hci0 status 0x10
      [  +0.000005] sco_connect_cfm: hcon ffff88003d1bd800 bdaddr 40:98:4e:32:d7:39 status 16
      [  +0.000003] sco_conn_del: hcon ffff88003d1bd800 conn ffff88003cc8e300, err 110
      [  +0.000015] BUG: unable to handle kernel NULL pointer dereference at 0000000000000199
      [  +0.000906] IP: [<ffffffff810620dd>] __lock_acquire+0xed/0xe82
      [  +0.000000] PGD 3d21f067 PUD 3d291067 PMD 0
      [  +0.000000] Oops: 0002 [#1] SMP
      [  +0.000000] Modules linked in: rfcomm bnep btusb bluetooth
      [  +0.000000] CPU 0
      [  +0.000000] Pid: 1481, comm: kworker/u:2H Not tainted 3.9.0-rc1-25019-gad82cdd1 #1 Bochs Bochs
      [  +0.000000] RIP: 0010:[<ffffffff810620dd>]  [<ffffffff810620dd>] __lock_acquire+0xed/0xe82
      [  +0.000000] RSP: 0018:ffff88003c3c19d8  EFLAGS: 00010002
      [  +0.000000] RAX: 0000000000000001 RBX: 0000000000000246 RCX: 0000000000000000
      [  +0.000000] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88003d1be868
      [  +0.000000] RBP: ffff88003c3c1a98 R08: 0000000000000002 R09: 0000000000000000
      [  +0.000000] R10: ffff88003d1be868 R11: ffff88003e20b000 R12: 0000000000000002
      [  +0.000000] R13: ffff88003aaa8000 R14: 000000000000006e R15: ffff88003d1be850
      [  +0.000000] FS:  0000000000000000(0000) GS:ffff88003e200000(0000) knlGS:0000000000000000
      [  +0.000000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [  +0.000000] CR2: 0000000000000199 CR3: 000000003c1cb000 CR4: 00000000000006b0
      [  +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  +0.000000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [  +0.000000] Process kworker/u:2H (pid: 1481, threadinfo ffff88003c3c0000, task ffff88003aaa8000)
      [  +0.000000] Stack:
      [  +0.000000]  ffffffff81b16342 0000000000000000 0000000000000000 ffff88003d1be868
      [  +0.000000]  ffffffff00000000 00018c0c7863e367 000000003c3c1a28 ffffffff8101efbd
      [  +0.000000]  0000000000000000 ffff88003e3d2400 ffff88003c3c1a38 ffffffff81007c7a
      [  +0.000000] Call Trace:
      [  +0.000000]  [<ffffffff8101efbd>] ? kvm_clock_read+0x34/0x3b
      [  +0.000000]  [<ffffffff81007c7a>] ? paravirt_sched_clock+0x9/0xd
      [  +0.000000]  [<ffffffff81007fd4>] ? sched_clock+0x9/0xb
      [  +0.000000]  [<ffffffff8104fd7a>] ? sched_clock_local+0x12/0x75
      [  +0.000000]  [<ffffffff810632d1>] lock_acquire+0x93/0xb1
      [  +0.000000]  [<ffffffffa0022339>] ? spin_lock+0x9/0xb [bluetooth]
      [  +0.000000]  [<ffffffff8105f3d8>] ? lock_release_holdtime.part.22+0x4e/0x55
      [  +0.000000]  [<ffffffff814f6038>] _raw_spin_lock+0x40/0x74
      [  +0.000000]  [<ffffffffa0022339>] ? spin_lock+0x9/0xb [bluetooth]
      [  +0.000000]  [<ffffffff814f6936>] ? _raw_spin_unlock+0x23/0x36
      [  +0.000000]  [<ffffffffa0022339>] spin_lock+0x9/0xb [bluetooth]
      [  +0.000000]  [<ffffffffa00230cc>] sco_conn_del+0x76/0xbb [bluetooth]
      [  +0.000000]  [<ffffffffa002391d>] sco_connect_cfm+0x2da/0x2e9 [bluetooth]
      [  +0.000000]  [<ffffffffa000862a>] hci_proto_connect_cfm+0x38/0x65 [bluetooth]
      [  +0.000000]  [<ffffffffa0008d30>] hci_sync_conn_complete_evt.isra.79+0x11a/0x13e [bluetooth]
      [  +0.000000]  [<ffffffffa000cd96>] hci_event_packet+0x153b/0x239d [bluetooth]
      [  +0.000000]  [<ffffffff814f68ff>] ? _raw_spin_unlock_irqrestore+0x48/0x5c
      [  +0.000000]  [<ffffffffa00025f6>] hci_rx_work+0xf3/0x2e3 [bluetooth]
      [  +0.000000]  [<ffffffff8103efed>] process_one_work+0x1dc/0x30b
      [  +0.000000]  [<ffffffff8103ef83>] ? process_one_work+0x172/0x30b
      [  +0.000000]  [<ffffffff8103e07f>] ? spin_lock_irq+0x9/0xb
      [  +0.000000]  [<ffffffff8103fc8d>] worker_thread+0x123/0x1d2
      [  +0.000000]  [<ffffffff8103fb6a>] ? manage_workers+0x240/0x240
      [  +0.000000]  [<ffffffff81044211>] kthread+0x9d/0xa5
      [  +0.000000]  [<ffffffff81044174>] ? __kthread_parkme+0x60/0x60
      [  +0.000000]  [<ffffffff814f75bc>] ret_from_fork+0x7c/0xb0
      [  +0.000000]  [<ffffffff81044174>] ? __kthread_parkme+0x60/0x60
      [  +0.000000] Code: d7 44 89 8d 50 ff ff ff 4c 89 95 58 ff ff ff e8 44 fc ff ff 44 8b 8d 50 ff ff ff 48 85 c0 4c 8b 95 58 ff ff ff 0f 84 7a 04 00 00 <f0> ff 80 98 01 00 00 83 3d 25 41 a7 00 00 45 8b b5 e8 05 00 00
      [  +0.000000] RIP  [<ffffffff810620dd>] __lock_acquire+0xed/0xe82
      [  +0.000000]  RSP <ffff88003c3c19d8>
      [  +0.000000] CR2: 0000000000000199
      [  +0.000000] ---[ end trace e73cd3b52352dd34 ]---
      
      Cc: stable@vger.kernel.org [3.8]
      Signed-off-by: default avatarVinicius Costa Gomes <vinicius.gomes@openbossa.org>
      Tested-by: default avatarFrederic Dalleau <frederic.dalleau@intel.com>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      eb20ff9c
  15. 08 Mar, 2013 1 commit
  16. 28 Feb, 2013 1 commit
    • Sasha Levin's avatar
      hlist: drop the node parameter from iterators · b67bfe0d
      Sasha Levin authored
      I'm not sure why, but the hlist for each entry iterators were conceived
      
              list_for_each_entry(pos, head, member)
      
      The hlist ones were greedy and wanted an extra parameter:
      
              hlist_for_each_entry(tpos, pos, head, member)
      
      Why did they need an extra pos parameter? I'm not quite sure. Not only
      they don't really need it, it also prevents the iterator from looking
      exactly like the list iterator, which is unfortunate.
      
      Besides the semantic patch, there was some manual work required:
      
       - Fix up the actual hlist iterators in linux/list.h
       - Fix up the declaration of other iterators based on the hlist ones.
       - A very small amount of places were using the 'node' parameter, this
       was modified to use 'obj->member' instead.
       - Coccinelle didn't handle the hlist_for_each_entry_safe iterator
       properly, so those had to be fixed up manually.
      
      The semantic patch which is mostly the work of Peter Senna Tschudin is here:
      
      @@
      iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
      
      type T;
      expression a,c,d,e;
      identifier b;
      statement S;
      @@
      
      -T b;
          <+... when != b
      (
      hlist_for_each_entry(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_continue(a,
      - b,
      c) S
      |
      hlist_for_each_entry_from(a,
      - b,
      c) S
      |
      hlist_for_each_entry_rcu(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_rcu_bh(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_continue_rcu_bh(a,
      - b,
      c) S
      |
      for_each_busy_worker(a, c,
      - b,
      d) S
      |
      ax25_uid_for_each(a,
      - b,
      c) S
      |
      ax25_for_each(a,
      - b,
      c) S
      |
      inet_bind_bucket_for_each(a,
      - b,
      c) S
      |
      sctp_for_each_hentry(a,
      - b,
      c) S
      |
      sk_for_each(a,
      - b,
      c) S
      |
      sk_for_each_rcu(a,
      - b,
      c) S
      |
      sk_for_each_from
      -(a, b)
      +(a)
      S
      + sk_for_each_from(a) S
      |
      sk_for_each_safe(a,
      - b,
      c, d) S
      |
      sk_for_each_bound(a,
      - b,
      c) S
      |
      hlist_for_each_entry_safe(a,
      - b,
      c, d, e) S
      |
      hlist_for_each_entry_continue_rcu(a,
      - b,
      c) S
      |
      nr_neigh_for_each(a,
      - b,
      c) S
      |
      nr_neigh_for_each_safe(a,
      - b,
      c, d) S
      |
      nr_node_for_each(a,
      - b,
      c) S
      |
      nr_node_for_each_safe(a,
      - b,
      c, d) S
      |
      - for_each_gfn_sp(a, c, d, b) S
      + for_each_gfn_sp(a, c, d) S
      |
      - for_each_gfn_indirect_valid_sp(a, c, d, b) S
      + for_each_gfn_indirect_valid_sp(a, c, d) S
      |
      for_each_host(a,
      - b,
      c) S
      |
      for_each_host_safe(a,
      - b,
      c, d) S
      |
      for_each_mesh_entry(a,
      - b,
      c, d) S
      )
          ...+>
      
      [akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
      [akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
      [akpm@linux-foundation.org: checkpatch fixes]
      [akpm@linux-foundation.org: fix warnings]
      [akpm@linux-foudnation.org: redo intrusive kvm changes]
      Tested-by: default avatarPeter Senna Tschudin <peter.senna@gmail.com>
      Acked-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Cc: Wu Fengguang <fengguang.wu@intel.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Gleb Natapov <gleb@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b67bfe0d
  17. 01 Feb, 2013 1 commit
    • Andre Guedes's avatar
      Bluetooth: Reduce critical section in sco_conn_ready · 40528088
      Andre Guedes authored
      This patch reduces the critical section protected by sco_conn_lock in
      sco_conn_ready function. The lock is acquired only when it is really
      needed.
      
      This patch fixes the following lockdep warning which is generated
      when the host terminates a SCO connection.
      
      Today, this warning is a false positive. There is no way those
      two threads reported by lockdep are running at the same time since
      hdev->workqueue (where rx_work is queued) is single-thread. However,
      if somehow this behavior is changed in future, we will have a
      potential deadlock.
      
      ======================================================
      [ INFO: possible circular locking dependency detected ]
      3.8.0-rc1+ #7 Not tainted
      -------------------------------------------------------
      kworker/u:1H/1018 is trying to acquire lock:
       (&(&conn->lock)->rlock){+.+...}, at: [<ffffffffa0033ba6>] sco_chan_del+0x66/0x190 [bluetooth]
      
      but task is already holding lock:
       (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}, at: [<ffffffffa0033d5a>] sco_conn_del+0x8a/0xe0 [bluetooth]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}:
             [<ffffffff81083011>] lock_acquire+0xb1/0xe0
             [<ffffffff813efd01>] _raw_spin_lock+0x41/0x80
             [<ffffffffa003436e>] sco_connect_cfm+0xbe/0x350 [bluetooth]
             [<ffffffffa0015d6c>] hci_event_packet+0xd3c/0x29b0 [bluetooth]
             [<ffffffffa0004583>] hci_rx_work+0x133/0x870 [bluetooth]
             [<ffffffff8104d65f>] process_one_work+0x2bf/0x4f0
             [<ffffffff81050022>] worker_thread+0x2b2/0x3e0
             [<ffffffff81056021>] kthread+0xd1/0xe0
             [<ffffffff813f14bc>] ret_from_fork+0x7c/0xb0
      
      -> #0 (&(&conn->lock)->rlock){+.+...}:
             [<ffffffff81082215>] __lock_acquire+0x1465/0x1c70
             [<ffffffff81083011>] lock_acquire+0xb1/0xe0
             [<ffffffff813efd01>] _raw_spin_lock+0x41/0x80
             [<ffffffffa0033ba6>] sco_chan_del+0x66/0x190 [bluetooth]
             [<ffffffffa0033d6d>] sco_conn_del+0x9d/0xe0 [bluetooth]
             [<ffffffffa0034653>] sco_disconn_cfm+0x53/0x60 [bluetooth]
             [<ffffffffa000fef3>] hci_disconn_complete_evt.isra.54+0x363/0x3c0 [bluetooth]
             [<ffffffffa00150f7>] hci_event_packet+0xc7/0x29b0 [bluetooth]
             [<ffffffffa0004583>] hci_rx_work+0x133/0x870 [bluetooth]
             [<ffffffff8104d65f>] process_one_work+0x2bf/0x4f0
             [<ffffffff81050022>] worker_thread+0x2b2/0x3e0
             [<ffffffff81056021>] kthread+0xd1/0xe0
             [<ffffffff813f14bc>] ret_from_fork+0x7c/0xb0
      
      other info that might help us debug this:
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(slock-AF_BLUETOOTH-BTPROTO_SCO);
                                     lock(&(&conn->lock)->rlock);
                                     lock(slock-AF_BLUETOOTH-BTPROTO_SCO);
        lock(&(&conn->lock)->rlock);
      
       *** DEADLOCK ***
      
      4 locks held by kworker/u:1H/1018:
       #0:  (hdev->name#2){.+.+.+}, at: [<ffffffff8104d5f8>] process_one_work+0x258/0x4f0
       #1:  ((&hdev->rx_work)){+.+.+.}, at: [<ffffffff8104d5f8>] process_one_work+0x258/0x4f0
       #2:  (&hdev->lock){+.+.+.}, at: [<ffffffffa000fbe9>] hci_disconn_complete_evt.isra.54+0x59/0x3c0 [bluetooth]
       #3:  (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}, at: [<ffffffffa0033d5a>] sco_conn_del+0x8a/0xe0 [bluetooth]
      
      stack backtrace:
      Pid: 1018, comm: kworker/u:1H Not tainted 3.8.0-rc1+ #7
      Call Trace:
       [<ffffffff813e92f9>] print_circular_bug+0x1fb/0x20c
       [<ffffffff81082215>] __lock_acquire+0x1465/0x1c70
       [<ffffffff81083011>] lock_acquire+0xb1/0xe0
       [<ffffffffa0033ba6>] ? sco_chan_del+0x66/0x190 [bluetooth]
       [<ffffffff813efd01>] _raw_spin_lock+0x41/0x80
       [<ffffffffa0033ba6>] ? sco_chan_del+0x66/0x190 [bluetooth]
       [<ffffffffa0033ba6>] sco_chan_del+0x66/0x190 [bluetooth]
       [<ffffffffa0033d6d>] sco_conn_del+0x9d/0xe0 [bluetooth]
       [<ffffffffa0034653>] sco_disconn_cfm+0x53/0x60 [bluetooth]
       [<ffffffffa000fef3>] hci_disconn_complete_evt.isra.54+0x363/0x3c0 [bluetooth]
       [<ffffffffa000fbd0>] ? hci_disconn_complete_evt.isra.54+0x40/0x3c0 [bluetooth]
       [<ffffffffa00150f7>] hci_event_packet+0xc7/0x29b0 [bluetooth]
       [<ffffffff81202e90>] ? __dynamic_pr_debug+0x80/0x90
       [<ffffffff8133ff7d>] ? kfree_skb+0x2d/0x40
       [<ffffffffa0021644>] ? hci_send_to_monitor+0x1a4/0x1c0 [bluetooth]
       [<ffffffffa0004583>] hci_rx_work+0x133/0x870 [bluetooth]
       [<ffffffff8104d5f8>] ? process_one_work+0x258/0x4f0
       [<ffffffff8104d65f>] process_one_work+0x2bf/0x4f0
       [<ffffffff8104d5f8>] ? process_one_work+0x258/0x4f0
       [<ffffffff8104fdc1>] ? worker_thread+0x51/0x3e0
       [<ffffffffa0004450>] ? hci_tx_work+0x800/0x800 [bluetooth]
       [<ffffffff81050022>] worker_thread+0x2b2/0x3e0
       [<ffffffff8104fd70>] ? busy_worker_rebind_fn+0x100/0x100
       [<ffffffff81056021>] kthread+0xd1/0xe0
       [<ffffffff81055f50>] ? flush_kthread_worker+0xc0/0xc0
       [<ffffffff813f14bc>] ret_from_fork+0x7c/0xb0
       [<ffffffff81055f50>] ? flush_kthread_worker+0xc0/0xc0
      Signed-off-by: default avatarAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      40528088
  18. 10 Jan, 2013 1 commit
    • Gustavo Padovan's avatar
      Bluetooth: Check if the hci connection exists in SCO shutdown · b7e98b51
      Gustavo Padovan authored
      Checking only for sco_conn seems to not be enough and lead to NULL
      dereferences in the code, check for hcon instead.
      
      <1>[11340.226404] BUG: unable to handle kernel NULL pointer dereference at
      0000000
      8
      <4>[11340.226619] EIP is at __sco_sock_close+0xe8/0x1a0
      <4>[11340.226629] EAX: f063a740 EBX: 00000000 ECX: f58f4544 EDX: 00000000
      <4>[11340.226640] ESI: dec83e00 EDI: 5f9a081f EBP: e0fdff38 ESP: e0fdff1c
      <0>[11340.226674] Stack:
      <4>[11340.226682]  c184db87 c1251028 dec83e00 e0fdff38 c1754aef dec83e00
      00000000
      e0fdff5c
      <4>[11340.226718]  c184f587 e0fdff64 e0fdff68 5f9a081f e0fdff5c c1751852
      d7813800
      62262f10
      <4>[11340.226752]  e0fdff70 c1753c00 00000000 00000001 0000000d e0fdffac
      c175425c
      00000041
      <0>[11340.226793] Call Trace:
      <4>[11340.226813]  [<c184db87>] ? sco_sock_clear_timer+0x27/0x60
      <4>[11340.226831]  [<c1251028>] ? local_bh_enable+0x68/0xd0
      <4>[11340.226846]  [<c1754aef>] ? lock_sock_nested+0x4f/0x60
      <4>[11340.226862]  [<c184f587>] sco_sock_shutdown+0x67/0xb0
      <4>[11340.226879]  [<c1751852>] ? sockfd_lookup_light+0x22/0x80
      <4>[11340.226897]  [<c1753c00>] sys_shutdown+0x30/0x60
      <4>[11340.226912]  [<c175425c>] sys_socketcall+0x1dc/0x2a0
      <4>[11340.226929]  [<c149ba78>] ? trace_hardirqs_on_thunk+0xc/0x10
      <4>[11340.226944]  [<c18860f1>] syscall_call+0x7/0xb
      <4>[11340.226960]  [<c1880000>] ? restore_cur+0x5e/0xd7
      <0>[11340.226969] Code: <f0> ff 4b 08 0f 94 c0 84 c0 74 20 80 7b 19 01 74
      2f b8 0a 00 00
      Reported-by: default avatarChuansheng Liu <chuansheng.liu@intel.com>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      b7e98b51
  19. 03 Dec, 2012 3 commits
  20. 27 Sep, 2012 2 commits
  21. 06 Aug, 2012 3 commits
    • Gustavo Padovan's avatar
      Bluetooth: Fix possible deadlock in SCO code · 269c4845
      Gustavo Padovan authored
      sco_chan_del() only has conn != NULL when called from sco_conn_del() so
      just move the code from it that deal with conn to sco_conn_del().
      
      [  120.765529]
      [  120.765529] ======================================================
      [  120.766529] [ INFO: possible circular locking dependency detected ]
      [  120.766529] 3.5.0-rc1-10292-g3701f944-dirty #70 Tainted: G        W
      [  120.766529] -------------------------------------------------------
      [  120.766529] kworker/u:3/1497 is trying to acquire lock:
      [  120.766529]  (&(&conn->lock)->rlock#2){+.+...}, at:
      [<ffffffffa00b7ecc>] sco_chan_del+0x4c/0x170 [bluetooth]
      [  120.766529]
      [  120.766529] but task is already holding lock:
      [  120.766529]  (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}, at:
      [<ffffffffa00b8401>] sco_conn_del+0x61/0xe0 [bluetooth]
      [  120.766529]
      [  120.766529] which lock already depends on the new lock.
      [  120.766529]
      [  120.766529]
      [  120.766529] the existing dependency chain (in reverse order) is:
      [  120.766529]
      [  120.766529] -> #1 (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}:
      [  120.766529]        [<ffffffff8107980e>] lock_acquire+0x8e/0xb0
      [  120.766529]        [<ffffffff813c19e0>] _raw_spin_lock+0x40/0x80
      [  120.766529]        [<ffffffffa00b85e9>] sco_connect_cfm+0x79/0x300
      [bluetooth]
      [  120.766529]        [<ffffffffa0094b13>]
      hci_sync_conn_complete_evt.isra.90+0x343/0x400 [bluetooth]
      [  120.766529]        [<ffffffffa009d447>] hci_event_packet+0x317/0xfb0
      [bluetooth]
      [  120.766529]        [<ffffffffa008aa68>] hci_rx_work+0x2c8/0x890
      [bluetooth]
      [  120.766529]        [<ffffffff81047db7>] process_one_work+0x197/0x460
      [  120.766529]        [<ffffffff810489d6>] worker_thread+0x126/0x2d0
      [  120.766529]        [<ffffffff8104ee4d>] kthread+0x9d/0xb0
      [  120.766529]        [<ffffffff813c4294>] kernel_thread_helper+0x4/0x10
      [  120.766529]
      [  120.766529] -> #0 (&(&conn->lock)->rlock#2){+.+...}:
      [  120.766529]        [<ffffffff81078a8a>] __lock_acquire+0x154a/0x1d30
      [  120.766529]        [<ffffffff8107980e>] lock_acquire+0x8e/0xb0
      [  120.766529]        [<ffffffff813c19e0>] _raw_spin_lock+0x40/0x80
      [  120.766529]        [<ffffffffa00b7ecc>] sco_chan_del+0x4c/0x170
      [bluetooth]
      [  120.766529]        [<ffffffffa00b8414>] sco_conn_del+0x74/0xe0
      [bluetooth]
      [  120.766529]        [<ffffffffa00b88a2>] sco_disconn_cfm+0x32/0x60
      [bluetooth]
      [  120.766529]        [<ffffffffa0093a82>]
      hci_disconn_complete_evt.isra.53+0x242/0x390 [bluetooth]
      [  120.766529]        [<ffffffffa009d747>] hci_event_packet+0x617/0xfb0
      [bluetooth]
      [  120.766529]        [<ffffffffa008aa68>] hci_rx_work+0x2c8/0x890
      [bluetooth]
      [  120.766529]        [<ffffffff81047db7>] process_one_work+0x197/0x460
      [  120.766529]        [<ffffffff810489d6>] worker_thread+0x126/0x2d0
      [  120.766529]        [<ffffffff8104ee4d>] kthread+0x9d/0xb0
      [  120.766529]        [<ffffffff813c4294>] kernel_thread_helper+0x4/0x10
      [  120.766529]
      [  120.766529] other info that might help us debug this:
      [  120.766529]
      [  120.766529]  Possible unsafe locking scenario:
      [  120.766529]
      [  120.766529]        CPU0                    CPU1
      [  120.766529]        ----                    ----
      [  120.766529]   lock(slock-AF_BLUETOOTH-BTPROTO_SCO);
      [  120.766529]
      lock(&(&conn->lock)->rlock#2);
      [  120.766529]
      lock(slock-AF_BLUETOOTH-BTPROTO_SCO);
      [  120.766529]   lock(&(&conn->lock)->rlock#2);
      [  120.766529]
      [  120.766529]  *** DEADLOCK ***
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      269c4845
    • Masatake YAMATO's avatar
      Bluetooth: Added /proc/net/sco via bt_procfs_init() · de9b9212
      Masatake YAMATO authored
      Added /proc/net/sco via bt_procfs_init().
      Signed-off-by: default avatarMasatake YAMATO <yamato@redhat.com>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      de9b9212
    • Andrei Emeltchenko's avatar
      Bluetooth: Make connect / disconnect cfm functions return void · 9e664631
      Andrei Emeltchenko authored
      Return values are never used because callers hci_proto_connect_cfm
      and hci_proto_disconn_cfm return void.
      Signed-off-by: default avatarAndrei Emeltchenko <andrei.emeltchenko@intel.com>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      9e664631
  22. 05 Jun, 2012 2 commits