1. 28 Feb, 2010 3 commits
  2. 13 Aug, 2009 1 commit
  3. 09 Feb, 2009 1 commit
    • Herbert Xu's avatar
      bridge: Fix LRO crash with tun · 4906f998
      Herbert Xu authored
      
      
      > Kernel BUG at drivers/net/tun.c:444
      > invalid opcode: 0000 [1] SMP
      > last sysfs file: /class/net/lo/ifindex
      > CPU 0
      > Modules linked in: tun ipt_MASQUERADE iptable_nat ip_nat xt_state ip_conntrack
      > nfnetlink ipt_REJECT xt_tcpudp iptable_filter d
      > Pid: 6912, comm: qemu-kvm Tainted: G      2.6.18-128.el5 #1
      > RIP: 0010:[<ffffffff886f57b0>]  [<ffffffff886f57b0>]
      > :tun:tun_chr_readv+0x2b1/0x3a6
      > RSP: 0018:ffff8102202c5e48  EFLAGS: 00010246
      > RAX: 0000000000000000 RBX: ffff8102202c5e98 RCX: 0000000004010000
      > RDX: ffff810227063680 RSI: ffff8102202c5e9e RDI: ffff8102202c5e92
      > RBP: 0000000000010ff6 R08: 0000000000000000 R09: 0000000000000001
      > R10: ffff8102202c5e94 R11: 0000000000000202 R12: ffff8102275357c0
      > R13: ffff81022755e500 R14: 0000000000000000 R15: ffff8102202c5ef8
      > FS:  00002ae4398db980(0000) GS:ffffffff803ac000(0000) knlGS:0000000000000000
      > CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      > CR2: 00002ae4ab514000 CR3: 0000000221344000 CR4: 00000000000026e0
      > Process qemu-kvm (pid: 6912, threadinfo ffff8102202c4000, task
      > ffff81022e58d820)
      > Stack:  00000000498735cb ffff810229d1a3c0 0000000000000000 ffff81022e58d820
      >  ffffffff8008a461 ffff81022755e528 ffff81022755e528 ffffffff8009f925
      >  000005ea05ea0000 ffff8102209d0000 00001051143e1600 ffffffff8003c00e
      > Call Trace:
      >  [<ffffffff8008a461>] default_wake_function+0x0/0xe
      >  [<ffffffff8009f925>] enqueue_hrtimer+0x55/0x70
      >  [<ffffffff8003c00e>] hrtimer_start+0xbc/0xce
      >  [<ffffffff886f58bf>] :tun:tun_chr_read+0x1a/0x1f
      >  [<ffffffff8000b3f3>] vfs_read+0xcb/0x171
      >  [<ffffffff800117d4>] sys_read+0x45/0x6e
      >  [<ffffffff8005d116>] system_call+0x7e/0x83
      >
      >
      > Code: 0f 0b 68 40 62 6f 88 c2 bc 01 f6 42 0a 08 74 0c 80 4c 24 41
      > RIP  [<ffffffff886f57b0>] :tun:tun_chr_readv+0x2b1/0x3a6
      >  RSP <ffff8102202c5e48>
      >  <0>Kernel panic - not syncing: Fatal exception
      
      This crashed when an LRO packet generated by bnx2x reached a
      tun device through the bridge.  We're supposed to drop it at
      the bridge.  However, because the check was placed in br_forward
      instead of __br_forward, it's only effective if we are sending
      the packet through a single port.
      
      This patch fixes it by moving the check into __br_forward.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4906f998
  4. 19 Jun, 2008 1 commit
  5. 12 Jun, 2008 1 commit
  6. 21 May, 2008 1 commit
  7. 16 Sep, 2007 1 commit
  8. 26 Apr, 2007 1 commit
    • Herbert Xu's avatar
      [NET]: Allow forwarding of ip_summed except CHECKSUM_COMPLETE · 35fc92a9
      Herbert Xu authored
      
      
      Right now Xen has a horrible hack that lets it forward packets with
      partial checksums.  One of the reasons that CHECKSUM_PARTIAL and
      CHECKSUM_COMPLETE were added is so that we can get rid of this hack
      (where it creates two extra bits in the skbuff to essentially mirror
      ip_summed without being destroyed by the forwarding code).
      
      I had forgotten that I've already gone through all the deivce drivers
      last time around to make sure that they're looking at ip_summed ==
      CHECKSUM_PARTIAL rather than ip_summed != 0 on transmit.  In any case,
      I've now done that again so it should definitely be safe.
      
      Unfortunately nobody has yet added any code to update CHECKSUM_COMPLETE
      values on forward so we I'm setting that to CHECKSUM_NONE.  This should
      be safe to remove for bridging but I'd like to check that code path
      first.
      
      So here is the patch that lets us get rid of the hack by preserving
      ip_summed (mostly) on forwarded packets.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      35fc92a9
  9. 11 Feb, 2007 1 commit
  10. 22 Sep, 2006 1 commit
  11. 27 Aug, 2006 1 commit
  12. 08 Jul, 2006 1 commit
  13. 23 Jun, 2006 1 commit
    • Herbert Xu's avatar
      [NET]: Merge TSO/UFO fields in sk_buff · 7967168c
      Herbert Xu authored
      
      
      Having separate fields in sk_buff for TSO/UFO (tso_size/ufo_size) is not
      going to scale if we add any more segmentation methods (e.g., DCCP).  So
      let's merge them.
      
      They were used to tell the protocol of a packet.  This function has been
      subsumed by the new gso_type field.  This is essentially a set of netdev
      feature bits (shifted by 16 bits) that are required to process a specific
      skb.  As such it's easy to tell whether a given device can process a GSO
      skb: you just have to and the gso_type field and the netdev's features
      field.
      
      I've made gso_type a conjunction.  The idea is that you have a base type
      (e.g., SKB_GSO_TCPV4) that can be modified further to support new features.
      For example, if we add a hardware TSO type that supports ECN, they would
      declare NETIF_F_TSO | NETIF_F_TSO_ECN.  All TSO packets with CWR set would
      have a gso_type of SKB_GSO_TCPV4 | SKB_GSO_TCPV4_ECN while all other TSO
      packets would be SKB_GSO_TCPV4.  This means that only the CWR packets need
      to be emulated in software.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7967168c
  14. 18 Jun, 2006 1 commit
  15. 26 Apr, 2006 1 commit
  16. 23 Sep, 2005 1 commit
  17. 21 Jun, 2005 1 commit
  18. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4