1. 15 2月, 2014 4 次提交
  2. 13 2月, 2014 1 次提交
  3. 13 11月, 2013 2 次提交
  4. 18 10月, 2013 1 次提交
  5. 14 10月, 2013 1 次提交
  6. 21 3月, 2013 1 次提交
  7. 08 3月, 2013 6 次提交
    • D
      Bluetooth: Remove redundant RFCOMM BT_CLOSED settings · 24fd642c
      Dean Jenkins 提交于
      rfcomm_session_close() sets the RFCOMM session state to BT_CLOSED.
      However, in multiple places immediately before the function is
      called, the RFCOMM session is set to BT_CLOSED. Therefore,
      remove these unnecessary state settings.
      Signed-off-by: NDean Jenkins <Dean_Jenkins@mentor.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      24fd642c
    • D
      Bluetooth: Remove redundant call to rfcomm_send_disc · 8e888f27
      Dean Jenkins 提交于
      In rfcomm_session_del() remove the redundant call to
      rfcomm_send_disc() because it is not possible for the
      session to be in BT_CONNECTED state during deletion
      of the session.
      Signed-off-by: NDean Jenkins <Dean_Jenkins@mentor.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      8e888f27
    • D
      Bluetooth: Remove RFCOMM session refcnt · 08c30aca
      Dean Jenkins 提交于
      Previous commits have improved the handling of the RFCOMM session
      timer and the RFCOMM session pointers such that freed RFCOMM
      session structures should no longer be erroneously accessed. The
      RFCOMM session refcnt now has no purpose and will be deleted by
      this commit.
      
      Note that the RFCOMM session is now deleted as soon as the
      RFCOMM control channel link is no longer required. This makes the
      lifetime of the RFCOMM session deterministic and absolute.
      Previously with the refcnt, there was uncertainty about when
      the session structure would be deleted because the relative
      refcnt prevented the session structure from being deleted at will.
      
      It was noted that the refcnt could malfunction under very heavy
      real-time processor loading in embedded SMP environments. This
      could cause premature RFCOMM session deletion or double session
      deletion that could result in kernel crashes. Removal of the
      refcnt prevents this issue.
      
      There are 4 connection / disconnection RFCOMM session scenarios:
      host initiated control link ---> host disconnected control link
      host initiated ctrl link ---> remote device disconnected ctrl link
      remote device initiated ctrl link ---> host disconnected ctrl link
      remote device initiated ctrl link ---> remote device disc'ed ctrl link
      
      The control channel connection procedures are independent of the
      disconnection procedures. Strangely, the RFCOMM session refcnt was
      applying special treatment so erroneously combining connection and
      disconnection events. This commit fixes this issue by removing
      some session code that used the "initiator" member of the session
      structure that was intended for use with the data channels.
      Signed-off-by: NDean Jenkins <Dean_Jenkins@mentor.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      08c30aca
    • D
      Bluetooth: Return RFCOMM session ptrs to avoid freed session · 8ff52f7d
      Dean Jenkins 提交于
      Unfortunately, the design retains local copies of the s RFCOMM
      session pointer in various code blocks and this invites the erroneous
      access to a freed RFCOMM session structure.
      
      Therefore, return the RFCOMM session pointer back up the call stack
      to avoid accessing a freed RFCOMM session structure. When the RFCOMM
      session is deleted, NULL is passed up the call stack.
      
      If active DLCs exist when the rfcomm session is terminating,
      avoid a memory leak of rfcomm_dlc structures by ensuring that
      rfcomm_session_close() is used instead of rfcomm_session_del().
      Signed-off-by: NDean Jenkins <Dean_Jenkins@mentor.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      8ff52f7d
    • D
      Bluetooth: Check rfcomm session and DLC exists on socket close · c06f7d53
      Dean Jenkins 提交于
      A race condition exists between near simultaneous asynchronous
      DLC data channel disconnection requests from the host and remote device.
      This causes the socket layer to request a socket shutdown at the same
      time the rfcomm core is processing the disconnect request from the remote
      device.
      
      The socket layer retains a copy of a struct rfcomm_dlc d pointer.
      The d pointer refers to a copy of a struct rfcomm_session.
      When the socket layer thread performs a socket shutdown, the thread
      may wait on a rfcomm lock in rfcomm_dlc_close(). This means that
      whilst the thread waits, the rfcomm_session and/or rfcomm_dlc structures
      pointed to by d maybe freed due to rfcomm core handling. Consequently,
      when the rfcomm lock becomes available and the thread runs, a
      malfunction could occur as a freed rfcomm_session structure and/or a
      freed rfcomm_dlc structure will be erroneously accessed.
      
      Therefore, after the rfcomm lock is acquired, check that the struct
      rfcomm_session is still valid by searching the rfcomm session list.
      If the session is valid then validate the d pointer by searching the
      rfcomm session list of active DLCs for the rfcomm_dlc structure
      pointed by d.
      Signed-off-by: NDean Jenkins <Dean_Jenkins@mentor.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      c06f7d53
    • D
      Bluetooth: Avoid rfcomm_session_timeout using freed session · fea7b02f
      Dean Jenkins 提交于
      Use del_timer_sync() instead of del_timer() as this ensures
      that rfcomm_session_timeout() is not running on a different
      CPU when rfcomm_session_put() is called. This avoids a race
      condition on SMP systems because potentially
      rfcomm_session_timeout() could reuse the freed RFCOMM session
      structure caused by the execution of rfcomm_session_put().
      
      Note that this modification makes the reason for the RFCOMM
      session refcnt mechanism redundant.
      Signed-off-by: NDean Jenkins <Dean_Jenkins@mentor.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      fea7b02f
  8. 05 2月, 2013 1 次提交
  9. 11 10月, 2012 1 次提交
  10. 28 9月, 2012 2 次提交
  11. 05 6月, 2012 2 次提交
  12. 15 2月, 2012 1 次提交
    • O
      Bluetooth: Fix RFCOMM session reference counting issue · cf33e77b
      Octavian Purdila 提交于
      There is an imbalance in the rfcomm_session_hold / rfcomm_session_put
      operations which causes the following crash:
      
      [  685.010159] BUG: unable to handle kernel paging request at 6b6b6b6b
      [  685.010169] IP: [<c149d76d>] rfcomm_process_dlcs+0x1b/0x15e
      [  685.010181] *pdpt = 000000002d665001 *pde = 0000000000000000
      [  685.010191] Oops: 0000 [#1] PREEMPT SMP
      [  685.010247]
      [  685.010255] Pid: 947, comm: krfcommd Tainted: G         C  3.0.16-mid8-dirty #44
      [  685.010266] EIP: 0060:[<c149d76d>] EFLAGS: 00010246 CPU: 1
      [  685.010274] EIP is at rfcomm_process_dlcs+0x1b/0x15e
      [  685.010281] EAX: e79f551c EBX: 6b6b6b6b ECX: 00000007 EDX: e79f40b4
      [  685.010288] ESI: e79f4060 EDI: ed4e1f70 EBP: ed4e1f68 ESP: ed4e1f50
      [  685.010295]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      [  685.010303] Process krfcommd (pid: 947, ti=ed4e0000 task=ed43e5e0 task.ti=ed4e0000)
      [  685.010308] Stack:
      [  685.010312]  ed4e1f68 c149eb53 e5925150 e79f4060 ed500000 ed4e1f70 ed4e1f80 c149ec10
      [  685.010331]  00000000 ed43e5e0 00000000 ed4e1f90 ed4e1f9c c149ec87 0000bf54 00000000
      [  685.010348]  00000000 ee03bf54 c149ec37 ed4e1fe4 c104fe01 00000000 00000000 00000000
      [  685.010367] Call Trace:
      [  685.010376]  [<c149eb53>] ? rfcomm_process_rx+0x6e/0x74
      [  685.010387]  [<c149ec10>] rfcomm_process_sessions+0xb7/0xde
      [  685.010398]  [<c149ec87>] rfcomm_run+0x50/0x6d
      [  685.010409]  [<c149ec37>] ? rfcomm_process_sessions+0xde/0xde
      [  685.010419]  [<c104fe01>] kthread+0x63/0x68
      [  685.010431]  [<c104fd9e>] ? __init_kthread_worker+0x42/0x42
      [  685.010442]  [<c14dae82>] kernel_thread_helper+0x6/0xd
      
      This issue has been brought up earlier here:
      
      https://lkml.org/lkml/2011/5/21/127
      
      The issue appears to be the rfcomm_session_put in rfcomm_recv_ua. This
      operation doesn't seem be to required as for the non-initiator case we
      have the rfcomm_process_rx doing an explicit put and in the initiator
      case the last dlc_unlink will drive the reference counter to 0.
      
      There have been several attempts to fix these issue:
      
      6c2718da Bluetooth: Do not call rfcomm_session_put() for RFCOMM UA on closed socket
      683d949a Bluetooth: Never deallocate a session when some DLC points to it
      
      but AFAICS they do not fix the issue just make it harder to reproduce.
      Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com>
      Signed-off-by: NGopala Krishna Murala <gopala.krishna.murala@intel.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      cf33e77b
  13. 13 2月, 2012 1 次提交
    • O
      Bluetooth: Fix RFCOMM session reference counting issue · 66f01296
      Octavian Purdila 提交于
      There is an imbalance in the rfcomm_session_hold / rfcomm_session_put
      operations which causes the following crash:
      
      [  685.010159] BUG: unable to handle kernel paging request at 6b6b6b6b
      [  685.010169] IP: [<c149d76d>] rfcomm_process_dlcs+0x1b/0x15e
      [  685.010181] *pdpt = 000000002d665001 *pde = 0000000000000000
      [  685.010191] Oops: 0000 [#1] PREEMPT SMP
      [  685.010247]
      [  685.010255] Pid: 947, comm: krfcommd Tainted: G         C  3.0.16-mid8-dirty #44
      [  685.010266] EIP: 0060:[<c149d76d>] EFLAGS: 00010246 CPU: 1
      [  685.010274] EIP is at rfcomm_process_dlcs+0x1b/0x15e
      [  685.010281] EAX: e79f551c EBX: 6b6b6b6b ECX: 00000007 EDX: e79f40b4
      [  685.010288] ESI: e79f4060 EDI: ed4e1f70 EBP: ed4e1f68 ESP: ed4e1f50
      [  685.010295]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      [  685.010303] Process krfcommd (pid: 947, ti=ed4e0000 task=ed43e5e0 task.ti=ed4e0000)
      [  685.010308] Stack:
      [  685.010312]  ed4e1f68 c149eb53 e5925150 e79f4060 ed500000 ed4e1f70 ed4e1f80 c149ec10
      [  685.010331]  00000000 ed43e5e0 00000000 ed4e1f90 ed4e1f9c c149ec87 0000bf54 00000000
      [  685.010348]  00000000 ee03bf54 c149ec37 ed4e1fe4 c104fe01 00000000 00000000 00000000
      [  685.010367] Call Trace:
      [  685.010376]  [<c149eb53>] ? rfcomm_process_rx+0x6e/0x74
      [  685.010387]  [<c149ec10>] rfcomm_process_sessions+0xb7/0xde
      [  685.010398]  [<c149ec87>] rfcomm_run+0x50/0x6d
      [  685.010409]  [<c149ec37>] ? rfcomm_process_sessions+0xde/0xde
      [  685.010419]  [<c104fe01>] kthread+0x63/0x68
      [  685.010431]  [<c104fd9e>] ? __init_kthread_worker+0x42/0x42
      [  685.010442]  [<c14dae82>] kernel_thread_helper+0x6/0xd
      
      This issue has been brought up earlier here:
      
      https://lkml.org/lkml/2011/5/21/127
      
      The issue appears to be the rfcomm_session_put in rfcomm_recv_ua. This
      operation doesn't seem be to required as for the non-initiator case we
      have the rfcomm_process_rx doing an explicit put and in the initiator
      case the last dlc_unlink will drive the reference counter to 0.
      
      There have been several attempts to fix these issue:
      
      6c2718da Bluetooth: Do not call rfcomm_session_put() for RFCOMM UA on closed socket
      683d949a Bluetooth: Never deallocate a session when some DLC points to it
      
      but AFAICS they do not fix the issue just make it harder to reproduce.
      Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com>
      Signed-off-by: NGopala Krishna Murala <gopala.krishna.murala@intel.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      66f01296
  14. 28 12月, 2011 1 次提交
  15. 23 12月, 2011 1 次提交
  16. 20 12月, 2011 1 次提交
  17. 19 12月, 2011 1 次提交
  18. 08 11月, 2011 3 次提交
    • S
      Bluetooth: rfcomm: Fix sleep in invalid context in rfcomm_security_cfm · db54467a
      Szymon Janc 提交于
      This was triggered by turning off encryption on ACL link when rfcomm
      was using high security. rfcomm_security_cfm (which is called from rx
      task) was closing DLC and this involves sending disconnect message
      (and locking socket).
      
      Move closing DLC to rfcomm_process_dlcs and only flag DLC for closure
      in rfcomm_security_cfm.
      
      BUG: sleeping function called from invalid context at net/core/sock.c:2032
      in_atomic(): 1, irqs_disabled(): 0, pid: 1788, name: kworker/0:3
      [<c0068a08>] (unwind_backtrace+0x0/0x108) from [<c05e25dc>] (dump_stack+0x20/0x24)
      [<c05e25dc>] (dump_stack+0x20/0x24) from [<c0087ba8>] (__might_sleep+0x110/0x12c)
      [<c0087ba8>] (__might_sleep+0x110/0x12c) from [<c04801d8>] (lock_sock_nested+0x2c/0x64)
      [<c04801d8>] (lock_sock_nested+0x2c/0x64) from [<c05670c8>] (l2cap_sock_sendmsg+0x58/0xcc)
      [<c05670c8>] (l2cap_sock_sendmsg+0x58/0xcc) from [<c047cf6c>] (sock_sendmsg+0xb0/0xd0)
      [<c047cf6c>] (sock_sendmsg+0xb0/0xd0) from [<c047cfc8>] (kernel_sendmsg+0x3c/0x44)
      [<c047cfc8>] (kernel_sendmsg+0x3c/0x44) from [<c056b0e8>] (rfcomm_send_frame+0x50/0x58)
      [<c056b0e8>] (rfcomm_send_frame+0x50/0x58) from [<c056b168>] (rfcomm_send_disc+0x78/0x80)
      [<c056b168>] (rfcomm_send_disc+0x78/0x80) from [<c056b9f4>] (__rfcomm_dlc_close+0x2d0/0x2fc)
      [<c056b9f4>] (__rfcomm_dlc_close+0x2d0/0x2fc) from [<c056bbac>] (rfcomm_security_cfm+0x140/0x1e0)
      [<c056bbac>] (rfcomm_security_cfm+0x140/0x1e0) from [<c0555ec0>] (hci_event_packet+0x1ce8/0x4d84)
      [<c0555ec0>] (hci_event_packet+0x1ce8/0x4d84) from [<c0550380>] (hci_rx_task+0x1d0/0x2d0)
      [<c0550380>] (hci_rx_task+0x1d0/0x2d0) from [<c009ee04>] (tasklet_action+0x138/0x1e4)
      [<c009ee04>] (tasklet_action+0x138/0x1e4) from [<c009f21c>] (__do_softirq+0xcc/0x274)
      [<c009f21c>] (__do_softirq+0xcc/0x274) from [<c009f6c0>] (do_softirq+0x60/0x6c)
      [<c009f6c0>] (do_softirq+0x60/0x6c) from [<c009f794>] (local_bh_enable_ip+0xc8/0xd4)
      [<c009f794>] (local_bh_enable_ip+0xc8/0xd4) from [<c05e5804>] (_raw_spin_unlock_bh+0x48/0x4c)
      [<c05e5804>] (_raw_spin_unlock_bh+0x48/0x4c) from [<c040d470>] (data_from_chip+0xf4/0xaec)
      [<c040d470>] (data_from_chip+0xf4/0xaec) from [<c04136c0>] (send_skb_to_core+0x40/0x178)
      [<c04136c0>] (send_skb_to_core+0x40/0x178) from [<c04139f4>] (cg2900_hu_receive+0x15c/0x2d0)
      [<c04139f4>] (cg2900_hu_receive+0x15c/0x2d0) from [<c0414cb8>] (hci_uart_tty_receive+0x74/0xa0)
      [<c0414cb8>] (hci_uart_tty_receive+0x74/0xa0) from [<c02cbd9c>] (flush_to_ldisc+0x188/0x198)
      [<c02cbd9c>] (flush_to_ldisc+0x188/0x198) from [<c00b2774>] (process_one_work+0x144/0x4b8)
      [<c00b2774>] (process_one_work+0x144/0x4b8) from [<c00b2e8c>] (worker_thread+0x198/0x468)
      [<c00b2e8c>] (worker_thread+0x198/0x468) from [<c00b9bc8>] (kthread+0x98/0xa0)
      [<c00b9bc8>] (kthread+0x98/0xa0) from [<c0061744>] (kernel_thread_exit+0x0/0x8)
      Signed-off-by: NSzymon Janc <szymon.janc@tieto.com>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      db54467a
    • L
    • L
      Bluetooth: replace list_for_each with list_for_each_entry whenever possible · 8035ded4
      Luiz Augusto von Dentz 提交于
      When all items in the list have the same type there is no much of a point
      to use list_for_each except if you want to use the list pointer itself.
      Signed-off-by: NLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      8035ded4
  19. 15 10月, 2011 1 次提交
    • S
      Bluetooth: rfcomm: Fix sleep in invalid context in rfcomm_security_cfm · 88149db4
      Szymon Janc 提交于
      This was triggered by turning off encryption on ACL link when rfcomm
      was using high security. rfcomm_security_cfm (which is called from rx
      task) was closing DLC and this involves sending disconnect message
      (and locking socket).
      
      Move closing DLC to rfcomm_process_dlcs and only flag DLC for closure
      in rfcomm_security_cfm.
      
      BUG: sleeping function called from invalid context at net/core/sock.c:2032
      in_atomic(): 1, irqs_disabled(): 0, pid: 1788, name: kworker/0:3
      [<c0068a08>] (unwind_backtrace+0x0/0x108) from [<c05e25dc>] (dump_stack+0x20/0x24)
      [<c05e25dc>] (dump_stack+0x20/0x24) from [<c0087ba8>] (__might_sleep+0x110/0x12c)
      [<c0087ba8>] (__might_sleep+0x110/0x12c) from [<c04801d8>] (lock_sock_nested+0x2c/0x64)
      [<c04801d8>] (lock_sock_nested+0x2c/0x64) from [<c05670c8>] (l2cap_sock_sendmsg+0x58/0xcc)
      [<c05670c8>] (l2cap_sock_sendmsg+0x58/0xcc) from [<c047cf6c>] (sock_sendmsg+0xb0/0xd0)
      [<c047cf6c>] (sock_sendmsg+0xb0/0xd0) from [<c047cfc8>] (kernel_sendmsg+0x3c/0x44)
      [<c047cfc8>] (kernel_sendmsg+0x3c/0x44) from [<c056b0e8>] (rfcomm_send_frame+0x50/0x58)
      [<c056b0e8>] (rfcomm_send_frame+0x50/0x58) from [<c056b168>] (rfcomm_send_disc+0x78/0x80)
      [<c056b168>] (rfcomm_send_disc+0x78/0x80) from [<c056b9f4>] (__rfcomm_dlc_close+0x2d0/0x2fc)
      [<c056b9f4>] (__rfcomm_dlc_close+0x2d0/0x2fc) from [<c056bbac>] (rfcomm_security_cfm+0x140/0x1e0)
      [<c056bbac>] (rfcomm_security_cfm+0x140/0x1e0) from [<c0555ec0>] (hci_event_packet+0x1ce8/0x4d84)
      [<c0555ec0>] (hci_event_packet+0x1ce8/0x4d84) from [<c0550380>] (hci_rx_task+0x1d0/0x2d0)
      [<c0550380>] (hci_rx_task+0x1d0/0x2d0) from [<c009ee04>] (tasklet_action+0x138/0x1e4)
      [<c009ee04>] (tasklet_action+0x138/0x1e4) from [<c009f21c>] (__do_softirq+0xcc/0x274)
      [<c009f21c>] (__do_softirq+0xcc/0x274) from [<c009f6c0>] (do_softirq+0x60/0x6c)
      [<c009f6c0>] (do_softirq+0x60/0x6c) from [<c009f794>] (local_bh_enable_ip+0xc8/0xd4)
      [<c009f794>] (local_bh_enable_ip+0xc8/0xd4) from [<c05e5804>] (_raw_spin_unlock_bh+0x48/0x4c)
      [<c05e5804>] (_raw_spin_unlock_bh+0x48/0x4c) from [<c040d470>] (data_from_chip+0xf4/0xaec)
      [<c040d470>] (data_from_chip+0xf4/0xaec) from [<c04136c0>] (send_skb_to_core+0x40/0x178)
      [<c04136c0>] (send_skb_to_core+0x40/0x178) from [<c04139f4>] (cg2900_hu_receive+0x15c/0x2d0)
      [<c04139f4>] (cg2900_hu_receive+0x15c/0x2d0) from [<c0414cb8>] (hci_uart_tty_receive+0x74/0xa0)
      [<c0414cb8>] (hci_uart_tty_receive+0x74/0xa0) from [<c02cbd9c>] (flush_to_ldisc+0x188/0x198)
      [<c02cbd9c>] (flush_to_ldisc+0x188/0x198) from [<c00b2774>] (process_one_work+0x144/0x4b8)
      [<c00b2774>] (process_one_work+0x144/0x4b8) from [<c00b2e8c>] (worker_thread+0x198/0x468)
      [<c00b2e8c>] (worker_thread+0x198/0x468) from [<c00b9bc8>] (kthread+0x98/0xa0)
      [<c00b9bc8>] (kthread+0x98/0xa0) from [<c0061744>] (kernel_thread_exit+0x0/0x8)
      Signed-off-by: NSzymon Janc <szymon.janc@tieto.com>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      88149db4
  20. 28 9月, 2011 1 次提交
  21. 12 8月, 2011 1 次提交
  22. 12 5月, 2011 1 次提交
  23. 28 4月, 2011 3 次提交
  24. 15 2月, 2011 1 次提交
  25. 20 1月, 2011 1 次提交