1. 05 Feb, 2010 1 commit
  2. 04 Feb, 2010 3 commits
    • Nick Pelly's avatar
      Bluetooth: Enter active mode before establishing a SCO link. · c390216b
      Nick Pelly authored
      When in sniff mode with a long interval time (1.28s) it can take 4+ seconds
      to establish a SCO link. Fix by requesting active mode before requesting
      SCO connection. This improves SCO setup time to ~500ms.
      
      Bluetooth headsets that use a long interval time, and exhibit the long
      SCO connection time include Motorola H790, HX1 and H17. They have a
      CSR 2.1 chipset.
      
      Verified this behavior and fix with host Bluetooth chipsets: BCM4329 and
      TI1271.
      
      2009-10-13 14:17:46.183722 > HCI Event: Mode Change (0x14) plen 6
          status 0x00 handle 1 mode 0x02 interval 2048
          Mode: Sniff
      2009-10-13 14:17:53.436285 < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
          handle 1 voice setting 0x0060
      2009-10-13 14:17:53.445593 > HCI Event: Command Status (0x0f) plen 4
          Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
      2009-10-13 14:17:57.788855 > HCI Event: Synchronous Connect Complete 0x2c) plen 17
          status 0x00 handle 257 bdaddr 00:1A:0E:F1:A4:7F type eSCO
          Air mode: CVSD
      Signed-off-by: default avatarNick Pelly <npelly@google.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      c390216b
    • Yoichi Yuasa's avatar
    • Nick Pelly's avatar
      Bluetooth: Do not call rfcomm_session_put() for RFCOMM UA on closed socket · 6c2718da
      Nick Pelly authored
      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: default avatarNick Pelly <npelly@google.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      6c2718da
  3. 03 Feb, 2010 2 commits
    • Marcel Holtmann's avatar
      Bluetooth: Fix sleeping function in RFCOMM within invalid context · 485f1eff
      Marcel Holtmann authored
      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: default avatarMarcel Holtmann <marcel@holtmann.org>
      Tested-by: default avatarDavid John <davidjon@xenontk.org>
      485f1eff
    • Nick Pelly's avatar
      Bluetooth: Fallback eSCO to SCO on error 0x1a (Unsupported Remote Feature) · 1038a00b
      Nick Pelly authored
      General Motors carkits that use LGE BT chipsets return this error code
      when an eSCO is attempted, despite advertising eSCO support.
      
      2009-08-13 14:41:39.755518 < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
         handle 1 voice setting 0x0060
      2009-08-13 14:41:39.757563 > HCI Event: Command Status (0x0f) plen 4
         Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
      2009-08-13 14:41:39.789484 > HCI Event: Synchronous Connect Complete (0x2c) plen 17
         status 0x1a handle 257 bdaddr 00:1E:B2:23:5E:B3 type eSCO
         Error: Unsupported Remote Feature / Unsupported LMP Feature
      Signed-off-by: default avatarJaikumar Ganesh <jaikumar@google.com>
      Signed-off-by: default avatarNick Pelly <npelly@google.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      1038a00b
  4. 02 Feb, 2010 3 commits
  5. 01 Feb, 2010 1 commit
  6. 30 Jan, 2010 5 commits
  7. 29 Jan, 2010 2 commits
  8. 28 Jan, 2010 7 commits
  9. 27 Jan, 2010 1 commit
  10. 26 Jan, 2010 3 commits
    • Zhu Yi's avatar
      mac80211: fix NULL pointer dereference when ftrace is enabled · 3092ad05
      Zhu Yi authored
      I got below kernel oops when I try to bring down the network interface if
      ftrace is enabled. The root cause is drv_ampdu_action() is passed with a
      NULL ssn pointer in the BA session tear down case. We need to check and
      avoid dereferencing it in trace entry assignment.
      
      BUG: unable to handle kernel NULL pointer dereference
      Modules linked in: at (null)
      IP: [<f98fe02a>] ftrace_raw_event_drv_ampdu_action+0x10a/0x160 [mac80211]
      *pde = 00000000
      Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
      [...]
      Call Trace:
       [<f98fdf20>] ? ftrace_raw_event_drv_ampdu_action+0x0/0x160 [mac80211]
       [<f98dac4c>] ? __ieee80211_stop_rx_ba_session+0xfc/0x220 [mac80211]
       [<f98d97fb>] ? ieee80211_sta_tear_down_BA_sessions+0x3b/0x50 [mac80211]
       [<f98dc6f6>] ? ieee80211_set_disassoc+0xe6/0x230 [mac80211]
       [<f98dc6ac>] ? ieee80211_set_disassoc+0x9c/0x230 [mac80211]
       [<f98dcbb8>] ? ieee80211_mgd_deauth+0x158/0x170 [mac80211]
       [<f98e4bdb>] ? ieee80211_deauth+0x1b/0x20 [mac80211]
       [<f8987f49>] ? __cfg80211_mlme_deauth+0xe9/0x120 [cfg80211]
       [<f898b870>] ? __cfg80211_disconnect+0x170/0x1d0 [cfg80211]
      
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: stable@kernel.org
      Signed-off-by: default avatarZhu Yi <yi.zhu@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3092ad05
    • Patrick McHardy's avatar
      netfilter: ctnetlink: fix expectation mask dump · e578756c
      Patrick McHardy authored
      The protocol number is not initialized, so userspace can't interpret
      the layer 4 data properly.
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      e578756c
    • Shan Wei's avatar
      ipv6: conntrack: Add member of user to nf_ct_frag6_queue structure · c92b544b
      Shan Wei authored
      The commit 0b5ccb2e(title:ipv6: reassembly: use seperate reassembly queues for
      conntrack and local delivery) has broken the saddr&&daddr member of
      nf_ct_frag6_queue when creating new queue.  And then hash value
      generated by nf_hashfn() was not equal with that generated by fq_find().
      So, a new received fragment can't be inserted to right queue.
      
      The patch fixes the bug with adding member of user to nf_ct_frag6_queue structure.
      Signed-off-by: default avatarShan Wei <shanwei@cn.fujitsu.com>
      Acked-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c92b544b
  11. 25 Jan, 2010 10 commits
  12. 24 Jan, 2010 1 commit
  13. 23 Jan, 2010 1 commit