1. 06 5月, 2014 1 次提交
  2. 15 2月, 2014 4 次提交
  3. 13 2月, 2014 1 次提交
  4. 14 10月, 2013 1 次提交
  5. 24 9月, 2013 1 次提交
  6. 08 3月, 2013 2 次提交
    • 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
  7. 08 11月, 2011 1 次提交
    • 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
  8. 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
  9. 10 6月, 2011 1 次提交
  10. 02 12月, 2010 2 次提交
  11. 12 10月, 2010 1 次提交
  12. 22 7月, 2010 1 次提交
  13. 23 8月, 2009 1 次提交
    • L
      Bluetooth: Fix rejected connection not disconnecting ACL link · 9e726b17
      Luiz Augusto von Dentz 提交于
      When using DEFER_SETUP on a RFCOMM socket, a SABM frame triggers
      authorization which when rejected send a DM response. This is fine
      according to the RFCOMM spec:
      
          the responding implementation may replace the "proper" response
          on the Multiplexer Control channel with a DM frame, sent on the
          referenced DLCI to indicate that the DLCI is not open, and that
          the responder would not grant a request to open it later either.
      
      But some stacks doesn't seems to cope with this leaving DLCI 0 open after
      receiving DM frame.
      
      To fix it properly a timer was introduced to rfcomm_session which is used
      to set a timeout when the last active DLC of a session is unlinked, this
      will give the remote stack some time to reply with a proper DISC frame on
      DLCI 0 avoiding both sides sending DISC to each other on stacks that
      follow the specification and taking care of those who don't by taking
      down DLCI 0.
      Signed-off-by: NLuiz Augusto von Dentz <luiz.dentz@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      9e726b17
  14. 04 8月, 2009 1 次提交
  15. 27 2月, 2009 3 次提交
    • M
      Bluetooth: Pause RFCOMM TX when encryption drops · 8c84b830
      Marcel Holtmann 提交于
      A role switch with devices following the Bluetooth pre-2.1 standards
      or without Encryption Pause and Resume support is not possible if
      encryption is enabled. Most newer headsets require the role switch,
      but also require that the connection is encrypted.
      
      For connections with a high security mode setting, the link will be
      immediately dropped. When the connection uses medium security mode
      setting, then a grace period is introduced where the TX is halted and
      the remote device gets a change to re-enable encryption after the
      role switch. If not re-enabled the link will be dropped.
      
      Based on initial work by Ville Tervo <ville.tervo@nokia.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      8c84b830
    • M
      Bluetooth: Replace RFCOMM link mode with security level · 9f2c8a03
      Marcel Holtmann 提交于
      Change the RFCOMM internals to use the new security levels and remove
      the link mode details.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      9f2c8a03
    • M
      Bluetooth: Add support for deferring RFCOMM connection setup · bb23c0ab
      Marcel Holtmann 提交于
      In order to decide if listening RFCOMM sockets should be accept()ed
      the BD_ADDR of the remote device needs to be known. This patch adds
      a socket option which defines a timeout for deferring the actual
      connection setup.
      
      The connection setup is done after reading from the socket for the
      first time. Until then writing to the socket returns ENOTCONN.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      bb23c0ab
  16. 15 7月, 2008 2 次提交
    • M
      [Bluetooth] Store remote modem status for RFCOMM TTY · 8b6b3da7
      Marcel Holtmann 提交于
      When switching a RFCOMM socket to a TTY, the remote modem status might
      be needed later. Currently it is lost since the original configuration
      is done via the socket interface. So store the modem status and reply
      it when the socket has been converted to a TTY.
      Signed-off-by: NDenis Kenzior <denis.kenzior@trolltech.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      8b6b3da7
    • M
      [Bluetooth] Enforce security for outgoing RFCOMM connections · 77db1980
      Marcel Holtmann 提交于
      Recent tests with various Bluetooth headsets have shown that some of
      them don't enforce authentication and encryption when connecting. All
      of them leave it up to the host stack to enforce it. Non of them should
      allow unencrypted connections, but that is how it is. So in case the
      link mode settings require authentication and/or encryption it will now
      also be enforced on outgoing RFCOMM connections. Previously this was
      only done for incoming connections.
      
      This support has a small drawback from a protocol level point of view
      since the host stack can't really tell with 100% certainty if a remote
      side is already authenticated or not. So if both sides are configured
      to enforce authentication it will be requested twice. Most Bluetooth
      chips are caching this information and thus no extra authentication
      procedure has to be triggered over-the-air, but it can happen.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      77db1980
  17. 29 1月, 2008 1 次提交
  18. 11 7月, 2007 1 次提交
  19. 03 12月, 2006 1 次提交
  20. 13 2月, 2006 1 次提交
  21. 09 11月, 2005 1 次提交
  22. 29 10月, 2005 1 次提交
  23. 09 10月, 2005 1 次提交
  24. 30 8月, 2005 2 次提交
  25. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4