1. 29 1月, 2008 2 次提交
  2. 24 10月, 2007 1 次提交
  3. 11 10月, 2007 2 次提交
    • R
      [NET]: Nuke SET_MODULE_OWNER macro. · 10d024c1
      Ralf Baechle 提交于
      It's been a useless no-op for long enough in 2.6 so I figured it's time to
      remove it.  The number of people that could object because they're
      maintaining unified 2.4 and 2.6 drivers is probably rather small.
      
      [ Handled drivers added by netdev tree and some missed IRDA cases... -DaveM ]
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      10d024c1
    • E
      [NET]: Make the device list and device lookups per namespace. · 881d966b
      Eric W. Biederman 提交于
      This patch makes most of the generic device layer network
      namespace safe.  This patch makes dev_base_head a
      network namespace variable, and then it picks up
      a few associated variables.  The functions:
      dev_getbyhwaddr
      dev_getfirsthwbytype
      dev_get_by_flags
      dev_get_by_name
      __dev_get_by_name
      dev_get_by_index
      __dev_get_by_index
      dev_ioctl
      dev_ethtool
      dev_load
      wireless_process_ioctl
      
      were modified to take a network namespace argument, and
      deal with it.
      
      vlan_ioctl_set and brioctl_set were modified so their
      hooks will receive a network namespace argument.
      
      So basically anthing in the core of the network stack that was
      affected to by the change of dev_base was modified to handle
      multiple network namespaces.  The rest of the network stack was
      simply modified to explicitly use &init_net the initial network
      namespace.  This can be fixed when those components of the network
      stack are modified to handle multiple network namespaces.
      
      For now the ifindex generator is left global.
      
      Fundametally ifindex numbers are per namespace, or else
      we will have corner case problems with migration when
      we get that far.
      
      At the same time there are assumptions in the network stack
      that the ifindex of a network device won't change.  Making
      the ifindex number global seems a good compromise until
      the network stack can cope with ifindex changes when
      you change namespaces, and the like.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      881d966b
  4. 11 7月, 2007 1 次提交
  5. 26 4月, 2007 6 次提交
  6. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau 提交于
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
      recently, it makes sense again to remove other superfluous sched.h includes.
      There are quite a lot of files which include it but don't actually need
      anything defined in there.  Presumably these includes were once needed for
      macros that used to live in sched.h, but moved to other header files in the
      course of cleaning it up.
      
      To ease the pain, this time I did not fiddle with any header files and only
      removed #includes from .c-files, which tend to cause less trouble.
      
      Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
      arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
      allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
      configs in arch/arm/configs on arm.  I also checked that no new warnings were
      introduced by the patch (actually, some warnings are removed that were emitted
      by unnecessarily included header files).
      Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  7. 14 2月, 2007 1 次提交
  8. 11 2月, 2007 1 次提交
  9. 09 2月, 2007 1 次提交
  10. 03 12月, 2006 1 次提交
  11. 23 9月, 2006 1 次提交
    • A
      [IPV4]: ipip and ip_gre encapsulation bugs · c55e2f49
      Al Viro 提交于
      Handling of ipip and ip_gre ICMP error relaying is b0rken; it accesses
      8bit field + 3 reserved octets as host-endian 32bit, does comparison,
      subtraction and stuffs the result back.  That breaks on big-endian.
      
      Fixed, made endian-clean.
      
      [ Note that this effected code is permanently commented out with
        and ifdef, so this error couldn't actually cause problems for
        anyone. -DaveM ]
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c55e2f49
  12. 22 7月, 2006 1 次提交
  13. 01 7月, 2006 1 次提交
  14. 10 4月, 2006 1 次提交
    • H
      [INET]: Move no-tunnel ICMP error to tunnel4/tunnel6 · 50fba2aa
      Herbert Xu 提交于
      This patch moves the sending of ICMP messages when there are no IPv4/IPv6
      tunnels present to tunnel4/tunnel6 respectively.  Please note that for now
      if xfrm4_tunnel/xfrm6_tunnel is loaded then no ICMP messages will ever be
      sent.  This is similar to how we handle AH/ESP/IPCOMP.
      
      This move fixes the bug where we always send an ICMP message when there is
      no ip6_tunnel device present for a given packet even if it is later handled
      by IPsec.  It also causes ICMP messages to be sent when no IPIP tunnel is
      present.
      
      I've decided to use the "port unreachable" ICMP message over the current
      value of "address unreachable" (and "protocol unreachable" by GRE) because
      it is not ambiguous unlike the other ones which can be triggered by other
      conditions.  There seems to be no standard specifying what value must be
      used so this change should be OK.  In fact we should change GRE to use
      this value as well.
      
      Incidentally, this patch also fixes a fairly serious bug in xfrm6_tunnel
      where we don't check whether the embedded IPv6 header is present before
      dereferencing it for the inside source address.
      
      This patch is inspired by a previous patch by Hugo Santos <hsantos@av.it.pt>.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      50fba2aa
  15. 29 3月, 2006 1 次提交
    • H
      [INET]: Introduce tunnel4/tunnel6 · d2acc347
      Herbert Xu 提交于
      Basically this patch moves the generic tunnel protocol stuff out of
      xfrm4_tunnel/xfrm6_tunnel and moves it into the new files of tunnel4.c
      and tunnel6 respectively.
      
      The reason for this is that the problem that Hugo uncovered is only
      the tip of the iceberg.  The real problem is that when we removed the
      dependency of ipip on xfrm4_tunnel we didn't really consider the module
      case at all.
      
      For instance, as it is it's possible to build both ipip and xfrm4_tunnel
      as modules and if the latter is loaded then ipip simply won't load.
      
      After considering the alternatives I've decided that the best way out of
      this is to restore the dependency of ipip on the non-xfrm-specific part
      of xfrm4_tunnel.  This is acceptable IMHO because the intention of the
      removal was really to be able to use ipip without the xfrm subsystem.
      This is still preserved by this patch.
      
      So now both ipip/xfrm4_tunnel depend on the new tunnel4.c which handles
      the arbitration between the two.  The order of processing is determined
      by a simple integer which ensures that ipip gets processed before
      xfrm4_tunnel.
      
      The situation for ICMP handling is a little bit more complicated since
      we may not have enough information to determine who it's for.  It's not
      a big deal at the moment since the xfrm ICMP handlers are basically
      no-ops.  In future we can deal with this when we look at ICMP caching
      in general.
      
      The user-visible change to this is the removal of the TUNNEL Kconfig
      prompts.  This makes sense because it can only be used through IPCOMP
      as it stands.
      
      The addition of the new modules shouldn't introduce any problems since
      module dependency will cause them to be loaded.
      
      Oh and I also turned some unnecessary pskb's in IPv6 related to this
      patch to skb's.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d2acc347
  16. 16 2月, 2006 1 次提交
    • P
      [XFRM]: Fix SNAT-related crash in xfrm4_output_finish · 48d5cad8
      Patrick McHardy 提交于
      When a packet matching an IPsec policy is SNATed so it doesn't match any
      policy anymore it looses its xfrm bundle, which makes xfrm4_output_finish
      crash because of a NULL pointer dereference.
      
      This patch directs these packets to the original output path instead. Since
      the packets have already passed the POST_ROUTING hook, but need to start at
      the beginning of the original output path which includes another
      POST_ROUTING invocation, a flag is added to the IPCB to indicate that the
      packet was rerouted and doesn't need to pass the POST_ROUTING hook again.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      48d5cad8
  17. 12 1月, 2006 1 次提交
  18. 10 1月, 2006 1 次提交
  19. 08 1月, 2006 2 次提交
  20. 06 1月, 2006 1 次提交
  21. 31 7月, 2005 1 次提交
  22. 20 7月, 2005 1 次提交
  23. 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