1. 13 Aug, 2010 3 commits
  2. 11 Aug, 2010 2 commits
    • Rajkumar Manoharan's avatar
      ath9k_htc: fix panic on packet injection using airbase-ng tool. · da93f106
      Rajkumar Manoharan authored
      This should fix the oops which occurs during the packet injection
      on monitor interface.
      
      EIP is at ath9k_htc_tx_start+0x69/0x220 [ath9k_htc]
       [<f84dc8ea>] ? invoke_tx_handlers+0xa5a/0xee0 [mac80211]
       [<f82c84f4>] ? ath9k_htc_tx+0x44/0xe0 [ath9k_htc]
       [<f84db7b8>] ? __ieee80211_tx+0xf8/0x190 [mac80211]
       [<f84dce0d>] ? ieee80211_tx+0x9d/0x1a0 [mac80211]
       [<f84dcfac>] ? ieee80211_xmit+0x9c/0x1c0 [mac80211]
       [<f84dd1b5>] ? ieee80211_monitor_start_xmit+0x85/0xb0 [mac80211]
       [<c04c30cd>] ? dev_hard_start_xmit+0x1ad/0x210
       [<c04b97c2>] ? __alloc_skb+0x52/0x130
       [<c04d7cd5>] ? sch_direct_xmit+0x105/0x170
       [<c04c5e9f>] ? dev_queue_xmit+0x37f/0x4b0
       [<c0567e1e>] ? packet_snd+0x21e/0x250
       [<c05684a2>] ? packet_sendmsg+0x32/0x40
       [<c04b4c63>] ? sock_aio_write+0x113/0x130
       [<c0207934>] ? do_sync_write+0xc4/0x100
       [<c0167740>] ? autoremove_wake_function+0x0/0x50
       [<c02f4414>] ? security_file_permission+0x14/0x20
       [<c0207ad4>] ? rw_verify_area+0x64/0xe0
       [<c01e6458>] ? handle_mm_fault+0x338/0x390
       [<c0207cd5>] ? vfs_write+0x185/0x1a0
       [<c058db20>] ? do_page_fault+0x160/0x3a0
       [<c0208512>] ? sys_write+0x42/0x70
       [<c01033ec>] ? syscall_call+0x7/0xb
      Signed-off-by: default avatarRajkumar Manoharan <rmanoharan@atheros.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      da93f106
    • John W. Linville's avatar
      ipw2100: register pm_qos request before registering pci driver · 2f81b471
      John W. Linville authored
      It is necessary to call pm_qos_add_request prior to calling
      pm_qos_update_request.  It was revealed that ipw2100 has been
      doing this wrong since "pm_qos: Get rid of the allocation in
      pm_qos_add_request()" (commit 82f68251)
      added a WARN that results in the following backtrace:
      
      WARNING: at kernel/pm_qos_params.c:264 pm_qos_update_request+0x5e/0x70()
      pm_qos_update_request() called for unknown object
      Call Trace:
      [<c1024088>] ? warn_slowpath_common+0x78/0xb0
      [<c1041c9e>] ? pm_qos_update_request+0x5e/0x70
      [<c1041c9e>] ? pm_qos_update_request+0x5e/0x70
      [<c1024153>] ? warn_slowpath_fmt+0x33/0x40
      [<c1041c9e>] ? pm_qos_update_request+0x5e/0x70
      [<f89fe15f>] ? ipw2100_up+0x3f/0xf10 [ipw2100]
      [<c11961c9>] ? vsnprintf+0xc9/0x530
      [<f89ff36c>] ? ipw2100_net_init+0x2c/0x1c0 [ipw2100]
      [<c12f542d>] ? register_netdevice+0x7d/0x3c0
      [<f89f9b00>] ? ipw2100_irq_tasklet+0x910/0x9a0 [ipw2100]
      [<c12f579f>] ? register_netdev+0x2f/0x40
      [<f89fd471>] ? ipw2100_pci_init_one+0xd21/0x1060 [ipw2100]
      [<c11a5ebb>] ? local_pci_probe+0xb/0x10
      [<c11a6d49>] ? pci_device_probe+0x69/0x90
      [<c1224704>] ? driver_probe_device+0x74/0x180
      [<c10dd15a>] ? sysfs_create_dir+0x6a/0xb0
      [<c1224889>] ? __driver_attach+0x79/0x80
      [<c1224810>] ? __driver_attach+0x0/0x80
      [<c1223fa2>] ? bus_for_each_dev+0x52/0x80
      [<c1224586>] ? driver_attach+0x16/0x20
      [<c1224810>] ? __driver_attach+0x0/0x80
      [<c122395f>] ? bus_add_driver+0x17f/0x250
      [<c11a5ec0>] ? pci_device_shutdown+0x0/0x20
      [<c11a6c80>] ? pci_device_remove+0x0/0x40
      [<c1224b13>] ? driver_register+0x63/0x120
      [<c11a6f96>] ? __pci_register_driver+0x36/0xa0
      [<f84f9048>] ? ipw2100_init+0x48/0x67 [ipw2100]
      [<c1001122>] ? do_one_initcall+0x32/0x170
      [<c1087078>] ? __vunmap+0xb8/0xf0
      [<f84f9000>] ? ipw2100_init+0x0/0x67 [ipw2100]
      [<c10510c1>] ? sys_init_module+0x161/0x1000
      [<c108f847>] ? sys_close+0x67/0xe0
      [<c13647c1>] ? syscall_call+0x7/0xb
      
      This patch moves pm_qos_add_request prior to pci_register_driver in
      ipw2100 in order to avoid this problem.
      Reported-by: default avatarChristoph Fritz <chf.fritz@googlemail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2f81b471
  3. 10 Aug, 2010 5 commits
  4. 09 Aug, 2010 8 commits
  5. 08 Aug, 2010 7 commits
  6. 06 Aug, 2010 3 commits
  7. 05 Aug, 2010 12 commits
    • Dan Carpenter's avatar
      isdn: fix information leak · 4b030d42
      Dan Carpenter authored
      The main motivation of this patch changing strcpy() to strlcpy().
      We strcpy() to copy a 48 byte buffers into a 49 byte buffers.  So at
      best the last byte has leaked information, or maybe there is an
      overflow?  Anyway, this patch closes the information leaks by zeroing
      the memory and the calls to strlcpy() prevent overflows.
      Signed-off-by: default avatarDan Carpenter <error27@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4b030d42
    • Jarek Poplawski's avatar
      net: Fix napi_gro_frags vs netpoll path · ce9e76c8
      Jarek Poplawski authored
      The netpoll_rx_on() check in __napi_gro_receive() skips part of the
      "common" GRO_NORMAL path, especially "pull:" in dev_gro_receive(),
      where at least eth header should be copied for entirely paged skbs.
      Signed-off-by: default avatarJarek Poplawski <jarkao2@gmail.com>
      Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ce9e76c8
    • Christian Samsel's avatar
      usbnet: remove noisy and hardly useful printk · 23d23e40
      Christian Samsel authored
      With turned on hspa modem (Dell 5530 internal card) and activated usb auto
      suspend, my system gets up 100 "usbnet_resume has delayed data" per
      minute. I didnt noticed any pathological behaviour, so just drop
      this message. if any objections, please at least change it to _DEBUG.
      Signed-off-by: default avatarChristian Samsel <christian.samsel@rwth-aachen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      23d23e40
    • John W. Linville's avatar
      rtl8180: avoid potential NULL deref in rtl8180_beacon_work · 8f1d2d2b
      John W. Linville authored
      ieee80211_beacon_get can return NULL...
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Cc: stable@kernel.org
      8f1d2d2b
    • Sujith's avatar
      ath9k: Remove myself from the MAINTAINERS list · c5d2711c
      Sujith authored
      So long.
      Signed-off-by: default avatarSujith <Sujith.Manoharan@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      c5d2711c
    • Dan Williams's avatar
      libertas: scan before assocation if no BSSID was given · cc026819
      Dan Williams authored
      Fix this leftover TODO from the cfg80211 conversion by doing a scan
      if cfg80211 didn't pass in the BSSID for us.  Since the scan code
      uses so much of the cfg80211_scan_request structure to build up the
      firmware command, we just fake one when the scan request is triggered
      internally.  But we need to make sure that internal 'fake' cfg82011
      scan request does not get back to cfg82011 via cfg80211_scan_done().
      Signed-off-by: default avatarDan Williams <dcbw@redhat.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      cc026819
    • Dan Williams's avatar
      libertas: fix association with some APs by using extended rates · 19757539
      Dan Williams authored
      Some APs get pissy if you don't send the firmware the extended rates
      in the association request's rates TLV.  Found this on a Linksys
      WRT54G v2; it denies association with status code 18 unless you
      add the extended rates too.  The old driver did this, but it got
      lost in the cfg80211 conversion.
      Signed-off-by: default avatarDan Williams <dcbw@redhat.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      19757539
    • Dan Williams's avatar
      libertas: get the right # of scanned BSSes · aebb628f
      Dan Williams authored
      Let's actually check the right field in the command response; and
      if there aren't any reported BSSes, exit early with success.
      Signed-off-by: default avatarDan Williams <dcbw@redhat.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      aebb628f
    • John W. Linville's avatar
    • Rusty Russell's avatar
      virtio_net: implements ethtool_ops.get_drvinfo · a767bde4
      Rusty Russell authored
      I often use "ethtool -i" command to check what driver controls the
      ehternet device.  But because current virtio_net driver doesn't
      support "ethtool -i", it becomes the following:
      
              # ethtool -i eth3
              Cannot get driver information: Operation not supported
      
      This patch simply adds the "ethtool -i" support. The following is the
      result when using the virtio_net driver with my patch applied to.
      
              # ethtool -i eth3
              driver: virtio_net
              version: N/A
              firmware-version: N/A
              bus-info: virtio0
      
      Personally, "-i" is one of the most frequently-used option, and most
      network drivers support "ethtool -i", so I think virtio_net also
      should do.
      Signed-off-by: default avatarTaku Izumi <izumi.taku@jp.fujitsu.com>
      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (use ARRAY_SIZE)
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a767bde4
    • stephen hemminger's avatar
      ppp: make channel_ops const · d7100da0
      stephen hemminger authored
      The PPP channel ops structure should be const.
      Cleanup the declarations to use standard C99 format.
      Signed-off-by: default avatarStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d7100da0
    • David Howells's avatar
      RxRPC: Fix a potential deadlock between the call resend_timer and state_lock · 3b5bac2b
      David Howells authored
      RxRPC can potentially deadlock as rxrpc_resend_time_expired() wants to get
      call->state_lock so that it can alter the state of an RxRPC call.  However, its
      caller (call_timer_fn()) has an apparent lock on the timer struct.
      
      The problem is that rxrpc_resend_time_expired() isn't permitted to lock
      call->state_lock as this could cause a deadlock against rxrpc_send_abort() as
      that takes state_lock and then attempts to delete the resend timer by calling
      del_timer_sync().
      
      The deadlock can occur because del_timer_sync() will sit there forever waiting
      for rxrpc_resend_time_expired() to return, but the latter may then wait for
      call->state_lock, which rxrpc_send_abort() holds around del_timer_sync()...
      
      This leads to a warning appearing in the kernel log that looks something like
      the attached.
      
      It should be sufficient to simply dispense with the locks.  It doesn't matter
      if we set the resend timer expired event bit and queue the event processor
      whilst we're changing state to one where the resend timer is irrelevant as the
      event can just be ignored by the processor thereafter.
      
      =======================================================
      [ INFO: possible circular locking dependency detected ]
      2.6.35-rc3-cachefs+ #115
      -------------------------------------------------------
      swapper/0 is trying to acquire lock:
       (&call->state_lock){++--..}, at: [<ffffffffa00200d4>] rxrpc_resend_time_expired+0x56/0x96 [af_rxrpc]
      
      but task is already holding lock:
       (&call->resend_timer){+.-...}, at: [<ffffffff8103b675>] run_timer_softirq+0x182/0x2a5
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&call->resend_timer){+.-...}:
             [<ffffffff810560bc>] __lock_acquire+0x889/0x8fa
             [<ffffffff81056184>] lock_acquire+0x57/0x6d
             [<ffffffff8103bb9c>] del_timer_sync+0x3c/0x86
             [<ffffffffa002bb7a>] rxrpc_send_abort+0x50/0x97 [af_rxrpc]
             [<ffffffffa002bdd9>] rxrpc_kernel_abort_call+0xa1/0xdd [af_rxrpc]
             [<ffffffffa0061588>] afs_deliver_to_call+0x129/0x368 [kafs]
             [<ffffffffa006181b>] afs_process_async_call+0x54/0xff [kafs]
             [<ffffffff8104261d>] worker_thread+0x1ef/0x2e2
             [<ffffffff81045f47>] kthread+0x7a/0x82
             [<ffffffff81002cd4>] kernel_thread_helper+0x4/0x10
      
      -> #0 (&call->state_lock){++--..}:
             [<ffffffff81055237>] validate_chain+0x727/0xd23
             [<ffffffff810560bc>] __lock_acquire+0x889/0x8fa
             [<ffffffff81056184>] lock_acquire+0x57/0x6d
             [<ffffffff813e6b69>] _raw_read_lock_bh+0x34/0x43
             [<ffffffffa00200d4>] rxrpc_resend_time_expired+0x56/0x96 [af_rxrpc]
             [<ffffffff8103b6e6>] run_timer_softirq+0x1f3/0x2a5
             [<ffffffff81036828>] __do_softirq+0xa2/0x13e
             [<ffffffff81002dcc>] call_softirq+0x1c/0x28
             [<ffffffff810049f0>] do_softirq+0x38/0x80
             [<ffffffff810361a2>] irq_exit+0x45/0x47
             [<ffffffff81018fb3>] smp_apic_timer_interrupt+0x88/0x96
             [<ffffffff81002893>] apic_timer_interrupt+0x13/0x20
             [<ffffffff810011ac>] cpu_idle+0x4d/0x83
             [<ffffffff813e06f3>] start_secondary+0x1bd/0x1c1
      
      other info that might help us debug this:
      
      1 lock held by swapper/0:
       #0:  (&call->resend_timer){+.-...}, at: [<ffffffff8103b675>] run_timer_softirq+0x182/0x2a5
      
      stack backtrace:
      Pid: 0, comm: swapper Not tainted 2.6.35-rc3-cachefs+ #115
      Call Trace:
       <IRQ>  [<ffffffff81054414>] print_circular_bug+0xae/0xbd
       [<ffffffff81055237>] validate_chain+0x727/0xd23
       [<ffffffff810560bc>] __lock_acquire+0x889/0x8fa
       [<ffffffff810539a7>] ? mark_lock+0x42f/0x51f
       [<ffffffff81056184>] lock_acquire+0x57/0x6d
       [<ffffffffa00200d4>] ? rxrpc_resend_time_expired+0x56/0x96 [af_rxrpc]
       [<ffffffff813e6b69>] _raw_read_lock_bh+0x34/0x43
       [<ffffffffa00200d4>] ? rxrpc_resend_time_expired+0x56/0x96 [af_rxrpc]
       [<ffffffffa00200d4>] rxrpc_resend_time_expired+0x56/0x96 [af_rxrpc]
       [<ffffffff8103b6e6>] run_timer_softirq+0x1f3/0x2a5
       [<ffffffff8103b675>] ? run_timer_softirq+0x182/0x2a5
       [<ffffffffa002007e>] ? rxrpc_resend_time_expired+0x0/0x96 [af_rxrpc]
       [<ffffffff810367ef>] ? __do_softirq+0x69/0x13e
       [<ffffffff81036828>] __do_softirq+0xa2/0x13e
       [<ffffffff81002dcc>] call_softirq+0x1c/0x28
       [<ffffffff810049f0>] do_softirq+0x38/0x80
       [<ffffffff810361a2>] irq_exit+0x45/0x47
       [<ffffffff81018fb3>] smp_apic_timer_interrupt+0x88/0x96
       [<ffffffff81002893>] apic_timer_interrupt+0x13/0x20
       <EOI>  [<ffffffff81049de1>] ? __atomic_notifier_call_chain+0x0/0x86
       [<ffffffff8100955b>] ? mwait_idle+0x6e/0x78
       [<ffffffff81009552>] ? mwait_idle+0x65/0x78
       [<ffffffff810011ac>] cpu_idle+0x4d/0x83
       [<ffffffff813e06f3>] start_secondary+0x1bd/0x1c1
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3b5bac2b