1. 20 Apr, 2010 3 commits
  2. 19 Apr, 2010 13 commits
  3. 18 Apr, 2010 2 commits
    • Eric Dumazet's avatar
      net: Introduce skb_orphan_try() · fc6055a5
      Eric Dumazet authored
      
      
      Transmitted skb might be attached to a socket and a destructor, for
      memory accounting purposes.
      
      Traditionally, this destructor is called at tx completion time, when skb
      is freed.
      
      When tx completion is performed by another cpu than the sender, this
      forces some cache lines to change ownership. XPS was an attempt to give
      tx completion to initial cpu.
      
      David idea is to call destructor right before giving skb to device (call
      to ndo_start_xmit()). Because device queues are usually small, orphaning
      skb before tx completion is not a big deal. Some drivers already do
      this, we could do it in upper level.
      
      There is one known exception to this early orphaning, called tx
      timestamping. It needs to keep a reference to socket until device can
      give a hardware or software timestamp.
      
      This patch adds a skb_orphan_try() helper, to centralize all exceptions
      to early orphaning in one spot, and use it in dev_hard_start_xmit().
      
      "tbench 16" results on a Nehalem machine (2 X5570  @ 2.93GHz)
      before: Throughput 4428.9 MB/sec 16 procs
      after: Throughput 4448.14 MB/sec 16 procs
      
      UDP should get even better results, its destructor being more complex,
      since SOCK_USE_WRITE_QUEUE is not set (four atomic ops instead of one)
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fc6055a5
    • Eric Dumazet's avatar
      net: remove time limit in process_backlog() · 9958da05
      Eric Dumazet authored
      
      
      - There is no point to enforce a time limit in process_backlog(), since
      other napi instances dont follow same rule. We can exit after only one
      packet processed...
      The normal quota of 64 packets per napi instance should be the norm, and
      net_rx_action() already has its own time limit.
      Note : /proc/net/core/dev_weight can be used to tune this 64 default
      value.
      
      - Use DEFINE_PER_CPU_ALIGNED for softnet_data definition.
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9958da05
  4. 17 Apr, 2010 1 commit
  5. 16 Apr, 2010 4 commits
    • Tom Herbert's avatar
      rfs: Receive Flow Steering · fec5e652
      Tom Herbert authored
      
      
      This patch implements receive flow steering (RFS).  RFS steers
      received packets for layer 3 and 4 processing to the CPU where
      the application for the corresponding flow is running.  RFS is an
      extension of Receive Packet Steering (RPS).
      
      The basic idea of RFS is that when an application calls recvmsg
      (or sendmsg) the application's running CPU is stored in a hash
      table that is indexed by the connection's rxhash which is stored in
      the socket structure.  The rxhash is passed in skb's received on
      the connection from netif_receive_skb.  For each received packet,
      the associated rxhash is used to look up the CPU in the hash table,
      if a valid CPU is set then the packet is steered to that CPU using
      the RPS mechanisms.
      
      The convolution of the simple approach is that it would potentially
      allow OOO packets.  If threads are thrashing around CPUs or multiple
      threads are trying to read from the same sockets, a quickly changing
      CPU value in the hash table could cause rampant OOO packets--
      we consider this a non-starter.
      
      To avoid OOO packets, this solution implements two types of hash
      tables: rps_sock_flow_table and rps_dev_flow_table.
      
      rps_sock_table is a global hash table.  Each entry is just a CPU
      number and it is populated in recvmsg and sendmsg as described above.
      This table contains the "desired" CPUs for flows.
      
      rps_dev_flow_table is specific to each device queue.  Each entry
      contains a CPU and a tail queue counter.  The CPU is the "current"
      CPU for a matching flow.  The tail queue counter holds the value
      of a tail queue counter for the associated CPU's backlog queue at
      the time of last enqueue for a flow matching the entry.
      
      Each backlog queue has a queue head counter which is incremented
      on dequeue, and so a queue tail counter is computed as queue head
      count + queue length.  When a packet is enqueued on a backlog queue,
      the current value of the queue tail counter is saved in the hash
      entry of the rps_dev_flow_table.
      
      And now the trick: when selecting the CPU for RPS (get_rps_cpu)
      the rps_sock_flow table and the rps_dev_flow table for the RX queue
      are consulted.  When the desired CPU for the flow (found in the
      rps_sock_flow table) does not match the current CPU (found in the
      rps_dev_flow table), the current CPU is changed to the desired CPU
      if one of the following is true:
      
      - The current CPU is unset (equal to RPS_NO_CPU)
      - Current CPU is offline
      - The current CPU's queue head counter >= queue tail counter in the
      rps_dev_flow table.  This checks if the queue tail has advanced
      beyond the last packet that was enqueued using this table entry.
      This guarantees that all packets queued using this entry have been
      dequeued, thus preserving in order delivery.
      
      Making each queue have its own rps_dev_flow table has two advantages:
      1) the tail queue counters will be written on each receive, so
      keeping the table local to interrupting CPU s good for locality.  2)
      this allows lockless access to the table-- the CPU number and queue
      tail counter need to be accessed together under mutual exclusion
      from netif_receive_skb, we assume that this is only called from
      device napi_poll which is non-reentrant.
      
      This patch implements RFS for TCP and connected UDP sockets.
      It should be usable for other flow oriented protocols.
      
      There are two configuration parameters for RFS.  The
      "rps_flow_entries" kernel init parameter sets the number of
      entries in the rps_sock_flow_table, the per rxqueue sysfs entry
      "rps_flow_cnt" contains the number of entries in the rps_dev_flow
      table for the rxqueue.  Both are rounded to power of two.
      
      The obvious benefit of RFS (over just RPS) is that it achieves
      CPU locality between the receive processing for a flow and the
      applications processing; this can result in increased performance
      (higher pps, lower latency).
      
      The benefits of RFS are dependent on cache hierarchy, application
      load, and other factors.  On simple benchmarks, we don't necessarily
      see improvement and sometimes see degradation.  However, for more
      complex benchmarks and for applications where cache pressure is
      much higher this technique seems to perform very well.
      
      Below are some benchmark results which show the potential benfit of
      this patch.  The netperf test has 500 instances of netperf TCP_RR
      test with 1 byte req. and resp.  The RPC test is an request/response
      test similar in structure to netperf RR test ith 100 threads on
      each host, but does more work in userspace that netperf.
      
      e1000e on 8 core Intel
         No RFS or RPS		104K tps at 30% CPU
         No RFS (best RPS config):    290K tps at 63% CPU
         RFS				303K tps at 61% CPU
      
      RPC test	tps	CPU%	50/90/99% usec latency	Latency StdDev
        No RFS/RPS	103K	48%	757/900/3185		4472.35
        RPS only:	174K	73%	415/993/2468		491.66
        RFS		223K	73%	379/651/1382		315.61
      Signed-off-by: default avatarTom Herbert <therbert@google.com>
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fec5e652
    • Shan Wei's avatar
      ipv6: fix the comment of ip6_xmit() · b5d43998
      Shan Wei authored
      
      
      ip6_xmit() is used by upper transport protocol.
      Signed-off-by: default avatarShan Wei <shanwei@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b5d43998
    • Shan Wei's avatar
      net: replace ipfragok with skb->local_df · 4e15ed4d
      Shan Wei authored
      
      
      As Herbert Xu said: we should be able to simply replace ipfragok
      with skb->local_df. commit f88037(sctp: Drop ipfargok in sctp_xmit function)
      has droped ipfragok and set local_df value properly.
      
      The patch kills the ipfragok parameter of .queue_xmit().
      Signed-off-by: default avatarShan Wei <shanwei@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4e15ed4d
    • Shan Wei's avatar
      ipv6: cancel to setting local_df in ip6_xmit() · 0eecb784
      Shan Wei authored
      
      
      commit f88037(sctp: Drop ipfargok in sctp_xmit function)
      has droped ipfragok and set local_df value properly.
      
      So the change of commit 77e2f1(ipv6: Fix ip6_xmit to
      send fragments if ipfragok is true) is not needed.
      So the patch remove them.
      Signed-off-by: default avatarShan Wei <shanwei@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0eecb784
  6. 15 Apr, 2010 9 commits
  7. 14 Apr, 2010 8 commits
    • David S. Miller's avatar
    • Jesse Brandeburg's avatar
      ixgbe: fix bug with vlan strip in promsic mode · 5f6c0181
      Jesse Brandeburg authored
      
      
      The ixgbe driver was setting up 82598 hardware correctly, so that
      when promiscuous mode was enabled hardware stripping was turned
      off.  But on 82599 the logic to disable/enable hardware stripping
      is different, and the code was not updated correctly when the
      hardware vlan stripping was enabled as default.
      
      This change comprises the creation of two new helper functions
      and calling them from the right locations to disable and enable
      hardware stripping of vlan tags at appropriate times.
      Signed-off-by: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5f6c0181
    • Eric Dumazet's avatar
      drivers: net: use skb_headlen() · e743d313
      Eric Dumazet authored
      
      
      replaces (skb->len - skb->data_len) occurrences by skb_headlen(skb)
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e743d313
    • Xose Vazquez Perez's avatar
      wireless: rt2x00: rt2800usb: identify Sitecom devices · a5e944f1
      Xose Vazquez Perez authored
      
      
      A very useful information was provided by Sitecom R&D guys:
      
      Please find the information regarding our latest Ralink adapters below;
      
      WL-302    -    VID: 0x0DF6,    PID: 0x002D    -    Ralink RT2771
      WL-315    -    VID: 0x0DF6,    PID: 0x0039    -    Ralink RT2770
      WL-319    -    VID: 0x182D,    PID: 0x0037    -    Ralink RT2860
      WL-321    -    VID: 0x0DF6,    PID: 0x003B    -    Ralink RT2770
      WL-324    -    VID: 0x0DF6,    PID: 0x003D    -    Ralink RT2870
      WL-329    -    VID: 0x0DF6,    PID: 0x0041    -    Ralink RT3572
      WL-343    -    VID: 0x0DF6,    PID: 0x003E    -    Ralink RT3070
      WL-344    -    VID: 0x0DF6,    PID: 0x0040    -    Ralink RT3071
      WL-345    -    VID: 0x0DF6,    PID: 0x0042    -    Ralink RT3072
      WL-608    -    VID: 0x0DF6,    PID: 0x003F    -    Ralink RT2070
      
      Note:
      PID: 0x003C, 0x004A, and 0x004D:   --these products do not exist; devices were never produced/shipped--
      
      The WL-349v4 USB dongle (0x0df6,0x0050) will be shipped soon (it isn't available yet), and uses a Ralink RT3370 chipset.
      Signed-off-by: default avatarXose Vazquez Perez <xose.vazquez@gmail.com>
      Acked-by: default avatarGertjan van Wingerde <gwingerde@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a5e944f1
    • Christian Lamparter's avatar
      ar9170usb: add a couple more USB IDs · 94d0bbe8
      Christian Lamparter authored
      
      
      This patch adds the following 5 entries to the usbid device table:
      
       * Netgear WNA1000
       * Proxim ORiNOCO Dual Band 802.11n USB Adapter
       * 3Com Dual Band 802.11n USB Adapter
       * H3C Dual Band 802.11n USB Adapter
       * WNC Generic 11n USB dongle
      
      CC: <stable@kernel.org>
      Signed-off-by: default avatarChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      94d0bbe8
    • Grazvydas Ignotas's avatar
      wl1251: don't require NVS data when EEPROM is used · afa5ec27
      Grazvydas Ignotas authored
      
      
      If EEPROM is used, NVS data is now loaded but ignored.
      Stop loading it to avoid need of dummy NVS file for modules with EEPROM.
      Signed-off-by: default avatarGrazvydas Ignotas <notasas@gmail.com>
      Acked-by: default avatarKalle Valo <kvalo@adurom.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      afa5ec27
    • Ming Lei's avatar
      ath9k-htc: fix lockdep warning and kernel warning after unplugging ar9271 usb device · f8e1d080
      Ming Lei authored
      
      
      This patch fixes two warnings below after unplugging ar9271 usb device:
      	-one is a kernel warning[1]
      	-another is a lockdep warning[2]
      
      The root reason is that __skb_queue_purge can't be executed in hardirq
      context, so the patch forks ath9k_skb_queue_purge(ath9k version of _skb_queue_purge),
      which frees skb with dev_kfree_skb_any which can be run in hardirq
      context safely, then prevent the lockdep warning and kernel warning after
      unplugging ar9271 usb device.
      
      [1] kernel warning
      [  602.894005] ------------[ cut here ]------------
      [  602.894005] WARNING: at net/core/skbuff.c:398 skb_release_head_state+0x71/0x87()
      [  602.894005] Hardware name: 6475EK2
      [  602.894005] Modules linked in: ath9k_htc ath9k ath9k_common ath9k_hw ath bridge stp llc sunrpc ipv6 cpufreq_ondemand acpi_cpufreq freq_table kvm_intel kvm arc4 ecb mac80211 snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep thinkpad_acpi snd_pcm snd_timer hwmon iTCO_wdt snd e1000e pcspkr i2c_i801 usbhid iTCO_vendor_support wmi cfg80211 yenta_socket rsrc_nonstatic pata_acpi snd_page_alloc soundcore uhci_hcd ohci_hcd ehci_hcd usbcore i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: ath]
      [  602.894005] Pid: 2506, comm: ping Tainted: G        W  2.6.34-rc3-wl #20
      [  602.894005] Call Trace:
      [  602.894005]  <IRQ>  [<ffffffff8104a41c>] warn_slowpath_common+0x7c/0x94
      [  602.894005]  [<ffffffffa022f398>] ? __skb_queue_purge+0x43/0x4a [ath9k_htc]
      [  602.894005]  [<ffffffff8104a448>] warn_slowpath_null+0x14/0x16
      [  602.894005]  [<ffffffff813269c1>] skb_release_head_state+0x71/0x87
      [  602.894005]  [<ffffffff8132829a>] __kfree_skb+0x16/0x81
      [  602.894005]  [<ffffffff813283b2>] kfree_skb+0x7e/0x86
      [  602.894005]  [<ffffffffa022f398>] __skb_queue_purge+0x43/0x4a [ath9k_htc]
      [  602.894005]  [<ffffffffa022f560>] __hif_usb_tx+0x1c1/0x21b [ath9k_htc]
      [  602.894005]  [<ffffffffa022f73c>] hif_usb_tx_cb+0x12f/0x154 [ath9k_htc]
      [  602.894005]  [<ffffffffa00d2fbe>] usb_hcd_giveback_urb+0x91/0xc5 [usbcore]
      [  602.894005]  [<ffffffffa00f6c34>] ehci_urb_done+0x7a/0x8b [ehci_hcd]
      [  602.894005]  [<ffffffffa00f6f33>] qh_completions+0x2ee/0x376 [ehci_hcd]
      [  602.894005]  [<ffffffffa00f8ba5>] ehci_work+0x95/0x76e [ehci_hcd]
      [  602.894005]  [<ffffffffa00fa5ae>] ? ehci_irq+0x2f/0x1d4 [ehci_hcd]
      [  602.894005]  [<ffffffffa00fa725>] ehci_irq+0x1a6/0x1d4 [ehci_hcd]
      [  602.894005]  [<ffffffff810a6d18>] ? __rcu_process_callbacks+0x7a/0x2df
      [  602.894005]  [<ffffffff810a47a4>] ? handle_fasteoi_irq+0x22/0xd2
      [  602.894005]  [<ffffffffa00d268d>] usb_hcd_irq+0x4a/0xa7 [usbcore]
      [  602.894005]  [<ffffffff810a2853>] handle_IRQ_event+0x77/0x14f
      [  602.894005]  [<ffffffff813285ce>] ? skb_release_data+0xc9/0xce
      [  602.894005]  [<ffffffff810a4814>] handle_fasteoi_irq+0x92/0xd2
      [  602.894005]  [<ffffffff8100c4fb>] handle_irq+0x88/0x91
      [  602.894005]  [<ffffffff8100baed>] do_IRQ+0x63/0xc9
      [  602.894005]  [<ffffffff81354245>] ? ip_flush_pending_frames+0x4d/0x5c
      [  602.894005]  [<ffffffff813ba993>] ret_from_intr+0x0/0x16
      [  602.894005]  <EOI>  [<ffffffff811095fe>] ? __delete_object+0x5a/0xb1
      [  602.894005]  [<ffffffff813ba5f5>] ? _raw_write_unlock_irqrestore+0x47/0x7e
      [  602.894005]  [<ffffffff813ba5fa>] ? _raw_write_unlock_irqrestore+0x4c/0x7e
      [  602.894005]  [<ffffffff811095fe>] __delete_object+0x5a/0xb1
      [  602.894005]  [<ffffffff81109814>] delete_object_full+0x25/0x31
      [  602.894005]  [<ffffffff813a60c0>] kmemleak_free+0x26/0x45
      [  602.894005]  [<ffffffff810ff517>] kfree+0xaa/0x149
      [  602.894005]  [<ffffffff81323fb7>] ? sock_def_write_space+0x84/0x89
      [  602.894005]  [<ffffffff81354245>] ? ip_flush_pending_frames+0x4d/0x5c
      [  602.894005]  [<ffffffff813285ce>] skb_release_data+0xc9/0xce
      [  602.894005]  [<ffffffff813282a2>] __kfree_skb+0x1e/0x81
      [  602.894005]  [<ffffffff813283b2>] kfree_skb+0x7e/0x86
      [  602.894005]  [<ffffffff81354245>] ip_flush_pending_frames+0x4d/0x5c
      [  602.894005]  [<ffffffff81370c1f>] raw_sendmsg+0x653/0x709
      [  602.894005]  [<ffffffff81379e31>] inet_sendmsg+0x54/0x5d
      [  602.894005]  [<ffffffff813207a2>] ? sock_recvmsg+0xc6/0xdf
      [  602.894005]  [<ffffffff813208c1>] sock_sendmsg+0xc0/0xd9
      [  602.894005]  [<ffffffff810e13b4>] ? might_fault+0x68/0xb8
      [  602.894005]  [<ffffffff810e13fd>] ? might_fault+0xb1/0xb8
      [  602.894005]  [<ffffffff8132a1c3>] ? copy_from_user+0x2f/0x31
      [  602.894005]  [<ffffffff8132a5b3>] ? verify_iovec+0x54/0x91
      [  602.894005]  [<ffffffff81320d41>] sys_sendmsg+0x1da/0x241
      [  602.894005]  [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9
      [  602.894005]  [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9
      [  602.894005]  [<ffffffff8107642e>] ? trace_hardirqs_on_caller+0x16/0x150
      [  602.894005]  [<ffffffff813ba27d>] ? _raw_spin_unlock_irq+0x56/0x63
      [  602.894005]  [<ffffffff8103d3cb>] ? finish_task_switch+0xa4/0xc9
      [  602.894005]  [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9
      [  602.894005]  [<ffffffff810357fe>] ? need_resched+0x23/0x2d
      [  602.894005]  [<ffffffff8107642e>] ? trace_hardirqs_on_caller+0x16/0x150
      [  602.894005]  [<ffffffff813b9750>] ? trace_hardirqs_on_thunk+0x3a/0x3f
      [  602.894005]  [<ffffffff81009c02>] system_call_fastpath+0x16/0x1b
      [  602.894005] ---[ end trace 91ba2d8dc7826839 ]---
      
      [2] lockdep warning
      [  169.363215] ======================================================
      [  169.365390] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
      [  169.366334] 2.6.34-rc3-wl #20
      [  169.366872] ------------------------------------------------------
      [  169.366872] khubd/78 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
      [  169.366872]  (clock-AF_INET){++.?..}, at: [<ffffffff81323f51>] sock_def_write_space+0x1e/0x89
      [  169.366872]
      [  169.366872] and this task is already holding:
      [  169.366872]  (&(&hif_dev->tx.tx_lock)->rlock){-.-...}, at: [<ffffffffa03715b0>] hif_usb_stop+0x24/0x53 [ath9k_htc]
      [  169.366872] which would create a new lock dependency:
      [  169.366872]  (&(&hif_dev->tx.tx_lock)->rlock){-.-...} -> (clock-AF_INET){++.?..}
      [  169.366872]
      [  169.366872] but this new dependency connects a HARDIRQ-irq-safe lock:
      [  169.366872]  (&(&hif_dev->tx.tx_lock)->rlock){-.-...}
      [  169.366872] ... which became HARDIRQ-irq-safe at:
      [  169.366872]   [<ffffffff810772d5>] __lock_acquire+0x2c6/0xd2b
      [  169.366872]   [<ffffffff8107866d>] lock_acquire+0xec/0x119
      [  169.366872]   [<ffffffff813b99bb>] _raw_spin_lock+0x40/0x73
      [  169.366872]   [<ffffffffa037163d>] hif_usb_tx_cb+0x5e/0x154 [ath9k_htc]
      [  169.366872]   [<ffffffffa00d2fbe>] usb_hcd_giveback_urb+0x91/0xc5 [usbcore]
      [  169.366872]   [<ffffffffa00f6c34>] ehci_urb_done+0x7a/0x8b [ehci_hcd]
      [  169.366872]   [<ffffffffa00f6f33>] qh_completions+0x2ee/0x376 [ehci_hcd]
      [  169.366872]   [<ffffffffa00f8ba5>] ehci_work+0x95/0x76e [ehci_hcd]
      [  169.366872]   [<ffffffffa00fa725>] ehci_irq+0x1a6/0x1d4 [ehci_hcd]
      [  169.366872]   [<ffffffffa00d268d>] usb_hcd_irq+0x4a/0xa7 [usbcore]
      [  169.366872]   [<ffffffff810a2853>] handle_IRQ_event+0x77/0x14f
      [  169.366872]   [<ffffffff810a4814>] handle_fasteoi_irq+0x92/0xd2
      [  169.366872]   [<ffffffff8100c4fb>] handle_irq+0x88/0x91
      [  169.366872]   [<ffffffff8100baed>] do_IRQ+0x63/0xc9
      [  169.366872]   [<ffffffff813ba993>] ret_from_intr+0x0/0x16
      [  169.366872]   [<ffffffff8130f6ee>] cpuidle_idle_call+0xa7/0x115
      [  169.366872]   [<ffffffff81008c4f>] cpu_idle+0x68/0xc4
      [  169.366872]   [<ffffffff813a41e0>] rest_init+0x104/0x10b
      [  169.366872]   [<ffffffff81899db3>] start_kernel+0x3f1/0x3fc
      [  169.366872]   [<ffffffff818992c8>] x86_64_start_reservations+0xb3/0xb7
      [  169.366872]   [<ffffffff818993c4>] x86_64_start_kernel+0xf8/0x107
      [  169.366872]
      [  169.366872] to a HARDIRQ-irq-unsafe lock:
      [  169.366872]  (clock-AF_INET){++.?..}
      [  169.366872] ... which became HARDIRQ-irq-unsafe at:
      [  169.366872] ...  [<ffffffff81077349>] __lock_acquire+0x33a/0xd2b
      [  169.366872]   [<ffffffff8107866d>] lock_acquire+0xec/0x119
      [  169.366872]   [<ffffffff813b9d07>] _raw_write_lock_bh+0x45/0x7a
      [  169.366872]   [<ffffffff8135cf14>] tcp_close+0x165/0x34d
      [  169.366872]   [<ffffffff8137aced>] inet_release+0x55/0x5c
      [  169.366872]   [<ffffffff81321350>] sock_release+0x1f/0x6e
      [  169.366872]   [<ffffffff813213c6>] sock_close+0x27/0x2b
      [  169.366872]   [<ffffffff8110dd45>] __fput+0x125/0x1ca
      [  169.366872]   [<ffffffff8110de04>] fput+0x1a/0x1c
      [  169.366872]   [<ffffffff8110adc9>] filp_close+0x68/0x72
      [  169.366872]   [<ffffffff8110ae80>] sys_close+0xad/0xe7
      [  169.366872]   [<ffffffff81009c02>] system_call_fastpath+0x16/0x1b
      
      (Trimmed at the "other info that might help us debug this" line in
      the interest of brevity... -- JWL)
      Signed-off-by: default avatarMing Lei <tom.leiming@gmail.com>
      Acked-by: default avatarSujith <Sujith.Manoharan@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f8e1d080
    • Ming Lei's avatar
      ath9k-htc:respect usb buffer cacheline alignment in reg out path · 0fa35a58
      Ming Lei authored
      
      
      In ath9k-htc register out path, ath9k-htc will pass skb->data into
      usb hcd and usb hcd will do dma mapping and unmapping to the buffer
      pointed by skb->data, so we should pass a cache-line aligned address.
      
      This patch replace __dev_alloc_skb with alloc_skb to make skb->data
      pointed to a cacheline aligned address simply since ath9k-htc does not
      skb_push on the skb and pass it to mac80211, also use kfree_skb to free
      the skb allocated by alloc_skb(we can use kfree_skb safely in hardirq
      context since skb->destructor is NULL always in the path).
      Signed-off-by: default avatarSujith <Sujith.Manoharan@atheros.com>
      Signed-off-by: default avatarMing Lei <tom.leiming@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0fa35a58