1. 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
  2. 10 6月, 2011 1 次提交
  3. 02 12月, 2010 2 次提交
  4. 12 10月, 2010 1 次提交
  5. 22 7月, 2010 1 次提交
  6. 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
  7. 04 8月, 2009 1 次提交
  8. 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
  9. 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
  10. 29 1月, 2008 1 次提交
  11. 11 7月, 2007 1 次提交
  12. 03 12月, 2006 1 次提交
  13. 13 2月, 2006 1 次提交
  14. 09 11月, 2005 1 次提交
  15. 29 10月, 2005 1 次提交
  16. 09 10月, 2005 1 次提交
  17. 30 8月, 2005 2 次提交
  18. 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