1. 15 Feb, 2012 9 commits
    • Octavian Purdila's avatar
      Bluetooth: Fix RFCOMM session reference counting issue · cf33e77b
      Octavian Purdila authored
      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: default avatarOctavian Purdila <octavian.purdila@intel.com>
      Signed-off-by: default avatarGopala Krishna Murala <gopala.krishna.murala@intel.com>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      cf33e77b
    • Andre Guedes's avatar
      Bluetooth: Fix potential deadlock · a51cd2be
      Andre Guedes authored
      We don't need to use the _sync variant in hci_conn_hold and
      hci_conn_put to cancel conn->disc_work delayed work. This way
      we avoid potential deadlocks like this one reported by lockdep.
      
      ======================================================
      [ INFO: possible circular locking dependency detected ]
      3.2.0+ #1 Not tainted
      -------------------------------------------------------
      kworker/u:1/17 is trying to acquire lock:
       (&hdev->lock){+.+.+.}, at: [<ffffffffa0041155>] hci_conn_timeout+0x62/0x158 [bluetooth]
      
      but task is already holding lock:
       ((&(&conn->disc_work)->work)){+.+...}, at: [<ffffffff81035751>] process_one_work+0x11a/0x2bf
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #2 ((&(&conn->disc_work)->work)){+.+...}:
             [<ffffffff81057444>] lock_acquire+0x8a/0xa7
             [<ffffffff81034ed1>] wait_on_work+0x3d/0xaa
             [<ffffffff81035b54>] __cancel_work_timer+0xac/0xef
             [<ffffffff81035ba4>] cancel_delayed_work_sync+0xd/0xf
             [<ffffffffa00554b0>] smp_chan_create+0xde/0xe6 [bluetooth]
             [<ffffffffa0056160>] smp_conn_security+0xa3/0x12d [bluetooth]
             [<ffffffffa0053640>] l2cap_connect_cfm+0x237/0x2e8 [bluetooth]
             [<ffffffffa004239c>] hci_proto_connect_cfm+0x2d/0x6f [bluetooth]
             [<ffffffffa0046ea5>] hci_event_packet+0x29d1/0x2d60 [bluetooth]
             [<ffffffffa003dde3>] hci_rx_work+0xd0/0x2e1 [bluetooth]
             [<ffffffff810357af>] process_one_work+0x178/0x2bf
             [<ffffffff81036178>] worker_thread+0xce/0x152
             [<ffffffff81039a03>] kthread+0x95/0x9d
             [<ffffffff812e7754>] kernel_thread_helper+0x4/0x10
      
      -> #1 (slock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+...}:
             [<ffffffff81057444>] lock_acquire+0x8a/0xa7
             [<ffffffff812e553a>] _raw_spin_lock_bh+0x36/0x6a
             [<ffffffff81244d56>] lock_sock_nested+0x24/0x7f
             [<ffffffffa004d96f>] lock_sock+0xb/0xd [bluetooth]
             [<ffffffffa0052906>] l2cap_chan_connect+0xa9/0x26f [bluetooth]
             [<ffffffffa00545f8>] l2cap_sock_connect+0xb3/0xff [bluetooth]
             [<ffffffff81243b48>] sys_connect+0x69/0x8a
             [<ffffffff812e6579>] system_call_fastpath+0x16/0x1b
      
      -> #0 (&hdev->lock){+.+.+.}:
             [<ffffffff81056d06>] __lock_acquire+0xa80/0xd74
             [<ffffffff81057444>] lock_acquire+0x8a/0xa7
             [<ffffffff812e3870>] __mutex_lock_common+0x48/0x38e
             [<ffffffff812e3c75>] mutex_lock_nested+0x2a/0x31
             [<ffffffffa0041155>] hci_conn_timeout+0x62/0x158 [bluetooth]
             [<ffffffff810357af>] process_one_work+0x178/0x2bf
             [<ffffffff81036178>] worker_thread+0xce/0x152
             [<ffffffff81039a03>] kthread+0x95/0x9d
             [<ffffffff812e7754>] kernel_thread_helper+0x4/0x10
      
      other info that might help us debug this:
      
      Chain exists of:
        &hdev->lock --> slock-AF_BLUETOOTH-BTPROTO_L2CAP --> (&(&conn->disc_work)->work)
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock((&(&conn->disc_work)->work));
                                     lock(slock-AF_BLUETOOTH-BTPROTO_L2CAP);
                                     lock((&(&conn->disc_work)->work));
        lock(&hdev->lock);
      
       *** DEADLOCK ***
      
      2 locks held by kworker/u:1/17:
       #0:  (hdev->name){.+.+.+}, at: [<ffffffff81035751>] process_one_work+0x11a/0x2bf
       #1:  ((&(&conn->disc_work)->work)){+.+...}, at: [<ffffffff81035751>] process_one_work+0x11a/0x2bf
      
      stack backtrace:
      Pid: 17, comm: kworker/u:1 Not tainted 3.2.0+ #1
      Call Trace:
       [<ffffffff812e06c6>] print_circular_bug+0x1f8/0x209
       [<ffffffff81056d06>] __lock_acquire+0xa80/0xd74
       [<ffffffff81021ef2>] ? arch_local_irq_restore+0x6/0xd
       [<ffffffff81022bc7>] ? vprintk+0x3f9/0x41e
       [<ffffffff81057444>] lock_acquire+0x8a/0xa7
       [<ffffffffa0041155>] ? hci_conn_timeout+0x62/0x158 [bluetooth]
       [<ffffffff812e3870>] __mutex_lock_common+0x48/0x38e
       [<ffffffffa0041155>] ? hci_conn_timeout+0x62/0x158 [bluetooth]
       [<ffffffff81190fd6>] ? __dynamic_pr_debug+0x6d/0x6f
       [<ffffffffa0041155>] ? hci_conn_timeout+0x62/0x158 [bluetooth]
       [<ffffffff8105320f>] ? trace_hardirqs_off+0xd/0xf
       [<ffffffff812e3c75>] mutex_lock_nested+0x2a/0x31
       [<ffffffffa0041155>] hci_conn_timeout+0x62/0x158 [bluetooth]
       [<ffffffff810357af>] process_one_work+0x178/0x2bf
       [<ffffffff81035751>] ? process_one_work+0x11a/0x2bf
       [<ffffffff81055af3>] ? lock_acquired+0x1d0/0x1df
       [<ffffffffa00410f3>] ? hci_acl_disconn+0x65/0x65 [bluetooth]
       [<ffffffff81036178>] worker_thread+0xce/0x152
       [<ffffffff810407ed>] ? finish_task_switch+0x45/0xc5
       [<ffffffff810360aa>] ? manage_workers.isra.25+0x16a/0x16a
       [<ffffffff81039a03>] kthread+0x95/0x9d
       [<ffffffff812e7754>] kernel_thread_helper+0x4/0x10
       [<ffffffff812e5db4>] ? retint_restore_args+0x13/0x13
       [<ffffffff8103996e>] ? __init_kthread_worker+0x55/0x55
       [<ffffffff812e7750>] ? gs_change+0x13/0x13
      Signed-off-by: default avatarAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: default avatarVinicius Costa Gomes <vinicius.gomes@openbossa.org>
      Reviewed-by: default avatarUlisses Furquim <ulisses@profusion.mobi>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      a51cd2be
    • Octavian Purdila's avatar
      Bluetooth: silence lockdep warning · b5a30dda
      Octavian Purdila authored
      Since bluetooth uses multiple protocols types, to avoid lockdep
      warnings, we need to use different lockdep classes (one for each
      protocol type).
      
      This is already done in bt_sock_create but it misses a couple of cases
      when new connections are created. This patch corrects that to fix the
      following warning:
      
      <4>[ 1864.732366] =======================================================
      <4>[ 1864.733030] [ INFO: possible circular locking dependency detected ]
      <4>[ 1864.733544] 3.0.16-mid3-00007-gc9a0f62 #3
      <4>[ 1864.733883] -------------------------------------------------------
      <4>[ 1864.734408] t.android.btclc/4204 is trying to acquire lock:
      <4>[ 1864.734869]  (rfcomm_mutex){+.+.+.}, at: [<c14970ea>] rfcomm_dlc_close+0x15/0x30
      <4>[ 1864.735541]
      <4>[ 1864.735549] but task is already holding lock:
      <4>[ 1864.736045]  (sk_lock-AF_BLUETOOTH){+.+.+.}, at: [<c1498bf7>] lock_sock+0xa/0xc
      <4>[ 1864.736732]
      <4>[ 1864.736740] which lock already depends on the new lock.
      <4>[ 1864.736750]
      <4>[ 1864.737428]
      <4>[ 1864.737437] the existing dependency chain (in reverse order) is:
      <4>[ 1864.738016]
      <4>[ 1864.738023] -> #1 (sk_lock-AF_BLUETOOTH){+.+.+.}:
      <4>[ 1864.738549]        [<c1062273>] lock_acquire+0x104/0x140
      <4>[ 1864.738977]        [<c13d35c1>] lock_sock_nested+0x58/0x68
      <4>[ 1864.739411]        [<c1493c33>] l2cap_sock_sendmsg+0x3e/0x76
      <4>[ 1864.739858]        [<c13d06c3>] __sock_sendmsg+0x50/0x59
      <4>[ 1864.740279]        [<c13d0ea2>] sock_sendmsg+0x94/0xa8
      <4>[ 1864.740687]        [<c13d0ede>] kernel_sendmsg+0x28/0x37
      <4>[ 1864.741106]        [<c14969ca>] rfcomm_send_frame+0x30/0x38
      <4>[ 1864.741542]        [<c1496a2a>] rfcomm_send_ua+0x58/0x5a
      <4>[ 1864.741959]        [<c1498447>] rfcomm_run+0x441/0xb52
      <4>[ 1864.742365]        [<c104f095>] kthread+0x63/0x68
      <4>[ 1864.742742]        [<c14d5182>] kernel_thread_helper+0x6/0xd
      <4>[ 1864.743187]
      <4>[ 1864.743193] -> #0 (rfcomm_mutex){+.+.+.}:
      <4>[ 1864.743667]        [<c1061ada>] __lock_acquire+0x988/0xc00
      <4>[ 1864.744100]        [<c1062273>] lock_acquire+0x104/0x140
      <4>[ 1864.744519]        [<c14d2c70>] __mutex_lock_common+0x3b/0x33f
      <4>[ 1864.744975]        [<c14d303e>] mutex_lock_nested+0x2d/0x36
      <4>[ 1864.745412]        [<c14970ea>] rfcomm_dlc_close+0x15/0x30
      <4>[ 1864.745842]        [<c14990d9>] __rfcomm_sock_close+0x5f/0x6b
      <4>[ 1864.746288]        [<c1499114>] rfcomm_sock_shutdown+0x2f/0x62
      <4>[ 1864.746737]        [<c13d275d>] sys_socketcall+0x1db/0x422
      <4>[ 1864.747165]        [<c14d42f0>] syscall_call+0x7/0xb
      Signed-off-by: default avatarOctavian Purdila <octavian.purdila@intel.com>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      b5a30dda
    • Vinicius Costa Gomes's avatar
      Bluetooth: Fix using an absolute timeout on hci_conn_put() · 33166063
      Vinicius Costa Gomes authored
      queue_delayed_work() expects a relative time for when that work
      should be scheduled.
      Signed-off-by: default avatarVinicius Costa Gomes <vinicius.gomes@openbossa.org>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      33166063
    • Andrzej Kaczmarek's avatar
      Bluetooth: l2cap_set_timer needs jiffies as timeout value · 6e1da683
      Andrzej Kaczmarek authored
      After moving L2CAP timers to workqueues l2cap_set_timer expects timeout
      value to be specified in jiffies but constants defined in miliseconds
      are used. This makes timeouts unreliable when CONFIG_HZ is not set to
      1000.
      
      __set_chan_timer macro still uses jiffies as input to avoid multiple
      conversions from/to jiffies for sk_sndtimeo value which is already
      specified in jiffies.
      Signed-off-by: default avatarAndrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
      Ackec-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      6e1da683
    • Andrzej Kaczmarek's avatar
      Bluetooth: Fix sk_sndtimeo initialization for L2CAP socket · a6375255
      Andrzej Kaczmarek authored
      sk_sndtime value should be specified in jiffies thus initial value
      needs to be converted from miliseconds. Otherwise this timeout is
      unreliable when CONFIG_HZ is not set to 1000.
      Signed-off-by: default avatarAndrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      a6375255
    • Johan Hedberg's avatar
      Bluetooth: Remove bogus inline declaration from l2cap_chan_connect · 4aa832c2
      Johan Hedberg authored
      As reported by Dan Carpenter this function causes a Sparse warning and
      shouldn't be declared inline:
      
      include/net/bluetooth/l2cap.h:837:30 error: marked inline, but without a
      definition"
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      4aa832c2
    • Daniel Wagner's avatar
      Bluetooth: Don't mark non xfer isoc endpoint URBs with URB_ISO_ASAP · 19ad9e94
      Daniel Wagner authored
      [ 2096.384084] btusb_send_frame:684: hci0
      [ 2096.384087] usb 3-1: BOGUS urb flags, 2 --> 0
      [ 2096.384091] Bluetooth: hci0 urb ffff8801b61d3a80 submission failed (22)
      
      According the documentation in usb_submit_urb() URB_ISO_ASAP
      flag is only allowed for endpoints of type USB_ENDPOINT_XFER_ISOC.
      
      This reverts commit b8aabfc9.
      Signed-off-by: default avatarDaniel Wagner <daniel.wagner@bmw-carit.de>
      Acked-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      19ad9e94
    • Peter Hurley's avatar
      Bluetooth: Fix l2cap conn failures for ssp devices · 18daf164
      Peter Hurley authored
      Commit 33060542 fixed l2cap conn establishment for non-ssp remote
      devices by not setting HCI_CONN_ENCRYPT_PEND every time conn security
      is tested (which was always returning failure on any subsequent
      security checks).
      
      However, this broke l2cap conn establishment for ssp remote devices
      when an ACL link was already established at SDP-level security. This
      fix ensures that encryption must be pending whenever authentication
      is also pending.
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Tested-by: default avatarDaniel Wagner <daniel.wagner@bmw-carit.de>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      18daf164
  2. 09 Feb, 2012 2 commits
    • Simon Graham's avatar
      rtlwifi: Modify rtl_pci_init to return 0 on success · c27111e5
      Simon Graham authored
      Fixes problem where caller would think routine succeeded when it failed
      leading to divide by zero panic.
      Signed-off-by: default avatarSimon Graham <simon.graham@virtualcomputer.com>
      Acked-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      c27111e5
    • Mohammed Shafi Shajakhan's avatar
      mac80211: Fix a rwlock bad magic bug · b57e6b56
      Mohammed Shafi Shajakhan authored
      read_lock(&tpt_trig->trig.leddev_list_lock) is accessed via the path
      ieee80211_open (->) ieee80211_do_open (->) ieee80211_mod_tpt_led_trig
      (->) ieee80211_start_tpt_led_trig (->) tpt_trig_timer before initializing
      it.
      the intilization of this read/write lock happens via the path
      ieee80211_led_init (->) led_trigger_register, but we are doing
      'ieee80211_led_init'  after 'ieeee80211_if_add' where we
      register netdev_ops.
      so we access leddev_list_lock before initializing it and causes the
      following bug in chrome laptops with AR928X cards with the following
      script
      
      while true
      do
      sudo modprobe -v ath9k
      sleep 3
      sudo modprobe -r ath9k
      sleep 3
      done
      
      	BUG: rwlock bad magic on CPU#1, wpa_supplicant/358, f5b9eccc
      	Pid: 358, comm: wpa_supplicant Not tainted 3.0.13 #1
      	Call Trace:
      
      	[<8137b9df>] rwlock_bug+0x3d/0x47
      	[<81179830>] do_raw_read_lock+0x19/0x29
      	[<8137f063>] _raw_read_lock+0xd/0xf
      	[<f9081957>] tpt_trig_timer+0xc3/0x145 [mac80211]
      	[<f9081f3a>] ieee80211_mod_tpt_led_trig+0x152/0x174 [mac80211]
      	[<f9076a3f>] ieee80211_do_open+0x11e/0x42e [mac80211]
      	[<f9075390>] ? ieee80211_check_concurrent_iface+0x26/0x13c [mac80211]
      	[<f9076d97>] ieee80211_open+0x48/0x4c [mac80211]
      	[<812dbed8>] __dev_open+0x82/0xab
      	[<812dc0c9>] __dev_change_flags+0x9c/0x113
      	[<812dc1ae>] dev_change_flags+0x18/0x44
      	[<8132144f>] devinet_ioctl+0x243/0x51a
      	[<81321ba9>] inet_ioctl+0x93/0xac
      	[<812cc951>] sock_ioctl+0x1c6/0x1ea
      	[<812cc78b>] ? might_fault+0x20/0x20
      	[<810b1ebb>] do_vfs_ioctl+0x46e/0x4a2
      	[<810a6ebb>] ? fget_light+0x2f/0x70
      	[<812ce549>] ? sys_recvmsg+0x3e/0x48
      	[<810b1f35>] sys_ioctl+0x46/0x69
      	[<8137fa77>] sysenter_do_call+0x12/0x2
      
      Cc: <stable@vger.kernel.org>
      Cc: Gary Morain <gmorain@google.com>
      Cc: Paul Stewart <pstew@google.com>
      Cc: Abhijit Pradhan <abhijit@qca.qualcomm.com>
      Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
      Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Acked-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Tested-by: default avatarMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: default avatarMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b57e6b56
  3. 07 Feb, 2012 1 commit
  4. 06 Feb, 2012 4 commits
  5. 03 Feb, 2012 3 commits
    • Mohammed Shafi Shajakhan's avatar
      ath9k: Fix kernel panic during driver initilization · 07445f68
      Mohammed Shafi Shajakhan authored
      all works need to be initialized before ieee80211_register_hw
      to prevent mac80211 call backs such as drv_start, drv_config
      getting started. otherwise we would queue/cancel works before
      initializing them and it leads to kernel panic.
      this issue can be recreated with the following script
      in Chrome laptops with AR928X cards, with background scan
      running (or) Network manager is running
      
      while true
      do
      sudo modprobe -v ath9k
      sleep 3
      sudo modprobe -r ath9k
      sleep 3
      done
      
      	 EIP: [<81040a47>] __cancel_work_timer+0xb8/0xe1 SS:ESP 0068:f6be9d70
      	 ---[ end trace 4f86d6139a9900ef ]---
      	 Registered led device: ath9k-phy0
      	 ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf88a0000,
      	 irq=16
      	 Kernel panic - not syncing: Fatal exception
      	 Pid: 456, comm: wpa_supplicant Tainted: G      D
      	 3.0.13 #1
      	Call Trace:
      	 [<81379e21>] panic+0x53/0x14a
      	 [<81004a30>] oops_end+0x73/0x81
      	 [<81004b53>] die+0x4c/0x55
      	 [<81002710>] do_trap+0x7c/0x83
      	 [<81002855>] ? do_bounds+0x58/0x58
      	 [<810028cc>] do_invalid_op+0x77/0x81
      	 [<81040a47>] ? __cancel_work_timer+0xb8/0xe1
      	 [<810489ec>] ? sched_clock_cpu+0x81/0x11f
      	 [<8103f809>] ? wait_on_work+0xe2/0xf7
      	 [<8137f807>] error_code+0x67/0x6c
      	 [<810300d8>] ? wait_consider_task+0x4ba/0x84c
      	 [<81040a47>] ? __cancel_work_timer+0xb8/0xe1
      	 [<810380c9>] ? try_to_del_timer_sync+0x5f/0x67
      	 [<81040a91>] cancel_work_sync+0xf/0x11
      	 [<f88d7b7c>] ath_set_channel+0x62/0x25c [ath9k]
      	 [<f88d67d1>] ? ath9k_tx_last_beacon+0x26a/0x85c [ath9k]
      	 [<f88d8899>] ath_radio_disable+0x3f1/0x68e [ath9k]
      	 [<f90d0edb>] ieee80211_hw_config+0x111/0x116 [mac80211]
      	 [<f90dd95c>] __ieee80211_recalc_idle+0x919/0xa37 [mac80211]
      	 [<f90dda76>] __ieee80211_recalc_idle+0xa33/0xa37 [mac80211]
      	 [<812dbed8>] __dev_open+0x82/0xab
      
      Cc: <stable@vger.kernel.org>
      Cc: Gary Morain <gmorain@google.com>
      Cc: Paul Stewart <pstew@google.com>
      Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
      Tested-by: default avatarMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: default avatarRajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Signed-off-by: default avatarMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      07445f68
    • Amitkumar Karwar's avatar
      mwifiex: handle association failure case correctly · b7097eb7
      Amitkumar Karwar authored
      Currently even if association is failed "iw link" shows some
      information about connected BSS and "Tx timeout" error is seen in
      dmesg log.
      
      This patch fixes below issues in the code to handle assoc failure
      case correctly.
      1) "status" variable in mwifiex_wait_queue_complete() is not
      correctly updated. Hence driver doesn't inform cfg80211 stack
      about association failure.
      2) During association network queues are stopped but carrier is
      not cleared, which gives Tx timeout error in failure case
      Signed-off-by: default avatarAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: default avatarBing Zhao <bzhao@marvell.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b7097eb7
    • John W. Linville's avatar
      ath9k: use WARN_ON_ONCE in ath_rc_get_highest_rix · 8149415e
      John W. Linville authored
      The device seems to survive the issue, so no need to flood the logs
      about it...
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      8149415e
  6. 01 Feb, 2012 6 commits
  7. 30 Jan, 2012 3 commits
    • Eric Dumazet's avatar
      af_unix: fix EPOLLET regression for stream sockets · 6f01fd6e
      Eric Dumazet authored
      Commit 0884d7aa (AF_UNIX: Fix poll blocking problem when reading from
      a stream socket) added a regression for epoll() in Edge Triggered mode
      (EPOLLET)
      
      Appropriate fix is to use skb_peek()/skb_unlink() instead of
      skb_dequeue(), and only call skb_unlink() when skb is fully consumed.
      
      This remove the need to requeue a partial skb into sk_receive_queue head
      and the extra sk->sk_data_ready() calls that added the regression.
      
      This is safe because once skb is given to sk_receive_queue, it is not
      modified by a writer, and readers are serialized by u->readlock mutex.
      
      This also reduce number of spinlock acquisition for small reads or
      MSG_PEEK users so should improve overall performance.
      Reported-by: default avatarNick Mathewson <nickm@freehaven.net>
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Cc: Alexey Moiseytsev <himeraster@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6f01fd6e
    • Neal Cardwell's avatar
      tcp: fix tcp_trim_head() to adjust segment count with skb MSS · 5b35e1e6
      Neal Cardwell authored
      This commit fixes tcp_trim_head() to recalculate the number of
      segments in the skb with the skb's existing MSS, so trimming the head
      causes the skb segment count to be monotonically non-increasing - it
      should stay the same or go down, but not increase.
      
      Previously tcp_trim_head() used the current MSS of the connection. But
      if there was a decrease in MSS between original transmission and ACK
      (e.g. due to PMTUD), this could cause tcp_trim_head() to
      counter-intuitively increase the segment count when trimming bytes off
      the head of an skb. This violated assumptions in tcp_tso_acked() that
      tcp_trim_head() only decreases the packet count, so that packets_acked
      in tcp_tso_acked() could underflow, leading tcp_clean_rtx_queue() to
      pass u32 pkts_acked values as large as 0xffffffff to
      ca_ops->pkts_acked().
      
      As an aside, if tcp_trim_head() had really wanted the skb to reflect
      the current MSS, it should have called tcp_set_skb_tso_segs()
      unconditionally, since a decrease in MSS would mean that a
      single-packet skb should now be sliced into multiple segments.
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Acked-by: default avatarNandita Dukkipati <nanditad@google.com>
      Acked-by: default avatarIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5b35e1e6
    • Glauber Costa's avatar
      net/tcp: Fix tcp memory limits initialization when !CONFIG_SYSCTL · 4acb4190
      Glauber Costa authored
      sysctl_tcp_mem() initialization was moved to sysctl_tcp_ipv4.c
      in commit 3dc43e3e, since it
      became a per-ns value.
      
      That code, however, will never run when CONFIG_SYSCTL is
      disabled, leading to bogus values on those fields - causing hung
      TCP sockets.
      
      This patch fixes it by keeping an initialization code in
      tcp_init(). It will be overwritten by the first net namespace
      init if CONFIG_SYSCTL is compiled in, and do the right thing if
      it is compiled out.
      
      It is also named properly as tcp_init_mem(), to properly signal
      its non-sysctl side effect on TCP limits.
      Reported-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarGlauber Costa <glommer@parallels.com>
      Cc: David S. Miller <davem@davemloft.net>
      Link: http://lkml.kernel.org/r/4F22D05A.8030604@parallels.com
      [ renamed the function, tidied up the changelog a bit ]
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4acb4190
  8. 28 Jan, 2012 3 commits
  9. 26 Jan, 2012 8 commits
    • Glauber Costa's avatar
      net: explicitly add jump_label.h header to sock.h · 9018e939
      Glauber Costa authored
      Commit 36a12119 removed linux/module.h
      include statement from one of the headers that end up in net/sock.h.
      It was providing us with static_branch() definition implicitly, so
      after its removal the build got broken.
      
      To fix this, and avoid having this happening in the future,
      let me do the right thing and include linux/jump_label.h
      explicitly in sock.h.
      Signed-off-by: default avatarGlauber Costa <glommer@parallels.com>
      Reported-by: default avatarRandy Dunlap <rdunlap@xenotime.net>
      CC: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9018e939
    • Stefan Gula's avatar
      net: RTNETLINK adjusting values of min_ifinfo_dump_size · f18da145
      Stefan Gula authored
      Setting link parameters on a netdevice changes the value
      of if_nlmsg_size(), therefore it is necessary to recalculate
      min_ifinfo_dump_size.
      Signed-off-by: default avatarStefan Gula <steweg@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f18da145
    • Willem de Bruijn's avatar
      ipv6: Fix ip_gre lockless xmits. · f2b3ee9e
      Willem de Bruijn authored
      Tunnel devices set NETIF_F_LLTX to bypass HARD_TX_LOCK.  Sit and
      ipip set this unconditionally in ops->setup, but gre enables it
      conditionally after parameter passing in ops->newlink. This is
      not called during tunnel setup as below, however, so GRE tunnels are
      still taking the lock.
      
      modprobe ip_gre
      ip tunnel add test0 mode gre remote 10.5.1.1 dev lo
      ip link set test0 up
      ip addr add 10.6.0.1 dev test0
       # cat /sys/class/net/test0/features
       # $DIR/test_tunnel_xmit 10 10.5.2.1
      ip route add 10.5.2.0/24 dev test0
      ip tunnel del test0
      
      The newlink callback is only called in rtnl_netlink, and only if
      the device is new, as it calls register_netdevice internally. Gre
      tunnels are created at 'ip tunnel add' with ioctl SIOCADDTUNNEL,
      which calls ipgre_tunnel_locate, which calls register_netdev.
      rtnl_newlink is called at 'ip link set', but skips ops->newlink
      and the device is up with locking still enabled. The equivalent
      ipip tunnel works fine, btw (just substitute 'method gre' for
      'method ipip').
      
      On kernels before /sys/class/net/*/features was removed [1],
      the first commented out line returns 0x6000 with method gre,
      which indicates that NETIF_F_LLTX (0x1000) is not set. With ipip,
      it reports 0x7000. This test cannot be used on recent kernels where
      the sysfs file is removed (and ETHTOOL_GFEATURES does not currently
      work for tunnel devices, because they lack dev->ethtool_ops).
      
      The second commented out line calls a simple transmission test [2]
      that sends on 24 cores at maximum rate. Results of a single run:
      
      ipip:			19,372,306
      gre before patch:	 4,839,753
      gre after patch:	19,133,873
      
      This patch replicates the condition check in ipgre_newlink to
      ipgre_tunnel_locate. It works for me, both with oseq on and off.
      This is the first time I looked at rtnetlink and iproute2 code,
      though, so someone more knowledgeable should probably check the
      patch. Thanks.
      
      The tail of both functions is now identical, by the way. To avoid
      code duplication, I'll be happy to rework this and merge the two.
      
      [1] http://patchwork.ozlabs.org/patch/104610/
      [2] http://kernel.googlecode.com/files/xmit_udp_parallel.cSigned-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Acked-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f2b3ee9e
    • Wei Liu's avatar
      40206dd9
    • Eric Dumazet's avatar
      netns: fix net_alloc_generic() · 073862ba
      Eric Dumazet authored
      When a new net namespace is created, we should attach to it a "struct
      net_generic" with enough slots (even empty), or we can hit the following
      BUG_ON() :
      
      [  200.752016] kernel BUG at include/net/netns/generic.h:40!
      ...
      [  200.752016]  [<ffffffff825c3cea>] ? get_cfcnfg+0x3a/0x180
      [  200.752016]  [<ffffffff821cf0b0>] ? lockdep_rtnl_is_held+0x10/0x20
      [  200.752016]  [<ffffffff825c41be>] caif_device_notify+0x2e/0x530
      [  200.752016]  [<ffffffff810d61b7>] notifier_call_chain+0x67/0x110
      [  200.752016]  [<ffffffff810d67c1>] raw_notifier_call_chain+0x11/0x20
      [  200.752016]  [<ffffffff821bae82>] call_netdevice_notifiers+0x32/0x60
      [  200.752016]  [<ffffffff821c2b26>] register_netdevice+0x196/0x300
      [  200.752016]  [<ffffffff821c2ca9>] register_netdev+0x19/0x30
      [  200.752016]  [<ffffffff81c1c67a>] loopback_net_init+0x4a/0xa0
      [  200.752016]  [<ffffffff821b5e62>] ops_init+0x42/0x180
      [  200.752016]  [<ffffffff821b600b>] setup_net+0x6b/0x100
      [  200.752016]  [<ffffffff821b6466>] copy_net_ns+0x86/0x110
      [  200.752016]  [<ffffffff810d5789>] create_new_namespaces+0xd9/0x190
      
      net_alloc_generic() should take into account the maximum index into the
      ptr array, as a subsystem might use net_generic() anytime.
      
      This also reduces number of reallocations in net_assign_generic()
      Reported-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Tested-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Cc: Sjur Brændeland <sjur.brandeland@stericsson.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Pavel Emelyanov <xemul@openvz.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      073862ba
    • Flavio Leitner's avatar
      tcp: bind() optimize port allocation · fddb7b57
      Flavio Leitner authored
      Port autoselection finds a port and then drop the lock,
      then right after that, gets the hash bucket again and lock it.
      
      Fix it to go direct.
      Signed-off-by: default avatarFlavio Leitner <fbl@redhat.com>
      Signed-off-by: default avatarMarcelo Ricardo Leitner <mleitner@redhat.com>
      Acked-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fddb7b57
    • Flavio Leitner's avatar
      tcp: bind() fix autoselection to share ports · 2b05ad33
      Flavio Leitner authored
      The current code checks for conflicts when the application
      requests a specific port.  If there is no conflict, then
      the request is granted.
      
      On the other hand, the port autoselection done by the kernel
      fails when all ports are bound even when there is a port
      with no conflict available.
      
      The fix changes port autoselection to check if there is a
      conflict and use it if not.
      Signed-off-by: default avatarFlavio Leitner <fbl@redhat.com>
      Signed-off-by: default avatarMarcelo Ricardo Leitner <mleitner@redhat.com>
      Acked-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2b05ad33
    • James Chapman's avatar
      l2tp: l2tp_ip - fix possible oops on packet receive · 68315801
      James Chapman authored
      When a packet is received on an L2TP IP socket (L2TPv3 IP link
      encapsulation), the l2tpip socket's backlog_rcv function calls
      xfrm4_policy_check(). This is not necessary, since it was called
      before the skb was added to the backlog. With CONFIG_NET_NS enabled,
      xfrm4_policy_check() will oops if skb->dev is null, so this trivial
      patch removes the call.
      
      This bug has always been present, but only when CONFIG_NET_NS is
      enabled does it cause problems. Most users are probably using UDP
      encapsulation for L2TP, hence the problem has only recently
      surfaced.
      
      EIP: 0060:[<c12bb62b>] EFLAGS: 00210246 CPU: 0
      EIP is at l2tp_ip_recvmsg+0xd4/0x2a7
      EAX: 00000001 EBX: d77b5180 ECX: 00000000 EDX: 00200246
      ESI: 00000000 EDI: d63cbd30 EBP: d63cbd18 ESP: d63cbcf4
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      Call Trace:
       [<c1218568>] sock_common_recvmsg+0x31/0x46
       [<c1215c92>] __sock_recvmsg_nosec+0x45/0x4d
       [<c12163a1>] __sock_recvmsg+0x31/0x3b
       [<c1216828>] sock_recvmsg+0x96/0xab
       [<c10b2693>] ? might_fault+0x47/0x81
       [<c10b2693>] ? might_fault+0x47/0x81
       [<c1167fd0>] ? _copy_from_user+0x31/0x115
       [<c121e8c8>] ? copy_from_user+0x8/0xa
       [<c121ebd6>] ? verify_iovec+0x3e/0x78
       [<c1216604>] __sys_recvmsg+0x10a/0x1aa
       [<c1216792>] ? sock_recvmsg+0x0/0xab
       [<c105a99b>] ? __lock_acquire+0xbdf/0xbee
       [<c12d5a99>] ? do_page_fault+0x193/0x375
       [<c10d1200>] ? fcheck_files+0x9b/0xca
       [<c10d1259>] ? fget_light+0x2a/0x9c
       [<c1216bbb>] sys_recvmsg+0x2b/0x43
       [<c1218145>] sys_socketcall+0x16d/0x1a5
       [<c11679f0>] ? trace_hardirqs_on_thunk+0xc/0x10
       [<c100305f>] sysenter_do_call+0x12/0x38
      Code: c6 05 8c ea a8 c1 01 e8 0c d4 d9 ff 85 f6 74 07 3e ff 86 80 00 00 00 b9 17 b6 2b c1 ba 01 00 00 00 b8 78 ed 48 c1 e8 23 f6 d9 ff <ff> 76 0c 68 28 e3 30 c1 68 2d 44 41 c1 e8 89 57 01 00 83 c4 0c
      Signed-off-by: default avatarJames Chapman <jchapman@katalix.com>
      Acked-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      68315801
  10. 24 Jan, 2012 1 commit
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 701b259f
      Linus Torvalds authored
      Davem says:
      
      1) Fix JIT code generation on x86-64 for divide by zero, from Eric Dumazet.
      
      2) tg3 header length computation correction from Eric Dumazet.
      
      3) More build and reference counting fixes for socket memory cgroup
         code from Glauber Costa.
      
      4) module.h snuck back into a core header after all the hard work we
         did to remove that, from Paul Gortmaker and Jesper Dangaard Brouer.
      
      5) Fix PHY naming regression and add some new PCI IDs in stmmac, from
         Alessandro Rubini.
      
      6) Netlink message generation fix in new team driver, should only advertise
         the entries that changed during events, from Jiri Pirko.
      
      7) SRIOV VF registration and unregistration fixes, and also add a
         missing PCI ID, from Roopa Prabhu.
      
      8) Fix infinite loop in tx queue flush code of brcmsmac, from Stanislaw Gruszka.
      
      9) ftgmac100/ftmac100 build fix, missing interrupt.h include.
      
      10) Memory leak fix in net/hyperv do_set_mutlicast() handling, from Wei Yongjun.
      
      11) Off by one fix in netem packet scheduler, from Vijay Subramanian.
      
      12) TCP loss detection fix from Yuchung Cheng.
      
      13) TCP reset packet MD5 calculation uses wrong address, fix from Shawn Lu.
      
      14) skge carrier assertion and DMA mapping fixes from Stephen Hemminger.
      
      15) Congestion recovery undo performed at the wrong spot in BIC and CUBIC
          congestion control modules, fix from Neal Cardwell.
      
      16) Ethtool ETHTOOL_GSSET_INFO is unnecessarily restrictive, from Michał Mirosław.
      
      17) Fix triggerable race in ipv6 sysctl handling, from Francesco Ruggeri.
      
      18) Statistics bug fixes in mlx4 from Eugenia Emantayev.
      
      19) rds locking bug fix during info dumps, from your's truly.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (67 commits)
        rds: Make rds_sock_lock BH rather than IRQ safe.
        netprio_cgroup.h: dont include module.h from other includes
        net: flow_dissector.c missing include linux/export.h
        team: send only changed options/ports via netlink
        net/hyperv: fix possible memory leak in do_set_multicast()
        drivers/net: dsa/mv88e6xxx.c files need linux/module.h
        stmmac: added PCI identifiers
        llc: Fix race condition in llc_ui_recvmsg
        stmmac: fix phy naming inconsistency
        dsa: Add reporting of silicon revision for Marvell 88E6123/88E6161/88E6165 switches.
        tg3: fix ipv6 header length computation
        skge: add byte queue limit support
        mv643xx_eth: Add Rx Discard and Rx Overrun statistics
        bnx2x: fix compilation error with SOE in fw_dump
        bnx2x: handle CHIP_REVISION during init_one
        bnx2x: allow user to change ring size in ISCSI SD mode
        bnx2x: fix Big-Endianess in ethtool -t
        bnx2x: fixed ethtool statistics for MF modes
        bnx2x: credit-leakage fixup on vlan_mac_del_all
        macvlan: fix a possible use after free
        ...
      701b259f