1. 27 2月, 2009 36 次提交
    • W
      af_key: remove some pointless conditionals before kfree_skb() · 6f961068
      Wei Yongjun 提交于
      Remove some pointless conditionals before kfree_skb().
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6f961068
    • 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
    • D
      Bluetooth: Move hci_conn_del_sysfs() back to avoid device destruct too early · 2ae9a6be
      Dave Young 提交于
      The following commit introduce a regression:
      
      	commit 7d0db0a3
      	Author: Marcel Holtmann <marcel@holtmann.org>
      	Date:   Mon Jul 14 20:13:51 2008 +0200
      
      		[Bluetooth] Use a more unique bus name for connections
      
      I get panic as following (by netconsole):
      
      [ 2709.344034] usb 5-1: new full speed USB device using uhci_hcd and address 4
      [ 2709.505776] usb 5-1: configuration #1 chosen from 1 choice
      [ 2709.569207] Bluetooth: Generic Bluetooth USB driver ver 0.4
      [ 2709.570169] usbcore: registered new interface driver btusb
      [ 2845.742781] BUG: unable to handle kernel paging request at 6b6b6c2f
      [ 2845.742958] IP: [<c015515c>] __lock_acquire+0x6c/0xa80
      [ 2845.743087] *pde = 00000000
      [ 2845.743206] Oops: 0002 [#1] SMP
      [ 2845.743377] last sysfs file: /sys/class/bluetooth/hci0/hci0:6/type
      [ 2845.743742] Modules linked in: btusb netconsole snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss rfcomm l2cap bluetooth vfat fuse snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm pl2303 snd_timer psmouse usbserial snd 3c59x e100 serio_raw soundcore i2c_i801 intel_agp mii agpgart snd_page_alloc rtc_cmos rtc_core thermal processor rtc_lib button thermal_sys sg evdev
      [ 2845.743742]
      [ 2845.743742] Pid: 0, comm: swapper Not tainted (2.6.29-rc5-smp #54) Dell DM051
      [ 2845.743742] EIP: 0060:[<c015515c>] EFLAGS: 00010002 CPU: 0
      [ 2845.743742] EIP is at __lock_acquire+0x6c/0xa80
      [ 2845.743742] EAX: 00000046 EBX: 00000046 ECX: 6b6b6b6b EDX: 00000002
      [ 2845.743742] ESI: 6b6b6b6b EDI: 00000000 EBP: c064fd14 ESP: c064fcc8
      [ 2845.743742]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
      [ 2845.743742] Process swapper (pid: 0, ti=c064e000 task=c05d1400 task.ti=c064e000)
      [ 2845.743742] Stack:
      [ 2845.743742]  c05d1400 00000002 c05d1400 00000001 00000002 00000000 f65388dc c05d1400
      [ 2845.743742]  6b6b6b6b 00000292 c064fd0c c0153732 00000000 00000000 00000001 f700fa50
      [ 2845.743742]  00000046 00000000 00000000 c064fd40 c0155be6 00000000 00000002 00000001
      [ 2845.743742] Call Trace:
      [ 2845.743742]  [<c0153732>] ? trace_hardirqs_on_caller+0x72/0x1c0
      [ 2845.743742]  [<c0155be6>] ? lock_acquire+0x76/0xa0
      [ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
      [ 2845.743742]  [<c046c885>] ? _spin_lock_irqsave+0x45/0x80
      [ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
      [ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
      [ 2845.743742]  [<c03e1f94>] ? skb_queue_purge+0x14/0x20
      [ 2845.743742]  [<f8171f5a>] ? hci_conn_del+0x10a/0x1c0 [bluetooth]
      [ 2845.743742]  [<f81399c9>] ? l2cap_disconn_ind+0x59/0xb0 [l2cap]
      [ 2845.743742]  [<f81795ce>] ? hci_conn_del_sysfs+0x8e/0xd0 [bluetooth]
      [ 2845.743742]  [<f8175758>] ? hci_event_packet+0x5f8/0x31c0 [bluetooth]
      [ 2845.743742]  [<c03dfe19>] ? sock_def_readable+0x59/0x80
      [ 2845.743742]  [<c046c14d>] ? _read_unlock+0x1d/0x20
      [ 2845.743742]  [<f8178aa9>] ? hci_send_to_sock+0xe9/0x1d0 [bluetooth]
      [ 2845.743742]  [<c015388b>] ? trace_hardirqs_on+0xb/0x10
      [ 2845.743742]  [<f816fa6a>] ? hci_rx_task+0x2ba/0x490 [bluetooth]
      [ 2845.743742]  [<c0133661>] ? tasklet_action+0x31/0xc0
      [ 2845.743742]  [<c013367c>] ? tasklet_action+0x4c/0xc0
      [ 2845.743742]  [<c0132eb7>] ? __do_softirq+0xa7/0x170
      [ 2845.743742]  [<c0116dec>] ? ack_apic_level+0x5c/0x1c0
      [ 2845.743742]  [<c0132fd7>] ? do_softirq+0x57/0x60
      [ 2845.743742]  [<c01333dc>] ? irq_exit+0x7c/0x90
      [ 2845.743742]  [<c01055bb>] ? do_IRQ+0x4b/0x90
      [ 2845.743742]  [<c01333d5>] ? irq_exit+0x75/0x90
      [ 2845.743742]  [<c010392c>] ? common_interrupt+0x2c/0x34
      [ 2845.743742]  [<c010a14f>] ? mwait_idle+0x4f/0x70
      [ 2845.743742]  [<c0101c05>] ? cpu_idle+0x65/0xb0
      [ 2845.743742]  [<c045731e>] ? rest_init+0x4e/0x60
      [ 2845.743742] Code: 0f 84 69 02 00 00 83 ff 07 0f 87 1e 06 00 00 85 ff 0f 85 08 05 00 00 8b 4d cc 8b 49 04 85 c9 89 4d d4 0f 84 f7 04 00 00 8b 75 d4 <f0> ff 86 c4 00 00 00 89 f0 e8 56 a9 ff ff 85 c0 0f 85 6e 03 00
      [ 2845.743742] EIP: [<c015515c>] __lock_acquire+0x6c/0xa80 SS:ESP 0068:c064fcc8
      [ 2845.743742] ---[ end trace 4c985b38f022279f ]---
      [ 2845.743742] Kernel panic - not syncing: Fatal exception in interrupt
      [ 2845.743742] ------------[ cut here ]------------
      [ 2845.743742] WARNING: at kernel/smp.c:329 smp_call_function_many+0x151/0x200()
      [ 2845.743742] Hardware name: Dell DM051
      [ 2845.743742] Modules linked in: btusb netconsole snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss rfcomm l2cap bluetooth vfat fuse snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm pl2303 snd_timer psmouse usbserial snd 3c59x e100 serio_raw soundcore i2c_i801 intel_agp mii agpgart snd_page_alloc rtc_cmos rtc_core thermal processor rtc_lib button thermal_sys sg evdev
      [ 2845.743742] Pid: 0, comm: swapper Tainted: G      D    2.6.29-rc5-smp #54
      [ 2845.743742] Call Trace:
      [ 2845.743742]  [<c012e076>] warn_slowpath+0x86/0xa0
      [ 2845.743742]  [<c015041b>] ? trace_hardirqs_off+0xb/0x10
      [ 2845.743742]  [<c0146384>] ? up+0x14/0x40
      [ 2845.743742]  [<c012e661>] ? release_console_sem+0x31/0x1e0
      [ 2845.743742]  [<c046c8ab>] ? _spin_lock_irqsave+0x6b/0x80
      [ 2845.743742]  [<c015041b>] ? trace_hardirqs_off+0xb/0x10
      [ 2845.743742]  [<c046c900>] ? _read_lock_irqsave+0x40/0x80
      [ 2845.743742]  [<c012e7f2>] ? release_console_sem+0x1c2/0x1e0
      [ 2845.743742]  [<c0146384>] ? up+0x14/0x40
      [ 2845.743742]  [<c015041b>] ? trace_hardirqs_off+0xb/0x10
      [ 2845.743742]  [<c046a3d7>] ? __mutex_unlock_slowpath+0x97/0x160
      [ 2845.743742]  [<c046a563>] ? mutex_trylock+0xb3/0x180
      [ 2845.743742]  [<c046a4a8>] ? mutex_unlock+0x8/0x10
      [ 2845.743742]  [<c015b991>] smp_call_function_many+0x151/0x200
      [ 2845.743742]  [<c010a1a0>] ? stop_this_cpu+0x0/0x40
      [ 2845.743742]  [<c015ba61>] smp_call_function+0x21/0x30
      [ 2845.743742]  [<c01137ae>] native_smp_send_stop+0x1e/0x50
      [ 2845.743742]  [<c012e0f5>] panic+0x55/0x110
      [ 2845.743742]  [<c01065a8>] oops_end+0xb8/0xc0
      [ 2845.743742]  [<c010668f>] die+0x4f/0x70
      [ 2845.743742]  [<c011a8c9>] do_page_fault+0x269/0x610
      [ 2845.743742]  [<c011a660>] ? do_page_fault+0x0/0x610
      [ 2845.743742]  [<c046cbaf>] error_code+0x77/0x7c
      [ 2845.743742]  [<c015515c>] ? __lock_acquire+0x6c/0xa80
      [ 2845.743742]  [<c0153732>] ? trace_hardirqs_on_caller+0x72/0x1c0
      [ 2845.743742]  [<c0155be6>] lock_acquire+0x76/0xa0
      [ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
      [ 2845.743742]  [<c046c885>] _spin_lock_irqsave+0x45/0x80
      [ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
      [ 2845.743742]  [<c03e1aad>] skb_dequeue+0x1d/0x70
      [ 2845.743742]  [<c03e1f94>] skb_queue_purge+0x14/0x20
      [ 2845.743742]  [<f8171f5a>] hci_conn_del+0x10a/0x1c0 [bluetooth]
      [ 2845.743742]  [<f81399c9>] ? l2cap_disconn_ind+0x59/0xb0 [l2cap]
      [ 2845.743742]  [<f81795ce>] ? hci_conn_del_sysfs+0x8e/0xd0 [bluetooth]
      [ 2845.743742]  [<f8175758>] hci_event_packet+0x5f8/0x31c0 [bluetooth]
      [ 2845.743742]  [<c03dfe19>] ? sock_def_readable+0x59/0x80
      [ 2845.743742]  [<c046c14d>] ? _read_unlock+0x1d/0x20
      [ 2845.743742]  [<f8178aa9>] ? hci_send_to_sock+0xe9/0x1d0 [bluetooth]
      [ 2845.743742]  [<c015388b>] ? trace_hardirqs_on+0xb/0x10
      [ 2845.743742]  [<f816fa6a>] hci_rx_task+0x2ba/0x490 [bluetooth]
      [ 2845.743742]  [<c0133661>] ? tasklet_action+0x31/0xc0
      [ 2845.743742]  [<c013367c>] tasklet_action+0x4c/0xc0
      [ 2845.743742]  [<c0132eb7>] __do_softirq+0xa7/0x170
      [ 2845.743742]  [<c0116dec>] ? ack_apic_level+0x5c/0x1c0
      [ 2845.743742]  [<c0132fd7>] do_softirq+0x57/0x60
      [ 2845.743742]  [<c01333dc>] irq_exit+0x7c/0x90
      [ 2845.743742]  [<c01055bb>] do_IRQ+0x4b/0x90
      [ 2845.743742]  [<c01333d5>] ? irq_exit+0x75/0x90
      [ 2845.743742]  [<c010392c>] common_interrupt+0x2c/0x34
      [ 2845.743742]  [<c010a14f>] ? mwait_idle+0x4f/0x70
      [ 2845.743742]  [<c0101c05>] cpu_idle+0x65/0xb0
      [ 2845.743742]  [<c045731e>] rest_init+0x4e/0x60
      [ 2845.743742] ---[ end trace 4c985b38f02227a0 ]---
      [ 2845.743742] ------------[ cut here ]------------
      [ 2845.743742] WARNING: at kernel/smp.c:226 smp_call_function_single+0x8e/0x110()
      [ 2845.743742] Hardware name: Dell DM051
      [ 2845.743742] Modules linked in: btusb netconsole snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss rfcomm l2cap bluetooth vfat fuse snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm pl2303 snd_timer psmouse usbserial snd 3c59x e100 serio_raw soundcore i2c_i801 intel_agp mii agpgart snd_page_alloc rtc_cmos rtc_core thermal processor rtc_lib button thermal_sys sg evdev
      [ 2845.743742] Pid: 0, comm: swapper Tainted: G      D W  2.6.29-rc5-smp #54
      [ 2845.743742] Call Trace:
      [ 2845.743742]  [<c012e076>] warn_slowpath+0x86/0xa0
      [ 2845.743742]  [<c012e000>] ? warn_slowpath+0x10/0xa0
      [ 2845.743742]  [<c015041b>] ? trace_hardirqs_off+0xb/0x10
      [ 2845.743742]  [<c0146384>] ? up+0x14/0x40
      [ 2845.743742]  [<c012e661>] ? release_console_sem+0x31/0x1e0
      [ 2845.743742]  [<c046c8ab>] ? _spin_lock_irqsave+0x6b/0x80
      [ 2845.743742]  [<c015041b>] ? trace_hardirqs_off+0xb/0x10
      [ 2845.743742]  [<c046c900>] ? _read_lock_irqsave+0x40/0x80
      [ 2845.743742]  [<c012e7f2>] ? release_console_sem+0x1c2/0x1e0
      [ 2845.743742]  [<c0146384>] ? up+0x14/0x40
      [ 2845.743742]  [<c015b7be>] smp_call_function_single+0x8e/0x110
      [ 2845.743742]  [<c010a1a0>] ? stop_this_cpu+0x0/0x40
      [ 2845.743742]  [<c026d23f>] ? cpumask_next_and+0x1f/0x40
      [ 2845.743742]  [<c015b95a>] smp_call_function_many+0x11a/0x200
      [ 2845.743742]  [<c010a1a0>] ? stop_this_cpu+0x0/0x40
      [ 2845.743742]  [<c015ba61>] smp_call_function+0x21/0x30
      [ 2845.743742]  [<c01137ae>] native_smp_send_stop+0x1e/0x50
      [ 2845.743742]  [<c012e0f5>] panic+0x55/0x110
      [ 2845.743742]  [<c01065a8>] oops_end+0xb8/0xc0
      [ 2845.743742]  [<c010668f>] die+0x4f/0x70
      [ 2845.743742]  [<c011a8c9>] do_page_fault+0x269/0x610
      [ 2845.743742]  [<c011a660>] ? do_page_fault+0x0/0x610
      [ 2845.743742]  [<c046cbaf>] error_code+0x77/0x7c
      [ 2845.743742]  [<c015515c>] ? __lock_acquire+0x6c/0xa80
      [ 2845.743742]  [<c0153732>] ? trace_hardirqs_on_caller+0x72/0x1c0
      [ 2845.743742]  [<c0155be6>] lock_acquire+0x76/0xa0
      [ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
      [ 2845.743742]  [<c046c885>] _spin_lock_irqsave+0x45/0x80
      [ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
      [ 2845.743742]  [<c03e1aad>] skb_dequeue+0x1d/0x70
      [ 2845.743742]  [<c03e1f94>] skb_queue_purge+0x14/0x20
      [ 2845.743742]  [<f8171f5a>] hci_conn_del+0x10a/0x1c0 [bluetooth]
      [ 2845.743742]  [<f81399c9>] ? l2cap_disconn_ind+0x59/0xb0 [l2cap]
      [ 2845.743742]  [<f81795ce>] ? hci_conn_del_sysfs+0x8e/0xd0 [bluetooth]
      [ 2845.743742]  [<f8175758>] hci_event_packet+0x5f8/0x31c0 [bluetooth]
      [ 2845.743742]  [<c03dfe19>] ? sock_def_readable+0x59/0x80
      [ 2845.743742]  [<c046c14d>] ? _read_unlock+0x1d/0x20
      [ 2845.743742]  [<f8178aa9>] ? hci_send_to_sock+0xe9/0x1d0 [bluetooth]
      [ 2845.743742]  [<c015388b>] ? trace_hardirqs_on+0xb/0x10
      [ 2845.743742]  [<f816fa6a>] hci_rx_task+0x2ba/0x490 [bluetooth]
      [ 2845.743742]  [<c0133661>] ? tasklet_action+0x31/0xc0
      [ 2845.743742]  [<c013367c>] tasklet_action+0x4c/0xc0
      [ 2845.743742]  [<c0132eb7>] __do_softirq+0xa7/0x170
      [ 2845.743742]  [<c0116dec>] ? ack_apic_level+0x5c/0x1c0
      [ 2845.743742]  [<c0132fd7>] do_softirq+0x57/0x60
      [ 2845.743742]  [<c01333dc>] irq_exit+0x7c/0x90
      [ 2845.743742]  [<c01055bb>] do_IRQ+0x4b/0x90
      [ 2845.743742]  [<c01333d5>] ? irq_exit+0x75/0x90
      [ 2845.743742]  [<c010392c>] common_interrupt+0x2c/0x34
      [ 2845.743742]  [<c010a14f>] ? mwait_idle+0x4f/0x70
      [ 2845.743742]  [<c0101c05>] cpu_idle+0x65/0xb0
      [ 2845.743742]  [<c045731e>] rest_init+0x4e/0x60
      [ 2845.743742] ---[ end trace 4c985b38f02227a1 ]---
      [ 2845.743742] Rebooting in 3 seconds..
      
      My logitec bluetooth mouse trying connect to pc, but
      pc side reject the connection again and again. then panic happens.
      
      The reason is due to hci_conn_del_sysfs now called in hci_event_packet,
      the del work is done in a workqueue, so it's possible done before
      skb_queue_purge called.
      
      I move the hci_conn_del_sysfs after skb_queue_purge just as that before
      marcel's commit.
      
      Remove the hci_conn_del_sysfs in hci_conn_hash_flush as well due to
      hci_conn_del will deal with the work.
      Signed-off-by: NDave Young <hidave.darkstar@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      2ae9a6be
    • 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: Fix RFCOMM usage of in-kernel L2CAP sockets · 37e62f55
      Marcel Holtmann 提交于
      The CID value of L2CAP sockets need to be set to zero. All userspace
      applications do this via memset() on the sockaddr_l2 structure. The
      RFCOMM implementation uses in-kernel L2CAP sockets and so it has to
      make sure that l2_cid is set to zero.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      37e62f55
    • 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: Change RFCOMM to use BT_CONNECT2 for BT_DEFER_SETUP · 8bf47941
      Marcel Holtmann 提交于
      When BT_DEFER_SETUP is enabled on a RFCOMM socket, then switch its
      current state from BT_OPEN to BT_CONNECT2. This gives the Bluetooth
      core a unified way to handle L2CAP and RFCOMM sockets. The BT_CONNECT2
      state is designated for incoming connections.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      8bf47941
    • M
      Bluetooth: Fix poll() misbehavior when using BT_DEFER_SETUP · d5f2d2be
      Marcel Holtmann 提交于
      When BT_DEFER_SETUP has been enabled on a Bluetooth socket it keeps
      signaling POLLIN all the time. This is a wrong behavior. The POLLIN
      should only be signaled if the client socket is in BT_CONNECT2 state
      and the parent has been BT_DEFER_SETUP enabled.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      d5f2d2be
    • M
      Bluetooth: Set authentication requirement before requesting it · 96a31833
      Marcel Holtmann 提交于
      The authentication requirement got only updated when the security level
      increased. This is a wrong behavior. The authentication requirement is
      read by the Bluetooth daemon to make proper decisions when handling the
      IO capabilities exchange. So set the value that is currently expected by
      the higher layers like L2CAP and RFCOMM.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      96a31833
    • 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
    • M
      Bluetooth: Fix double L2CAP connection request · 6a8d3010
      Marcel Holtmann 提交于
      If the remote L2CAP server uses authentication pending stage and
      encryption is enabled it can happen that a L2CAP connection request is
      sent twice due to a race condition in the connection state machine.
      
      When the remote side indicates any kind of connection pending, then
      track this state and skip sending of L2CAP commands for this period.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      6a8d3010
    • M
      Bluetooth: Fix race condition with L2CAP information request · 984947dc
      Marcel Holtmann 提交于
      When two L2CAP connections are requested quickly after the ACL link has
      been established there exists a window for a race condition where a
      connection request is sent before the information response has been
      received. Any connection request should only be sent after an exchange
      of the extended features mask has been finished.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      984947dc
    • M
      Bluetooth: Set authentication requirements if not available · 657e17b0
      Marcel Holtmann 提交于
      When no authentication requirements are selected, but an outgoing or
      incoming connection has requested any kind of security enforcement,
      then set these authentication requirements.
      
      This ensures that the userspace always gets informed about the
      authentication requirements (if available). Only when no security
      enforcement has happened, the kernel will signal invalid requirements.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      657e17b0
    • M
      Bluetooth: Use general bonding whenever possible · 0684e5f9
      Marcel Holtmann 提交于
      When receiving incoming connection to specific services, always use
      general bonding. This ensures that the link key gets stored and can be
      used for further authentications.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      0684e5f9
    • M
      Bluetooth: Add SCO fallback for eSCO connection attempts · efc7688b
      Marcel Holtmann 提交于
      When attempting to setup eSCO connections it can happen that some link
      manager implementations fail to properly negotiate the eSCO parameters
      and thus fail the eSCO setup. Normally the link manager is responsible
      for the negotiation of the parameters and actually fallback to SCO if
      no agreement can be reached. In cases where the link manager is just too
      stupid, then at least try to establish a SCO link if eSCO fails.
      
      For the Bluetooth devices with EDR support this includes handling packet
      types of EDR basebands. This is particular tricky since for the EDR the
      logic of enabling/disabling one specific packet type is turned around.
      This fix contains an extra bitmask to disable eSCO EDR packet when
      trying to fallback to a SCO connection.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      efc7688b
    • M
      Bluetooth: Don't check encryption for L2CAP raw sockets · 255c7601
      Marcel Holtmann 提交于
      For L2CAP sockets with medium and high security requirement a missing
      encryption will enforce the closing of the link. For the L2CAP raw
      sockets this is not needed, so skip that check.
      
      This fixes a crash when pairing Bluetooth 2.0 (and earlier) devices
      since the L2CAP state machine got confused and then locked up the whole
      system.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      255c7601
    • J
      Bluetooth: When encryption is dropped, do not send RFCOMM packets · 6e1031a4
      Jaikumar Ganesh 提交于
      During a role change with pre-Bluetooth 2.1 devices, the remote side drops
      the encryption of the RFCOMM connection. We allow a grace period for the
      encryption to be re-established, before dropping the connection. During
      this grace period, the RFCOMM_SEC_PENDING flag is set. Check this flag
      before sending RFCOMM packets.
      Signed-off-by: NJaikumar Ganesh <jaikumar@google.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      6e1031a4
    • D
      Bluetooth: Remove CONFIG_DEBUG_LOCK_ALLOC ifdefs · dd2efd03
      Dave Young 提交于
      Due to lockdep changes, the CONFIG_DEBUG_LOCK_ALLOC ifdef is not needed
      now. So just remove it here.
      
      The following commit fixed the !lockdep build warnings:
      
      commit e8f6fbf6
      Author: Ingo Molnar <mingo@elte.hu>
      Date:   Wed Nov 12 01:38:36 2008 +0000
      
          lockdep: include/linux/lockdep.h - fix warning in net/bluetooth/af_bluetooth.c
      Signed-off-by: NDave Young <hidave.darkstar@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      dd2efd03
    • M
      Bluetooth: Update version numbers · 5f9018af
      Marcel Holtmann 提交于
      With the support for the enhanced security model and the support for
      deferring connection setup, it is a good idea to increase various
      version numbers.
      
      This is purely cosmetic and has no effect on the behavior, but can
      be really helpful when debugging problems in different kernel versions.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      5f9018af
    • M
      Bluetooth: Restrict application of socket options · 0588d94f
      Marcel Holtmann 提交于
      The new socket options should only be evaluated for SOL_BLUETOOTH level
      and not for every other level. Previously this causes some minor issues
      when detecting if a kernel with certain features is available.
      
      Also restrict BT_SECURITY to SOCK_SEQPACKET for L2CAP and SOCK_STREAM for
      the RFCOMM protocol.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      0588d94f
    • M
      Bluetooth: Disconnect L2CAP connections without encryption · f62e4323
      Marcel Holtmann 提交于
      For L2CAP connections with high security setting, the link will be
      immediately dropped when the encryption gets disabled. For L2CAP
      connections with medium security there will be grace period where
      the remote device has the chance to re-enable encryption. If it
      doesn't happen then the link will also be disconnected.
      
      The requirement for the grace period with medium security comes from
      Bluetooth 2.0 and earlier devices that require role switching.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      f62e4323
    • 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: Replace L2CAP link mode with security level · 2af6b9d5
      Marcel Holtmann 提交于
      Change the L2CAP internals to use the new security levels and remove
      the link mode details.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      2af6b9d5
    • M
      Bluetooth: Add enhanced security model for Simple Pairing · 8c1b2355
      Marcel Holtmann 提交于
      The current security model is based around the flags AUTH, ENCRYPT and
      SECURE. Starting with support for the Bluetooth 2.1 specification this is
      no longer sufficient. The different security levels are now defined as
      SDP, LOW, MEDIUM and SECURE.
      
      Previously it was possible to set each security independently, but this
      actually doesn't make a lot of sense. For Bluetooth the encryption depends
      on a previous successful authentication. Also you can only update your
      existing link key if you successfully created at least one before. And of
      course the update of link keys without having proper encryption in place
      is a security issue.
      
      The new security levels from the Bluetooth 2.1 specification are now
      used internally. All old settings are mapped to the new values and this
      way it ensures that old applications still work. The only limitation
      is that it is no longer possible to set authentication without also
      enabling encryption. No application should have done this anyway since
      this is actually a security issue. Without encryption the integrity of
      the authentication can't be guaranteed.
      
      As default for a new L2CAP or RFCOMM connection, the LOW security level
      is used. The only exception here are the service discovery sessions on
      PSM 1 where SDP level is used. To have similar security strength as with
      a Bluetooth 2.0 and before combination key, the MEDIUM level should be
      used. This is according to the Bluetooth specification. The MEDIUM level
      will not require any kind of man-in-the-middle (MITM) protection. Only
      the HIGH security level will require this.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      8c1b2355
    • M
      Bluetooth: Fix SCO state handling for incoming connections · c89b6e6b
      Marcel Holtmann 提交于
      When the remote device supports only SCO connections, on receipt of
      the HCI_EV_CONN_COMPLETE event packet, the connect state is changed to
      BT_CONNECTED, but the socket state is not updated. Hence, the connect()
      call times out even though the SCO connection has been successfully
      established.
      
      Based on a report by Jaikumar Ganesh <jaikumar@google.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      c89b6e6b
    • M
      Bluetooth: Reject incoming SCO connections without listeners · 71aeeaa1
      Marcel Holtmann 提交于
      All SCO and eSCO connection are auto-accepted no matter if there is a
      corresponding listening socket for them. This patch changes this and
      connection requests for SCO and eSCO without any socket are rejected.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      71aeeaa1
    • M
      Bluetooth: Add support for deferring L2CAP connection setup · f66dc81f
      Marcel Holtmann 提交于
      In order to decide if listening L2CAP 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.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      f66dc81f
    • 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
    • M
      Bluetooth: Add global deferred socket parameter · c4f912e1
      Marcel Holtmann 提交于
      The L2CAP and RFCOMM applications require support for authorization
      and the ability of rejecting incoming connection requests. The socket
      interface is not really able to support this.
      
      This patch does the ground work for a socket option to defer connection
      setup. Setting this option allows calling of accept() and then the
      first read() will trigger the final connection setup. Calling close()
      would reject the connection.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      c4f912e1
    • M
      Bluetooth: Preparation for usage of SOL_BLUETOOTH · d58daf42
      Marcel Holtmann 提交于
      The socket option levels SOL_L2CAP, SOL_RFOMM and SOL_SCO are currently
      in use by various Bluetooth applications. Going forward the common
      option level SOL_BLUETOOTH should be used. This patch prepares the clean
      split of the old and new option levels while keeping everything backward
      compatibility.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      d58daf42
    • V
      Bluetooth: Fix issue with return value of rfcomm_sock_sendmsg() · 91aa35a5
      Victor Shcherbatyuk 提交于
      In case of connection failures the rfcomm_sock_sendmsg() should return
      an error and not a 0 value.
      Signed-off-by: NVictor Shcherbatyuk <victor.shcherbatyuk@tomtom.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      91aa35a5
  2. 25 2月, 2009 4 次提交