1. 27 Feb, 2010 3 commits
  2. 19 Oct, 2009 1 commit
    • Dave Young's avatar
      bluetooth: scheduling while atomic bug fix · f74c77cb
      Dave Young authored
      
      
      Due to driver core changes dev_set_drvdata will call kzalloc which should be
      in might_sleep context, but hci_conn_add will be called in atomic context
      
      Like dev_set_name move dev_set_drvdata to work queue function.
      
      oops as following:
      
      Oct  2 17:41:59 darkstar kernel: [  438.001341] BUG: sleeping function called from invalid context at mm/slqb.c:1546
      Oct  2 17:41:59 darkstar kernel: [  438.001345] in_atomic(): 1, irqs_disabled(): 0, pid: 2133, name: sdptool
      Oct  2 17:41:59 darkstar kernel: [  438.001348] 2 locks held by sdptool/2133:
      Oct  2 17:41:59 darkstar kernel: [  438.001350]  #0:  (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.+.}, at: [<faa1d2f5>] lock_sock+0xa/0xc [l2cap]
      Oct  2 17:41:59 darkstar kernel: [  438.001360]  #1:  (&hdev->lock){+.-.+.}, at: [<faa20e16>] l2cap_sock_connect+0x103/0x26b [l2cap]
      Oct  2 17:41:59 darkstar kernel: [  438.001371] Pid: 2133, comm: sdptool Not tainted 2.6.31-mm1 #2
      Oct  2 17:41:59 darkstar kernel: [  438.001373] Call Trace:
      Oct  2 17:41:59 darkstar kernel: [  438.001381]  [<c022433f>] __might_sleep+0xde/0xe5
      Oct  2 17:41:59 darkstar kernel: [  438.001386]  [<c0298843>] __kmalloc+0x4a/0x15a
      Oct  2 17:41:59 darkstar kernel: [  438.001392]  [<c03f0065>] ? kzalloc+0xb/0xd
      Oct  2 17:41:59 darkstar kernel: [  438.001396]  [<c03f0065>] kzalloc+0xb/0xd
      Oct  2 17:41:59 darkstar kernel: [  438.001400]  [<c03f04ff>] device_private_init+0x15/0x3d
      Oct  2 17:41:59 darkstar kernel: [  438.001405]  [<c03f24c5>] dev_set_drvdata+0x18/0x26
      Oct  2 17:41:59 darkstar kernel: [  438.001414]  [<fa51fff7>] hci_conn_init_sysfs+0x40/0xd9 [bluetooth]
      Oct  2 17:41:59 darkstar kernel: [  438.001422]  [<fa51cdc0>] ? hci_conn_add+0x128/0x186 [bluetooth]
      Oct  2 17:41:59 darkstar kernel: [  438.001429]  [<fa51ce0f>] hci_conn_add+0x177/0x186 [bluetooth]
      Oct  2 17:41:59 darkstar kernel: [  438.001437]  [<fa51cf8a>] hci_connect+0x3c/0xfb [bluetooth]
      Oct  2 17:41:59 darkstar kernel: [  438.001442]  [<faa20e87>] l2cap_sock_connect+0x174/0x26b [l2cap]
      Oct  2 17:41:59 darkstar kernel: [  438.001448]  [<c04c8df5>] sys_connect+0x60/0x7a
      Oct  2 17:41:59 darkstar kernel: [  438.001453]  [<c024b703>] ? lock_release_non_nested+0x84/0x1de
      Oct  2 17:41:59 darkstar kernel: [  438.001458]  [<c028804b>] ? might_fault+0x47/0x81
      Oct  2 17:41:59 darkstar kernel: [  438.001462]  [<c028804b>] ? might_fault+0x47/0x81
      Oct  2 17:41:59 darkstar kernel: [  438.001468]  [<c033361f>] ? __copy_from_user_ll+0x11/0xce
      Oct  2 17:41:59 darkstar kernel: [  438.001472]  [<c04c9419>] sys_socketcall+0x82/0x17b
      Oct  2 17:41:59 darkstar kernel: [  438.001477]  [<c020329d>] syscall_call+0x7/0xb
      Signed-off-by: default avatarDave Young <hidave.darkstar@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f74c77cb
  3. 15 Sep, 2009 1 commit
  4. 27 May, 2009 1 commit
    • Dave Young's avatar
      Bluetooth: Remove useless flush_work() causing lockdep warnings · 4c713189
      Dave Young authored
      The calls to flush_work() are pointless in a single thread workqueue
      and they are actually causing a lockdep warning.
      
      =============================================
      [ INFO: possible recursive locking detected ]
      2.6.30-rc6-02911-gbb803cfb #16
      ---------------------------------------------
      bluetooth/2518 is trying to acquire lock:
       (bluetooth){+.+.+.}, at: [<c0130c14>] flush_work+0x28/0xb0
      
      but task is already holding lock:
       (bluetooth){+.+.+.}, at: [<c0130424>] worker_thread+0x149/0x25e
      
      other info that might help us debug this:
      2 locks held by bluetooth/2518:
       #0:  (bluetooth){+.+.+.}, at: [<c0130424>] worker_thread+0x149/0x25e
       #1:  (&conn->work_del){+.+...}, at: [<c0130424>] worker_thread+0x149/0x25e
      
      stack backtrace:
      Pid: 2518, comm: bluetooth Not tainted 2.6.30-rc6-02911-gbb803cfb
      
       #16
      Call Trace:
       [<c03d64d9>] ? printk+0xf/0x11
       [<c0140d96>] __lock_acquire+0x7ce/0xb1b
       [<c0141173>] lock_acquire+0x90/0xad
       [<c0130c14>] ? flush_work+0x28/0xb0
       [<c0130c2e>] flush_work+0x42/0xb0
       [<c0130c14>] ? flush_work+0x28/0xb0
       [<f8b84966>] del_conn+0x1c/0x84 [bluetooth]
       [<c0130469>] worker_thread+0x18e/0x25e
       [<c0130424>] ? worker_thread+0x149/0x25e
       [<f8b8494a>] ? del_conn+0x0/0x84 [bluetooth]
       [<c0133843>] ? autoremove_wake_function+0x0/0x33
       [<c01302db>] ? worker_thread+0x0/0x25e
       [<c013355a>] kthread+0x45/0x6b
       [<c0133515>] ? kthread+0x0/0x6b
       [<c01034a7>] kernel_thread_helper+0x7/0x10
      
      Based on a report by Oliver Hartkopp <oliver@hartkopp.net>
      Signed-off-by: default avatarDave Young <hidave.darkstar@gmail.com>
      Tested-by: default avatarOliver Hartkopp <oliver@hartkopp.net>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      4c713189
  5. 09 May, 2009 1 commit
    • Marcel Holtmann's avatar
      Bluetooth: Fix wrong module refcount when connection setup fails · 384943ec
      Marcel Holtmann authored
      
      
      The module refcount is increased by hci_dev_hold() call in hci_conn_add()
      and decreased by hci_dev_put() call in del_conn(). In case the connection
      setup fails, hci_dev_put() is never called.
      
      Procedure to reproduce the issue:
      
        # hciconfig hci0 up
        # lsmod | grep btusb                   -> "used by" refcount = 1
      
        # hcitool cc <non-exisiting bdaddr>    -> will get timeout
      
        # lsmod | grep btusb                   -> "used by" refcount = 2
        # hciconfig hci0 down
        # lsmod | grep btusb                   -> "used by" refcount = 1
        # rmmod btusb                          -> ERROR: Module btusb is in use
      
      The hci_dev_put() call got moved into del_conn() with the 2.6.25 kernel
      to fix an issue with hci_dev going away before hci_conn. However that
      change was wrong and introduced this problem.
      
      When calling hci_conn_del() it has to call hci_dev_put() after freeing
      the connection details. This handling should be fully symmetric. The
      execution of del_conn() is done in a work queue and needs it own calls
      to hci_dev_hold() and hci_dev_put() to ensure that the hci_dev stays
      until the connection cleanup has been finished.
      
      Based on a report by Bing Zhao <bzhao@marvell.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Tested-by: default avatarBing Zhao <bzhao@marvell.com>
      384943ec
  6. 05 May, 2009 1 commit
    • Marcel Holtmann's avatar
      Bluetooth: Move dev_set_name() to a context that can sleep · 457ca7bb
      Marcel Holtmann authored
      
      
      Setting the name of a sysfs device has to be done in a context that can
      actually sleep. It allocates its memory with GFP_KERNEL. Previously it
      was a static (size limited) string and that got changed to accommodate
      longer device names. So move the dev_set_name() just before calling
      device_add() which is executed in a work queue.
      
      This fixes the following error:
      
      [  110.012125] BUG: sleeping function called from invalid context at mm/slub.c:1595
      [  110.012135] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper
      [  110.012141] 2 locks held by swapper/0:
      [  110.012145]  #0:  (hci_task_lock){++.-.+}, at: [<ffffffffa01f822f>] hci_rx_task+0x2f/0x2d0 [bluetooth]
      [  110.012173]  #1:  (&hdev->lock){+.-.+.}, at: [<ffffffffa01fb9e2>] hci_event_packet+0x72/0x25c0 [bluetooth]
      [  110.012198] Pid: 0, comm: swapper Tainted: G        W 2.6.30-rc4-g953cdaa #1
      [  110.012203] Call Trace:
      [  110.012207]  <IRQ>  [<ffffffff8023eabd>] __might_sleep+0x14d/0x170
      [  110.012228]  [<ffffffff802cfbe1>] __kmalloc+0x111/0x170
      [  110.012239]  [<ffffffff803c2094>] kvasprintf+0x64/0xb0
      [  110.012248]  [<ffffffff803b7a5b>] kobject_set_name_vargs+0x3b/0xa0
      [  110.012257]  [<ffffffff80465326>] dev_set_name+0x76/0xa0
      [  110.012273]  [<ffffffffa01fb9e2>] ? hci_event_packet+0x72/0x25c0 [bluetooth]
      [  110.012289]  [<ffffffffa01ffc1d>] hci_conn_add_sysfs+0x3d/0x70 [bluetooth]
      [  110.012303]  [<ffffffffa01fba2c>] hci_event_packet+0xbc/0x25c0 [bluetooth]
      [  110.012312]  [<ffffffff80516eb0>] ? sock_def_readable+0x80/0xa0
      [  110.012328]  [<ffffffffa01fee0c>] ? hci_send_to_sock+0xfc/0x1c0 [bluetooth]
      [  110.012343]  [<ffffffff80516eb0>] ? sock_def_readable+0x80/0xa0
      [  110.012347]  [<ffffffff805e88c5>] ? _read_unlock+0x75/0x80
      [  110.012354]  [<ffffffffa01fee0c>] ? hci_send_to_sock+0xfc/0x1c0 [bluetooth]
      [  110.012360]  [<ffffffffa01f8403>] hci_rx_task+0x203/0x2d0 [bluetooth]
      [  110.012365]  [<ffffffff80250ab5>] tasklet_action+0xb5/0x160
      [  110.012369]  [<ffffffff8025116c>] __do_softirq+0x9c/0x150
      [  110.012372]  [<ffffffff805e850f>] ? _spin_unlock+0x3f/0x80
      [  110.012376]  [<ffffffff8020cbbc>] call_softirq+0x1c/0x30
      [  110.012380]  [<ffffffff8020f01d>] do_softirq+0x8d/0xe0
      [  110.012383]  [<ffffffff80250df5>] irq_exit+0xc5/0xe0
      [  110.012386]  [<ffffffff8020e71d>] do_IRQ+0x9d/0x120
      [  110.012389]  [<ffffffff8020c3d3>] ret_from_intr+0x0/0xf
      [  110.012391]  <EOI>  [<ffffffff80431832>] ? acpi_idle_enter_bm+0x264/0x2a6
      [  110.012399]  [<ffffffff80431828>] ? acpi_idle_enter_bm+0x25a/0x2a6
      [  110.012403]  [<ffffffff804f50d5>] ? cpuidle_idle_call+0xc5/0x130
      [  110.012407]  [<ffffffff8020a4b4>] ? cpu_idle+0xc4/0x130
      [  110.012411]  [<ffffffff805d2268>] ? rest_init+0x88/0xb0
      [  110.012416]  [<ffffffff807e2fbd>] ? start_kernel+0x3b5/0x412
      [  110.012420]  [<ffffffff807e2281>] ? x86_64_start_reservations+0x91/0xb5
      [  110.012424]  [<ffffffff807e2394>] ? x86_64_start_kernel+0xef/0x11b
      
      Based on a report by Davide Pesavento <davidepesa@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Tested-by: default avatarHugo Mildenberger <hugo.mildenberger@namir.de>
      Tested-by: default avatarBing Zhao <bzhao@marvell.com>
      457ca7bb
  7. 04 May, 2009 1 commit
    • Marcel Holtmann's avatar
      Bluetooth: Fix issue with sysfs handling for connections · a67e899c
      Marcel Holtmann authored
      
      
      Due to a semantic changes in flush_workqueue() the current approach of
      synchronizing the sysfs handling for connections doesn't work anymore. The
      whole approach is actually fully broken and based on assumptions that are
      no longer valid.
      
      With the introduction of Simple Pairing support, the creation of low-level
      ACL links got changed. This change invalidates the reason why in the past
      two independent work queues have been used for adding/removing sysfs
      devices. The adding of the actual sysfs device is now postponed until the
      host controller successfully assigns an unique handle to that link. So
      the real synchronization happens inside the controller and not the host.
      
      The only left-over problem is that some internals of the sysfs device
      handling are not initialized ahead of time. This leaves potential access
      to invalid data and can cause various NULL pointer dereferences. To fix
      this a new function makes sure that all sysfs details are initialized
      when an connection attempt is made. The actual sysfs device is only
      registered when the connection has been successfully established. To
      avoid a race condition with the registration, the check if a device is
      registered has been moved into the removal work.
      
      As an extra protection two flush_work() calls are left in place to
      make sure a previous add/del work has been completed first.
      
      Based on a report by Marc Pignat <marc.pignat@hevs.ch>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Tested-by: default avatarJustin P. Mattock <justinmattock@gmail.com>
      Tested-by: default avatarRoger Quadros <ext-roger.quadros@nokia.com>
      Tested-by: default avatarMarc Pignat <marc.pignat@hevs.ch>
      a67e899c
  8. 28 Apr, 2009 1 commit
    • Roger Quadros's avatar
      Bluetooth: Ensure that HCI sysfs add/del is preempt safe · f3784d83
      Roger Quadros authored
      
      
      Use a different work_struct variables for add_conn() and del_conn() and
      use single work queue instead of two for adding and deleting connections.
      
      It eliminates the following error on a preemptible kernel:
      
      [  204.358032] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
      [  204.370697] pgd = c0004000
      [  204.373443] [0000000c] *pgd=00000000
      [  204.378601] Internal error: Oops: 17 [#1] PREEMPT
      [  204.383361] Modules linked in: vfat fat rfcomm sco l2cap sd_mod scsi_mod iphb pvr2d drm omaplfb ps
      [  204.438537] CPU: 0    Not tainted  (2.6.28-maemo2 #1)
      [  204.443664] PC is at klist_put+0x2c/0xb4
      [  204.447601] LR is at klist_put+0x18/0xb4
      [  204.451568] pc : [<c0270f08>]    lr : [<c0270ef4>]    psr: a0000113
      [  204.451568] sp : cf1b3f10  ip : cf1b3f10  fp : cf1b3f2c
      [  204.463104] r10: 00000000  r9 : 00000000  r8 : bf08029c
      [  204.468353] r7 : c7869200  r6 : cfbe2690  r5 : c78692c8  r4 : 00000001
      [  204.474945] r3 : 00000001  r2 : cf1b2000  r1 : 00000001  r0 : 00000000
      [  204.481506] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment kernel
      [  204.488861] Control: 10c5387d  Table: 887fc018  DAC: 00000017
      [  204.494628] Process btdelconn (pid: 515, stack limit = 0xcf1b22e0)
      Signed-off-by: default avatarRoger Quadros <ext-roger.quadros@nokia.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      f3784d83
  9. 24 Mar, 2009 1 commit
  10. 30 Nov, 2008 2 commits
    • Marcel Holtmann's avatar
      Bluetooth: Fix format arguments warning · 2e792995
      Marcel Holtmann authored
      
      
      Newer GCC versions are a little bit picky about how to deal with format
      arguments:
      
      net/bluetooth/hci_sysfs.c: In function ‘hci_register_sysfs’:
      net/bluetooth/hci_sysfs.c:418: warning: format not a string literal and no format arguments
      
      It is simple enough to fix and makes the compiler happy.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      2e792995
    • Marcel Holtmann's avatar
      Bluetooth: Enable per-module dynamic debug messages · a418b893
      Marcel Holtmann authored
      
      
      With the introduction of CONFIG_DYNAMIC_PRINTK_DEBUG it is possible to
      allow debugging without having to recompile the kernel. This patch turns
      all BT_DBG() calls into pr_debug() to support dynamic debug messages.
      
      As a side effect all CONFIG_BT_*_DEBUG statements are now removed and
      some broken debug entries have been fixed.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      a418b893
  11. 10 Nov, 2008 1 commit
  12. 18 Aug, 2008 1 commit
    • Marcel Holtmann's avatar
      [Bluetooth] Fix userspace breakage due missing class links · 90855d7b
      Marcel Holtmann authored
      
      
      The Bluetooth adapters and connections are best presented via a class
      in sysfs. The removal of the links inside the Bluetooth class broke
      assumptions by userspace programs on how to find attached adapters.
      
      This patch creates adapters and connections as part of the Bluetooth
      class, but it uses different device types to distinguish them. The
      userspace programs can now easily navigate in the sysfs device tree.
      
      The unused platform device and bus have been removed to keep the
      code simple and clean.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      90855d7b
  13. 21 Jul, 2008 1 commit
  14. 14 Jul, 2008 2 commits
  15. 18 Feb, 2008 3 commits
  16. 31 Jan, 2008 2 commits
  17. 23 Jan, 2008 1 commit
  18. 29 Dec, 2007 1 commit
  19. 22 Oct, 2007 1 commit
    • Marcel Holtmann's avatar
      [Bluetooth] Switch from OGF+OCF to using only opcodes · a9de9248
      Marcel Holtmann authored
      
      
      The Bluetooth HCI commands are divided into logical OGF groups for
      easier identification of their purposes. While this still makes sense
      for the written specification, its makes the code only more complex
      and harder to read. So instead of using separate OGF and OCF values
      to identify the commands, use a common 16-bit opcode that combines
      both values. As a side effect this also reduces the complexity of
      OGF and OCF calculations during command header parsing.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      a9de9248
  20. 07 May, 2007 1 commit
  21. 04 May, 2007 1 commit
    • Marcel Holtmann's avatar
      [Bluetooth] Attach host adapters to the Bluetooth bus · 53c1d4b0
      Marcel Holtmann authored
      
      
      The Bluetooth host adapters are attached to the Bluetooth class and the
      low-level connections are children of these class devices. Having class
      devices as parent of bus devices breaks a lot of reasonable assumptions
      about sysfs. The host adapters should be attached to the Bluetooth bus
      to simplify the dependency resolving. For compatibility an additional
      symlink from the Bluetooth class will be used.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      53c1d4b0
  22. 09 Jan, 2007 1 commit
  23. 22 Nov, 2006 1 commit
  24. 21 Nov, 2006 1 commit
  25. 16 Oct, 2006 2 commits
  26. 28 Sep, 2006 5 commits
  27. 03 Jul, 2006 2 commits