1. 05 2月, 2013 1 次提交
  2. 11 10月, 2012 1 次提交
  3. 28 9月, 2012 2 次提交
  4. 05 6月, 2012 2 次提交
  5. 15 2月, 2012 1 次提交
    • O
      Bluetooth: Fix RFCOMM session reference counting issue · cf33e77b
      Octavian Purdila 提交于
      There is an imbalance in the rfcomm_session_hold / rfcomm_session_put
      operations which causes the following crash:
      
      [  685.010159] BUG: unable to handle kernel paging request at 6b6b6b6b
      [  685.010169] IP: [<c149d76d>] rfcomm_process_dlcs+0x1b/0x15e
      [  685.010181] *pdpt = 000000002d665001 *pde = 0000000000000000
      [  685.010191] Oops: 0000 [#1] PREEMPT SMP
      [  685.010247]
      [  685.010255] Pid: 947, comm: krfcommd Tainted: G         C  3.0.16-mid8-dirty #44
      [  685.010266] EIP: 0060:[<c149d76d>] EFLAGS: 00010246 CPU: 1
      [  685.010274] EIP is at rfcomm_process_dlcs+0x1b/0x15e
      [  685.010281] EAX: e79f551c EBX: 6b6b6b6b ECX: 00000007 EDX: e79f40b4
      [  685.010288] ESI: e79f4060 EDI: ed4e1f70 EBP: ed4e1f68 ESP: ed4e1f50
      [  685.010295]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      [  685.010303] Process krfcommd (pid: 947, ti=ed4e0000 task=ed43e5e0 task.ti=ed4e0000)
      [  685.010308] Stack:
      [  685.010312]  ed4e1f68 c149eb53 e5925150 e79f4060 ed500000 ed4e1f70 ed4e1f80 c149ec10
      [  685.010331]  00000000 ed43e5e0 00000000 ed4e1f90 ed4e1f9c c149ec87 0000bf54 00000000
      [  685.010348]  00000000 ee03bf54 c149ec37 ed4e1fe4 c104fe01 00000000 00000000 00000000
      [  685.010367] Call Trace:
      [  685.010376]  [<c149eb53>] ? rfcomm_process_rx+0x6e/0x74
      [  685.010387]  [<c149ec10>] rfcomm_process_sessions+0xb7/0xde
      [  685.010398]  [<c149ec87>] rfcomm_run+0x50/0x6d
      [  685.010409]  [<c149ec37>] ? rfcomm_process_sessions+0xde/0xde
      [  685.010419]  [<c104fe01>] kthread+0x63/0x68
      [  685.010431]  [<c104fd9e>] ? __init_kthread_worker+0x42/0x42
      [  685.010442]  [<c14dae82>] kernel_thread_helper+0x6/0xd
      
      This issue has been brought up earlier here:
      
      https://lkml.org/lkml/2011/5/21/127
      
      The issue appears to be the rfcomm_session_put in rfcomm_recv_ua. This
      operation doesn't seem be to required as for the non-initiator case we
      have the rfcomm_process_rx doing an explicit put and in the initiator
      case the last dlc_unlink will drive the reference counter to 0.
      
      There have been several attempts to fix these issue:
      
      6c2718da Bluetooth: Do not call rfcomm_session_put() for RFCOMM UA on closed socket
      683d949a Bluetooth: Never deallocate a session when some DLC points to it
      
      but AFAICS they do not fix the issue just make it harder to reproduce.
      Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com>
      Signed-off-by: NGopala Krishna Murala <gopala.krishna.murala@intel.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      cf33e77b
  6. 13 2月, 2012 1 次提交
    • O
      Bluetooth: Fix RFCOMM session reference counting issue · 66f01296
      Octavian Purdila 提交于
      There is an imbalance in the rfcomm_session_hold / rfcomm_session_put
      operations which causes the following crash:
      
      [  685.010159] BUG: unable to handle kernel paging request at 6b6b6b6b
      [  685.010169] IP: [<c149d76d>] rfcomm_process_dlcs+0x1b/0x15e
      [  685.010181] *pdpt = 000000002d665001 *pde = 0000000000000000
      [  685.010191] Oops: 0000 [#1] PREEMPT SMP
      [  685.010247]
      [  685.010255] Pid: 947, comm: krfcommd Tainted: G         C  3.0.16-mid8-dirty #44
      [  685.010266] EIP: 0060:[<c149d76d>] EFLAGS: 00010246 CPU: 1
      [  685.010274] EIP is at rfcomm_process_dlcs+0x1b/0x15e
      [  685.010281] EAX: e79f551c EBX: 6b6b6b6b ECX: 00000007 EDX: e79f40b4
      [  685.010288] ESI: e79f4060 EDI: ed4e1f70 EBP: ed4e1f68 ESP: ed4e1f50
      [  685.010295]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      [  685.010303] Process krfcommd (pid: 947, ti=ed4e0000 task=ed43e5e0 task.ti=ed4e0000)
      [  685.010308] Stack:
      [  685.010312]  ed4e1f68 c149eb53 e5925150 e79f4060 ed500000 ed4e1f70 ed4e1f80 c149ec10
      [  685.010331]  00000000 ed43e5e0 00000000 ed4e1f90 ed4e1f9c c149ec87 0000bf54 00000000
      [  685.010348]  00000000 ee03bf54 c149ec37 ed4e1fe4 c104fe01 00000000 00000000 00000000
      [  685.010367] Call Trace:
      [  685.010376]  [<c149eb53>] ? rfcomm_process_rx+0x6e/0x74
      [  685.010387]  [<c149ec10>] rfcomm_process_sessions+0xb7/0xde
      [  685.010398]  [<c149ec87>] rfcomm_run+0x50/0x6d
      [  685.010409]  [<c149ec37>] ? rfcomm_process_sessions+0xde/0xde
      [  685.010419]  [<c104fe01>] kthread+0x63/0x68
      [  685.010431]  [<c104fd9e>] ? __init_kthread_worker+0x42/0x42
      [  685.010442]  [<c14dae82>] kernel_thread_helper+0x6/0xd
      
      This issue has been brought up earlier here:
      
      https://lkml.org/lkml/2011/5/21/127
      
      The issue appears to be the rfcomm_session_put in rfcomm_recv_ua. This
      operation doesn't seem be to required as for the non-initiator case we
      have the rfcomm_process_rx doing an explicit put and in the initiator
      case the last dlc_unlink will drive the reference counter to 0.
      
      There have been several attempts to fix these issue:
      
      6c2718da Bluetooth: Do not call rfcomm_session_put() for RFCOMM UA on closed socket
      683d949a Bluetooth: Never deallocate a session when some DLC points to it
      
      but AFAICS they do not fix the issue just make it harder to reproduce.
      Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com>
      Signed-off-by: NGopala Krishna Murala <gopala.krishna.murala@intel.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      66f01296
  7. 28 12月, 2011 1 次提交
  8. 23 12月, 2011 1 次提交
  9. 20 12月, 2011 1 次提交
  10. 19 12月, 2011 1 次提交
  11. 08 11月, 2011 3 次提交
    • 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
    • L
    • L
      Bluetooth: replace list_for_each with list_for_each_entry whenever possible · 8035ded4
      Luiz Augusto von Dentz 提交于
      When all items in the list have the same type there is no much of a point
      to use list_for_each except if you want to use the list pointer itself.
      Signed-off-by: NLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      8035ded4
  12. 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
  13. 28 9月, 2011 1 次提交
  14. 12 8月, 2011 1 次提交
  15. 12 5月, 2011 1 次提交
  16. 28 4月, 2011 3 次提交
  17. 15 2月, 2011 1 次提交
  18. 20 1月, 2011 1 次提交
  19. 07 12月, 2010 1 次提交
  20. 02 12月, 2010 1 次提交
  21. 09 11月, 2010 1 次提交
  22. 12 10月, 2010 3 次提交
  23. 24 9月, 2010 1 次提交
  24. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  25. 21 3月, 2010 2 次提交
  26. 08 3月, 2010 1 次提交
  27. 04 2月, 2010 2 次提交
    • N
      Bluetooth: Do not call rfcomm_session_put() for RFCOMM UA on closed socket · 6c2718da
      Nick Pelly 提交于
      When processing a RFCOMM UA frame when the socket is closed and we were
      not the RFCOMM initiator would cause rfcomm_session_put() to be called
      twice during rfcomm_process_rx(). This would cause a kernel panic in
      rfcomm_session_close() then.
      
      This could be easily reproduced during disconnect with devices such as
      Motorola H270 that send RFCOMM UA followed quickly by L2CAP disconnect
      request. This trace for this looks like:
      
      2009-09-21 17:22:37.788895 < ACL data: handle 1 flags 0x02 dlen 8
         L2CAP(d): cid 0x0041 len 4 [psm 3]
           RFCOMM(s): DISC: cr 0 dlci 20 pf 1 ilen 0 fcs 0x7d
      2009-09-21 17:22:37.906204 > HCI Event: Number of Completed Packets (0x13) plen 5
         handle 1 packets 1
      2009-09-21 17:22:37.933090 > ACL data: handle 1 flags 0x02 dlen 8
         L2CAP(d): cid 0x0040 len 4 [psm 3]
           RFCOMM(s): UA: cr 0 dlci 20 pf 1 ilen 0 fcs 0x57
      2009-09-21 17:22:38.636764 < ACL data: handle 1 flags 0x02 dlen 8
         L2CAP(d): cid 0x0041 len 4 [psm 3]
           RFCOMM(s): DISC: cr 0 dlci 0 pf 1 ilen 0 fcs 0x9c
      2009-09-21 17:22:38.744125 > HCI Event: Number of Completed Packets (0x13) plen 5
         handle 1 packets 1
      2009-09-21 17:22:38.763687 > ACL data: handle 1 flags 0x02 dlen 8
         L2CAP(d): cid 0x0040 len 4 [psm 3]
           RFCOMM(s): UA: cr 0 dlci 0 pf 1 ilen 0 fcs 0xb6
      2009-09-21 17:22:38.783554 > ACL data: handle 1 flags 0x02 dlen 12
         L2CAP(s): Disconn req: dcid 0x0040 scid 0x0041
      
      Avoid calling rfcomm_session_put() twice by skipping this call
      in rfcomm_recv_ua() if the socket is closed.
      Signed-off-by: NNick Pelly <npelly@google.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      6c2718da
    • M
      Bluetooth: Fix sleeping function in RFCOMM within invalid context · 485f1eff
      Marcel Holtmann 提交于
      With the commit 9e726b17 the
      rfcomm_session_put() gets accidentially called from a timeout
      callback and results in this:
      
      BUG: sleeping function called from invalid context at net/core/sock.c:1897
      in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper
      Pid: 0, comm: swapper Tainted: P           2.6.32 #31
      Call Trace:
       <IRQ>  [<ffffffff81036455>] __might_sleep+0xf8/0xfa
       [<ffffffff8138ef1d>] lock_sock_nested+0x29/0xc4
       [<ffffffffa03921b3>] lock_sock+0xb/0xd [l2cap]
       [<ffffffffa03948e6>] l2cap_sock_shutdown+0x1c/0x76 [l2cap]
       [<ffffffff8106adea>] ? clockevents_program_event+0x75/0x7e
       [<ffffffff8106bea2>] ? tick_dev_program_event+0x37/0xa5
       [<ffffffffa0394967>] l2cap_sock_release+0x27/0x67 [l2cap]
       [<ffffffff8138c971>] sock_release+0x1a/0x67
       [<ffffffffa03d2492>] rfcomm_session_del+0x34/0x53 [rfcomm]
       [<ffffffffa03d24c5>] rfcomm_session_put+0x14/0x16 [rfcomm]
       [<ffffffffa03d28b4>] rfcomm_session_timeout+0xe/0x1a [rfcomm]
       [<ffffffff810554a8>] run_timer_softirq+0x1e2/0x29a
       [<ffffffffa03d28a6>] ? rfcomm_session_timeout+0x0/0x1a [rfcomm]
       [<ffffffff8104e0f6>] __do_softirq+0xfe/0x1c5
       [<ffffffff8100e8ce>] ? timer_interrupt+0x1a/0x21
       [<ffffffff8100cc4c>] call_softirq+0x1c/0x28
       [<ffffffff8100e05b>] do_softirq+0x33/0x6b
       [<ffffffff8104daf6>] irq_exit+0x36/0x85
       [<ffffffff8100d7a9>] do_IRQ+0xa6/0xbd
       [<ffffffff8100c493>] ret_from_intr+0x0/0xa
       <EOI>  [<ffffffff812585b3>] ? acpi_idle_enter_bm+0x269/0x294
       [<ffffffff812585a9>] ? acpi_idle_enter_bm+0x25f/0x294
       [<ffffffff81373ddc>] ? cpuidle_idle_call+0x97/0x107
       [<ffffffff8100aca0>] ? cpu_idle+0x53/0xaa
       [<ffffffff81429006>] ? rest_init+0x7a/0x7c
       [<ffffffff8177bc8c>] ? start_kernel+0x389/0x394
       [<ffffffff8177b29c>] ? x86_64_start_reservations+0xac/0xb0
       [<ffffffff8177b384>] ? x86_64_start_kernel+0xe4/0xeb
      
      To fix this, the rfcomm_session_put() needs to be moved out of
      rfcomm_session_timeout() into rfcomm_process_sessions(). In that
      context it is perfectly fine to sleep and disconnect the socket.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Tested-by: NDavid John <davidjon@xenontk.org>
      485f1eff
  28. 04 12月, 2009 1 次提交
  29. 23 8月, 2009 2 次提交
    • 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
    • M
      Bluetooth: Coding style cleanup from previous rfcomm_init bug fix · 52d18347
      Marcel Holtmann 提交于
      The rfcomm_init bug fix went into the kernel premature before it got fully
      reviewed and acknowledged by the Bluetooth maintainer. So fix up the coding
      style now.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      52d18347