1. 18 8月, 2006 1 次提交
  2. 14 8月, 2006 1 次提交
  3. 01 7月, 2006 1 次提交
  4. 30 6月, 2006 1 次提交
  5. 26 6月, 2006 1 次提交
  6. 04 5月, 2006 1 次提交
  7. 02 5月, 2006 1 次提交
    • P
      [NETFILTER] x_tables: fix compat related crash on non-x86 · 46c5ea3c
      Patrick McHardy 提交于
      When iptables userspace adds an ipt_standard_target, it calculates the size
      of the entire entry as:
      
      sizeof(struct ipt_entry) + XT_ALIGN(sizeof(struct ipt_standard_target))
      
      ipt_standard_target looks like this:
      
        struct xt_standard_target
        {
              struct xt_entry_target target;
              int verdict;
        };
      
      xt_entry_target contains a pointer, so when compiled for 64 bit the
      structure gets an extra 4 byte of padding at the end. On 32 bit
      architectures where iptables aligns to 8 byte it will also have 4
      byte padding at the end because it is only 36 bytes large.
      
      The compat_ipt_standard_fn in the kernel adjusts the offsets by
      
        sizeof(struct ipt_standard_target) - sizeof(struct compat_ipt_standard_target),
      
      which will always result in 4, even if the structure from userspace
      was already padded to a multiple of 8. On x86 this works out by
      accident because userspace only aligns to 4, on all other
      architectures this is broken and causes incorrect adjustments to
      the size and following offsets.
      
      Thanks to Linus for lots of debugging help and testing.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      46c5ea3c
  8. 11 4月, 2006 1 次提交
  9. 01 4月, 2006 1 次提交
  10. 29 3月, 2006 1 次提交
  11. 23 3月, 2006 1 次提交
  12. 21 3月, 2006 5 次提交
  13. 05 2月, 2006 1 次提交
  14. 13 1月, 2006 1 次提交
    • H
      [NETFILTER] x_tables: Abstraction layer for {ip,ip6,arp}_tables · 2e4e6a17
      Harald Welte 提交于
      This monster-patch tries to do the best job for unifying the data
      structures and backend interfaces for the three evil clones ip_tables,
      ip6_tables and arp_tables.  In an ideal world we would never have
      allowed this kind of copy+paste programming... but well, our world
      isn't (yet?) ideal.
      
      o introduce a new x_tables module
      o {ip,arp,ip6}_tables depend on this x_tables module
      o registration functions for tables, matches and targets are only
        wrappers around x_tables provided functions
      o all matches/targets that are used from ip_tables and ip6_tables
        are now implemented as xt_FOOBAR.c files and provide module aliases
        to ipt_FOOBAR and ip6t_FOOBAR
      o header files for xt_matches are in include/linux/netfilter/,
        include/linux/netfilter_{ipv4,ipv6} contains compatibility wrappers
        around the xt_FOOBAR.h headers
      
      Based on this patchset we're going to further unify the code,
      gradually getting rid of all the layer 3 specific assumptions.
      Signed-off-by: NHarald Welte <laforge@netfilter.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2e4e6a17
  15. 12 1月, 2006 1 次提交
  16. 04 1月, 2006 1 次提交
    • E
      [NETFILTER] ip_tables: NUMA-aware allocation · 31836064
      Eric Dumazet 提交于
      Part of a performance problem with ip_tables is that memory allocation
      is not NUMA aware, but 'only' SMP aware (ie each CPU normally touch
      separate cache lines)
      
      Even with small iptables rules, the cost of this misplacement can be
      high on common workloads.  Instead of using one vmalloc() area
      (located in the node of the iptables process), we now allocate an area
      for each possible CPU, using vmalloc_node() so that memory should be
      allocated in the CPU's node if possible.
      
      Port to arp_tables and ip6_tables by Harald Welte.
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      31836064
  17. 30 11月, 2005 1 次提交
  18. 14 10月, 2005 1 次提交
  19. 30 8月, 2005 2 次提交
    • P
      [NETFILTER]: Add goto target · 05465343
      Patrick McHardy 提交于
      Originally written by Henrik Nordstrom <hno@marasystems.com>, taken
      from netfilter patch-o-matic and added ip6_tables support.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      05465343
    • H
      [NETFILTER]: reduce netfilter sk_buff enlargement · 6869c4d8
      Harald Welte 提交于
      As discussed at netconf'05, we're trying to save every bit in sk_buff.
      The patch below makes sk_buff 8 bytes smaller.  I did some basic
      testing on my notebook and it seems to work.
      
      The only real in-tree user of nfcache was IPVS, who only needs a
      single bit.  Unfortunately I couldn't find some other free bit in
      sk_buff to stuff that bit into, so I introduced a separate field for
      them.  Maybe the IPVS guys can resolve that to further save space.
      
      Initially I wanted to shrink pkt_type to three bits (PACKET_HOST and
      alike are only 6 values defined), but unfortunately the bluetooth code
      overloads pkt_type :(
      
      The conntrack-event-api (out-of-tree) uses nfcache, but Rusty just
      came up with a way how to do it without any skb fields, so it's safe
      to remove it.
      
      - remove all never-implemented 'nfcache' code
      - don't have ipvs code abuse 'nfcache' field. currently get's their own
        compile-conditional skb->ipvs_property field.  IPVS maintainers can
        decide to move this bit elswhere, but nfcache needs to die.
      - remove skb->nfcache field to save 4 bytes
      - move skb->nfctinfo into three unused bits to save further 4 bytes
      Signed-off-by: NHarald Welte <laforge@netfilter.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6869c4d8
  20. 22 6月, 2005 1 次提交
  21. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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