1. 30 11月, 2009 1 次提交
  2. 16 11月, 2009 2 次提交
  3. 06 11月, 2009 2 次提交
  4. 20 10月, 2009 1 次提交
    • D
      bluetooth: static lock key fix · 45054dc1
      Dave Young 提交于
      When shutdown ppp connection, lockdep waring about non-static key
      will happen, it is caused by the lock is not initialized properly
      at that time.
      
      Fix with tuning the lock/skb_queue_head init order
      
      [   94.339261] INFO: trying to register non-static key.
      [   94.342509] the code is fine but needs lockdep annotation.
      [   94.342509] turning off the locking correctness validator.
      [   94.342509] Pid: 0, comm: swapper Not tainted 2.6.31-mm1 #2
      [   94.342509] Call Trace:
      [   94.342509]  [<c0248fbe>] register_lock_class+0x58/0x241
      [   94.342509]  [<c024b5df>] ? __lock_acquire+0xb57/0xb73
      [   94.342509]  [<c024ab34>] __lock_acquire+0xac/0xb73
      [   94.342509]  [<c024b7fa>] ? lock_release_non_nested+0x17b/0x1de
      [   94.342509]  [<c024b662>] lock_acquire+0x67/0x84
      [   94.342509]  [<c04cd1eb>] ? skb_dequeue+0x15/0x41
      [   94.342509]  [<c054a857>] _spin_lock_irqsave+0x2f/0x3f
      [   94.342509]  [<c04cd1eb>] ? skb_dequeue+0x15/0x41
      [   94.342509]  [<c04cd1eb>] skb_dequeue+0x15/0x41
      [   94.342509]  [<c054a648>] ? _read_unlock+0x1d/0x20
      [   94.342509]  [<c04cd641>] skb_queue_purge+0x14/0x1b
      [   94.342509]  [<fab94fdc>] l2cap_recv_frame+0xea1/0x115a [l2cap]
      [   94.342509]  [<c024b5df>] ? __lock_acquire+0xb57/0xb73
      [   94.342509]  [<c0249c04>] ? mark_lock+0x1e/0x1c7
      [   94.342509]  [<f8364963>] ? hci_rx_task+0xd2/0x1bc [bluetooth]
      [   94.342509]  [<fab95346>] l2cap_recv_acldata+0xb1/0x1c6 [l2cap]
      [   94.342509]  [<f8364997>] hci_rx_task+0x106/0x1bc [bluetooth]
      [   94.342509]  [<fab95295>] ? l2cap_recv_acldata+0x0/0x1c6 [l2cap]
      [   94.342509]  [<c02302c4>] tasklet_action+0x69/0xc1
      [   94.342509]  [<c022fbef>] __do_softirq+0x94/0x11e
      [   94.342509]  [<c022fcaf>] do_softirq+0x36/0x5a
      [   94.342509]  [<c022fe14>] irq_exit+0x35/0x68
      [   94.342509]  [<c0204ced>] do_IRQ+0x72/0x89
      [   94.342509]  [<c02038ee>] common_interrupt+0x2e/0x34
      [   94.342509]  [<c024007b>] ? pm_qos_add_requirement+0x63/0x9d
      [   94.342509]  [<c038e8a5>] ? acpi_idle_enter_bm+0x209/0x238
      [   94.342509]  [<c049d238>] cpuidle_idle_call+0x5c/0x94
      [   94.342509]  [<c02023f8>] cpu_idle+0x4e/0x6f
      [   94.342509]  [<c0534153>] rest_init+0x53/0x55
      [   94.342509]  [<c0781894>] start_kernel+0x2f0/0x2f5
      [   94.342509]  [<c0781091>] i386_start_kernel+0x91/0x96
      Reported-by: NOliver Hartkopp <oliver@hartkopp.net>
      Signed-off-by: NDave Young <hidave.darkstar@gmail.com>
      Tested-by: NOliver Hartkopp <oliver@hartkopp.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      45054dc1
  5. 07 10月, 2009 1 次提交
  6. 01 10月, 2009 1 次提交
  7. 26 8月, 2009 3 次提交
  8. 24 8月, 2009 2 次提交
  9. 23 8月, 2009 13 次提交
  10. 08 6月, 2009 6 次提交
  11. 27 2月, 2009 8 次提交
    • W
      Bluetooth: Remove some pointless conditionals before kfree_skb() · 7585b97a
      Wei Yongjun 提交于
      Remove some pointless conditionals before kfree_skb().
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      7585b97a
    • M
      Bluetooth: Permit BT_SECURITY also for L2CAP raw sockets · 2526d3d8
      Marcel Holtmann 提交于
      Userspace pairing code can be simplified if it doesn't have to fall
      back to using L2CAP_LM in the case of L2CAP raw sockets. This patch
      allows the BT_SECURITY socket option to be used for these sockets.
      Signed-off-by: NJohan Hedberg <johan.hedberg@nokia.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      2526d3d8
    • M
      Bluetooth: Disallow usage of L2CAP CID setting for now · 2a517ca6
      Marcel Holtmann 提交于
      In the future the L2CAP layer will have full support for fixed channels
      and right now it already can export the channel assignment, but for the
      functions bind() and connect() the usage of only CID 0 is allowed. This
      allows an easy detection if the kernel supports fixed channels or not,
      because otherwise it would impossible for application to tell.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      2a517ca6
    • M
      Bluetooth: Fix authentication requirements for L2CAP security check · 00ae4af9
      Marcel Holtmann 提交于
      The L2CAP layer can trigger the authentication via an ACL connection or
      later on to increase the security level. When increasing the security
      level it didn't use the same authentication requirements when triggering
      a new ACL connection. Make sure that exactly the same authentication
      requirements are used. The only exception here are the L2CAP raw sockets
      which are only used for dedicated bonding.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      00ae4af9
    • M
      Bluetooth: Ask upper layers for HCI disconnect reason · 2950f21a
      Marcel Holtmann 提交于
      Some of the qualification tests demand that in case of failures in L2CAP
      the HCI disconnect should indicate a reason why L2CAP fails. This is a
      bluntly layer violation since multiple L2CAP connections could be using
      the same ACL and thus forcing a disconnect reason is not a good idea.
      
      To comply with the Bluetooth test specification, the disconnect reason
      is now stored in the L2CAP connection structure and every time a new
      L2CAP channel is added it will set back to its default. So only in the
      case where the L2CAP channel with the disconnect reason is really the
      last one, it will propagated to the HCI layer.
      
      The HCI layer has been extended with a disconnect indication that allows
      it to ask upper layers for a disconnect reason. The upper layer must not
      support this callback and in that case it will nicely default to the
      existing behavior. If an upper layer like L2CAP can provide a disconnect
      reason that one will be used to disconnect the ACL or SCO link.
      
      No modification to the ACL disconnect timeout have been made. So in case
      of Linux to Linux connection the initiator will disconnect the ACL link
      before the acceptor side can signal the specific disconnect reason. That
      is perfectly fine since Linux doesn't make use of this value anyway. The
      L2CAP layer has a perfect valid error code for rejecting connection due
      to a security violation. It is unclear why the Bluetooth specification
      insists on having specific HCI disconnect reason.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      2950f21a
    • M
      Bluetooth: Add CID field to L2CAP socket address structure · f29972de
      Marcel Holtmann 提交于
      In preparation for L2CAP fixed channel support, the CID value of a
      L2CAP connection needs to be accessible via the socket interface. The
      CID is the connection identifier and exists as source and destination
      value. So extend the L2CAP socket address structure with this field and
      change getsockname() and getpeername() to fill it in.
      
      The bind() and connect() functions have been modified to handle L2CAP
      socket address structures of variable sizes. This makes them future
      proof if additional fields need to be added.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      f29972de
    • M
      Bluetooth: Request L2CAP fixed channel list if available · e1027a7c
      Marcel Holtmann 提交于
      If the extended features mask indicates support for fixed channels,
      request the list of available fixed channels. This also enables the
      fixed channel features bit so remote implementations can request
      information about it. Currently only the signal channel will be
      listed.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      e1027a7c
    • M
      Bluetooth: Don't enforce authentication for L2CAP PSM 1 and 3 · 435fef20
      Marcel Holtmann 提交于
      The recommendation for the L2CAP PSM 1 (SDP) is to not use any kind
      of authentication or encryption. So don't trigger authentication
      for incoming and outgoing SDP connections.
      
      For L2CAP PSM 3 (RFCOMM) there is no clear requirement, but with
      Bluetooth 2.1 the initiator is required to enable authentication
      and encryption first and this gets enforced. So there is no need
      to trigger an additional authentication step. The RFCOMM service
      security will make sure that a secure enough link key is present.
      
      When the encryption gets enabled after the SDP connection setup,
      then switch the security level from SDP to low security.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      435fef20