1. 10 2月, 2011 1 次提交
  2. 09 2月, 2011 9 次提交
  3. 08 2月, 2011 13 次提交
  4. 07 2月, 2011 1 次提交
  5. 06 2月, 2011 2 次提交
  6. 05 2月, 2011 6 次提交
    • M
      ath9k: Fix possible double free of PAPRD skb's · 9cf04dcc
      Mohammed Shafi Shajakhan 提交于
      This patch reverts the following commit
      ath9k: remove bfs_paprd_timestamp from struct ath_buf_state
      
      Under high interference/noisy environment conditions where PAPRD frames
      fails heavily introduces a possibility of double freeing skb's and causes
      kernel panic after some time.This patch reverts back to the original approach
      of using paprd_timestamp before freeing the PAPRD frame skb's
      
      [  194.193705] Pid: 0, comm: swapper Tainted: G      D WC
      2.6.35-22-generic #33-Ubuntu
      [  194.193712] Call Trace:
      [  194.193722]  [<c05c6468>] ? printk+0x2d/0x35
      [  194.193732]  [<c05c63c3>] panic+0x5a/0xd2
      [  194.193741]  [<c05ca3ed>] oops_end+0xcd/0xd0
      [  194.193750]  [<c0105f74>] die+0x54/0x80
      [  194.193758]  [<c05c9a16>] do_trap+0x96/0xc0
      [  194.193837]  [<c0103fb0>] ? do_invalid_op+0x0/0xa0
      [  194.193846]  [<c010403b>] do_invalid_op+0x8b/0xa0
      [  194.193856]  [<c020bd4c>] ? kfree+0xec/0xf0
      [  194.193866]  [<c012ce18>] ? default_spin_lock_flags+0x8/0x10
      [  194.193877]  [<c01de47a>] ? free_one_page+0x12a/0x2d0
      [  194.193888]  [<c01e04dc>] ? __free_pages+0x1c/0x40
      [  194.193897]  [<c05c97a7>] error_code+0x73/0x78
      [  194.193906]  [<c020bd4c>] ? kfree+0xec/0xf0
      [  194.193915]  [<c04ecdd0>] ? skb_release_data+0x70/0xa0
      [  194.193924]  [<c04ecdd0>] skb_release_data+0x70/0xa0
      [  194.193933]  [<c04ec997>] __kfree_skb+0x17/0x90
      [  194.193941]  [<c04eca31>] consume_skb+0x21/0x40
      [  194.193964]  [<f85e0b70>] ieee80211_tx_status+0x760/0x860 [mac80211]
      [  194.193979]  [<f85caddf>] ath_tx_complete_buf+0x1bf/0x2c0 [ath9k]
      [  194.193988]  [<c05c8b9f>] ? _raw_spin_lock_irqsave+0x2f/0x50
      [  194.193997]  [<c04ec40e>] ? skb_queue_tail+0x3e/0x50
      [  194.194010]  [<f85cc803>] ath_tx_complete_aggr+0x823/0x940 [ath9k]
      [  194.194021]  [<c0108a28>] ? sched_clock+0x8/0x10
      [  194.194030]  [<c016bf14>] ? sched_clock_local+0xa4/0x180
      [  194.194040]  [<c0139f57>] ? enqueue_sleeper+0x1e7/0x2b0
      [  194.194051]  [<c013a194>] ? enqueue_entity+0x174/0x200
      [  194.194064]  [<f85ce83d>] ath_tx_edma_tasklet+0x2bd/0x3b0 [ath9k]
      [  194.194074]  [<c05c8b9f>] ? _raw_spin_lock_irqsave+0x2f/0x50
      [  194.194088]  [<f85c7b9f>] ath9k_tasklet+0x9f/0x190 [ath9k]
      [  194.194097]  [<c01505d7>] tasklet_action+0xa7/0xb0
      [  194.194107]  [<c015127c>] __do_softirq+0x9c/0x1b0
      [  194.194117]  [<c01a7f64>] ? irq_to_desc+0x14/0x20
      [  194.194126]  [<c0124fc4>] ? ack_apic_level+0x64/0x1f0
      [  194.194136]  [<c01513d5>] do_softirq+0x45/0x50
      [  194.194145]  [<c0151545>] irq_exit+0x65/0x70
      [  194.194153]  [<c05cf665>] do_IRQ+0x55/0xc0
      [  194.194162]  [<c016a6c7>] ? hrtimer_start+0x27/0x30
      [  194.194171]  [<c0103630>] common_interrupt+0x30/0x38
      [  194.194181]  [<c012c21a>] ? native_safe_halt+0xa/0x10
      [  194.194268]  [<c010a2f9>] default_idle+0x49/0xb0
      [  194.194277]  [<c0101fcc>] cpu_idle+0x8c/0xd0
      [  194.194286]  [<c05b2431>] rest_init+0x71/0x80
      [  194.194295]  [<c081981a>] start_kernel+0x36e/0x374
      [  194.194305]  [<c08199dd>] ? pass_all_bootoptions+0x0/0xa
      [  194.194314]  [<c08190d7>] i386_start_kernel+0xd7/0xdf
      [  194.194364] panic occurred, switching back to text console
      Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9cf04dcc
    • C
      carl9170: fix typo in PS code · 5820de53
      Christian Lamparter 提交于
      This patch fixes a off-by-one bug which bugged
      the driver's PS-POLL capability.
      
      Cc: <stable@kernel.org>
      Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5820de53
    • V
      net: can: janz-ican3: world-writable sysfs termination file · 1e6d93e4
      Vasiliy Kulikov 提交于
      Don't allow everybody to set terminator via sysfs.
      Signed-off-by: NVasiliy Kulikov <segoon@openwall.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1e6d93e4
    • V
      net: can: at91_can: world-writable sysfs files · fef52b01
      Vasiliy Kulikov 提交于
      Don't allow everybody to write to mb0_id file.
      Signed-off-by: NVasiliy Kulikov <segoon@openwall.com>
      Acked-by: NKurt Van Dijck <kurt.van.dijck@eia.be>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fef52b01
    • A
    • P
      bridge: Don't put partly initialized fdb into hash · 1158f762
      Pavel Emelyanov 提交于
      The fdb_create() puts a new fdb into hash with only addr set. This is
      not good, since there are callers, that search the hash w/o the lock
      and access all the other its fields.
      
      Applies to current netdev tree.
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1158f762
  7. 04 2月, 2011 8 次提交
    • F
      r8169: prevent RxFIFO induced loops in the irq handler. · f60ac8e7
      Francois Romieu 提交于
      While the RxFIFO interruption is masked for most 8168, nothing prevents
      it to appear in the irq status word. This is no excuse to crash.
      Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Cc: Ivan Vecera <ivecera@redhat.com>
      Cc: Hayes <hayeswang@realtek.com>
      f60ac8e7
    • F
      r8169: RxFIFO overflow oddities with 8168 chipsets. · 1519e57f
      Francois Romieu 提交于
      Some experiment-based action to prevent my 8168 chipsets locking-up hard
      in the irq handler under load (pktgen ~1Mpps). Apparently a reset is not
      always mandatory (is it at all ?).
      
      - RTL_GIGA_MAC_VER_12
      - RTL_GIGA_MAC_VER_25
        Missed ~55% packets. Note:
        - this is an old SiS 965L motherboard
        - the 8168 chipset emits (lots of) control frames towards the sender
      
      - RTL_GIGA_MAC_VER_26
        The chipset does not go into a frenzy of mac control pause when it
        crashes yet but it can still be crashed. It needs more work.
      Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Cc: Ivan Vecera <ivecera@redhat.com>
      Cc: Hayes <hayeswang@realtek.com>
      1519e57f
    • I
      r8169: use RxFIFO overflow workaround for 8168c chipset. · b5ba6d12
      Ivan Vecera 提交于
      I found that one of the 8168c chipsets (concretely XID 1c4000c0) starts
      generating RxFIFO overflow errors. The result is an infinite loop in
      interrupt handler as the RxFIFOOver is handled only for ...MAC_VER_11.
      With the workaround everything goes fine.
      Signed-off-by: NIvan Vecera <ivecera@redhat.com>
      Acked-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Cc: Hayes <hayeswang@realtek.com>
      b5ba6d12
    • J
      include/net/genetlink.h: Allow genlmsg_cancel to accept a NULL argument · 38db9e1d
      Julia Lawall 提交于
      nlmsg_cancel can accept NULL as its second argument, so for similarity,
      this patch extends genlmsg_cancel to be able to accept a NULL second
      argument as well.
      Signed-off-by: NJulia Lawall <julia@diku.dk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      38db9e1d
    • D
    • D
      ca6b8bb0
    • D
      net: Fix bug in compat SIOCGETSGCNT handling. · 0033d5ad
      David S. Miller 提交于
      Commit 709b46e8 ("net: Add compat
      ioctl support for the ipv4 multicast ioctl SIOCGETSGCNT") added the
      correct plumbing to handle SIOCGETSGCNT properly.
      
      However, whilst definiting a proper "struct compat_sioc_sg_req" it
      isn't actually used in ipmr_compat_ioctl().
      
      Correct this oversight.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0033d5ad
    • D
      niu: Fix races between up/down and get_stats. · 9690c636
      David S. Miller 提交于
      As reported by Flavio Leitner, there is no synchronization to protect
      NIU's get_stats method from seeing a NULL pointer in either
      np->rx_rings or np->tx_rings.  In fact, as far as ->ndo_get_stats
      is concerned, these values are set completely asynchronously.
      
      Flavio attempted to fix this using a RW semaphore, which in fact
      works most of the time.  However, dev_get_stats() can be invoked
      from non-sleepable contexts in some cases, so this fix doesn't
      work in all cases.
      
      So instead, control the visibility of the np->{rx,tx}_ring pointers
      when the device is being brough up, and use properties of the device
      down sequence to our advantage.
      
      In niu_get_stats(), return immediately if netif_running() is false.
      The device shutdown sequence first marks the device as not running (by
      clearing the __LINK_STATE_START bit), then it performans a
      synchronize_rcu() (in dev_deactive_many()), and then finally it
      invokes the driver ->ndo_stop() method.
      
      This guarentees that all invocations of niu_get_stats() either see
      netif_running() as false, or they see the channel pointers before
      ->ndo_stop() clears them out.
      
      If netif_running() is true, protect against startup races by loading
      the np->{rx,tx}_rings pointer into a local variable, and punting if
      it is NULL.  Use ACCESS_ONCE to prevent the compiler from reloading
      the pointer on us.
      
      Also, during open, control the order in which the pointers and the
      ring counts become visible globally using SMP write memory barriers.
      We make sure the np->num_{rx,tx}_rings value is stable and visible
      before np->{rx,tx}_rings is.
      
      Such visibility control is not necessary on the niu_free_channels()
      side because of the RCU sequencing that happens during device down as
      described above.  We are always guarenteed that all niu_get_stats
      calls are finished, or will see netif_running() false, by the time
      ->ndo_stop is invoked.
      Reported-by: NFlavio Leitner <fleitner@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9690c636