1. 04 Feb, 2011 8 commits
    • Francois Romieu's avatar
      r8169: prevent RxFIFO induced loops in the irq handler. · f60ac8e7
      Francois Romieu authored
      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: default avatarFrancois Romieu <romieu@fr.zoreil.com>
      Cc: Ivan Vecera <ivecera@redhat.com>
      Cc: Hayes <hayeswang@realtek.com>
      f60ac8e7
    • Francois Romieu's avatar
      r8169: RxFIFO overflow oddities with 8168 chipsets. · 1519e57f
      Francois Romieu authored
      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: default avatarFrancois Romieu <romieu@fr.zoreil.com>
      Cc: Ivan Vecera <ivecera@redhat.com>
      Cc: Hayes <hayeswang@realtek.com>
      1519e57f
    • Ivan Vecera's avatar
      r8169: use RxFIFO overflow workaround for 8168c chipset. · b5ba6d12
      Ivan Vecera authored
      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: default avatarIvan Vecera <ivecera@redhat.com>
      Acked-by: default avatarFrancois Romieu <romieu@fr.zoreil.com>
      Cc: Hayes <hayeswang@realtek.com>
      b5ba6d12
    • Julia Lawall's avatar
      include/net/genetlink.h: Allow genlmsg_cancel to accept a NULL argument · 38db9e1d
      Julia Lawall authored
      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: default avatarJulia Lawall <julia@diku.dk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      38db9e1d
    • David S. Miller's avatar
    • David S. Miller's avatar
      ca6b8bb0
    • David S. Miller's avatar
      net: Fix bug in compat SIOCGETSGCNT handling. · 0033d5ad
      David S. Miller authored
      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: default avatarDavid S. Miller <davem@davemloft.net>
      0033d5ad
    • David S. Miller's avatar
      niu: Fix races between up/down and get_stats. · 9690c636
      David S. Miller authored
      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: default avatarFlavio Leitner <fleitner@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9690c636
  2. 02 Feb, 2011 10 commits
  3. 01 Feb, 2011 16 commits
  4. 31 Jan, 2011 6 commits