12 Jul, 2016

1 commit

  • Using a combination if #if conditionals and goto labels to unwind
    tunnel4_init seems unwieldy. This patch takes a simpler approach of
    directly unregistering previously registered protocols when an error
    occurs.

    This fixes a number of problems with the current implementation
    including the potential presence of labels when they are unused
    and the potential absence of unregister code when it is needed.

    Fixes: 8afe97e5d416 ("tunnels: support MPLS over IPv4 tunnels")
    Signed-off-by: Simon Horman
    Signed-off-by: David S. Miller

    Simon Horman
     

10 Jul, 2016

1 commit

  • Extend tunnel support to MPLS over IPv4. The implementation extends the
    existing differentiation between IPIP and IPv6 over IPv4 to also cover MPLS
    over IPv4.

    Signed-off-by: Simon Horman
    Reviewed-by: Dinan Gunawardena
    Signed-off-by: David S. Miller

    Simon Horman
     

12 Mar, 2012

1 commit

  • Use a more current kernel messaging style.

    Convert a printk block to print_hex_dump.
    Coalesce formats, align arguments.
    Use %s, __func__ instead of embedding function names.

    Some messages that were prefixed with _close are
    now prefixed with _fini. Some ah4 and esp messages
    are now not prefixed with "ip ".

    The intent of this patch is to later add something like
    #define pr_fmt(fmt) "IPv4: " fmt.
    to standardize the output messages.

    Text size is trivially reduced. (x86-32 allyesconfig)

    $ size net/ipv4/built-in.o*
    text data bss dec hex filename
    887888 31558 249696 1169142 11d6f6 net/ipv4/built-in.o.new
    887934 31558 249800 1169292 11d78c net/ipv4/built-in.o.old

    Signed-off-by: Joe Perches
    Signed-off-by: David S. Miller

    Joe Perches
     

12 Dec, 2011

1 commit


28 Oct, 2010

1 commit

  • Add __rcu annotations to :
    (struct ip_tunnel)->prl
    (struct ip_tunnel_prl_entry)->next
    (struct xfrm_tunnel)->next
    struct xfrm_tunnel *tunnel4_handlers
    struct xfrm_tunnel *tunnel64_handlers

    And use appropriate rcu primitives to reduce sparse warnings if
    CONFIG_SPARSE_RCU_POINTER=y

    Signed-off-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Eric Dumazet
     

10 Sep, 2010

1 commit

  • xfrm4_tunnel_register() & xfrm6_tunnel_register() should
    use rcu_assign_pointer() to make sure previous writes
    (to handler->next) are committed to memory before chain
    insertion.

    deregister functions dont need a particular barrier.

    Signed-off-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Eric Dumazet
     

02 Sep, 2010

1 commit

  • tunnel4_handlers, tunnel64_handlers, tunnel6_handlers and
    tunnel46_handlers are protected by RCU, but we dont use appropriate rcu
    primitives to scan them. rcu_lock() is already held by caller.

    Signed-off-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Eric Dumazet
     

31 Aug, 2010

1 commit


13 Jul, 2010

1 commit


30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

15 Sep, 2009

1 commit


05 Jun, 2008

1 commit


16 Apr, 2008

2 commits


11 Nov, 2007

2 commits

  • Both check for the family to select an appropriate tunnel list.
    Consolidate this check and make the for() loop more readable.

    Signed-off-by: Pavel Emelyanov
    Signed-off-by: David S. Miller

    Pavel Emelyanov
     
  • The tunnel64_protocol uses the tunnel4_protocol's err_handler and
    thus calls the tunnel4_protocol's handlers.

    This is not very good, as in case of (icmp) error the wrong error
    handlers will be called (e.g. ipip ones instead of sit) and this
    won't be noticed at all, because the error is not reported.

    Signed-off-by: Pavel Emelyanov
    Signed-off-by: David S. Miller

    Pavel Emelyanov
     

14 Feb, 2007

1 commit


10 Apr, 2006

1 commit

  • 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 .

    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     

29 Mar, 2006

1 commit

  • 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: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu