1. 30 10月, 2009 1 次提交
  2. 16 4月, 2009 1 次提交
  3. 14 4月, 2009 1 次提交
  4. 18 3月, 2009 1 次提交
  5. 17 3月, 2009 1 次提交
    • H
      GRO: Move netpoll checks to correct location · d1c76af9
      Herbert Xu 提交于
      As my netpoll fix for net doesn't really work for net-next, we
      need this update to move the checks into the right place.  As it
      stands we may pass freed skbs to netpoll_receive_skb.
      
      This patch also introduces a netpoll_rx_on function to avoid GRO
      completely if we're invoked through netpoll.  This might seem
      paranoid but as netpoll may have an external receive hook it's
      better to be safe than sorry.  I don't think we need this for
      2.6.29 though since there's nothing immediately broken by it.
      
      This patch also moves the GRO_* return values to netdevice.h since
      VLAN needs them too (I tried to avoid this originally but alas
      this seems to be the easiest way out).  This fixes a bug in VLAN
      where it continued to use the old return value 2 instead of the
      correct GRO_DROP.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d1c76af9
  6. 01 3月, 2009 1 次提交
    • H
      netpoll: Add drop checks to all entry points · 4ead4431
      Herbert Xu 提交于
      The netpoll entry checks are required to ensure that we don't
      receive normal packets when invoked via netpoll.  Unfortunately
      it only ever worked for the netif_receive_skb/netif_rx entry
      points.  The VLAN (and subsequently GRO) entry point didn't
      have the check and therefore can trigger all sorts of weird
      problems.
      
      This patch adds the netpoll check to all entry points.
      
      I'm still uneasy with receiving at all under netpoll (which
      apparently is only used by the out-of-tree kdump code).  The
      reason is it is perfectly legal to receive all data including
      headers into highmem if netpoll is off, but if you try to do
      that with netpoll on and someone gets a printk in an IRQ handler                                             
      you're going to get a nice BUG_ON.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4ead4431
  7. 09 2月, 2009 1 次提交
  8. 30 1月, 2009 2 次提交
  9. 27 1月, 2009 1 次提交
  10. 07 1月, 2009 1 次提交
    • H
      vlan: Add GRO interfaces · e1c096e2
      Herbert Xu 提交于
      This patch adds GRO interfaces for hardware-assisted VLAN reception.
      With this in place we're now at parity with LRO as far as the
      interface is concerned.  That is, you can now take any LRO driver
      and convert it over to GRO.
      
      As the CB memory clashes with GRO's use of CB, I've removed it
      entirely by storing dev in skb->dev.  This is OK because VLAN
      gets called first thing in netif_receive_skb and skb->dev is
      not used in between us calling netif_rx and netif_receive_skb
      getting called.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e1c096e2
  11. 05 11月, 2008 1 次提交
    • P
      net: fix packet socket delivery in rx irq handler · 9b22ea56
      Patrick McHardy 提交于
      The changes to deliver hardware accelerated VLAN packets to packet
      sockets (commit bc1d0411) caused a warning for non-NAPI drivers.
      The __vlan_hwaccel_rx() function is called directly from the drivers
      RX function, for non-NAPI drivers that means its still in RX IRQ
      context:
      
      [   27.779463] ------------[ cut here ]------------
      [   27.779509] WARNING: at kernel/softirq.c:136 local_bh_enable+0x37/0x81()
      ...
      [   27.782520]  [<c0264755>] netif_nit_deliver+0x5b/0x75
      [   27.782590]  [<c02bba83>] __vlan_hwaccel_rx+0x79/0x162
      [   27.782664]  [<f8851c1d>] atl1_intr+0x9a9/0xa7c [atl1]
      [   27.782738]  [<c0155b17>] handle_IRQ_event+0x23/0x51
      [   27.782808]  [<c015692e>] handle_edge_irq+0xc2/0x102
      [   27.782878]  [<c0105fd5>] do_IRQ+0x4d/0x64
      
      Split hardware accelerated VLAN reception into two parts to fix this:
      
      - __vlan_hwaccel_rx just stores the VLAN TCI and performs the VLAN
        device lookup, then calls netif_receive_skb()/netif_rx()
      
      - vlan_hwaccel_do_receive(), which is invoked by netif_receive_skb()
        in softirq context, performs the real reception and delivery to
        packet sockets.
      Reported-and-tested-by: NRamon Casellas <ramon.casellas@cttc.es>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9b22ea56
  12. 04 11月, 2008 1 次提交
  13. 15 7月, 2008 1 次提交
  14. 08 7月, 2008 3 次提交